diff mbox

OMAP_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)

Message ID 20090506224917.GS5593@atomide.com (mailing list archive)
State Superseded, archived
Headers show

Commit Message

Tony Lindgren May 6, 2009, 10:49 p.m. UTC
* Tony Lindgren <tony@atomide.com> [090505 21:00]:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [090505 12:52]:
> > On Tue, Apr 28, 2009 at 03:42:37PM -0700, Tony Lindgren wrote:
> > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [090428 15:07]:
> > > > Tony, et.al.,
> > > > 
> > > > Any ideas when more LDP support will be pushed into mainline (such as
> > > > the framebuffer support)?
> > > 
> > > I'll be looking at the board-*.c patches for the next merge window
> > > hopefully this week or next week.
> > > 
> > > Looks like LDP keyboard, touchscreen & RTC are pretty much ready
> > > to go. Then the MMC has some regulator updates, but AFAIK the MMC
> > > should work OK already.
> > > 
> > > For the framebuffer, Imre and Tomi know the status the best, so
> > > I've added them to Cc.
> > > 
> > > Imre has been meaning to send a bunch of drivers/video/omap changes
> > > to the fbdev list for a while now and LDP framebuffer may depend on
> > > those. Imre, any news on the status of sending the fb patches
> > > upstream?
> > > 
> > > Then there are the upcoming DSS patches from Tomi, but those still
> > > need some work before they're ready to go.
> > 
> > Is there any news on this?  Will we see more functional OMAP3 / LDP
> > support queued for the next merge window?
> 
> Yes fro the stuff listed above, but still no news on the framebuffer
> patches. Imre?

Added Stanley Miao to Cc. Here's an updated version of Stanley's patch to
add fb support for LDP.

I don't have an LDP, maybe you guys can give it a try against the mainline
kernel and see if it works! There might be some changes needed to 
drivers/video/omap/dispc.c too.. And those should be handled by Imre.

But if this works, at least we can then add support for few more boards
easily while waiting for Imre to send his updates.

Cheers,

Tony

Comments

stanley.miao May 7, 2009, 3:01 p.m. UTC | #1
Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [090505 21:00]:
>   
>> * Russell King - ARM Linux <linux@arm.linux.org.uk> [090505 12:52]:
>>     
>>> On Tue, Apr 28, 2009 at 03:42:37PM -0700, Tony Lindgren wrote:
>>>       
>>>> * Russell King - ARM Linux <linux@arm.linux.org.uk> [090428 15:07]:
>>>>         
>>>>> Tony, et.al.,
>>>>>
>>>>> Any ideas when more LDP support will be pushed into mainline (such as
>>>>> the framebuffer support)?
>>>>>           
>>>> I'll be looking at the board-*.c patches for the next merge window
>>>> hopefully this week or next week.
>>>>
>>>> Looks like LDP keyboard, touchscreen & RTC are pretty much ready
>>>> to go. Then the MMC has some regulator updates, but AFAIK the MMC
>>>> should work OK already.
>>>>
>>>> For the framebuffer, Imre and Tomi know the status the best, so
>>>> I've added them to Cc.
>>>>
>>>> Imre has been meaning to send a bunch of drivers/video/omap changes
>>>> to the fbdev list for a while now and LDP framebuffer may depend on
>>>> those. Imre, any news on the status of sending the fb patches
>>>> upstream?
>>>>
>>>> Then there are the upcoming DSS patches from Tomi, but those still
>>>> need some work before they're ready to go.
>>>>         
>>> Is there any news on this?  Will we see more functional OMAP3 / LDP
>>> support queued for the next merge window?
>>>       
>> Yes fro the stuff listed above, but still no news on the framebuffer
>> patches. Imre?
>>     
>
> Added Stanley Miao to Cc. Here's an updated version of Stanley's patch to
> add fb support for LDP.
>
> I don't have an LDP, maybe you guys can give it a try against the mainline
> kernel and see if it works! There might be some changes needed to 
> drivers/video/omap/dispc.c too.. And those should be handled by Imre.
>
> But if this works, at least we can then add support for few more boards
> easily while waiting for Imre to send his updates.
>   
Hi, Tony,

Now the kernel can't boot on LDP. The attached file is the boot log.

I will check it when I have  time.

Stanley.

> Cheers,
>
> Tony 
>   

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Russell King - ARM Linux May 7, 2009, 4:19 p.m. UTC | #2
On Thu, May 07, 2009 at 11:01:35PM +0800, stanley.miao wrote:
> Hi, Tony,
>
> Now the kernel can't boot on LDP. The attached file is the boot log.

No boot log found.

My master branch, based upon 2.6.29-rc3 boots fine on the LDP.

Uncompressing Linux.............................................................
............................................ done, booting the kernel.
Linux version 2.6.29-rc3 (rmk@dyn-67.arm.linux.org.uk) (gcc version 4.3.2 (GCC)) #125 Mon Feb 2 22:22:54 GMT 2009
CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=10c5387f
CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: OMAP LDP board
Memory policy: ECC disabled, Data cache writeback
OMAP3430 ES2.1
SRAM: Mapped pa 0x40200000 to va 0xd7000000 size: 0x100000
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32512
Kernel command line: console=ttyS2,115200n8 noinitrd mem=128M root=/dev/mmcblk0p2 rw ip=none rootdelay=2 video=omap24xxfb:rotation=270
Clocking rate (Crystal/DPLL/ARM core): 26.0/266/500 MHz
GPMC revision 5.0
IRQ: Found an INTC at 0xd8200000 (revision 4.0) with 96 interrupts
Total of 96 interrupts on 1 active controller
OMAP34xx GPIO hardware version 2.5
PID hash table entries: 512 (order: 9, 2048 bytes)
Console: colour dummy device 80x30
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 128MB = 128MB total
Memory: 126292KB available (2964K code, 372K data, 120K init)
Calibrating delay loop... 498.87 BogoMIPS (lpj=1945600)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
net_namespace: 296 bytes
NET: Registered protocol family 16
OMAP DMA hardware revision 4.0
USB: No board-specific platform config found
bio: create slab <bio-0> at 0
SCSI subsystem initialized
i2c_omap i2c_omap.1: bus 1 rev3.12 at 2600 kHz
twl4030: PIH (irq 7) chaining IRQs 368..375
twl4030: power (irq 373) chaining IRQs 376..383
twl4030: gpio (irq 368) chaining IRQs 384..401
i2c_omap i2c_omap.2: bus 2 rev3.12 at 400 kHz
i2c_omap i2c_omap.3: bus 3 rev3.12 at 400 kHz
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP reno registered
NET: Registered protocol family 1
NetWinder Floating Point Emulator V0.97 (double precision)
VFS: Disk quotas dquot_6.5.2
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
msgmni has been set to 246
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
omapfb: configured for panel ldp
omapfb: DISPC version 3.0 initialized
omapfb: Framebuffer initialized. Total vram 614400 planes 1
omapfb: Pixclock 32000 kHz hfreq 60.3 kHz vfreq 93.7 Hz
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
serial8250.0: ttyS0 at MMIO 0x4806a000 (irq = 72) is a ST16654
serial8250.0: ttyS1 at MMIO 0x4806c000 (irq = 73) is a ST16654
serial8250.0: ttyS2 at MMIO 0x49020000 (irq = 74) is a ST16654
console [ttyS2] enabled
brd: module loaded
loop: module loaded
smsc911x: Driver version 2008-10-21.
smsc911x-mdio: probed
eth0: attached PHY driver [Generic PHY] (mii_bus:phy_addr=ffffffff:01, irq=-1)
net eth0: MAC Address: 00:08:ee:02:24:b2
Driver 'sd' needs updating - please use bus_type methods
twl4030_rtc twl4030_rtc: rtc core: registered twl4030_rtc as rtc0
twl4030_rtc twl4030_rtc: Power up reset detected.
twl4030_rtc twl4030_rtc: Enabling TWL4030-RTC.
i2c /dev entries driver
Driver for 1-wire Dallas network protocol.
OMAP Watchdog Timer Rev 0x31: initial timeout 60 sec
mmci-omap-hs mmci-omap-hs.0: Failed to get debounce clock
Advanced Linux Sound Architecture Driver Version 1.0.18a.
No device for DAI AD73311
No device for DAI AK4535
No device for DAI CS4270
No device for DAI PCM3008 HiFi
No device for DAI SSM2602
No device for DAI tlv320aic23
No device for DAI tlv320aic3x
No device for DAI twl4030
No device for DAI UDA134X
No device for DAI UDA1380
No device for DAI UDA1380
No device for DAI UDA1380
No device for DAI WM8510 HiFi
No device for DAI WM8580 PAIFRX
No device for DAI WM8580 PAIFTX
No device for DAI WM8728
No device for DAI WM8731
No device for DAI WM8750
No device for DAI WM8971
No device for DAI WM8990 ADC/DAC Primary
ALSA device list:
  No soundcards found.
