NGW100 LCD interface

Log in or register to post comments
Go To Last Post
9 posts / 0 new
Author
Message
SimonFisher
SimonFisher's picture
Level: Wannabe
Joined: Sun. Sep 2, 2001
Posts: 86 View posts
Location: Swansea UK
#1
Posted by SimonFisher: Sun. May 13, 2007 - 11:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi, has anyone got the LCD interface on the NGW100 working? I've compiled a kernal with the LCD options included, but it stops the MMC operating, also the error below

pio: invalid pin 128
Stack: (0x901f5f40 to 0x901f6000)
5f40: 900106f6 901f5f54 00000000 00000000 00000000 90002966 901f5f68 00000000
5f60: 00000000 00000000 90002fd6 901f5f8c 00000000 9000bbe0 00000000 00000000
5f80: 90017ad8 9000e5dc 00000000 900034f8 901f5fa0 9000bc18 00000000 00000000
5fa0: 9000e63a 901f5fdc 9000ba18 9000d5ac 00000000 00000000 00400000 90011474
5fc0: 90011474 901f6000 00000000 00000000 00000000 00000000 00000000 90017ad8
5fe0: 00000000 00000000 00000000 00000000 00000000 90017ad8 9000e5dc 00000000
Call trace:
[<900106e4>] show_stack+0x3c/0x44
[<900106f6>] dump_stack+0xa/0xc
[<90002966>] at32_select_gpio+0xba/0xc4
[<90002fd6>] at32_add_device_mmci+0x62/0x8c
[<900034f8>] atngw_init+0x4c/0x60
[<9000e63a>] init+0x5e/0x1c0
[<90017ad8>] do_exit+0x0/0x598

.....

probing modules ... vfat failed, mmc_block failed, atmel-mci failed
, [ OK ]

Is there a step by step on how to add LCD support to the NGW100? I note from the wiki that some LCD signals are used by the MMC interface.

Tags:

AVR Microcontrollers, AVR UC3
Top
squidgit
squidgit's picture
Level: Raving Lunatic
Joined: Sun. Sep 14, 2003
Posts: 4228 View posts
Location: Queanbeyan, Australia
Posted by squidgit: Mon. May 14, 2007 - 03:15 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

All the board setup code in the Linux kernel lives at arch/avr32/boards/atngw100/setup.c. In the atngw100_init function you will need to remove the code to set up the MMCI or at least set the GPIO descriptors in the mmc info structure up the top to GPIO_PIN_NONE. This will prevent the signal clash.

MMCI will still work with GPIO_PIN_NONE descriptors, this is how the STK1000 runs, it just obviously will have to assume the card is always inserted and never write-protected. This isn't as dangerous as it sounds, it just means an operation on an empty socket will be more noisy and nasty than it would be if the MMCI actually knew there wasn't a card there. (as opposed to assuming there is a card there but it's horked)

Of course if you're LCD implementation actually requires the LCD_CC and/or LCD_PWR signals which are routed to the MMC socket, you'll have to do a little Frankensteining.

-S.

Blag: http://www.niasdigital.com/blag

Top
SimonFisher
SimonFisher's picture
Level: Wannabe
Joined: Sun. Sep 2, 2001
Posts: 86 View posts
Location: Swansea UK
Posted by SimonFisher: Mon. May 14, 2007 - 12:07 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the reply. Looking at the arch/avr32/boards/atngw100/setup.c file and the corresponding atstk1000 file, I may have to copy some LCD init code from the stk1000 into the atngw100 setup.c file.

Thanks for bringing that to my attention!

Top
squidgit
squidgit's picture
Level: Raving Lunatic
Joined: Sun. Sep 14, 2003
Posts: 4228 View posts
Location: Queanbeyan, Australia
Posted by squidgit: Mon. May 14, 2007 - 01:09 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No probs occourse! Note that you'll also want to add an fbmem=900k or similar entry to your bootargs from uboot. The default fbmem allocation is only good for 320x240 @ 1bpp. Or 1 byte per pixel. Something small anyways.

-S.

Blag: http://www.niasdigital.com/blag

Top
ttyridal
ttyridal's picture
Level: Hangaround
Joined: Thu. Feb 3, 2005
Posts: 102 View posts
Location: Oslo, No
Posted by ttyridal: Mon. May 14, 2007 - 03:03 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Another thing, If you are connecting the LCD to the expansion header (as opposed to de-soldering the ethernet phy and more) it is not the same pins as the STK1000, but the "alternate routing"

Haven't tried it, but my guess is that you'll have to adjust for this in the setup code.

Top
how
how's picture
Level: Posting Freak
Joined: Wed. Apr 26, 2006
Posts: 1079 View posts
Location: Trondheim, Norway
Posted by how: Mon. May 14, 2007 - 03:05 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah, the default fbmem allocation in the sidsafb driver is a bit crappy. FWIW it is much better in the new atmel_lcdfb driver that was posted to linux-kernel by Nicolas Ferre, and which will replace sidsafb in future kernels.

Top
squidgit
squidgit's picture
Level: Raving Lunatic
Joined: Sun. Sep 14, 2003
Posts: 4228 View posts
Location: Queanbeyan, Australia
Posted by squidgit: Tue. May 15, 2007 - 01:10 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ah great, so that is going to be/ has been merged? It has a _much_ better interface for adding support for different LCDs too. Moved the board specific data to the board specific files which is always nice.

Blag: http://www.niasdigital.com/blag

Top
squidgit
squidgit's picture
Level: Raving Lunatic
Joined: Sun. Sep 14, 2003
Posts: 4228 View posts
Location: Queanbeyan, Australia
Posted by squidgit: Tue. May 15, 2007 - 01:16 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ttyridal wrote:
Another thing, If you are connecting the LCD to the expansion header (as opposed to de-soldering the ethernet phy and more) it is not the same pins as the STK1000, but the "alternate routing"

Haven't tried it, but my guess is that you'll have to adjust for this in the setup code.

Very true, you'll find the code in question in arch/avr32/mach-at32ap/at32ap7000.c. Only the stk1000-style routing is set up. Might be worth adding an extra parameter to the at32_add_device_lcdc() call which reserves the alternate routing.

In fact I suppose this is a more general problem, most of the peripherals have alternate routings available but not supported in at32ap7000.c. Any big-picture plans for this anyone? [looking at how ;) ]

-S.

Blag: http://www.niasdigital.com/blag

Top
SimonFisher
SimonFisher's picture
Level: Wannabe
Joined: Sun. Sep 2, 2001
Posts: 86 View posts
Location: Swansea UK
Posted by SimonFisher: Tue. May 15, 2007 - 10:12 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'd go along with that. I would also extend that to allow other configurations, as I'm using a Hitachi TFT that only uses dclk and drdy, and I'd like to keep the MMC wp and present inputs!

Top