TCP cubic registered
NET: Registered protocol family 17
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 1
twl4030_rtc twl4030_rtc: setting system clock to 2000-01-01 00:00:00 UTC (946684800)
Waiting 2sec before mounting root device...
mmc0: host does not support reading read-only switch. assuming write-enable.
mmc0: new high speed SD card at address 0002
mmcblk0: mmc0:0002 00000 971 MiB 
 mmcblk0: p1 p2
kjournald starting.  Commit interval 5 seconds
EXT3-fs warning: mounting fs with errors, running e2fsck is recommended
EXT3 FS on mmcblk0p2, internal journal
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) on device 179:2.
Freeing init memory: 120K
INIT: version 2.86 booting
.udev/ already exists on the static /dev!
Starting the hotplug events dispatcher udevd
Synthesizing the initial hotplug events
...
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Tony Lindgren May 7, 2009, 4:28 p.m. UTC | #3
* Russell King - ARM Linux <linux@arm.linux.org.uk> [090507 09:19]:
> On Thu, May 07, 2009 at 11:01:35PM +0800, stanley.miao wrote:
> > Hi, Tony,
> >
> > Now the kernel can't boot on LDP. The attached file is the boot log.
> 
> No boot log found.
> 
> My master branch, based upon 2.6.29-rc3 boots fine on the LDP.
> 
> Uncompressing Linux.............................................................
> ............................................ done, booting the kernel.
> Linux version 2.6.29-rc3 (rmk@dyn-67.arm.linux.org.uk) (gcc version 4.3.2 (GCC)) #125 Mon Feb 2 22:22:54 GMT 2009

<snip snip>

> omapfb: configured for panel ldp
> omapfb: DISPC version 3.0 initialized
> omapfb: Framebuffer initialized. Total vram 614400 planes 1
> omapfb: Pixclock 32000 kHz hfreq 60.3 kHz vfreq 93.7 Hz

Can you see the penguin?

Tony

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Russell King - ARM Linux May 7, 2009, 4:34 p.m. UTC | #4
On Thu, May 07, 2009 at 09:28:34AM -0700, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [090507 09:19]:
> > On Thu, May 07, 2009 at 11:01:35PM +0800, stanley.miao wrote:
> > > Hi, Tony,
> > >
> > > Now the kernel can't boot on LDP. The attached file is the boot log.
> > 
> > No boot log found.
> > 
> > My master branch, based upon 2.6.29-rc3 boots fine on the LDP.
> > 
> > Uncompressing Linux.............................................................
> > ............................................ done, booting the kernel.
> > Linux version 2.6.29-rc3 (rmk@dyn-67.arm.linux.org.uk) (gcc version 4.3.2 (GCC)) #125 Mon Feb 2 22:22:54 GMT 2009
> 
> <snip snip>
> 
> > omapfb: configured for panel ldp
> > omapfb: DISPC version 3.0 initialized
> > omapfb: Framebuffer initialized. Total vram 614400 planes 1
> > omapfb: Pixclock 32000 kHz hfreq 60.3 kHz vfreq 93.7 Hz
> 
> Can you see the penguin?

Interestingly, CONFIG_FB is not set, so I'm not sure why we have a
framebuffer driver.

Ah, hmm.  Oh sod it, what kernel am I booting.  Oh, it's an ages
old one.  Fucking $#^"$#^%$^#"^^"%#%^5268903284769065983 UBOOT.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Russell King - ARM Linux May 7, 2009, 4:37 p.m. UTC | #5
On Thu, May 07, 2009 at 05:34:05PM +0100, Russell King - ARM Linux wrote:
> On Thu, May 07, 2009 at 09:28:34AM -0700, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [090507 09:19]:
> > > On Thu, May 07, 2009 at 11:01:35PM +0800, stanley.miao wrote:
> > > > Hi, Tony,
> > > >
> > > > Now the kernel can't boot on LDP. The attached file is the boot log.
> > > 
> > > No boot log found.
> > > 
> > > My master branch, based upon 2.6.29-rc3 boots fine on the LDP.
> > > 
> > > Uncompressing Linux.............................................................
> > > ............................................ done, booting the kernel.
> > > Linux version 2.6.29-rc3 (rmk@dyn-67.arm.linux.org.uk) (gcc version 4.3.2 (GCC)) #125 Mon Feb 2 22:22:54 GMT 2009
> > 
> > <snip snip>
> > 
> > > omapfb: configured for panel ldp
> > > omapfb: DISPC version 3.0 initialized
> > > omapfb: Framebuffer initialized. Total vram 614400 planes 1
> > > omapfb: Pixclock 32000 kHz hfreq 60.3 kHz vfreq 93.7 Hz
> > 
> > Can you see the penguin?
> 
> Interestingly, CONFIG_FB is not set, so I'm not sure why we have a
> framebuffer driver.
> 
> Ah, hmm.  Oh sod it, what kernel am I booting.  Oh, it's an ages
> old one.  Fucking $#^"$#^%$^#"^^"%#%^5268903284769065983 UBOOT.

Sod it, I'm not going to bother with this crap with its stupidly long
build times because of bloated gcc4 requirements this side of my holiday.
I've better things to be doing like washing the car.

So you're on your own with LDP support for the next 9 days.  So this
email marks the end of my pre-holiday Linux involvement.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Tony Lindgren May 7, 2009, 4:41 p.m. UTC | #6
* Russell King - ARM Linux <linux@arm.linux.org.uk> [090507 09:37]:
> On Thu, May 07, 2009 at 05:34:05PM +0100, Russell King - ARM Linux wrote:
> > On Thu, May 07, 2009 at 09:28:34AM -0700, Tony Lindgren wrote:
> > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [090507 09:19]:
> > > > On Thu, May 07, 2009 at 11:01:35PM +0800, stanley.miao wrote:
> > > > > Hi, Tony,
> > > > >
> > > > > Now the kernel can't boot on LDP. The attached file is the boot log.
> > > > 
> > > > No boot log found.
> > > > 
> > > > My master branch, based upon 2.6.29-rc3 boots fine on the LDP.
> > > > 
> > > > Uncompressing Linux.............................................................
> > > > ............................................ done, booting the kernel.
> > > > Linux version 2.6.29-rc3 (rmk@dyn-67.arm.linux.org.uk) (gcc version 4.3.2 (GCC)) #125 Mon Feb 2 22:22:54 GMT 2009
> > > 
> > > <snip snip>
> > > 
> > > > omapfb: configured for panel ldp
> > > > omapfb: DISPC version 3.0 initialized
> > > > omapfb: Framebuffer initialized. Total vram 614400 planes 1
> > > > omapfb: Pixclock 32000 kHz hfreq 60.3 kHz vfreq 93.7 Hz
> > > 
> > > Can you see the penguin?
> > 
> > Interestingly, CONFIG_FB is not set, so I'm not sure why we have a
> > framebuffer driver.
> > 
> > Ah, hmm.  Oh sod it, what kernel am I booting.  Oh, it's an ages
> > old one.  Fucking $#^"$#^%$^#"^^"%#%^5268903284769065983 UBOOT.
> 
> Sod it, I'm not going to bother with this crap with its stupidly long
> build times because of bloated gcc4 requirements this side of my holiday.
> I've better things to be doing like washing the car.
> 
> So you're on your own with LDP support for the next 9 days.  So this
> email marks the end of my pre-holiday Linux involvement.

Happy holidays :) We'll get the LDP patches ready by the time you're back.

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Koen Kooi May 7, 2009, 4:56 p.m. UTC | #7
Op 7 mei 2009, om 18:28 heeft Tony Lindgren het volgende geschreven:

> * Russell King - ARM Linux <linux@arm.linux.org.uk> [090507 09:19]:
>> On Thu, May 07, 2009 at 11:01:35PM +0800, stanley.miao wrote:
>>> Hi, Tony,
>>>
>>> Now the kernel can't boot on LDP. The attached file is the boot log.
>>
>> No boot log found.
>>
>> My master branch, based upon 2.6.29-rc3 boots fine on the LDP.
>>
>> Uncompressing  
>> Linux.............................................................
>> ............................................ done, booting the  
>> kernel.
>> Linux version 2.6.29-rc3 (rmk@dyn-67.arm.linux.org.uk) (gcc version  
>> 4.3.2 (GCC)) #125 Mon Feb 2 22:22:54 GMT 2009
>
> <snip snip>
>
>> omapfb: configured for panel ldp
>> omapfb: DISPC version 3.0 initialized
>> omapfb: Framebuffer initialized. Total vram 614400 planes 1
>> omapfb: Pixclock 32000 kHz hfreq 60.3 kHz vfreq 93.7 Hz
>
> Can you see the penguin?

2.6.29 does this on my zoom:

http://www.flickr.com/photos/koenkooi/3406819626/

Boots into X and all :) That's with DSS1, not Tomi's DSS2. As I said  
earlier, the touchscreen is unusable.

regards,

Koen
Tony Lindgren May 7, 2009, 5:18 p.m. UTC | #8
* Koen Kooi <koen@dominion.thruhere.net> [090507 09:57]:
>
> Op 7 mei 2009, om 18:28 heeft Tony Lindgren het volgende geschreven:
>
>> * Russell King - ARM Linux <linux@arm.linux.org.uk> [090507 09:19]:
>>> On Thu, May 07, 2009 at 11:01:35PM +0800, stanley.miao wrote:
>>>> Hi, Tony,
>>>>
>>>> Now the kernel can't boot on LDP. The attached file is the boot log.
>>>
>>> No boot log found.
>>>
>>> My master branch, based upon 2.6.29-rc3 boots fine on the LDP.
>>>
>>> Uncompressing  
>>> Linux.............................................................
>>> ............................................ done, booting the  
>>> kernel.
>>> Linux version 2.6.29-rc3 (rmk@dyn-67.arm.linux.org.uk) (gcc version  
>>> 4.3.2 (GCC)) #125 Mon Feb 2 22:22:54 GMT 2009
>>
>> <snip snip>
>>
>>> omapfb: configured for panel ldp
>>> omapfb: DISPC version 3.0 initialized
>>> omapfb: Framebuffer initialized. Total vram 614400 planes 1
>>> omapfb: Pixclock 32000 kHz hfreq 60.3 kHz vfreq 93.7 Hz
>>
>> Can you see the penguin?
>
> 2.6.29 does this on my zoom:
>
> http://www.flickr.com/photos/koenkooi/3406819626/
>
> Boots into X and all :) That's with DSS1, not Tomi's DSS2. As I said  
> earlier, the touchscreen is unusable.

Good to hear. What patches do you have applied?

What exactly is wrong with the touchscreen? Got any patches for that?

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Koen Kooi May 7, 2009, 6:45 p.m. UTC | #9
Op 7 mei 2009, om 19:18 heeft Tony Lindgren het volgende geschreven:

> * Koen Kooi <koen@dominion.thruhere.net> [090507 09:57]:
>>
>> Op 7 mei 2009, om 18:28 heeft Tony Lindgren het volgende geschreven:
>>
>>> * Russell King - ARM Linux <linux@arm.linux.org.uk> [090507 09:19]:
>>>> On Thu, May 07, 2009 at 11:01:35PM +0800, stanley.miao wrote:
>>>>> Hi, Tony,
>>>>>
>>>>> Now the kernel can't boot on LDP. The attached file is the boot  
>>>>> log.
>>>>
>>>> No boot log found.
>>>>
>>>> My master branch, based upon 2.6.29-rc3 boots fine on the LDP.
>>>>
>>>> Uncompressing
>>>> Linux.............................................................
>>>> ............................................ done, booting the
>>>> kernel.
>>>> Linux version 2.6.29-rc3 (rmk@dyn-67.arm.linux.org.uk) (gcc version
>>>> 4.3.2 (GCC)) #125 Mon Feb 2 22:22:54 GMT 2009
>>>
>>> <snip snip>
>>>
>>>> omapfb: configured for panel ldp
>>>> omapfb: DISPC version 3.0 initialized
>>>> omapfb: Framebuffer initialized. Total vram 614400 planes 1
>>>> omapfb: Pixclock 32000 kHz hfreq 60.3 kHz vfreq 93.7 Hz
>>>
>>> Can you see the penguin?
>>
>> 2.6.29 does this on my zoom:
>>
>> http://www.flickr.com/photos/koenkooi/3406819626/
>>
>> Boots into X and all :) That's with DSS1, not Tomi's DSS2. As I said
>> earlier, the touchscreen is unusable.
>
> Good to hear. What patches do you have applied?

None relating to DSS1, the rest are DSS2 patches (not enabled in  
defconfig), musb patches, etc.

> What exactly is wrong with the touchscreen?

It seems to have a reduced resolution with lots of noise, tslib is  
unable to calibrate it to a usable state. It might be the mcspi  
problem the evm had (has?) all over again, haven't looked into that.

> Got any patches for that?

none, sorry.

regards,

Koen

>
> Regards,
>
> Tony
Tony Lindgren May 7, 2009, 9:42 p.m. UTC | #10
* stanley.miao <stanley.miao@windriver.com> [090507 07:59]:
> Tony Lindgren wrote:
>> * Tony Lindgren <tony@atomide.com> [090505 21:00]:
>>   
>>> * Russell King - ARM Linux <linux@arm.linux.org.uk> [090505 12:52]:
>>>     
>>>> On Tue, Apr 28, 2009 at 03:42:37PM -0700, Tony Lindgren wrote:
>>>>       
>>>>> * Russell King - ARM Linux <linux@arm.linux.org.uk> [090428 15:07]:
>>>>>         
>>>>>> Tony, et.al.,
>>>>>>
>>>>>> Any ideas when more LDP support will be pushed into mainline (such as
>>>>>> the framebuffer support)?
>>>>>>           
>>>>> I'll be looking at the board-*.c patches for the next merge window
>>>>> hopefully this week or next week.
>>>>>
>>>>> Looks like LDP keyboard, touchscreen & RTC are pretty much ready
>>>>> to go. Then the MMC has some regulator updates, but AFAIK the MMC
>>>>> should work OK already.
>>>>>
>>>>> For the framebuffer, Imre and Tomi know the status the best, so
>>>>> I've added them to Cc.
>>>>>
>>>>> Imre has been meaning to send a bunch of drivers/video/omap changes
>>>>> to the fbdev list for a while now and LDP framebuffer may depend on
>>>>> those. Imre, any news on the status of sending the fb patches
>>>>> upstream?
>>>>>
>>>>> Then there are the upcoming DSS patches from Tomi, but those still
>>>>> need some work before they're ready to go.
>>>>>         
>>>> Is there any news on this?  Will we see more functional OMAP3 / LDP
>>>> support queued for the next merge window?
>>>>       
>>> Yes fro the stuff listed above, but still no news on the framebuffer
>>> patches. Imre?
>>>     
>>
>> Added Stanley Miao to Cc. Here's an updated version of Stanley's patch to
>> add fb support for LDP.
>>
>> I don't have an LDP, maybe you guys can give it a try against the mainline
>> kernel and see if it works! There might be some changes needed to  
>> drivers/video/omap/dispc.c too.. And those should be handled by Imre.
>>
>> But if this works, at least we can then add support for few more boards
>> easily while waiting for Imre to send his updates.
>>   
> Hi, Tony,
>
> Now the kernel can't boot on LDP. The attached file is the boot log.
>
> I will check it when I have  time.

Looks like the get_dss_clocks() in dispc.c at least needs updating for
omap3. It should use clkdev too now btw.

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
stanley.miao May 8, 2009, 3:26 a.m. UTC | #11
Russell King - ARM Linux wrote:
> On Thu, May 07, 2009 at 11:01:35PM +0800, stanley.miao wrote:
>   
>> Hi, Tony,
>>
>> Now the kernel can't boot on LDP. The attached file is the boot log.
>>     
>
> No boot log found.
>
>
>   
Sorry, forgot to attach the boot log.

It is linux-omap master branch.

Stanley.
Uncompressing Linux.................................................................................................................... done, booting the kernel.
<5>Linux version 2.6.30-rc4-omap1-05873-g2489dcb (stanley@stanley-desktop) (gcc version 4.2.1 (CodeSourcery Sourcery G++ Lite 2007q3-53)) #1 Thu May 7 22:52:12 CST9
CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=10c5387f
CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: OMAP LDP board
Memory policy: ECC disabled, Data cache writeback
<7>On node 0 totalpages: 32768
<7>free_area_init_node: node 0, pgdat c038db50, node_mem_map c03a9000
<7>  Normal zone: 256 pages used for memmap
<7>  Normal zone: 0 pages reserved
<7>  Normal zone: 32512 pages, LIFO batch:7
<6>OMAP3430 ES2.1
<6>SRAM: Mapped pa 0x40200000 to va 0xd7000000 size: 0x100000
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32512
<5>Kernel command line: root=/dev/nfs rw nfsroot=128.224.163.169:/export/rootfs console=ttyS2,115200n8 mem=128M ip=128.224.163.125:128.224.163.169:128.224.162.1:25}
<6>NR_IRQS:402
<6>Clocking rate (Crystal/DPLL/ARM core): 26.0/266/500 MHz
<6>GPMC revision 5.0
<6>IRQ: Found an INTC at 0xd8200000 (revision 4.0) with 96 interrupts
<6>Total of 96 interrupts on 1 active controller
<6>OMAP34xx GPIO hardware version 2.5
PID hash table entries: 512 (order: 9, 2048 bytes)
<6>OMAP clockevent source: GPTIMER1 at 32768 Hz
Console: colour dummy device 80x30
<6>Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
<6>Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
<6>Memory: 128MB = 128MB total
<5>Memory: 126036KB available (3176K code, 292K data, 132K init, 0K highmem)
<6>Calibrating delay loop...
Anand Gadiyar May 8, 2009, 3:27 a.m. UTC | #12
Stanley.miao wrote:
> Russell King - ARM Linux wrote:
> > On Thu, May 07, 2009 at 11:01:35PM +0800, stanley.miao wrote:
> >   
> >> Hi, Tony,
> >>
> >> Now the kernel can't boot on LDP. The attached file is the boot log.
> >>     
> >
> > No boot log found.
> >
> >
> >   
> Sorry, forgot to attach the boot log.
> 
> It is linux-omap master branch.
> 
> Stanley.

Looks like you used the CodeSourcery 2007q3 toolchain. This had been
reported earlier. Switching to 2008q3 works.

- Anand


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
stanley.miao May 8, 2009, 9:18 a.m. UTC | #13
Gadiyar, Anand wrote:
> Stanley.miao wrote:
>   
>> Russell King - ARM Linux wrote:
>>     
>>> On Thu, May 07, 2009 at 11:01:35PM +0800, stanley.miao wrote:
>>>   
>>>       
>>>> Hi, Tony,
>>>>
>>>> Now the kernel can't boot on LDP. The attached file is the boot log.
>>>>     
>>>>         
>>> No boot log found.
>>>
>>>
>>>   
>>>       
>> Sorry, forgot to attach the boot log.
>>
>> It is linux-omap master branch.
>>
>> Stanley.
>>     
>
> Looks like you used the CodeSourcery 2007q3 toolchain. This had been
> reported earlier. Switching to 2008q3 works.
>
> - Anand
>
>
>
>   
Yeah, Now the kernel booted. it's compiler's problem.

Linux version 2.6.30-rc4-omap1-05873-g2489dcb (stanley@stanley-desktop) 
(gcc version 4.3.2 (Sourcery G++ Lite 2008q3-72) ) #2 Fri May 8 17:06:34 
CST 2009
CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=10c5387f
CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: OMAP LDP board


Hi, Tony,

LCD still works.
The code I tested is the master branch of linux-omap. Is it right ?

Stanley.

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Tony Lindgren May 8, 2009, 3:22 p.m. UTC | #14
* stanley.miao <stanley.miao@windriver.com> [090508 02:15]:
> Gadiyar, Anand wrote:
>> Stanley.miao wrote:
>>   
>>> Russell King - ARM Linux wrote:
>>>     
>>>> On Thu, May 07, 2009 at 11:01:35PM +0800, stanley.miao wrote:
>>>>         
>>>>> Hi, Tony,
>>>>>
>>>>> Now the kernel can't boot on LDP. The attached file is the boot log.
>>>>>             
>>>> No boot log found.
>>>>
>>>>
>>>>         
>>> Sorry, forgot to attach the boot log.
>>>
>>> It is linux-omap master branch.
>>>
>>> Stanley.
>>>     
>>
>> Looks like you used the CodeSourcery 2007q3 toolchain. This had been
>> reported earlier. Switching to 2008q3 works.
>>
>> - Anand
>>
>>
>>
>>   
> Yeah, Now the kernel booted. it's compiler's problem.
>
> Linux version 2.6.30-rc4-omap1-05873-g2489dcb (stanley@stanley-desktop)  
> (gcc version 4.3.2 (Sourcery G++ Lite 2008q3-72) ) #2 Fri May 8 17:06:34  
> CST 2009
> CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=10c5387f
> CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
> Machine: OMAP LDP board
>
>
> Hi, Tony,
>
> LCD still works.
> The code I tested is the master branch of linux-omap. Is it right ?

Well the goal here is to get the mainline code to work for the LCD.

I'll post few patches for you to test after trying them out on 3430sdp.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Kalle Valo May 8, 2009, 4:47 p.m. UTC | #15
"stanley.miao" <stanley.miao@windriver.com> writes:

>> Looks like you used the CodeSourcery 2007q3 toolchain. This had been
>> reported earlier. Switching to 2008q3 works.
>
> Yeah, Now the kernel booted. it's compiler's problem.

I was bitten by the same problem few weeks ago. Any chance of getting a
warning/error if using 2007q3 compiler until the problem is fixed?
Russell King - ARM Linux May 16, 2009, 8:19 a.m. UTC | #16
On Fri, May 08, 2009 at 07:47:09PM +0300, Kalle Valo wrote:
> "stanley.miao" <stanley.miao@windriver.com> writes:
> 
> >> Looks like you used the CodeSourcery 2007q3 toolchain. This had been
> >> reported earlier. Switching to 2008q3 works.
> >
> > Yeah, Now the kernel booted. it's compiler's problem.
> 
> I was bitten by the same problem few weeks ago. Any chance of getting a
> warning/error if using 2007q3 compiler until the problem is fixed?

Is there any way of detecting the 2007q3 compiler?

With normal GCC versions, you can use __GNUC__, __GNUC_MINOR__ and
__GNUC_PATCHLEVEL__ to identify the three digit version number.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Kalle Valo May 18, 2009, 3:54 p.m. UTC | #17
Russell King - ARM Linux <linux@arm.linux.org.uk> writes:

> On Fri, May 08, 2009 at 07:47:09PM +0300, Kalle Valo wrote:
>> "stanley.miao" <stanley.miao@windriver.com> writes:
>> 
>> >> Looks like you used the CodeSourcery 2007q3 toolchain. This had been
>> >> reported earlier. Switching to 2008q3 works.
>> >
>> > Yeah, Now the kernel booted. it's compiler's problem.
>> 
>> I was bitten by the same problem few weeks ago. Any chance of getting a
>> warning/error if using 2007q3 compiler until the problem is fixed?
>
> Is there any way of detecting the 2007q3 compiler?
>
> With normal GCC versions, you can use __GNUC__, __GNUC_MINOR__ and
> __GNUC_PATCHLEVEL__ to identify the three digit version number.

I don't know, most probably not. But Jon Hunter investigated the issue
and he found the issue was related to CONFIG_ARCH_WANT_FRAME_POINTERS:

http://www.mail-archive.com/linux-omap@vger.kernel.org/msg12403.html

So maybe we can fix or workaround this.
Russell King - ARM Linux May 18, 2009, 4:09 p.m. UTC | #18
On Mon, May 18, 2009 at 06:54:56PM +0300, Kalle Valo wrote:
> Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> 
> > On Fri, May 08, 2009 at 07:47:09PM +0300, Kalle Valo wrote:
> >> "stanley.miao" <stanley.miao@windriver.com> writes:
> >> 
> >> >> Looks like you used the CodeSourcery 2007q3 toolchain. This had been
> >> >> reported earlier. Switching to 2008q3 works.
> >> >
> >> > Yeah, Now the kernel booted. it's compiler's problem.
> >> 
> >> I was bitten by the same problem few weeks ago. Any chance of getting a
> >> warning/error if using 2007q3 compiler until the problem is fixed?
> >
> > Is there any way of detecting the 2007q3 compiler?
> >
> > With normal GCC versions, you can use __GNUC__, __GNUC_MINOR__ and
> > __GNUC_PATCHLEVEL__ to identify the three digit version number.
> 
> I don't know, most probably not. But Jon Hunter investigated the issue
> and he found the issue was related to CONFIG_ARCH_WANT_FRAME_POINTERS:
> 
> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg12403.html
> 
> So maybe we can fix or workaround this.

Why does this change anything?  FRAME_POINTERS seems to be enabled
anyway (and should be given the Kconfig setup we have.)
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Kevin Hilman May 18, 2009, 5:13 p.m. UTC | #19
Russell King - ARM Linux <linux@arm.linux.org.uk> writes:

> On Mon, May 18, 2009 at 06:54:56PM +0300, Kalle Valo wrote:
>> Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
>> 
>> > On Fri, May 08, 2009 at 07:47:09PM +0300, Kalle Valo wrote:
>> >> "stanley.miao" <stanley.miao@windriver.com> writes:
>> >> 
>> >> >> Looks like you used the CodeSourcery 2007q3 toolchain. This had been
>> >> >> reported earlier. Switching to 2008q3 works.
>> >> >
>> >> > Yeah, Now the kernel booted. it's compiler's problem.
>> >> 
>> >> I was bitten by the same problem few weeks ago. Any chance of getting a
>> >> warning/error if using 2007q3 compiler until the problem is fixed?
>> >
>> > Is there any way of detecting the 2007q3 compiler?
>> >
>> > With normal GCC versions, you can use __GNUC__, __GNUC_MINOR__ and
>> > __GNUC_PATCHLEVEL__ to identify the three digit version number.
>> 
>> I don't know, most probably not. But Jon Hunter investigated the issue
>> and he found the issue was related to CONFIG_ARCH_WANT_FRAME_POINTERS:
>> 
>> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg12403.html
>> 
>> So maybe we can fix or workaround this.
>
> Why does this change anything?  FRAME_POINTERS seems to be enabled
> anyway (and should be given the Kconfig setup we have.)

See the 'depends on' line in lib/Kconfig.debug.  The result is that
without the patch from Jon, even if you have CONFIG_FRAME_POINTERS=y
in your .config, it gets dropped if the arch doesn't set
CONFIG_ARCH_WANT_FRAME_POINTERS.

Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Russell King - ARM Linux May 18, 2009, 6:59 p.m. UTC | #20
On Mon, May 18, 2009 at 10:13:55AM -0700, Kevin Hilman wrote:
> Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> 
> > On Mon, May 18, 2009 at 06:54:56PM +0300, Kalle Valo wrote:
> >> Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> >> 
> >> > On Fri, May 08, 2009 at 07:47:09PM +0300, Kalle Valo wrote:
> >> >> "stanley.miao" <stanley.miao@windriver.com> writes:
> >> >> 
> >> >> >> Looks like you used the CodeSourcery 2007q3 toolchain. This had been
> >> >> >> reported earlier. Switching to 2008q3 works.
> >> >> >
> >> >> > Yeah, Now the kernel booted. it's compiler's problem.
> >> >> 
> >> >> I was bitten by the same problem few weeks ago. Any chance of getting a
> >> >> warning/error if using 2007q3 compiler until the problem is fixed?
> >> >
> >> > Is there any way of detecting the 2007q3 compiler?
> >> >
> >> > With normal GCC versions, you can use __GNUC__, __GNUC_MINOR__ and
> >> > __GNUC_PATCHLEVEL__ to identify the three digit version number.
> >> 
> >> I don't know, most probably not. But Jon Hunter investigated the issue
> >> and he found the issue was related to CONFIG_ARCH_WANT_FRAME_POINTERS:
> >> 
> >> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg12403.html
> >> 
> >> So maybe we can fix or workaround this.
> >
> > Why does this change anything?  FRAME_POINTERS seems to be enabled
> > anyway (and should be given the Kconfig setup we have.)
> 
> See the 'depends on' line in lib/Kconfig.debug.  The result is that
> without the patch from Jon, even if you have CONFIG_FRAME_POINTERS=y
> in your .config, it gets dropped if the arch doesn't set
> CONFIG_ARCH_WANT_FRAME_POINTERS.

Well, two things.

1. We don't want to force frame pointers on if unwinding support is enabled.

2. The lib/Kconfig.debug entry is overridden by ARM's own version in
   arch/arm/Kconfig.debug.  I've added samr into the discussion since
   he created this.

arch/arm/Kconfig.debug:

# RMK wants arm kernels compiled with frame pointers or stack unwinding.
# If you know what you are doing and are willing to live without stack
# traces, you can get a slightly smaller kernel by setting this option to
# n, but then RMK will have to kill you ;).
config FRAME_POINTER
        bool
        default y if !ARM_UNWIND
        help
          If you say N here, the resulting kernel will be slightly smaller and
          faster. However, if neither FRAME_POINTER nor ARM_UNWIND are enabled,
          when a problem occurs with the kernel, the information that is
          reported is severely limited.

And lib/Kconfig.debug:

config FRAME_POINTER
        bool "Compile the kernel with frame pointers"
        depends on DEBUG_KERNEL && \
                (CRIS || M68K || M68KNOMMU || FRV || UML || \
                 AVR32 || SUPERH || BLACKFIN || MN10300) || \
                ARCH_WANT_FRAME_POINTERS
        default y if (DEBUG_INFO && UML) || ARCH_WANT_FRAME_POINTERS
        help
          If you say Y here the resulting kernel image will be slightly
          larger and slower, but it gives very useful debugging information
          in case of kernel bugs. (precise oopses/stacktraces/warnings)

this still results in frame pointers being enabled.  This is because the
ARM version follows the one in lib/, it overrides it rather than
supplementing the generic version.  I've just checked that by adding
'n &&' to that depends on line in lib/Kconfig.debug, and making oldconfig.
I still end up with FRAME_POINTER=y in my configs.  However, if I stub out
the 'default y' line in arch/arm/Kconfig.debug, it goes away.

So I think setting ARCH_WANT_FRAME_POINTERS will be ineffectual.

Moreover, I don't think forcing frame pointers to be enabled even with
unwinding support is the right solution - if we have frame pointers
there's no need for unwind support (so maybe the right answer is to
force unwind support off for the time being?)
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Hunter, Jon May 19, 2009, 8:54 p.m. UTC | #21
Russell King - ARM Linux wrote:
> Moreover, I don't think forcing frame pointers to be enabled even with
> unwinding support is the right solution - if we have frame pointers
> there's no need for unwind support (so maybe the right answer is to
> force unwind support off for the time being?)

Ok, so I have tested this and if we add the following to the omap 
defconfigs then this will enable frame pointers and disable unwinding 
support. Hence, this should avoid the problems seen with the 2007q3 code 
sourcery compiler.

# CONFIG_ARM_UNWIND is not set

Tony, would this be ok with you?

Russell, sorry I did not see this thread earlier.

Jon

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

commit 6ceeed27b64fab326963a8a867c7549443e7536e
Author: Stanley Miao <stanley.miao@windriver.com>
Date:   Wed May 6 15:09:35 2009 -0700

    OMAP_LDP: Support LCD display as a FB device on ZOOM MDK
    
    Add glue to control the OMAP_LDP LCD as a frame buffer device
    using the existing dispc.c driver under omapfb.
    
    Patch updated for mainline kernel. Note that the
    drivers/video/omap should be updated to pass omap_lcd_config
    in platform_data. The patch should also be updated to compile
    if twl4030 is not selected, and eventually to use the regulator
    framework.
    
    Signed-off-by: Stanley.Miao <stanley.miao@windriver.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>

diff --git a/arch/arm/configs/omap_ldp_defconfig b/arch/arm/configs/omap_ldp_defconfig
index 679a4a3..8a979cd 100644
--- a/arch/arm/configs/omap_ldp_defconfig
+++ b/arch/arm/configs/omap_ldp_defconfig
@@ -685,11 +685,16 @@  CONFIG_GPIOLIB=y
 # CONFIG_GPIO_SYSFS is not set
 
 #
+# Memory mapped GPIO expanders:
+#
+
+#
 # I2C GPIO expanders:
 #
 # CONFIG_GPIO_MAX732X is not set
 # CONFIG_GPIO_PCA953X is not set
 # CONFIG_GPIO_PCF857X is not set
+CONFIG_GPIO_TWL4030=y
 
 #
 # PCI GPIO expanders:
@@ -740,12 +745,19 @@  CONFIG_SSB_POSSIBLE=y
 #
 # CONFIG_MFD_CORE is not set
 # CONFIG_MFD_SM501 is not set
+# CONFIG_MFD_ASIC3 is not set
 # CONFIG_HTC_EGPIO is not set
 # CONFIG_HTC_PASIC3 is not set
+# CONFIG_TPS65010 is not set
+CONFIG_TWL4030_CORE=y
 # CONFIG_MFD_TMIO is not set
 # CONFIG_MFD_T7L66XB is not set
 # CONFIG_MFD_TC6387XB is not set
 # CONFIG_MFD_TC6393XB is not set
+# CONFIG_PMIC_DA903X is not set
+# CONFIG_MFD_WM8400 is not set
+# CONFIG_MFD_WM8350_I2C is not set
+# CONFIG_MFD_PCF50633 is not set
 
 #
 # Multimedia devices
@@ -767,8 +779,45 @@  CONFIG_DAB=y
 #
 # CONFIG_VGASTATE is not set
 CONFIG_VIDEO_OUTPUT_CONTROL=m
-# CONFIG_FB is not set
-# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
+CONFIG_FB=y
+CONFIG_FIRMWARE_EDID=y
+# CONFIG_FB_DDC is not set
+# CONFIG_FB_BOOT_VESA_SUPPORT is not set
+CONFIG_FB_CFB_FILLRECT=y
+CONFIG_FB_CFB_COPYAREA=y
+CONFIG_FB_CFB_IMAGEBLIT=y
+# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
+# CONFIG_FB_SYS_FILLRECT is not set
+# CONFIG_FB_SYS_COPYAREA is not set
+# CONFIG_FB_SYS_IMAGEBLIT is not set
+# CONFIG_FB_FOREIGN_ENDIAN is not set
+# CONFIG_FB_SYS_FOPS is not set
+# CONFIG_FB_SVGALIB is not set
+# CONFIG_FB_MACMODES is not set
+# CONFIG_FB_BACKLIGHT is not set
+CONFIG_FB_MODE_HELPERS=y
+CONFIG_FB_TILEBLITTING=y
+
+#
+# Frame buffer hardware drivers
+#
+# CONFIG_FB_S1D13XXX is not set
+# CONFIG_FB_VIRTUAL is not set
+# CONFIG_FB_METRONOME is not set
+CONFIG_FB_OMAP=y
+CONFIG_FB_OMAP_LCD_VGA=y
+# CONFIG_FB_OMAP_LCDC_EXTERNAL is not set
+# CONFIG_FB_OMAP_BOOTLOADER_INIT is not set
+CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE=4
+CONFIG_BACKLIGHT_LCD_SUPPORT=y
+CONFIG_LCD_CLASS_DEVICE=y
+# CONFIG_LCD_LTV350QV is not set
+# CONFIG_LCD_ILI9320 is not set
+# CONFIG_LCD_TDO24M is not set
+# CONFIG_LCD_VGG2432A4 is not set
+CONFIG_LCD_PLATFORM=y
+CONFIG_BACKLIGHT_CLASS_DEVICE=y
+# CONFIG_BACKLIGHT_CORGI is not set
 
 #
 # Display device support
@@ -780,6 +829,16 @@  CONFIG_VIDEO_OUTPUT_CONTROL=m
 #
 # CONFIG_VGA_CONSOLE is not set
 CONFIG_DUMMY_CONSOLE=y
+CONFIG_FRAMEBUFFER_CONSOLE=y
+# CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set
+# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
+# CONFIG_FONTS is not set
+CONFIG_FONT_8x8=y
+CONFIG_FONT_8x16=y
+CONFIG_LOGO=y
+CONFIG_LOGO_LINUX_MONO=y
+CONFIG_LOGO_LINUX_VGA16=y
+CONFIG_LOGO_LINUX_CLUT224=y
 CONFIG_SOUND=y
 CONFIG_SND=y
 # CONFIG_SND_SEQUENCER is not set
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index da57b0f..abbbdfc 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -77,8 +77,14 @@  static struct platform_device ldp_smsc911x_device = {
 	},
 };
 
+static struct platform_device ldp_lcd_device = {
+	.name		= "ldp_lcd",
+	.id		= -1,
+};
+
 static struct platform_device *ldp_devices[] __initdata = {
 	&ldp_smsc911x_device,
+	&ldp_lcd_device,
 };
 
 static inline void __init ldp_init_smsc911x(void)
@@ -122,8 +128,13 @@  static struct omap_uart_config ldp_uart_config __initdata = {
 	.enabled_uarts	= ((1 << 0) | (1 << 1) | (1 << 2)),
 };
 
+static struct omap_lcd_config ldp_lcd_config __initdata = {
+	.ctrl_name	= "internal",
+};
+
 static struct omap_board_config_kernel ldp_config[] __initdata = {
 	{ OMAP_TAG_UART,	&ldp_uart_config },
+	{ OMAP_TAG_LCD,		&ldp_lcd_config },
 };
 
 static struct twl4030_gpio_platform_data ldp_gpio_data = {
diff --git a/drivers/video/omap/Kconfig b/drivers/video/omap/Kconfig
index 4440885..6c86ec0 100644
--- a/drivers/video/omap/Kconfig
+++ b/drivers/video/omap/Kconfig
@@ -7,6 +7,10 @@  config FB_OMAP
 	help
           Frame buffer driver for OMAP based boards.
 
+config FB_OMAP_LCD_VGA
+        bool "Use LCD in VGA mode"
+	  depends on MACH_OMAP_3430SDP || MACH_OMAP_LDP
+
 config FB_OMAP_BOOTLOADER_INIT
 	bool "Check bootloader initialization"
 	depends on FB_OMAP
diff --git a/drivers/video/omap/Makefile b/drivers/video/omap/Makefile
index ed13889..a8f5b2e 100644
--- a/drivers/video/omap/Makefile
+++ b/drivers/video/omap/Makefile
@@ -8,6 +8,7 @@  objs-yy := omapfb_main.o
 
 objs-y$(CONFIG_ARCH_OMAP1) += lcdc.o
 objs-y$(CONFIG_ARCH_OMAP2) += dispc.o
+objs-y$(CONFIG_ARCH_OMAP3) += dispc.o
 
 objs-$(CONFIG_ARCH_OMAP1)$(CONFIG_FB_OMAP_LCDC_EXTERNAL) += sossi.o
 objs-$(CONFIG_ARCH_OMAP2)$(CONFIG_FB_OMAP_LCDC_EXTERNAL) += rfbi.o
@@ -23,6 +24,7 @@  objs-y$(CONFIG_MACH_OMAP_PALMZ71) += lcd_palmz71.o
 objs-$(CONFIG_ARCH_OMAP16XX)$(CONFIG_MACH_OMAP_INNOVATOR) += lcd_inn1610.o
 objs-$(CONFIG_ARCH_OMAP15XX)$(CONFIG_MACH_OMAP_INNOVATOR) += lcd_inn1510.o
 objs-y$(CONFIG_MACH_OMAP_OSK) += lcd_osk.o
+objs-y$(CONFIG_MACH_OMAP_LDP) += lcd_ldp.o
 
 omapfb-objs := $(objs-yy)
 
diff --git a/drivers/video/omap/lcd_ldp.c b/drivers/video/omap/lcd_ldp.c
new file mode 100644
index 0000000..8925230
--- /dev/null
+++ b/drivers/video/omap/lcd_ldp.c
@@ -0,0 +1,200 @@ 
+/*
+ * LCD panel support for the TI LDP board
+ *
+ * Copyright (C) 2007 WindRiver
+ * Author: Stanley Miao <stanley.miao@windriver.com>
+ *
+ * Derived from drivers/video/omap/lcd-2430sdp.c
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
+ */
+
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/delay.h>
+#include <linux/i2c/twl4030.h>
+
+#include <mach/gpio.h>
+#include <mach/mux.h>
+#include <mach/omapfb.h>
+#include <asm/mach-types.h>
+
+#define LCD_PANEL_BACKLIGHT_GPIO 	(15 + OMAP_MAX_GPIO_LINES)
+#define LCD_PANEL_ENABLE_GPIO 		(7 + OMAP_MAX_GPIO_LINES)
+
+#define LCD_PANEL_RESET_GPIO		55
+#define LCD_PANEL_QVGA_GPIO		56
+
+#ifdef CONFIG_FB_OMAP_LCD_VGA
+#define LCD_XRES		480
+#define LCD_YRES		640
+#define LCD_PIXCLOCK_MAX	41700
+#else
+#define LCD_XRES		240
+#define LCD_YRES		320
+#define LCD_PIXCLOCK_MAX	185186
+#endif
+
+#define PM_RECEIVER             TWL4030_MODULE_PM_RECEIVER
+#define ENABLE_VAUX2_DEDICATED  0x09
+#define ENABLE_VAUX2_DEV_GRP    0x20
+#define ENABLE_VAUX3_DEDICATED	0x03
+#define ENABLE_VAUX3_DEV_GRP	0x20
+
+#define ENABLE_VPLL2_DEDICATED          0x05
+#define ENABLE_VPLL2_DEV_GRP            0xE0
+#define TWL4030_VPLL2_DEV_GRP           0x33
+#define TWL4030_VPLL2_DEDICATED         0x36
+
+#define t2_out(c, r, v) twl4030_i2c_write_u8(c, r, v)
+
+
+static int ldp_panel_init(struct lcd_panel *panel,
+				struct omapfb_device *fbdev)
+{
+	gpio_request(LCD_PANEL_RESET_GPIO, "lcd reset");
+	gpio_request(LCD_PANEL_QVGA_GPIO, "lcd qvga");
+	gpio_request(LCD_PANEL_ENABLE_GPIO, "lcd panel");
+	gpio_request(LCD_PANEL_BACKLIGHT_GPIO, "lcd backlight");
+
+	gpio_direction_output(LCD_PANEL_QVGA_GPIO, 0);
+	gpio_direction_output(LCD_PANEL_RESET_GPIO, 0);
+	gpio_direction_output(LCD_PANEL_ENABLE_GPIO, 0);
+	gpio_direction_output(LCD_PANEL_BACKLIGHT_GPIO, 0);
+
+#ifdef CONFIG_FB_OMAP_LCD_VGA
+	gpio_set_value(LCD_PANEL_QVGA_GPIO, 0);
+#else
+	gpio_set_value(LCD_PANEL_QVGA_GPIO, 1);
+#endif
+	gpio_set_value(LCD_PANEL_RESET_GPIO, 1);
+
+	return 0;
+}
+
+static void ldp_panel_cleanup(struct lcd_panel *panel)
+{
+	gpio_free(LCD_PANEL_RESET_GPIO);
+	gpio_free(LCD_PANEL_QVGA_GPIO);
+	gpio_free(LCD_PANEL_ENABLE_GPIO);
+	gpio_free(LCD_PANEL_BACKLIGHT_GPIO);
+}
+
+static int ldp_panel_enable(struct lcd_panel *panel)
+{
+	if (0 != t2_out(PM_RECEIVER, ENABLE_VPLL2_DEDICATED,
+			TWL4030_VPLL2_DEDICATED))
+		return -EIO;
+	if (0 != t2_out(PM_RECEIVER, ENABLE_VPLL2_DEV_GRP,
+			TWL4030_VPLL2_DEV_GRP))
+		return -EIO;
+
+	gpio_direction_output(LCD_PANEL_ENABLE_GPIO, 1);
+	gpio_direction_output(LCD_PANEL_BACKLIGHT_GPIO, 1);
+
+	if (0 != t2_out(PM_RECEIVER, ENABLE_VAUX3_DEDICATED,
+				TWL4030_VAUX3_DEDICATED))
+		return -EIO;
+	if (0 != t2_out(PM_RECEIVER, ENABLE_VAUX3_DEV_GRP,
+				TWL4030_VAUX3_DEV_GRP))
+		return -EIO;
+
+	return 0;
+}
+
+static void ldp_panel_disable(struct lcd_panel *panel)
+{
+	gpio_direction_output(LCD_PANEL_ENABLE_GPIO, 0);
+	gpio_direction_output(LCD_PANEL_BACKLIGHT_GPIO, 0);
+
+	t2_out(PM_RECEIVER, 0x0, TWL4030_VPLL2_DEDICATED);
+	t2_out(PM_RECEIVER, 0x0, TWL4030_VPLL2_DEV_GRP);
+	mdelay(4);
+}
+
+static unsigned long ldp_panel_get_caps(struct lcd_panel *panel)
+{
+	return 0;
+}
+
+struct lcd_panel ldp_panel = {
+	.name		= "ldp",
+	.config		= OMAP_LCDC_PANEL_TFT | OMAP_LCDC_INV_VSYNC |
+			  OMAP_LCDC_INV_HSYNC,
+
+	.bpp		= 16,
+	.data_lines	= 18,
+	.x_res		= LCD_XRES,
+	.y_res		= LCD_YRES,
+	.hsw		= 3,		/* hsync_len (4) - 1 */
+	.hfp		= 3,		/* right_margin (4) - 1 */
+	.hbp		= 39,		/* left_margin (40) - 1 */
+	.vsw		= 1,		/* vsync_len (2) - 1 */
+	.vfp		= 2,		/* lower_margin */
+	.vbp		= 7,		/* upper_margin (8) - 1 */
+
+	.pixel_clock	= LCD_PIXCLOCK_MAX,
+
+	.init		= ldp_panel_init,
+	.cleanup	= ldp_panel_cleanup,
+	.enable		= ldp_panel_enable,
+	.disable	= ldp_panel_disable,
+	.get_caps	= ldp_panel_get_caps,
+};
+
+static int ldp_panel_probe(struct platform_device *pdev)
+{
+	omapfb_register_panel(&ldp_panel);
+	return 0;
+}
+
+static int ldp_panel_remove(struct platform_device *pdev)
+{
+	return 0;
+}
+
+static int ldp_panel_suspend(struct platform_device *pdev, pm_message_t mesg)
+{
+	return 0;
+}
+
+static int ldp_panel_resume(struct platform_device *pdev)
+{
+	return 0;
+}
+
+struct platform_driver ldp_panel_driver = {
+	.probe		= ldp_panel_probe,
+	.remove		= ldp_panel_remove,
+	.suspend	= ldp_panel_suspend,
+	.resume		= ldp_panel_resume,
+	.driver		= {
+		.name	= "ldp_lcd",
+		.owner	= THIS_MODULE,
+	},
+};
+
+static int __init ldp_panel_drv_init(void)
+{
+	return platform_driver_register(&ldp_panel_driver);
+}
+
+static void __exit ldp_panel_drv_exit(void)
+{
+	platform_driver_unregister(&ldp_panel_driver);
+}
+
+module_init(ldp_panel_drv_init);
+module_exit(ldp_panel_drv_exit);