OMAP display subsystem - does it work?

OMAP display subsystem - does it work?

[Russell King - ARM Linux]

In my continuing woes with having the OMAP boards I have produce output,
where things used to work on the LDP, they now do not.  And on the SDP4430
board, where things were detected, they're no longer detected.

I thought this was just a matter of adjusting the configuration, but it
seems there's much more wrong than just that - so I wasn't too worried.
Last night, I updated the configuration to ensure that the appropriate
connector configuration symbols were enabled (see the changelog in the
configuration seeds.)

All the time that stuff on OMAP gets broken and/or doesn't work (inspite
of repeated attempts at reporting problems - I've never seen the displays
on the SDP4430 board ever work with a mainline kernel in all the years
I've had the platform - but they have worked with the originally supplied
TI kernels) I really find myself not really caring very much about OMAP
and whether it works or not.

Quite honestly, I regard OMAP as nothing more than an overly complex toy
implementation rather than a serious architecture because of this kind
of stuff - unlike every other ARM platform where stuff like this "just
works", OMAP stuff is always seems to be much harder to make work, and
more prone to stuff breaking.

So, here goes.  LDP3430:

OMAP DSS rev 2.0
omapdss DPI error: can't get VDDS_DSI regulator
omapfb omapfb: failed to connect default display
omapfb omapfb: failed to init overlay connections
omapfb omapfb: failed to setup omapfb
platform omapfb: Driver omapfb requests probe deferral

I don't see evidence of it being re-probed, but I do see this during boot
which implies that there's nothing there:

XIO:  fatal IO error 104 (Connection reset by peer) on X server ":0.0"
      after 0 requests (0 known processed) with 0 events remaining.



For the SDP4430, it used to detect the displays, even though nothing has
ever been displayed on them.  Now it just spits out this:

OMAP DSS rev 4.0
omapdss DSI error: can't get VDDS_DSI regulator
panel-dsi-cm panel-dsi-cm.0: Failed to connect to video source
omapfb omapfb: failed to connect default display
omapfb omapfb: failed to init overlay connections
omapfb omapfb: failed to setup omapfb
platform omapfb: Driver omapfb requests probe deferral
...
omapdss DSI error: failed to set complexio power state to 1
panel-dsi-cm panel-dsi-cm.0: failed to enable DSI
omapfb omapfb: Failed to enable display 'lcd'
omapfb omapfb: failed to initialize default display
omapfb omapfb: failed to setup omapfb

Configurations, build and boot logs are all on
http://www.arm.linux.org.uk/developer/build/

OMAP display subsystem - does it work?

[Russell King - ARM Linux]

In my continuing woes with having the OMAP boards I have produce output,
where things used to work on the LDP, they now do not.  And on the SDP4430
board, where things were detected, they're no longer detected.

I thought this was just a matter of adjusting the configuration, but it
seems there's much more wrong than just that - so I wasn't too worried.
Last night, I updated the configuration to ensure that the appropriate
connector configuration symbols were enabled (see the changelog in the
configuration seeds.)

All the time that stuff on OMAP gets broken and/or doesn't work (inspite
of repeated attempts at reporting problems - I've never seen the displays
on the SDP4430 board ever work with a mainline kernel in all the years
I've had the platform - but they have worked with the originally supplied
TI kernels) I really find myself not really caring very much about OMAP
and whether it works or not.

Quite honestly, I regard OMAP as nothing more than an overly complex toy
implementation rather than a serious architecture because of this kind
of stuff - unlike every other ARM platform where stuff like this "just
works", OMAP stuff is always seems to be much harder to make work, and
more prone to stuff breaking.

So, here goes.  LDP3430:

OMAP DSS rev 2.0
omapdss DPI error: can't get VDDS_DSI regulator
omapfb omapfb: failed to connect default display
omapfb omapfb: failed to init overlay connections
omapfb omapfb: failed to setup omapfb
platform omapfb: Driver omapfb requests probe deferral

I don't see evidence of it being re-probed, but I do see this during boot
which implies that there's nothing there:

XIO:  fatal IO error 104 (Connection reset by peer) on X server ":0.0"
      after 0 requests (0 known processed) with 0 events remaining.



For the SDP4430, it used to detect the displays, even though nothing has
ever been displayed on them.  Now it just spits out this:

OMAP DSS rev 4.0
omapdss DSI error: can't get VDDS_DSI regulator
panel-dsi-cm panel-dsi-cm.0: Failed to connect to video source
omapfb omapfb: failed to connect default display
omapfb omapfb: failed to init overlay connections
omapfb omapfb: failed to setup omapfb
platform omapfb: Driver omapfb requests probe deferral
...
omapdss DSI error: failed to set complexio power state to 1
panel-dsi-cm panel-dsi-cm.0: failed to enable DSI
omapfb omapfb: Failed to enable display 'lcd'
omapfb omapfb: failed to initialize default display
omapfb omapfb: failed to setup omapfb

Configurations, build and boot logs are all on
http://www.arm.linux.org.uk/developer/build/

Re: OMAP display subsystem - does it work?

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 2768 bytes --]

On 2013-12-18 14:00, Russell King - ARM Linux wrote:

> So, here goes.  LDP3430:
> 
> OMAP DSS rev 2.0
> omapdss DPI error: can't get VDDS_DSI regulator
> omapfb omapfb: failed to connect default display
> omapfb omapfb: failed to init overlay connections
> omapfb omapfb: failed to setup omapfb
> platform omapfb: Driver omapfb requests probe deferral
> 
> I don't see evidence of it being re-probed, but I do see this during boot
> which implies that there's nothing there:
> 
> XIO:  fatal IO error 104 (Connection reset by peer) on X server ":0.0"
>       after 0 requests (0 known processed) with 0 events remaining.

I don't have an LDP board at hand, and I wasn't able to find out anything from
the logs.

I think I should change omapfb to print something if it's probed succesfully,
as the deferred probing makes finding out if something is probed fine or not
quite murky. Without deferred probing, it was simpler: no errors -> the driver
must be (most likely) ok.

Although... In an earlier log, where there was no panel driver, the log has
these errors:

Error opening /dev/fb0: No such device

There are none in the latest log, which makes me guess the omapfb has been
probed, and fb0 is actually there. But the X is still dying for some reason...

I'll look at this more. Maybe someone in our team can find a board to test.
 
> For the SDP4430, it used to detect the displays, even though nothing has
> ever been displayed on them.  Now it just spits out this:

Those particular LCDs are supposed to be updated manually using custom ioctl,
so normal software using fb won't put anything on the display. For testing
purposes, a SW based automatic update (~20 fps) can be enabled by kernel
cmdline parameter "omapfb.auto_update" or via sysfs:

echo 1 > /sys/class/graphics/fb0/update_mode

> OMAP DSS rev 4.0
> omapdss DSI error: can't get VDDS_DSI regulator
> panel-dsi-cm panel-dsi-cm.0: Failed to connect to video source
> omapfb omapfb: failed to connect default display
> omapfb omapfb: failed to init overlay connections
> omapfb omapfb: failed to setup omapfb
> platform omapfb: Driver omapfb requests probe deferral
> ...
> omapdss DSI error: failed to set complexio power state to 1
> panel-dsi-cm panel-dsi-cm.0: failed to enable DSI
> omapfb omapfb: Failed to enable display 'lcd'
> omapfb omapfb: failed to initialize default display
> omapfb omapfb: failed to setup omapfb

Commit e30b06f4d5f000c31a7747a7e7ada78a5fd419a1 (ARM: OMAP2+: Remove legacy mux
code for display.c) was overly enthusiastic in removing legacy code which was
already in use. Tony has a partial revert for that queued up. It can also be
reverted fully for testing. After that, the panel wakes up.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

OMAP display subsystem - does it work?

[Tomi Valkeinen]

On 2013-12-18 14:00, Russell King - ARM Linux wrote:

> So, here goes.  LDP3430:
> 
> OMAP DSS rev 2.0
> omapdss DPI error: can't get VDDS_DSI regulator
> omapfb omapfb: failed to connect default display
> omapfb omapfb: failed to init overlay connections
> omapfb omapfb: failed to setup omapfb
> platform omapfb: Driver omapfb requests probe deferral
> 
> I don't see evidence of it being re-probed, but I do see this during boot
> which implies that there's nothing there:
> 
> XIO:  fatal IO error 104 (Connection reset by peer) on X server ":0.0"
>       after 0 requests (0 known processed) with 0 events remaining.

I don't have an LDP board at hand, and I wasn't able to find out anything from
the logs.

I think I should change omapfb to print something if it's probed succesfully,
as the deferred probing makes finding out if something is probed fine or not
quite murky. Without deferred probing, it was simpler: no errors -> the driver
must be (most likely) ok.

Although... In an earlier log, where there was no panel driver, the log has
these errors:

Error opening /dev/fb0: No such device

There are none in the latest log, which makes me guess the omapfb has been
probed, and fb0 is actually there. But the X is still dying for some reason...

I'll look at this more. Maybe someone in our team can find a board to test.
 
> For the SDP4430, it used to detect the displays, even though nothing has
> ever been displayed on them.  Now it just spits out this:

Those particular LCDs are supposed to be updated manually using custom ioctl,
so normal software using fb won't put anything on the display. For testing
purposes, a SW based automatic update (~20 fps) can be enabled by kernel
cmdline parameter "omapfb.auto_update" or via sysfs:

echo 1 > /sys/class/graphics/fb0/update_mode

> OMAP DSS rev 4.0
> omapdss DSI error: can't get VDDS_DSI regulator
> panel-dsi-cm panel-dsi-cm.0: Failed to connect to video source
> omapfb omapfb: failed to connect default display
> omapfb omapfb: failed to init overlay connections
> omapfb omapfb: failed to setup omapfb
> platform omapfb: Driver omapfb requests probe deferral
> ...
> omapdss DSI error: failed to set complexio power state to 1
> panel-dsi-cm panel-dsi-cm.0: failed to enable DSI
> omapfb omapfb: Failed to enable display 'lcd'
> omapfb omapfb: failed to initialize default display
> omapfb omapfb: failed to setup omapfb

Commit e30b06f4d5f000c31a7747a7e7ada78a5fd419a1 (ARM: OMAP2+: Remove legacy mux
code for display.c) was overly enthusiastic in removing legacy code which was
already in use. Tony has a partial revert for that queued up. It can also be
reverted fully for testing. After that, the panel wakes up.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131218/db863376/attachment.sig>

Re: OMAP display subsystem - does it work?

[Russell King - ARM Linux]

On Wed, Dec 18, 2013 at 03:54:42PM +0200, Tomi Valkeinen wrote:
> On 2013-12-18 14:00, Russell King - ARM Linux wrote:
> > For the SDP4430, it used to detect the displays, even though nothing has
> > ever been displayed on them.  Now it just spits out this:
> 
> Those particular LCDs are supposed to be updated manually using custom ioctl,
> so normal software using fb won't put anything on the display. For testing
> purposes, a SW based automatic update (~20 fps) can be enabled by kernel
> cmdline parameter "omapfb.auto_update" or via sysfs:
> 
> echo 1 > /sys/class/graphics/fb0/update_mode

I'm confused.  How then can the original kernel which came with the board
run two gstreamer videos on these displays by just talking to the
framebuffers and play it back smoothly given that we're talking about
video at normal fps settings?

When I received the board, that's exactly what it did at boot up - it
played back two different video trailers, one on each LCD, and the
playback was smooth, just like you'd expect from watching a DVD on your
TV.  No missing frames, which is what you'd get if you tried to update
at 20fps.

OMAP display subsystem - does it work?

[Russell King - ARM Linux]

On Wed, Dec 18, 2013 at 03:54:42PM +0200, Tomi Valkeinen wrote:
> On 2013-12-18 14:00, Russell King - ARM Linux wrote:
> > For the SDP4430, it used to detect the displays, even though nothing has
> > ever been displayed on them.  Now it just spits out this:
> 
> Those particular LCDs are supposed to be updated manually using custom ioctl,
> so normal software using fb won't put anything on the display. For testing
> purposes, a SW based automatic update (~20 fps) can be enabled by kernel
> cmdline parameter "omapfb.auto_update" or via sysfs:
> 
> echo 1 > /sys/class/graphics/fb0/update_mode

I'm confused.  How then can the original kernel which came with the board
run two gstreamer videos on these displays by just talking to the
framebuffers and play it back smoothly given that we're talking about
video at normal fps settings?

When I received the board, that's exactly what it did at boot up - it
played back two different video trailers, one on each LCD, and the
playback was smooth, just like you'd expect from watching a DVD on your
TV.  No missing frames, which is what you'd get if you tried to update
at 20fps.

Re: OMAP display subsystem - does it work?

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 2197 bytes --]

On 2013-12-18 17:29, Russell King - ARM Linux wrote:
> On Wed, Dec 18, 2013 at 03:54:42PM +0200, Tomi Valkeinen wrote:
>> On 2013-12-18 14:00, Russell King - ARM Linux wrote:
>>> For the SDP4430, it used to detect the displays, even though nothing has
>>> ever been displayed on them.  Now it just spits out this:
>>
>> Those particular LCDs are supposed to be updated manually using custom ioctl,
>> so normal software using fb won't put anything on the display. For testing
>> purposes, a SW based automatic update (~20 fps) can be enabled by kernel
>> cmdline parameter "omapfb.auto_update" or via sysfs:
>>
>> echo 1 > /sys/class/graphics/fb0/update_mode
> 
> I'm confused.  How then can the original kernel which came with the board
> run two gstreamer videos on these displays by just talking to the
> framebuffers and play it back smoothly given that we're talking about
> video at normal fps settings?
> 
> When I received the board, that's exactly what it did at boot up - it
> played back two different video trailers, one on each LCD, and the
> playback was smooth, just like you'd expect from watching a DVD on your
> TV.  No missing frames, which is what you'd get if you tried to update
> at 20fps.

We once had auto-update support in omapdss in the early versions. It was
removed quite a while ago, as it was a burden to maintain. Either the
kernel you talk about had the auto-update support, or the userspace has
support for manual-update displays.

The thing is, these LCDs are not meant to be used in auto-update mode.
The main point with LCDs with their own framebuffer is that they are
only updated when needed. So a production device would not need
auto-update support. Furthermore, as these LCDs are quite rare, and
4430SDP is the only one we support having these displays, and that board
itself is not exactly a common one, it was decided that the maintenance
burden is not worth it.

I have been thinking of improving the auto-update in omapfb, but it has
never been on the top of my list (or even middle). The current code
basically does just queue_delayed_work() 20 times per second, so it's
just a hack for testing.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

OMAP display subsystem - does it work?

[Tomi Valkeinen]

On 2013-12-18 17:29, Russell King - ARM Linux wrote:
> On Wed, Dec 18, 2013 at 03:54:42PM +0200, Tomi Valkeinen wrote:
>> On 2013-12-18 14:00, Russell King - ARM Linux wrote:
>>> For the SDP4430, it used to detect the displays, even though nothing has
>>> ever been displayed on them.  Now it just spits out this:
>>
>> Those particular LCDs are supposed to be updated manually using custom ioctl,
>> so normal software using fb won't put anything on the display. For testing
>> purposes, a SW based automatic update (~20 fps) can be enabled by kernel
>> cmdline parameter "omapfb.auto_update" or via sysfs:
>>
>> echo 1 > /sys/class/graphics/fb0/update_mode
> 
> I'm confused.  How then can the original kernel which came with the board
> run two gstreamer videos on these displays by just talking to the
> framebuffers and play it back smoothly given that we're talking about
> video at normal fps settings?
> 
> When I received the board, that's exactly what it did at boot up - it
> played back two different video trailers, one on each LCD, and the
> playback was smooth, just like you'd expect from watching a DVD on your
> TV.  No missing frames, which is what you'd get if you tried to update
> at 20fps.

We once had auto-update support in omapdss in the early versions. It was
removed quite a while ago, as it was a burden to maintain. Either the
kernel you talk about had the auto-update support, or the userspace has
support for manual-update displays.

The thing is, these LCDs are not meant to be used in auto-update mode.
The main point with LCDs with their own framebuffer is that they are
only updated when needed. So a production device would not need
auto-update support. Furthermore, as these LCDs are quite rare, and
4430SDP is the only one we support having these displays, and that board
itself is not exactly a common one, it was decided that the maintenance
burden is not worth it.

I have been thinking of improving the auto-update in omapfb, but it has
never been on the top of my list (or even middle). The current code
basically does just queue_delayed_work() 20 times per second, so it's
just a hack for testing.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131218/e518498b/attachment.sig>

Re: OMAP display subsystem - does it work?

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [131218 05:56]:
> On 2013-12-18 14:00, Russell King - ARM Linux wrote:
> 
> > So, here goes.  LDP3430:
> > 
> > OMAP DSS rev 2.0
> > omapdss DPI error: can't get VDDS_DSI regulator
> > omapfb omapfb: failed to connect default display
> > omapfb omapfb: failed to init overlay connections
> > omapfb omapfb: failed to setup omapfb
> > platform omapfb: Driver omapfb requests probe deferral
> > 
> > I don't see evidence of it being re-probed, but I do see this during boot
> > which implies that there's nothing there:
> > 
> > XIO:  fatal IO error 104 (Connection reset by peer) on X server ":0.0"
> >       after 0 requests (0 known processed) with 0 events remaining.
> 
> I don't have an LDP board at hand, and I wasn't able to find out anything from
> the logs.
> 
> I think I should change omapfb to print something if it's probed succesfully,
> as the deferred probing makes finding out if something is probed fine or not
> quite murky. Without deferred probing, it was simpler: no errors -> the driver
> must be (most likely) ok.
> 
> Although... In an earlier log, where there was no panel driver, the log has
> these errors:
> 
> Error opening /dev/fb0: No such device
> 
> There are none in the latest log, which makes me guess the omapfb has been
> probed, and fb0 is actually there. But the X is still dying for some reason...
> 
> I'll look at this more. Maybe someone in our team can find a board to test.

Hmm I had the framebuffer working with DT on LDP after fixing the twl4030
gpio regression with 0b2aa8bed3e1 (gpio: twl4030: Fix regression for twl
gpio output) using this pdata quirks patch:

[PATCH 3/5] ARM: OMAP2+: Add DT init code for DPI displays and make omap3 LDP to use it

AFAIK the pdata hack above should not be needed now, but I have not tried
with Tomi's DSS DT patches yet.

Tomi do you have some sample panel dpi .dts entry somewhere for the LDP I
could try at some point?

Russell, maybe all you're missing is just omapfb.vram=0:2M,1:5M or similar
from your kernel cmdline?

> > For the SDP4430, it used to detect the displays, even though nothing has
> > ever been displayed on them.  Now it just spits out this:
> 
> Those particular LCDs are supposed to be updated manually using custom ioctl,
> so normal software using fb won't put anything on the display. For testing
> purposes, a SW based automatic update (~20 fps) can be enabled by kernel
> cmdline parameter "omapfb.auto_update" or via sysfs:
> 
> echo 1 > /sys/class/graphics/fb0/update_mode
> 
> > OMAP DSS rev 4.0
> > omapdss DSI error: can't get VDDS_DSI regulator
> > panel-dsi-cm panel-dsi-cm.0: Failed to connect to video source
> > omapfb omapfb: failed to connect default display
> > omapfb omapfb: failed to init overlay connections
> > omapfb omapfb: failed to setup omapfb
> > platform omapfb: Driver omapfb requests probe deferral
> > ...
> > omapdss DSI error: failed to set complexio power state to 1
> > panel-dsi-cm panel-dsi-cm.0: failed to enable DSI
> > omapfb omapfb: Failed to enable display 'lcd'
> > omapfb omapfb: failed to initialize default display
> > omapfb omapfb: failed to setup omapfb
> 
> Commit e30b06f4d5f000c31a7747a7e7ada78a5fd419a1 (ARM: OMAP2+: Remove legacy mux
> code for display.c) was overly enthusiastic in removing legacy code which was
> already in use. Tony has a partial revert for that queued up. It can also be
> reverted fully for testing. After that, the panel wakes up.

Yes sorry for accidentally removing some extra code there, I just sent a
pull request for the fix. My 4430 SDP is face down in the rack because of
the way the Ethernet connector plugs in..

Regards,

Tony

OMAP display subsystem - does it work?

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [131218 05:56]:
> On 2013-12-18 14:00, Russell King - ARM Linux wrote:
> 
> > So, here goes.  LDP3430:
> > 
> > OMAP DSS rev 2.0
> > omapdss DPI error: can't get VDDS_DSI regulator
> > omapfb omapfb: failed to connect default display
> > omapfb omapfb: failed to init overlay connections
> > omapfb omapfb: failed to setup omapfb
> > platform omapfb: Driver omapfb requests probe deferral
> > 
> > I don't see evidence of it being re-probed, but I do see this during boot
> > which implies that there's nothing there:
> > 
> > XIO:  fatal IO error 104 (Connection reset by peer) on X server ":0.0"
> >       after 0 requests (0 known processed) with 0 events remaining.
> 
> I don't have an LDP board at hand, and I wasn't able to find out anything from
> the logs.
> 
> I think I should change omapfb to print something if it's probed succesfully,
> as the deferred probing makes finding out if something is probed fine or not
> quite murky. Without deferred probing, it was simpler: no errors -> the driver
> must be (most likely) ok.
> 
> Although... In an earlier log, where there was no panel driver, the log has
> these errors:
> 
> Error opening /dev/fb0: No such device
> 
> There are none in the latest log, which makes me guess the omapfb has been
> probed, and fb0 is actually there. But the X is still dying for some reason...
> 
> I'll look at this more. Maybe someone in our team can find a board to test.

Hmm I had the framebuffer working with DT on LDP after fixing the twl4030
gpio regression with 0b2aa8bed3e1 (gpio: twl4030: Fix regression for twl
gpio output) using this pdata quirks patch:

[PATCH 3/5] ARM: OMAP2+: Add DT init code for DPI displays and make omap3 LDP to use it

AFAIK the pdata hack above should not be needed now, but I have not tried
with Tomi's DSS DT patches yet.

Tomi do you have some sample panel dpi .dts entry somewhere for the LDP I
could try at some point?

Russell, maybe all you're missing is just omapfb.vram=0:2M,1:5M or similar
from your kernel cmdline?

> > For the SDP4430, it used to detect the displays, even though nothing has
> > ever been displayed on them.  Now it just spits out this:
> 
> Those particular LCDs are supposed to be updated manually using custom ioctl,
> so normal software using fb won't put anything on the display. For testing
> purposes, a SW based automatic update (~20 fps) can be enabled by kernel
> cmdline parameter "omapfb.auto_update" or via sysfs:
> 
> echo 1 > /sys/class/graphics/fb0/update_mode
> 
> > OMAP DSS rev 4.0
> > omapdss DSI error: can't get VDDS_DSI regulator
> > panel-dsi-cm panel-dsi-cm.0: Failed to connect to video source
> > omapfb omapfb: failed to connect default display
> > omapfb omapfb: failed to init overlay connections
> > omapfb omapfb: failed to setup omapfb
> > platform omapfb: Driver omapfb requests probe deferral
> > ...
> > omapdss DSI error: failed to set complexio power state to 1
> > panel-dsi-cm panel-dsi-cm.0: failed to enable DSI
> > omapfb omapfb: Failed to enable display 'lcd'
> > omapfb omapfb: failed to initialize default display
> > omapfb omapfb: failed to setup omapfb
> 
> Commit e30b06f4d5f000c31a7747a7e7ada78a5fd419a1 (ARM: OMAP2+: Remove legacy mux
> code for display.c) was overly enthusiastic in removing legacy code which was
> already in use. Tony has a partial revert for that queued up. It can also be
> reverted fully for testing. After that, the panel wakes up.

Yes sorry for accidentally removing some extra code there, I just sent a
pull request for the fix. My 4430 SDP is face down in the rack because of
the way the Ethernet connector plugs in..

Regards,

Tony

Re: OMAP display subsystem - does it work?

[Tomi Valkeinen]

[-- Attachment #1.1: Type: text/plain, Size: 855 bytes --]

On 2013-12-18 20:23, Tony Lindgren wrote:

> Hmm I had the framebuffer working with DT on LDP after fixing the twl4030
> gpio regression with 0b2aa8bed3e1 (gpio: twl4030: Fix regression for twl
> gpio output) using this pdata quirks patch:
> 
> [PATCH 3/5] ARM: OMAP2+: Add DT init code for DPI displays and make omap3 LDP to use it
> 
> AFAIK the pdata hack above should not be needed now, but I have not tried
> with Tomi's DSS DT patches yet.
> 
> Tomi do you have some sample panel dpi .dts entry somewhere for the LDP I
> could try at some point?

Hmm, I thought this was about legacy booting on v3.14-rc4. That still
uses the board files for omap3.

> Russell, maybe all you're missing is just omapfb.vram=0:2M,1:5M or similar
> from your kernel cmdline?

Nothing like that should be required for normal operation.

 Tomi



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

OMAP display subsystem - does it work?

[Tomi Valkeinen]

On 2013-12-18 20:23, Tony Lindgren wrote:

> Hmm I had the framebuffer working with DT on LDP after fixing the twl4030
> gpio regression with 0b2aa8bed3e1 (gpio: twl4030: Fix regression for twl
> gpio output) using this pdata quirks patch:
> 
> [PATCH 3/5] ARM: OMAP2+: Add DT init code for DPI displays and make omap3 LDP to use it
> 
> AFAIK the pdata hack above should not be needed now, but I have not tried
> with Tomi's DSS DT patches yet.
> 
> Tomi do you have some sample panel dpi .dts entry somewhere for the LDP I
> could try at some point?

Hmm, I thought this was about legacy booting on v3.14-rc4. That still
uses the board files for omap3.

> Russell, maybe all you're missing is just omapfb.vram=0:2M,1:5M or similar
> from your kernel cmdline?

Nothing like that should be required for normal operation.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131219/fbc28d3b/attachment.sig>

Re: OMAP display subsystem - does it work?

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [131218 21:24]:
> On 2013-12-18 20:23, Tony Lindgren wrote:
> 
> > Hmm I had the framebuffer working with DT on LDP after fixing the twl4030
> > gpio regression with 0b2aa8bed3e1 (gpio: twl4030: Fix regression for twl
> > gpio output) using this pdata quirks patch:
> > 
> > [PATCH 3/5] ARM: OMAP2+: Add DT init code for DPI displays and make omap3 LDP to use it
> > 
> > AFAIK the pdata hack above should not be needed now, but I have not tried
> > with Tomi's DSS DT patches yet.
> > 
> > Tomi do you have some sample panel dpi .dts entry somewhere for the LDP I
> > could try at some point?
> 
> Hmm, I thought this was about legacy booting on v3.14-rc4. That still
> uses the board files for omap3.

AFAIK 0b2aa8bed3e1 was the only thing needed for legacy booting and it's
in -rc4.
 
> > Russell, maybe all you're missing is just omapfb.vram=0:2M,1:5M or similar
> > from your kernel cmdline?
> 
> Nothing like that should be required for normal operation.

Hmm maybe these instructions need some updating then:

http://omappedia.org/wiki/Bootargs_for_enabling_display

Regards,

Tony

OMAP display subsystem - does it work?

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [131218 21:24]:
> On 2013-12-18 20:23, Tony Lindgren wrote:
> 
> > Hmm I had the framebuffer working with DT on LDP after fixing the twl4030
> > gpio regression with 0b2aa8bed3e1 (gpio: twl4030: Fix regression for twl
> > gpio output) using this pdata quirks patch:
> > 
> > [PATCH 3/5] ARM: OMAP2+: Add DT init code for DPI displays and make omap3 LDP to use it
> > 
> > AFAIK the pdata hack above should not be needed now, but I have not tried
> > with Tomi's DSS DT patches yet.
> > 
> > Tomi do you have some sample panel dpi .dts entry somewhere for the LDP I
> > could try at some point?
> 
> Hmm, I thought this was about legacy booting on v3.14-rc4. That still
> uses the board files for omap3.

AFAIK 0b2aa8bed3e1 was the only thing needed for legacy booting and it's
in -rc4.
 
> > Russell, maybe all you're missing is just omapfb.vram=0:2M,1:5M or similar
> > from your kernel cmdline?
> 
> Nothing like that should be required for normal operation.

Hmm maybe these instructions need some updating then:

http://omappedia.org/wiki/Bootargs_for_enabling_display

Regards,

Tony

Re: OMAP display subsystem - does it work?

[Russell King - ARM Linux]

On Wed, Dec 18, 2013 at 03:54:42PM +0200, Tomi Valkeinen wrote:
> On 2013-12-18 14:00, Russell King - ARM Linux wrote:
> 
> > So, here goes.  LDP3430:
> > 
> > OMAP DSS rev 2.0
> > omapdss DPI error: can't get VDDS_DSI regulator
> > omapfb omapfb: failed to connect default display
> > omapfb omapfb: failed to init overlay connections
> > omapfb omapfb: failed to setup omapfb
> > platform omapfb: Driver omapfb requests probe deferral
> > 
> > I don't see evidence of it being re-probed, but I do see this during boot
> > which implies that there's nothing there:
> > 
> > XIO:  fatal IO error 104 (Connection reset by peer) on X server ":0.0"
> >       after 0 requests (0 known processed) with 0 events remaining.
> 
> I don't have an LDP board at hand, and I wasn't able to find out anything
> from the logs.

Well, the X server dies because of some issue with tslib.  No idea
about that.  However, disabling touschreen stuff, the X server comes
up, but the LCD remains blank.

Since the LDP has openembedded stuff on it, it normally would boot
with a progress splash - that also is never displayed.  Maybe there's
something up with the backlight support?  This used to work with
mainline kernels I don't know how long ago.

OMAP display subsystem - does it work?

[Russell King - ARM Linux]

On Wed, Dec 18, 2013 at 03:54:42PM +0200, Tomi Valkeinen wrote:
> On 2013-12-18 14:00, Russell King - ARM Linux wrote:
> 
> > So, here goes.  LDP3430:
> > 
> > OMAP DSS rev 2.0
> > omapdss DPI error: can't get VDDS_DSI regulator
> > omapfb omapfb: failed to connect default display
> > omapfb omapfb: failed to init overlay connections
> > omapfb omapfb: failed to setup omapfb
> > platform omapfb: Driver omapfb requests probe deferral
> > 
> > I don't see evidence of it being re-probed, but I do see this during boot
> > which implies that there's nothing there:
> > 
> > XIO:  fatal IO error 104 (Connection reset by peer) on X server ":0.0"
> >       after 0 requests (0 known processed) with 0 events remaining.
> 
> I don't have an LDP board at hand, and I wasn't able to find out anything
> from the logs.

Well, the X server dies because of some issue with tslib.  No idea
about that.  However, disabling touschreen stuff, the X server comes
up, but the LCD remains blank.

Since the LDP has openembedded stuff on it, it normally would boot
with a progress splash - that also is never displayed.  Maybe there's
something up with the backlight support?  This used to work with
mainline kernels I don't know how long ago.

Re: OMAP display subsystem - does it work?

[Russell King - ARM Linux]

On Wed, Dec 18, 2013 at 10:23:54AM -0800, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [131218 05:56]:
> > I don't have an LDP board at hand, and I wasn't able to find out anything from
> > the logs.
> > 
> > I think I should change omapfb to print something if it's probed succesfully,
> > as the deferred probing makes finding out if something is probed fine or not
> > quite murky. Without deferred probing, it was simpler: no errors -> the driver
> > must be (most likely) ok.
> > 
> > Although... In an earlier log, where there was no panel driver, the log has
> > these errors:
> > 
> > Error opening /dev/fb0: No such device
> > 
> > There are none in the latest log, which makes me guess the omapfb has been
> > probed, and fb0 is actually there. But the X is still dying for some reason...
> > 
> > I'll look at this more. Maybe someone in our team can find a board to test.
> 
> Hmm I had the framebuffer working with DT on LDP after fixing the twl4030
> gpio regression with 0b2aa8bed3e1 (gpio: twl4030: Fix regression for twl
> gpio output) using this pdata quirks patch:
> 
> [PATCH 3/5] ARM: OMAP2+: Add DT init code for DPI displays and make omap3 LDP to use it
> 
> AFAIK the pdata hack above should not be needed now, but I have not tried
> with Tomi's DSS DT patches yet.
> 
> Tomi do you have some sample panel dpi .dts entry somewhere for the LDP I
> could try at some point?
> 
> Russell, maybe all you're missing is just omapfb.vram=0:2M,1:5M or similar
> from your kernel cmdline?

Note that I'm trying to get non-DT stuff working properly here first, in
such a state that it has done in the past with mainline kernels.  This is
quite an old regression, but it's still a regression nevertheless.

I've just built and booted a kernel with the backlight support in.  No
change.

OMAP display subsystem - does it work?

[Russell King - ARM Linux]

On Wed, Dec 18, 2013 at 10:23:54AM -0800, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [131218 05:56]:
> > I don't have an LDP board at hand, and I wasn't able to find out anything from
> > the logs.
> > 
> > I think I should change omapfb to print something if it's probed succesfully,
> > as the deferred probing makes finding out if something is probed fine or not
> > quite murky. Without deferred probing, it was simpler: no errors -> the driver
> > must be (most likely) ok.
> > 
> > Although... In an earlier log, where there was no panel driver, the log has
> > these errors:
> > 
> > Error opening /dev/fb0: No such device
> > 
> > There are none in the latest log, which makes me guess the omapfb has been
> > probed, and fb0 is actually there. But the X is still dying for some reason...
> > 
> > I'll look at this more. Maybe someone in our team can find a board to test.
> 
> Hmm I had the framebuffer working with DT on LDP after fixing the twl4030
> gpio regression with 0b2aa8bed3e1 (gpio: twl4030: Fix regression for twl
> gpio output) using this pdata quirks patch:
> 
> [PATCH 3/5] ARM: OMAP2+: Add DT init code for DPI displays and make omap3 LDP to use it
> 
> AFAIK the pdata hack above should not be needed now, but I have not tried
> with Tomi's DSS DT patches yet.
> 
> Tomi do you have some sample panel dpi .dts entry somewhere for the LDP I
> could try at some point?
> 
> Russell, maybe all you're missing is just omapfb.vram=0:2M,1:5M or similar
> from your kernel cmdline?

Note that I'm trying to get non-DT stuff working properly here first, in
such a state that it has done in the past with mainline kernels.  This is
quite an old regression, but it's still a regression nevertheless.

I've just built and booted a kernel with the backlight support in.  No
change.

Re: OMAP display subsystem - does it work?

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [131219 09:58]:
> On Wed, Dec 18, 2013 at 10:23:54AM -0800, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [131218 05:56]:
> > > I don't have an LDP board at hand, and I wasn't able to find out anything from
> > > the logs.
> > > 
> > > I think I should change omapfb to print something if it's probed succesfully,
> > > as the deferred probing makes finding out if something is probed fine or not
> > > quite murky. Without deferred probing, it was simpler: no errors -> the driver
> > > must be (most likely) ok.
> > > 
> > > Although... In an earlier log, where there was no panel driver, the log has
> > > these errors:
> > > 
> > > Error opening /dev/fb0: No such device
> > > 
> > > There are none in the latest log, which makes me guess the omapfb has been
> > > probed, and fb0 is actually there. But the X is still dying for some reason...
> > > 
> > > I'll look at this more. Maybe someone in our team can find a board to test.
> > 
> > Hmm I had the framebuffer working with DT on LDP after fixing the twl4030
> > gpio regression with 0b2aa8bed3e1 (gpio: twl4030: Fix regression for twl
> > gpio output) using this pdata quirks patch:
> > 
> > [PATCH 3/5] ARM: OMAP2+: Add DT init code for DPI displays and make omap3 LDP to use it
> > 
> > AFAIK the pdata hack above should not be needed now, but I have not tried
> > with Tomi's DSS DT patches yet.
> > 
> > Tomi do you have some sample panel dpi .dts entry somewhere for the LDP I
> > could try at some point?
> > 
> > Russell, maybe all you're missing is just omapfb.vram=0:2M,1:5M or similar
> > from your kernel cmdline?
> 
> Note that I'm trying to get non-DT stuff working properly here first, in
> such a state that it has done in the past with mainline kernels.  This is
> quite an old regression, but it's still a regression nevertheless.

Yeah that should just work now.
 
> I've just built and booted a kernel with the backlight support in.  No
> change.

I just tried it here with v3.13-rc4 in legacy mode using omap2plus_defconfig
with the following test script and seems to work just fine for producing a
nice random color pattern on the LCD:

#!/bin/sh
mount -o rw,remount /
depmod -a
modprobe panel-generic-dpi
modprobe panel-dpi
modprobe omapfb vram=0:2M,1:5M
if [ -c /dev/fb0 ]; then
        dd if=/dev/urandom of=/dev/fb0;
fi

Note that as the panel name has changed recently so my script tries to
load both panel modules.

Maybe you're missing something from your .config file still?

BTW, I'm seeing MMC errors with my LDP here though, does that work
for you?

Regards,

Tony

OMAP display subsystem - does it work?

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [131219 09:58]:
> On Wed, Dec 18, 2013 at 10:23:54AM -0800, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [131218 05:56]:
> > > I don't have an LDP board at hand, and I wasn't able to find out anything from
> > > the logs.
> > > 
> > > I think I should change omapfb to print something if it's probed succesfully,
> > > as the deferred probing makes finding out if something is probed fine or not
> > > quite murky. Without deferred probing, it was simpler: no errors -> the driver
> > > must be (most likely) ok.
> > > 
> > > Although... In an earlier log, where there was no panel driver, the log has
> > > these errors:
> > > 
> > > Error opening /dev/fb0: No such device
> > > 
> > > There are none in the latest log, which makes me guess the omapfb has been
> > > probed, and fb0 is actually there. But the X is still dying for some reason...
> > > 
> > > I'll look at this more. Maybe someone in our team can find a board to test.
> > 
> > Hmm I had the framebuffer working with DT on LDP after fixing the twl4030
> > gpio regression with 0b2aa8bed3e1 (gpio: twl4030: Fix regression for twl
> > gpio output) using this pdata quirks patch:
> > 
> > [PATCH 3/5] ARM: OMAP2+: Add DT init code for DPI displays and make omap3 LDP to use it
> > 
> > AFAIK the pdata hack above should not be needed now, but I have not tried
> > with Tomi's DSS DT patches yet.
> > 
> > Tomi do you have some sample panel dpi .dts entry somewhere for the LDP I
> > could try at some point?
> > 
> > Russell, maybe all you're missing is just omapfb.vram=0:2M,1:5M or similar
> > from your kernel cmdline?
> 
> Note that I'm trying to get non-DT stuff working properly here first, in
> such a state that it has done in the past with mainline kernels.  This is
> quite an old regression, but it's still a regression nevertheless.

Yeah that should just work now.
 
> I've just built and booted a kernel with the backlight support in.  No
> change.

I just tried it here with v3.13-rc4 in legacy mode using omap2plus_defconfig
with the following test script and seems to work just fine for producing a
nice random color pattern on the LCD:

#!/bin/sh
mount -o rw,remount /
depmod -a
modprobe panel-generic-dpi
modprobe panel-dpi
modprobe omapfb vram=0:2M,1:5M
if [ -c /dev/fb0 ]; then
        dd if=/dev/urandom of=/dev/fb0;
fi

Note that as the panel name has changed recently so my script tries to
load both panel modules.

Maybe you're missing something from your .config file still?

BTW, I'm seeing MMC errors with my LDP here though, does that work
for you?

Regards,

Tony

Re: OMAP display subsystem - does it work?

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 693 bytes --]

On 2013-12-19 18:56, Tony Lindgren wrote:

>>> Russell, maybe all you're missing is just omapfb.vram=0:2M,1:5M or similar
>>> from your kernel cmdline?
>>
>> Nothing like that should be required for normal operation.
> 
> Hmm maybe these instructions need some updating then:
> 
> http://omappedia.org/wiki/Bootargs_for_enabling_display

The page says omapfb.vram "can" be used, and "If the size is not
specified, frame buffers with default size are created". You only need
omapfb.vram option if you want to allocate extra memory for the fb.

The plain 'vram' option has no function anymore, now that we're using
normal dma alloc. So that part should be updated.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

OMAP display subsystem - does it work?

[Tomi Valkeinen]

On 2013-12-19 18:56, Tony Lindgren wrote:

>>> Russell, maybe all you're missing is just omapfb.vram=0:2M,1:5M or similar
>>> from your kernel cmdline?
>>
>> Nothing like that should be required for normal operation.
> 
> Hmm maybe these instructions need some updating then:
> 
> http://omappedia.org/wiki/Bootargs_for_enabling_display

The page says omapfb.vram "can" be used, and "If the size is not
specified, frame buffers with default size are created". You only need
omapfb.vram option if you want to allocate extra memory for the fb.

The plain 'vram' option has no function anymore, now that we're using
normal dma alloc. So that part should be updated.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131220/19bb3721/attachment.sig>

Re: OMAP display subsystem - does it work?

[Russell King - ARM Linux]

On Thu, Dec 19, 2013 at 10:22:53AM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [131219 09:58]:
> > On Wed, Dec 18, 2013 at 10:23:54AM -0800, Tony Lindgren wrote:
> > > * Tomi Valkeinen <tomi.valkeinen@ti.com> [131218 05:56]:
> > > > I don't have an LDP board at hand, and I wasn't able to find out anything from
> > > > the logs.
> > > > 
> > > > I think I should change omapfb to print something if it's probed succesfully,
> > > > as the deferred probing makes finding out if something is probed fine or not
> > > > quite murky. Without deferred probing, it was simpler: no errors -> the driver
> > > > must be (most likely) ok.
> > > > 
> > > > Although... In an earlier log, where there was no panel driver, the log has
> > > > these errors:
> > > > 
> > > > Error opening /dev/fb0: No such device
> > > > 
> > > > There are none in the latest log, which makes me guess the omapfb has been
> > > > probed, and fb0 is actually there. But the X is still dying for some reason...
> > > > 
> > > > I'll look at this more. Maybe someone in our team can find a board to test.
> > > 
> > > Hmm I had the framebuffer working with DT on LDP after fixing the twl4030
> > > gpio regression with 0b2aa8bed3e1 (gpio: twl4030: Fix regression for twl
> > > gpio output) using this pdata quirks patch:
> > > 
> > > [PATCH 3/5] ARM: OMAP2+: Add DT init code for DPI displays and make omap3 LDP to use it
> > > 
> > > AFAIK the pdata hack above should not be needed now, but I have not tried
> > > with Tomi's DSS DT patches yet.
> > > 
> > > Tomi do you have some sample panel dpi .dts entry somewhere for the LDP I
> > > could try at some point?
> > > 
> > > Russell, maybe all you're missing is just omapfb.vram=0:2M,1:5M or similar
> > > from your kernel cmdline?
> > 
> > Note that I'm trying to get non-DT stuff working properly here first, in
> > such a state that it has done in the past with mainline kernels.  This is
> > quite an old regression, but it's still a regression nevertheless.
> 
> Yeah that should just work now.
>  
> > I've just built and booted a kernel with the backlight support in.  No
> > change.
> 
> I just tried it here with v3.13-rc4 in legacy mode using omap2plus_defconfig
> with the following test script and seems to work just fine for producing a
> nice random color pattern on the LCD:
> 
> #!/bin/sh
> mount -o rw,remount /
> depmod -a
> modprobe panel-generic-dpi
> modprobe panel-dpi
> modprobe omapfb vram=0:2M,1:5M
> if [ -c /dev/fb0 ]; then
>         dd if=/dev/urandom of=/dev/fb0;
> fi
> 
> Note that as the panel name has changed recently so my script tries to
> load both panel modules.

I don't think the problem is with the creation of the framebuffer.

> Maybe you're missing something from your .config file still?

Maybe, but that's the problem - finding out what is missing.  This is the
endless problem where things keep changing - it's very difficult to keep
a "working configuration" working because the config symbols keep changing.

Also, bear in mind that there's many different variants of the LDP hardware
with stuff connected up in different ways (I'm aware that the keypad is
just randomly allocated).  I wouldn't be surprised if this also applied
to how the backlight on the LCD was done.

> BTW, I'm seeing MMC errors with my LDP here though, does that work
> for you?

I see no errors there.

Okay, while digging through the changes, I found this - this is the old
code.  gpio + 15 is the backlight enable GPIO.

 static int ldp_twl_gpio_setup(struct device *dev, unsigned gpio, unsigned ngpio)
 {
-       ldp_panel_data.gpios[0] = gpio + 7;
-       ldp_panel_data.gpio_invert[0] = true;

-       ldp_panel_data.gpios[1] = gpio + 15;
-       ldp_panel_data.gpio_invert[1] = true;

        return 0;
 }

...

-static int generic_dpi_panel_power_on(struct omap_dss_device *dssdev)
-{
...
-       for (i = 0; i < panel_data->num_gpios; ++i) {
-               gpio_set_value_cansleep(panel_data->gpios[i],
-                               panel_data->gpio_invert[i] ? 0 : 1);
-       }

-static void generic_dpi_panel_power_off(struct omap_dss_device *dssdev)
-{
...
-       for (i = panel_data->num_gpios - 1; i >= 0; --i) {
-               gpio_set_value_cansleep(panel_data->gpios[i],
-                               panel_data->gpio_invert[i] ? 1 : 0);
-       }

-static int generic_dpi_panel_probe(struct omap_dss_device *dssdev)
-{
-       for (i = 0; i < panel_data->num_gpios; ++i) {
-               r = devm_gpio_request_one(dssdev->dev, panel_data->gpios[i],
-                               panel_data->gpio_invert[i] ?
-                               GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW,
-                               "panel gpio");
-               if (r)
-                       return r;
-       }

So, when gpio_invert[] is set, the signal is active low for "on".  What
does the new code do?

 static int ldp_twl_gpio_setup(struct device *dev, unsigned gpio, unsigned ngpio)
 {
+       /* LCD enable GPIO */
+       ldp_lcd_pdata.enable_gpio = gpio + 7;

+       /* Backlight enable GPIO */
+       ldp_lcd_pdata.backlight_gpio = gpio + 15;
...

static int panel_dpi_enable(struct omap_dss_device *dssdev)
{
...
        if (gpio_is_valid(ddata->backlight_gpio))
                gpio_set_value_cansleep(ddata->backlight_gpio, 1);

...
static void panel_dpi_disable(struct omap_dss_device *dssdev)
{
...
        if (gpio_is_valid(ddata->backlight_gpio))
                gpio_set_value_cansleep(ddata->backlight_gpio, 0);

...
static int panel_dpi_probe(struct platform_device *pdev)
{
...
        if (gpio_is_valid(ddata->backlight_gpio)) {
                r = devm_gpio_request_one(&pdev->dev, ddata->backlight_gpio,
                                GPIOF_OUT_INIT_LOW, "panel backlight");

which is fixed at active-high for "on".

Would you like to revise whether this works for you... I suspect that
you're missing configuration which means that the backlight_gpio is
not valid, and hence it's being left in same default state (maybe by
the boot loader?)

OMAP display subsystem - does it work?

[Russell King - ARM Linux]

On Thu, Dec 19, 2013 at 10:22:53AM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [131219 09:58]:
> > On Wed, Dec 18, 2013 at 10:23:54AM -0800, Tony Lindgren wrote:
> > > * Tomi Valkeinen <tomi.valkeinen@ti.com> [131218 05:56]:
> > > > I don't have an LDP board at hand, and I wasn't able to find out anything from
> > > > the logs.
> > > > 
> > > > I think I should change omapfb to print something if it's probed succesfully,
> > > > as the deferred probing makes finding out if something is probed fine or not
> > > > quite murky. Without deferred probing, it was simpler: no errors -> the driver
> > > > must be (most likely) ok.
> > > > 
> > > > Although... In an earlier log, where there was no panel driver, the log has
> > > > these errors:
> > > > 
> > > > Error opening /dev/fb0: No such device
> > > > 
> > > > There are none in the latest log, which makes me guess the omapfb has been
> > > > probed, and fb0 is actually there. But the X is still dying for some reason...
> > > > 
> > > > I'll look at this more. Maybe someone in our team can find a board to test.
> > > 
> > > Hmm I had the framebuffer working with DT on LDP after fixing the twl4030
> > > gpio regression with 0b2aa8bed3e1 (gpio: twl4030: Fix regression for twl
> > > gpio output) using this pdata quirks patch:
> > > 
> > > [PATCH 3/5] ARM: OMAP2+: Add DT init code for DPI displays and make omap3 LDP to use it
> > > 
> > > AFAIK the pdata hack above should not be needed now, but I have not tried
> > > with Tomi's DSS DT patches yet.
> > > 
> > > Tomi do you have some sample panel dpi .dts entry somewhere for the LDP I
> > > could try at some point?
> > > 
> > > Russell, maybe all you're missing is just omapfb.vram=0:2M,1:5M or similar
> > > from your kernel cmdline?
> > 
> > Note that I'm trying to get non-DT stuff working properly here first, in
> > such a state that it has done in the past with mainline kernels.  This is
> > quite an old regression, but it's still a regression nevertheless.
> 
> Yeah that should just work now.
>  
> > I've just built and booted a kernel with the backlight support in.  No
> > change.
> 
> I just tried it here with v3.13-rc4 in legacy mode using omap2plus_defconfig
> with the following test script and seems to work just fine for producing a
> nice random color pattern on the LCD:
> 
> #!/bin/sh
> mount -o rw,remount /
> depmod -a
> modprobe panel-generic-dpi
> modprobe panel-dpi
> modprobe omapfb vram=0:2M,1:5M
> if [ -c /dev/fb0 ]; then
>         dd if=/dev/urandom of=/dev/fb0;
> fi
> 
> Note that as the panel name has changed recently so my script tries to
> load both panel modules.

I don't think the problem is with the creation of the framebuffer.

> Maybe you're missing something from your .config file still?

Maybe, but that's the problem - finding out what is missing.  This is the
endless problem where things keep changing - it's very difficult to keep
a "working configuration" working because the config symbols keep changing.

Also, bear in mind that there's many different variants of the LDP hardware
with stuff connected up in different ways (I'm aware that the keypad is
just randomly allocated).  I wouldn't be surprised if this also applied
to how the backlight on the LCD was done.

> BTW, I'm seeing MMC errors with my LDP here though, does that work
> for you?

I see no errors there.

Okay, while digging through the changes, I found this - this is the old
code.  gpio + 15 is the backlight enable GPIO.

 static int ldp_twl_gpio_setup(struct device *dev, unsigned gpio, unsigned ngpio)
 {
-       ldp_panel_data.gpios[0] = gpio + 7;
-       ldp_panel_data.gpio_invert[0] = true;

-       ldp_panel_data.gpios[1] = gpio + 15;
-       ldp_panel_data.gpio_invert[1] = true;

        return 0;
 }

...

-static int generic_dpi_panel_power_on(struct omap_dss_device *dssdev)
-{
...
-       for (i = 0; i < panel_data->num_gpios; ++i) {
-               gpio_set_value_cansleep(panel_data->gpios[i],
-                               panel_data->gpio_invert[i] ? 0 : 1);
-       }

-static void generic_dpi_panel_power_off(struct omap_dss_device *dssdev)
-{
...
-       for (i = panel_data->num_gpios - 1; i >= 0; --i) {
-               gpio_set_value_cansleep(panel_data->gpios[i],
-                               panel_data->gpio_invert[i] ? 1 : 0);
-       }

-static int generic_dpi_panel_probe(struct omap_dss_device *dssdev)
-{
-       for (i = 0; i < panel_data->num_gpios; ++i) {
-               r = devm_gpio_request_one(dssdev->dev, panel_data->gpios[i],
-                               panel_data->gpio_invert[i] ?
-                               GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW,
-                               "panel gpio");
-               if (r)
-                       return r;
-       }

So, when gpio_invert[] is set, the signal is active low for "on".  What
does the new code do?

 static int ldp_twl_gpio_setup(struct device *dev, unsigned gpio, unsigned ngpio)
 {
+       /* LCD enable GPIO */
+       ldp_lcd_pdata.enable_gpio = gpio + 7;

+       /* Backlight enable GPIO */
+       ldp_lcd_pdata.backlight_gpio = gpio + 15;
...

static int panel_dpi_enable(struct omap_dss_device *dssdev)
{
...
        if (gpio_is_valid(ddata->backlight_gpio))
                gpio_set_value_cansleep(ddata->backlight_gpio, 1);

...
static void panel_dpi_disable(struct omap_dss_device *dssdev)
{
...
        if (gpio_is_valid(ddata->backlight_gpio))
                gpio_set_value_cansleep(ddata->backlight_gpio, 0);

...
static int panel_dpi_probe(struct platform_device *pdev)
{
...
        if (gpio_is_valid(ddata->backlight_gpio)) {
                r = devm_gpio_request_one(&pdev->dev, ddata->backlight_gpio,
                                GPIOF_OUT_INIT_LOW, "panel backlight");

which is fixed at active-high for "on".

Would you like to revise whether this works for you... I suspect that
you're missing configuration which means that the backlight_gpio is
not valid, and hence it's being left in same default state (maybe by
the boot loader?)

Re: OMAP display subsystem - does it work?

[Russell King - ARM Linux]

On Fri, Dec 20, 2013 at 11:27:01AM +0000, Russell King - ARM Linux wrote:
> Maybe, but that's the problem - finding out what is missing.  This is the
> endless problem where things keep changing - it's very difficult to keep
> a "working configuration" working because the config symbols keep changing.
> 
> Also, bear in mind that there's many different variants of the LDP hardware
> with stuff connected up in different ways (I'm aware that the keypad is
> just randomly allocated).  I wouldn't be surprised if this also applied
> to how the backlight on the LCD was done.

Or maybe this is getting buggered by the idiotic deferred probing...  It
seems that the GPIOs for controlling the LCD and backlight aren't even
getting claimed if the DSS modules are built in:

# cat /sys/kernel/debug/gpio
...
GPIOs 238-255, platform/twl4030_gpio, twl4030, can sleep:
# echo panel-dpi.0 > /sys/bus/platform/drivers/panel-dpi/unbind
# echo panel-dpi.0 > /sys/bus/platform/drivers/panel-dpi/bind
# cat /sys/kernel/debug/gpio
...
GPIOs 238-255, platform/twl4030_gpio, twl4030, can sleep:
 gpio-245 (panel enable        ) out lo
 gpio-253 (panel backlight     ) out lo

Tony, try this with the stuff not as modules but built-in.

OMAP display subsystem - does it work?

[Russell King - ARM Linux]

On Fri, Dec 20, 2013 at 11:27:01AM +0000, Russell King - ARM Linux wrote:
> Maybe, but that's the problem - finding out what is missing.  This is the
> endless problem where things keep changing - it's very difficult to keep
> a "working configuration" working because the config symbols keep changing.
> 
> Also, bear in mind that there's many different variants of the LDP hardware
> with stuff connected up in different ways (I'm aware that the keypad is
> just randomly allocated).  I wouldn't be surprised if this also applied
> to how the backlight on the LCD was done.

Or maybe this is getting buggered by the idiotic deferred probing...  It
seems that the GPIOs for controlling the LCD and backlight aren't even
getting claimed if the DSS modules are built in:

# cat /sys/kernel/debug/gpio
...
GPIOs 238-255, platform/twl4030_gpio, twl4030, can sleep:
# echo panel-dpi.0 > /sys/bus/platform/drivers/panel-dpi/unbind
# echo panel-dpi.0 > /sys/bus/platform/drivers/panel-dpi/bind
# cat /sys/kernel/debug/gpio
...
GPIOs 238-255, platform/twl4030_gpio, twl4030, can sleep:
 gpio-245 (panel enable        ) out lo
 gpio-253 (panel backlight     ) out lo

Tony, try this with the stuff not as modules but built-in.

Re: OMAP display subsystem - does it work?

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1885 bytes --]

On 2013-12-20 13:48, Russell King - ARM Linux wrote:
> On Fri, Dec 20, 2013 at 11:27:01AM +0000, Russell King - ARM Linux wrote:
>> Maybe, but that's the problem - finding out what is missing.  This is the
>> endless problem where things keep changing - it's very difficult to keep
>> a "working configuration" working because the config symbols keep changing.
>>
>> Also, bear in mind that there's many different variants of the LDP hardware
>> with stuff connected up in different ways (I'm aware that the keypad is
>> just randomly allocated).  I wouldn't be surprised if this also applied
>> to how the backlight on the LCD was done.

I need to cook up a patch for the gpio active-low problem. I tried to
figure out how to do it with the old GPIO API, but as far as I
understand, I have to do it manually in the driver (as it was done in
the old driver).

> Or maybe this is getting buggered by the idiotic deferred probing...  It
> seems that the GPIOs for controlling the LCD and backlight aren't even
> getting claimed if the DSS modules are built in:
> 
> # cat /sys/kernel/debug/gpio
> ...
> GPIOs 238-255, platform/twl4030_gpio, twl4030, can sleep:
> # echo panel-dpi.0 > /sys/bus/platform/drivers/panel-dpi/unbind
> # echo panel-dpi.0 > /sys/bus/platform/drivers/panel-dpi/bind
> # cat /sys/kernel/debug/gpio
> ...
> GPIOs 238-255, platform/twl4030_gpio, twl4030, can sleep:
>  gpio-245 (panel enable        ) out lo
>  gpio-253 (panel backlight     ) out lo

This looks odd... Presuming the panel device was probed successfully, it
should always get the gpios or return an error. Only if gpio_is_valid()
returns false for the gpio, it skips it and continues. But in this case,
the gpio number comes from the platform data, so it should always be valid.

And if it wasn't probed successfully, then there shouldn't be a fb0.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

OMAP display subsystem - does it work?

[Tomi Valkeinen]

On 2013-12-20 13:48, Russell King - ARM Linux wrote:
> On Fri, Dec 20, 2013 at 11:27:01AM +0000, Russell King - ARM Linux wrote:
>> Maybe, but that's the problem - finding out what is missing.  This is the
>> endless problem where things keep changing - it's very difficult to keep
>> a "working configuration" working because the config symbols keep changing.
>>
>> Also, bear in mind that there's many different variants of the LDP hardware
>> with stuff connected up in different ways (I'm aware that the keypad is
>> just randomly allocated).  I wouldn't be surprised if this also applied
>> to how the backlight on the LCD was done.

I need to cook up a patch for the gpio active-low problem. I tried to
figure out how to do it with the old GPIO API, but as far as I
understand, I have to do it manually in the driver (as it was done in
the old driver).

> Or maybe this is getting buggered by the idiotic deferred probing...  It
> seems that the GPIOs for controlling the LCD and backlight aren't even
> getting claimed if the DSS modules are built in:
> 
> # cat /sys/kernel/debug/gpio
> ...
> GPIOs 238-255, platform/twl4030_gpio, twl4030, can sleep:
> # echo panel-dpi.0 > /sys/bus/platform/drivers/panel-dpi/unbind
> # echo panel-dpi.0 > /sys/bus/platform/drivers/panel-dpi/bind
> # cat /sys/kernel/debug/gpio
> ...
> GPIOs 238-255, platform/twl4030_gpio, twl4030, can sleep:
>  gpio-245 (panel enable        ) out lo
>  gpio-253 (panel backlight     ) out lo

This looks odd... Presuming the panel device was probed successfully, it
should always get the gpios or return an error. Only if gpio_is_valid()
returns false for the gpio, it skips it and continues. But in this case,
the gpio number comes from the platform data, so it should always be valid.

And if it wasn't probed successfully, then there shouldn't be a fb0.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131220/2431be61/attachment.sig>

Re: OMAP display subsystem - does it work?

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [131220 05:45]:
> On 2013-12-20 13:48, Russell King - ARM Linux wrote:
> > On Fri, Dec 20, 2013 at 11:27:01AM +0000, Russell King - ARM Linux wrote:
> >> Maybe, but that's the problem - finding out what is missing.  This is the
> >> endless problem where things keep changing - it's very difficult to keep
> >> a "working configuration" working because the config symbols keep changing.
> >>
> >> Also, bear in mind that there's many different variants of the LDP hardware
> >> with stuff connected up in different ways (I'm aware that the keypad is
> >> just randomly allocated).  I wouldn't be surprised if this also applied
> >> to how the backlight on the LCD was done.
> 
> I need to cook up a patch for the gpio active-low problem. I tried to
> figure out how to do it with the old GPIO API, but as far as I
> understand, I have to do it manually in the driver (as it was done in
> the old driver).
> 
> > Or maybe this is getting buggered by the idiotic deferred probing...  It
> > seems that the GPIOs for controlling the LCD and backlight aren't even
> > getting claimed if the DSS modules are built in:
> > 
> > # cat /sys/kernel/debug/gpio
> > ...
> > GPIOs 238-255, platform/twl4030_gpio, twl4030, can sleep:
> > # echo panel-dpi.0 > /sys/bus/platform/drivers/panel-dpi/unbind
> > # echo panel-dpi.0 > /sys/bus/platform/drivers/panel-dpi/bind
> > # cat /sys/kernel/debug/gpio
> > ...
> > GPIOs 238-255, platform/twl4030_gpio, twl4030, can sleep:
> >  gpio-245 (panel enable        ) out lo
> >  gpio-253 (panel backlight     ) out lo
> 
> This looks odd... Presuming the panel device was probed successfully, it
> should always get the gpios or return an error. Only if gpio_is_valid()
> returns false for the gpio, it skips it and continues. But in this case,
> the gpio number comes from the platform data, so it should always be valid.
> 
> And if it wasn't probed successfully, then there shouldn't be a fb0.

I bet that's it though. If the display is probed before twl4030 GPIO
is initialized, the GPIO numbers will be 0. I'm using omap2plus_defconfig
which has DSS built as modules.

Regards,

Tony

OMAP display subsystem - does it work?

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [131220 05:45]:
> On 2013-12-20 13:48, Russell King - ARM Linux wrote:
> > On Fri, Dec 20, 2013 at 11:27:01AM +0000, Russell King - ARM Linux wrote:
> >> Maybe, but that's the problem - finding out what is missing.  This is the
> >> endless problem where things keep changing - it's very difficult to keep
> >> a "working configuration" working because the config symbols keep changing.
> >>
> >> Also, bear in mind that there's many different variants of the LDP hardware
> >> with stuff connected up in different ways (I'm aware that the keypad is
> >> just randomly allocated).  I wouldn't be surprised if this also applied
> >> to how the backlight on the LCD was done.
> 
> I need to cook up a patch for the gpio active-low problem. I tried to
> figure out how to do it with the old GPIO API, but as far as I
> understand, I have to do it manually in the driver (as it was done in
> the old driver).
> 
> > Or maybe this is getting buggered by the idiotic deferred probing...  It
> > seems that the GPIOs for controlling the LCD and backlight aren't even
> > getting claimed if the DSS modules are built in:
> > 
> > # cat /sys/kernel/debug/gpio
> > ...
> > GPIOs 238-255, platform/twl4030_gpio, twl4030, can sleep:
> > # echo panel-dpi.0 > /sys/bus/platform/drivers/panel-dpi/unbind
> > # echo panel-dpi.0 > /sys/bus/platform/drivers/panel-dpi/bind
> > # cat /sys/kernel/debug/gpio
> > ...
> > GPIOs 238-255, platform/twl4030_gpio, twl4030, can sleep:
> >  gpio-245 (panel enable        ) out lo
> >  gpio-253 (panel backlight     ) out lo
> 
> This looks odd... Presuming the panel device was probed successfully, it
> should always get the gpios or return an error. Only if gpio_is_valid()
> returns false for the gpio, it skips it and continues. But in this case,
> the gpio number comes from the platform data, so it should always be valid.
> 
> And if it wasn't probed successfully, then there shouldn't be a fb0.

I bet that's it though. If the display is probed before twl4030 GPIO
is initialized, the GPIO numbers will be 0. I'm using omap2plus_defconfig
which has DSS built as modules.

Regards,

Tony

Re: OMAP display subsystem - does it work?

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [131220 03:28]:
> 
> > BTW, I'm seeing MMC errors with my LDP here though, does that work
> > for you?
> 
> I see no errors there.

OK thanks that's good to hear. I'm seeing them even after changing the
MMC card, need to check that again though. I'm almost certain it worked
just fine a month ago or so when I was playing with it.. Maybe some dirt
in the contacts or something.
 
> Okay, while digging through the changes, I found this - this is the old
> code.  gpio + 15 is the backlight enable GPIO.
> 
>  static int ldp_twl_gpio_setup(struct device *dev, unsigned gpio, unsigned ngpio)
>  {
> -       ldp_panel_data.gpios[0] = gpio + 7;
> -       ldp_panel_data.gpio_invert[0] = true;
> 
> -       ldp_panel_data.gpios[1] = gpio + 15;
> -       ldp_panel_data.gpio_invert[1] = true;
> 
>         return 0;
>  }
> 
> ...
> 
> -static int generic_dpi_panel_power_on(struct omap_dss_device *dssdev)
> -{
> ...
> -       for (i = 0; i < panel_data->num_gpios; ++i) {
> -               gpio_set_value_cansleep(panel_data->gpios[i],
> -                               panel_data->gpio_invert[i] ? 0 : 1);
> -       }
> 
> -static void generic_dpi_panel_power_off(struct omap_dss_device *dssdev)
> -{
> ...
> -       for (i = panel_data->num_gpios - 1; i >= 0; --i) {
> -               gpio_set_value_cansleep(panel_data->gpios[i],
> -                               panel_data->gpio_invert[i] ? 1 : 0);
> -       }
> 
> -static int generic_dpi_panel_probe(struct omap_dss_device *dssdev)
> -{
> -       for (i = 0; i < panel_data->num_gpios; ++i) {
> -               r = devm_gpio_request_one(dssdev->dev, panel_data->gpios[i],
> -                               panel_data->gpio_invert[i] ?
> -                               GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW,
> -                               "panel gpio");
> -               if (r)
> -                       return r;
> -       }
> 
> So, when gpio_invert[] is set, the signal is active low for "on".  What
> does the new code do?
> 
>  static int ldp_twl_gpio_setup(struct device *dev, unsigned gpio, unsigned ngpio)
>  {
> +       /* LCD enable GPIO */
> +       ldp_lcd_pdata.enable_gpio = gpio + 7;
> 
> +       /* Backlight enable GPIO */
> +       ldp_lcd_pdata.backlight_gpio = gpio + 15;
> ...
> 
> static int panel_dpi_enable(struct omap_dss_device *dssdev)
> {
> ...
>         if (gpio_is_valid(ddata->backlight_gpio))
>                 gpio_set_value_cansleep(ddata->backlight_gpio, 1);
> 
> ...
> static void panel_dpi_disable(struct omap_dss_device *dssdev)
> {
> ...
>         if (gpio_is_valid(ddata->backlight_gpio))
>                 gpio_set_value_cansleep(ddata->backlight_gpio, 0);
> 
> ...
> static int panel_dpi_probe(struct platform_device *pdev)
> {
> ...
>         if (gpio_is_valid(ddata->backlight_gpio)) {
>                 r = devm_gpio_request_one(&pdev->dev, ddata->backlight_gpio,
>                                 GPIOF_OUT_INIT_LOW, "panel backlight");
> 
> which is fixed at active-high for "on".
> 
> Would you like to revise whether this works for you... I suspect that
> you're missing configuration which means that the backlight_gpio is
> not valid, and hence it's being left in same default state (maybe by
> the boot loader?)

Nope, my LCD if off from the bootloader and gets enabled by the kernel.
I think the old gpio_invert was inverting the value unnecessarily or
something, the new code does the right thing without a need for the
gpio_invert flags.

Regards,

Tony

OMAP display subsystem - does it work?

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [131220 03:28]:
> 
> > BTW, I'm seeing MMC errors with my LDP here though, does that work
> > for you?
> 
> I see no errors there.

OK thanks that's good to hear. I'm seeing them even after changing the
MMC card, need to check that again though. I'm almost certain it worked
just fine a month ago or so when I was playing with it.. Maybe some dirt
in the contacts or something.
 
> Okay, while digging through the changes, I found this - this is the old
> code.  gpio + 15 is the backlight enable GPIO.
> 
>  static int ldp_twl_gpio_setup(struct device *dev, unsigned gpio, unsigned ngpio)
>  {
> -       ldp_panel_data.gpios[0] = gpio + 7;
> -       ldp_panel_data.gpio_invert[0] = true;
> 
> -       ldp_panel_data.gpios[1] = gpio + 15;
> -       ldp_panel_data.gpio_invert[1] = true;
> 
>         return 0;
>  }
> 
> ...
> 
> -static int generic_dpi_panel_power_on(struct omap_dss_device *dssdev)
> -{
> ...
> -       for (i = 0; i < panel_data->num_gpios; ++i) {
> -               gpio_set_value_cansleep(panel_data->gpios[i],
> -                               panel_data->gpio_invert[i] ? 0 : 1);
> -       }
> 
> -static void generic_dpi_panel_power_off(struct omap_dss_device *dssdev)
> -{
> ...
> -       for (i = panel_data->num_gpios - 1; i >= 0; --i) {
> -               gpio_set_value_cansleep(panel_data->gpios[i],
> -                               panel_data->gpio_invert[i] ? 1 : 0);
> -       }
> 
> -static int generic_dpi_panel_probe(struct omap_dss_device *dssdev)
> -{
> -       for (i = 0; i < panel_data->num_gpios; ++i) {
> -               r = devm_gpio_request_one(dssdev->dev, panel_data->gpios[i],
> -                               panel_data->gpio_invert[i] ?
> -                               GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW,
> -                               "panel gpio");
> -               if (r)
> -                       return r;
> -       }
> 
> So, when gpio_invert[] is set, the signal is active low for "on".  What
> does the new code do?
> 
>  static int ldp_twl_gpio_setup(struct device *dev, unsigned gpio, unsigned ngpio)
>  {
> +       /* LCD enable GPIO */
> +       ldp_lcd_pdata.enable_gpio = gpio + 7;
> 
> +       /* Backlight enable GPIO */
> +       ldp_lcd_pdata.backlight_gpio = gpio + 15;
> ...
> 
> static int panel_dpi_enable(struct omap_dss_device *dssdev)
> {
> ...
>         if (gpio_is_valid(ddata->backlight_gpio))
>                 gpio_set_value_cansleep(ddata->backlight_gpio, 1);
> 
> ...
> static void panel_dpi_disable(struct omap_dss_device *dssdev)
> {
> ...
>         if (gpio_is_valid(ddata->backlight_gpio))
>                 gpio_set_value_cansleep(ddata->backlight_gpio, 0);
> 
> ...
> static int panel_dpi_probe(struct platform_device *pdev)
> {
> ...
>         if (gpio_is_valid(ddata->backlight_gpio)) {
>                 r = devm_gpio_request_one(&pdev->dev, ddata->backlight_gpio,
>                                 GPIOF_OUT_INIT_LOW, "panel backlight");
> 
> which is fixed at active-high for "on".
> 
> Would you like to revise whether this works for you... I suspect that
> you're missing configuration which means that the backlight_gpio is
> not valid, and hence it's being left in same default state (maybe by
> the boot loader?)

Nope, my LCD if off from the bootloader and gets enabled by the kernel.
I think the old gpio_invert was inverting the value unnecessarily or
something, the new code does the right thing without a need for the
gpio_invert flags.

Regards,

Tony

Re: OMAP display subsystem - does it work?

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [131220 08:06]:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [131220 05:45]:
> > On 2013-12-20 13:48, Russell King - ARM Linux wrote:
> > 
> > > Or maybe this is getting buggered by the idiotic deferred probing...  It
> > > seems that the GPIOs for controlling the LCD and backlight aren't even
> > > getting claimed if the DSS modules are built in:
> > > 
> > > # cat /sys/kernel/debug/gpio
> > > ...
> > > GPIOs 238-255, platform/twl4030_gpio, twl4030, can sleep:
> > > # echo panel-dpi.0 > /sys/bus/platform/drivers/panel-dpi/unbind
> > > # echo panel-dpi.0 > /sys/bus/platform/drivers/panel-dpi/bind
> > > # cat /sys/kernel/debug/gpio
> > > ...
> > > GPIOs 238-255, platform/twl4030_gpio, twl4030, can sleep:
> > >  gpio-245 (panel enable        ) out lo
> > >  gpio-253 (panel backlight     ) out lo
> > 
> > This looks odd... Presuming the panel device was probed successfully, it
> > should always get the gpios or return an error. Only if gpio_is_valid()
> > returns false for the gpio, it skips it and continues. But in this case,
> > the gpio number comes from the platform data, so it should always be valid.
> > 
> > And if it wasn't probed successfully, then there shouldn't be a fb0.
> 
> I bet that's it though. If the display is probed before twl4030 GPIO
> is initialized, the GPIO numbers will be 0. I'm using omap2plus_defconfig
> which has DSS built as modules.

Yeah this seems to do the trick for me for the built-in DSS on LDP.

Tony

8< -----------------------------------
From: Tony Lindgren <tony@atomide.com>
Date: Fri, 20 Dec 2013 08:53:27 -0800
Subject: [PATCH] ARM: OMAP2+: Fix LCD panel backlight regression for LDP legacy booting

Looks like the LCD panel on LDP has been broken quite a while, and
recently got fixed. However, there's still an issue where the panel
backlight does not come on if the LCD drivers are built into the
kernel.

Fix the issue by registering the DPI LCD panel only after the twl4030
GPIO has probed.

Reported-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Tony Lindgren <tony@atomide.com>

--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -248,7 +248,7 @@ static int ldp_twl_gpio_setup(struct device *dev, unsigned gpio, unsigned ngpio)
 	/* Backlight enable GPIO */
 	ldp_lcd_pdata.backlight_gpio = gpio + 15;
 
-	return 0;
+	return platform_device_register(&ldp_lcd_device);
 }
 
 static struct twl4030_gpio_platform_data ldp_gpio_data = {
@@ -346,7 +346,6 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
 
 static struct platform_device *ldp_devices[] __initdata = {
 	&ldp_gpio_keys_device,
-	&ldp_lcd_device,
 };
 
 #ifdef CONFIG_OMAP_MUX

OMAP display subsystem - does it work?

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [131220 08:06]:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [131220 05:45]:
> > On 2013-12-20 13:48, Russell King - ARM Linux wrote:
> > 
> > > Or maybe this is getting buggered by the idiotic deferred probing...  It
> > > seems that the GPIOs for controlling the LCD and backlight aren't even
> > > getting claimed if the DSS modules are built in:
> > > 
> > > # cat /sys/kernel/debug/gpio
> > > ...
> > > GPIOs 238-255, platform/twl4030_gpio, twl4030, can sleep:
> > > # echo panel-dpi.0 > /sys/bus/platform/drivers/panel-dpi/unbind
> > > # echo panel-dpi.0 > /sys/bus/platform/drivers/panel-dpi/bind
> > > # cat /sys/kernel/debug/gpio
> > > ...
> > > GPIOs 238-255, platform/twl4030_gpio, twl4030, can sleep:
> > >  gpio-245 (panel enable        ) out lo
> > >  gpio-253 (panel backlight     ) out lo
> > 
> > This looks odd... Presuming the panel device was probed successfully, it
> > should always get the gpios or return an error. Only if gpio_is_valid()
> > returns false for the gpio, it skips it and continues. But in this case,
> > the gpio number comes from the platform data, so it should always be valid.
> > 
> > And if it wasn't probed successfully, then there shouldn't be a fb0.
> 
> I bet that's it though. If the display is probed before twl4030 GPIO
> is initialized, the GPIO numbers will be 0. I'm using omap2plus_defconfig
> which has DSS built as modules.

Yeah this seems to do the trick for me for the built-in DSS on LDP.

Tony

8< -----------------------------------
From: Tony Lindgren <tony@atomide.com>
Date: Fri, 20 Dec 2013 08:53:27 -0800
Subject: [PATCH] ARM: OMAP2+: Fix LCD panel backlight regression for LDP legacy booting

Looks like the LCD panel on LDP has been broken quite a while, and
recently got fixed. However, there's still an issue where the panel
backlight does not come on if the LCD drivers are built into the
kernel.

Fix the issue by registering the DPI LCD panel only after the twl4030
GPIO has probed.

Reported-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Tony Lindgren <tony@atomide.com>

--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -248,7 +248,7 @@ static int ldp_twl_gpio_setup(struct device *dev, unsigned gpio, unsigned ngpio)
 	/* Backlight enable GPIO */
 	ldp_lcd_pdata.backlight_gpio = gpio + 15;
 
-	return 0;
+	return platform_device_register(&ldp_lcd_device);
 }
 
 static struct twl4030_gpio_platform_data ldp_gpio_data = {
@@ -346,7 +346,6 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
 
 static struct platform_device *ldp_devices[] __initdata = {
 	&ldp_gpio_keys_device,
-	&ldp_lcd_device,
 };
 
 #ifdef CONFIG_OMAP_MUX

Re: OMAP display subsystem - does it work?

[Russell King - ARM Linux]

On Fri, Dec 20, 2013 at 08:55:03AM -0800, Tony Lindgren wrote:
> Yeah this seems to do the trick for me for the built-in DSS on LDP.
> 
> Tony
> 
> 8< -----------------------------------
> From: Tony Lindgren <tony@atomide.com>
> Date: Fri, 20 Dec 2013 08:53:27 -0800
> Subject: [PATCH] ARM: OMAP2+: Fix LCD panel backlight regression for LDP legacy booting
> 
> Looks like the LCD panel on LDP has been broken quite a while, and
> recently got fixed. However, there's still an issue where the panel
> backlight does not come on if the LCD drivers are built into the
> kernel.
> 
> Fix the issue by registering the DPI LCD panel only after the twl4030
> GPIO has probed.
> 
> Reported-by: Russell King <rmk+kernel@arm.linux.org.uk>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> 
> --- a/arch/arm/mach-omap2/board-ldp.c
> +++ b/arch/arm/mach-omap2/board-ldp.c
> @@ -248,7 +248,7 @@ static int ldp_twl_gpio_setup(struct device *dev, unsigned gpio, unsigned ngpio)
>  	/* Backlight enable GPIO */
>  	ldp_lcd_pdata.backlight_gpio = gpio + 15;
>  
> -	return 0;
> +	return platform_device_register(&ldp_lcd_device);
>  }
>  
>  static struct twl4030_gpio_platform_data ldp_gpio_data = {
> @@ -346,7 +346,6 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
>  
>  static struct platform_device *ldp_devices[] __initdata = {
>  	&ldp_gpio_keys_device,
> -	&ldp_lcd_device,
>  };
>  
>  #ifdef CONFIG_OMAP_MUX

I've added it to the test build for tonight (only as an uncommitted
modification) so we'll see what happens tomorrow morning.

OMAP display subsystem - does it work?

[Russell King - ARM Linux]

On Fri, Dec 20, 2013 at 08:55:03AM -0800, Tony Lindgren wrote:
> Yeah this seems to do the trick for me for the built-in DSS on LDP.
> 
> Tony
> 
> 8< -----------------------------------
> From: Tony Lindgren <tony@atomide.com>
> Date: Fri, 20 Dec 2013 08:53:27 -0800
> Subject: [PATCH] ARM: OMAP2+: Fix LCD panel backlight regression for LDP legacy booting
> 
> Looks like the LCD panel on LDP has been broken quite a while, and
> recently got fixed. However, there's still an issue where the panel
> backlight does not come on if the LCD drivers are built into the
> kernel.
> 
> Fix the issue by registering the DPI LCD panel only after the twl4030
> GPIO has probed.
> 
> Reported-by: Russell King <rmk+kernel@arm.linux.org.uk>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> 
> --- a/arch/arm/mach-omap2/board-ldp.c
> +++ b/arch/arm/mach-omap2/board-ldp.c
> @@ -248,7 +248,7 @@ static int ldp_twl_gpio_setup(struct device *dev, unsigned gpio, unsigned ngpio)
>  	/* Backlight enable GPIO */
>  	ldp_lcd_pdata.backlight_gpio = gpio + 15;
>  
> -	return 0;
> +	return platform_device_register(&ldp_lcd_device);
>  }
>  
>  static struct twl4030_gpio_platform_data ldp_gpio_data = {
> @@ -346,7 +346,6 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
>  
>  static struct platform_device *ldp_devices[] __initdata = {
>  	&ldp_gpio_keys_device,
> -	&ldp_lcd_device,
>  };
>  
>  #ifdef CONFIG_OMAP_MUX

I've added it to the test build for tonight (only as an uncommitted
modification) so we'll see what happens tomorrow morning.

Re: OMAP display subsystem - does it work?

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 913 bytes --]

On 2013-12-20 18:04, Tony Lindgren wrote:

>> This looks odd... Presuming the panel device was probed successfully, it
>> should always get the gpios or return an error. Only if gpio_is_valid()
>> returns false for the gpio, it skips it and continues. But in this case,
>> the gpio number comes from the platform data, so it should always be valid.
>>
>> And if it wasn't probed successfully, then there shouldn't be a fb0.
> 
> I bet that's it though. If the display is probed before twl4030 GPIO
> is initialized, the GPIO numbers will be 0. I'm using omap2plus_defconfig
> which has DSS built as modules.

Ah, right, I see. The gpio numbers for the panel pdata are initialized
to -1 (not 0) in the board file. The twl init code will set those to
their appropriate numbers, but if the panel is probed before twl, the
panel driver just presumes gpios are not needed as they are -1.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

OMAP display subsystem - does it work?

[Tomi Valkeinen]

On 2013-12-20 18:04, Tony Lindgren wrote:

>> This looks odd... Presuming the panel device was probed successfully, it
>> should always get the gpios or return an error. Only if gpio_is_valid()
>> returns false for the gpio, it skips it and continues. But in this case,
>> the gpio number comes from the platform data, so it should always be valid.
>>
>> And if it wasn't probed successfully, then there shouldn't be a fb0.
> 
> I bet that's it though. If the display is probed before twl4030 GPIO
> is initialized, the GPIO numbers will be 0. I'm using omap2plus_defconfig
> which has DSS built as modules.

Ah, right, I see. The gpio numbers for the panel pdata are initialized
to -1 (not 0) in the board file. The twl init code will set those to
their appropriate numbers, but if the panel is probed before twl, the
panel driver just presumes gpios are not needed as they are -1.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131223/a6bd5089/attachment.sig>

Re: OMAP display subsystem - does it work?

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1979 bytes --]

On 2013-12-20 18:55, Tony Lindgren wrote:

>> I bet that's it though. If the display is probed before twl4030 GPIO
>> is initialized, the GPIO numbers will be 0. I'm using omap2plus_defconfig
>> which has DSS built as modules.
> 
> Yeah this seems to do the trick for me for the built-in DSS on LDP.
> 
> Tony
> 
> 8< -----------------------------------
> From: Tony Lindgren <tony@atomide.com>
> Date: Fri, 20 Dec 2013 08:53:27 -0800
> Subject: [PATCH] ARM: OMAP2+: Fix LCD panel backlight regression for LDP legacy booting
> 
> Looks like the LCD panel on LDP has been broken quite a while, and
> recently got fixed. However, there's still an issue where the panel
> backlight does not come on if the LCD drivers are built into the
> kernel.
> 
> Fix the issue by registering the DPI LCD panel only after the twl4030
> GPIO has probed.
> 
> Reported-by: Russell King <rmk+kernel@arm.linux.org.uk>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> 
> --- a/arch/arm/mach-omap2/board-ldp.c
> +++ b/arch/arm/mach-omap2/board-ldp.c
> @@ -248,7 +248,7 @@ static int ldp_twl_gpio_setup(struct device *dev, unsigned gpio, unsigned ngpio)
>  	/* Backlight enable GPIO */
>  	ldp_lcd_pdata.backlight_gpio = gpio + 15;
>  
> -	return 0;
> +	return platform_device_register(&ldp_lcd_device);

If the panel device registration fails, does the whole TWL probe fail?
If so, that sounds a bit harsh to me.

>  }
>  
>  static struct twl4030_gpio_platform_data ldp_gpio_data = {
> @@ -346,7 +346,6 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
>  
>  static struct platform_device *ldp_devices[] __initdata = {
>  	&ldp_gpio_keys_device,
> -	&ldp_lcd_device,
>  };
>  
>  #ifdef CONFIG_OMAP_MUX
> 

Looks right to me:

Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

Rather ugly, though, but there's probably no point in trying to do it in
a cleaner way (the new GPIO API, I think?), as we'll move to DT soon.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

OMAP display subsystem - does it work?

[Tomi Valkeinen]

On 2013-12-20 18:55, Tony Lindgren wrote:

>> I bet that's it though. If the display is probed before twl4030 GPIO
>> is initialized, the GPIO numbers will be 0. I'm using omap2plus_defconfig
>> which has DSS built as modules.
> 
> Yeah this seems to do the trick for me for the built-in DSS on LDP.
> 
> Tony
> 
> 8< -----------------------------------
> From: Tony Lindgren <tony@atomide.com>
> Date: Fri, 20 Dec 2013 08:53:27 -0800
> Subject: [PATCH] ARM: OMAP2+: Fix LCD panel backlight regression for LDP legacy booting
> 
> Looks like the LCD panel on LDP has been broken quite a while, and
> recently got fixed. However, there's still an issue where the panel
> backlight does not come on if the LCD drivers are built into the
> kernel.
> 
> Fix the issue by registering the DPI LCD panel only after the twl4030
> GPIO has probed.
> 
> Reported-by: Russell King <rmk+kernel@arm.linux.org.uk>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> 
> --- a/arch/arm/mach-omap2/board-ldp.c
> +++ b/arch/arm/mach-omap2/board-ldp.c
> @@ -248,7 +248,7 @@ static int ldp_twl_gpio_setup(struct device *dev, unsigned gpio, unsigned ngpio)
>  	/* Backlight enable GPIO */
>  	ldp_lcd_pdata.backlight_gpio = gpio + 15;
>  
> -	return 0;
> +	return platform_device_register(&ldp_lcd_device);

If the panel device registration fails, does the whole TWL probe fail?
If so, that sounds a bit harsh to me.

>  }
>  
>  static struct twl4030_gpio_platform_data ldp_gpio_data = {
> @@ -346,7 +346,6 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
>  
>  static struct platform_device *ldp_devices[] __initdata = {
>  	&ldp_gpio_keys_device,
> -	&ldp_lcd_device,
>  };
>  
>  #ifdef CONFIG_OMAP_MUX
> 

Looks right to me:

Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

Rather ugly, though, but there's probably no point in trying to do it in
a cleaner way (the new GPIO API, I think?), as we'll move to DT soon.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131223/c560f9ab/attachment.sig>

Re: OMAP display subsystem - does it work?

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [131222 23:55]:
> On 2013-12-20 18:55, Tony Lindgren wrote:
> > --- a/arch/arm/mach-omap2/board-ldp.c
> > +++ b/arch/arm/mach-omap2/board-ldp.c
> > @@ -248,7 +248,7 @@ static int ldp_twl_gpio_setup(struct device *dev, unsigned gpio, unsigned ngpio)
> >  	/* Backlight enable GPIO */
> >  	ldp_lcd_pdata.backlight_gpio = gpio + 15;
> >  
> > -	return 0;
> > +	return platform_device_register(&ldp_lcd_device);
> 
> If the panel device registration fails, does the whole TWL probe fail?
> If so, that sounds a bit harsh to me.

OK I've applied the updated version below which does not make the
TWL GPIO probe to fail on errors.
 
> Looks right to me:
> 
> Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> 
> Rather ugly, though, but there's probably no point in trying to do it in
> a cleaner way (the new GPIO API, I think?), as we'll move to DT soon.

Yes we should not need the callbacks just to set TWL GPIO numbers
when booted with DT so this problem will disappear.

Updated patch below for reference, I kept your ack hope that's OK with
you.

Regards,

Tony

8< --------------------------------
From: Tony Lindgren <tony@atomide.com>
Date: Fri, 27 Dec 2013 09:33:27 -0800
Subject: [PATCH] ARM: OMAP2+: Fix LCD panel backlight regression for LDP legacy booting

Looks like the LCD panel on LDP has been broken quite a while, and
recently got fixed by commit 0b2aa8bed3e1 (gpio: twl4030: Fix regression
for twl gpio output). However, there's still an issue left where the panel
backlight does not come on if the LCD drivers are built into the
kernel.

Fix the issue by registering the DPI LCD panel only after the twl4030
GPIO has probed.

Reported-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
[tony@atomide.com: updated per Tomi's comments]
Signed-off-by: Tony Lindgren <tony@atomide.com>

--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -242,12 +242,18 @@ static void __init ldp_display_init(void)
 
 static int ldp_twl_gpio_setup(struct device *dev, unsigned gpio, unsigned ngpio)
 {
+	int res;
+
 	/* LCD enable GPIO */
 	ldp_lcd_pdata.enable_gpio = gpio + 7;
 
 	/* Backlight enable GPIO */
 	ldp_lcd_pdata.backlight_gpio = gpio + 15;
 
+	res = platform_device_register(&ldp_lcd_device);
+	if (res)
+		pr_err("Unable to register LCD: %d\n", res);
+
 	return 0;
 }
 
@@ -346,7 +352,6 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
 
 static struct platform_device *ldp_devices[] __initdata = {
 	&ldp_gpio_keys_device,
-	&ldp_lcd_device,
 };
 
 #ifdef CONFIG_OMAP_MUX

OMAP display subsystem - does it work?

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [131222 23:55]:
> On 2013-12-20 18:55, Tony Lindgren wrote:
> > --- a/arch/arm/mach-omap2/board-ldp.c
> > +++ b/arch/arm/mach-omap2/board-ldp.c
> > @@ -248,7 +248,7 @@ static int ldp_twl_gpio_setup(struct device *dev, unsigned gpio, unsigned ngpio)
> >  	/* Backlight enable GPIO */
> >  	ldp_lcd_pdata.backlight_gpio = gpio + 15;
> >  
> > -	return 0;
> > +	return platform_device_register(&ldp_lcd_device);
> 
> If the panel device registration fails, does the whole TWL probe fail?
> If so, that sounds a bit harsh to me.

OK I've applied the updated version below which does not make the
TWL GPIO probe to fail on errors.
 
> Looks right to me:
> 
> Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> 
> Rather ugly, though, but there's probably no point in trying to do it in
> a cleaner way (the new GPIO API, I think?), as we'll move to DT soon.

Yes we should not need the callbacks just to set TWL GPIO numbers
when booted with DT so this problem will disappear.

Updated patch below for reference, I kept your ack hope that's OK with
you.

Regards,

Tony

8< --------------------------------
From: Tony Lindgren <tony@atomide.com>
Date: Fri, 27 Dec 2013 09:33:27 -0800
Subject: [PATCH] ARM: OMAP2+: Fix LCD panel backlight regression for LDP legacy booting

Looks like the LCD panel on LDP has been broken quite a while, and
recently got fixed by commit 0b2aa8bed3e1 (gpio: twl4030: Fix regression
for twl gpio output). However, there's still an issue left where the panel
backlight does not come on if the LCD drivers are built into the
kernel.

Fix the issue by registering the DPI LCD panel only after the twl4030
GPIO has probed.

Reported-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
[tony at atomide.com: updated per Tomi's comments]
Signed-off-by: Tony Lindgren <tony@atomide.com>

--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -242,12 +242,18 @@ static void __init ldp_display_init(void)
 
 static int ldp_twl_gpio_setup(struct device *dev, unsigned gpio, unsigned ngpio)
 {
+	int res;
+
 	/* LCD enable GPIO */
 	ldp_lcd_pdata.enable_gpio = gpio + 7;
 
 	/* Backlight enable GPIO */
 	ldp_lcd_pdata.backlight_gpio = gpio + 15;
 
+	res = platform_device_register(&ldp_lcd_device);
+	if (res)
+		pr_err("Unable to register LCD: %d\n", res);
+
 	return 0;
 }
 
@@ -346,7 +352,6 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
 
 static struct platform_device *ldp_devices[] __initdata = {
 	&ldp_gpio_keys_device,
-	&ldp_lcd_device,
 };
 
 #ifdef CONFIG_OMAP_MUX

Re: OMAP display subsystem - does it work?

[Russell King - ARM Linux]

On Sat, Dec 21, 2013 at 12:59:41AM +0000, Russell King - ARM Linux wrote:
> On Fri, Dec 20, 2013 at 08:55:03AM -0800, Tony Lindgren wrote:
> > Yeah this seems to do the trick for me for the built-in DSS on LDP.
> > 
> > Tony
> > 
> > 8< -----------------------------------
> > From: Tony Lindgren <tony@atomide.com>
> > Date: Fri, 20 Dec 2013 08:53:27 -0800
> > Subject: [PATCH] ARM: OMAP2+: Fix LCD panel backlight regression for LDP legacy booting
> > 
> > Looks like the LCD panel on LDP has been broken quite a while, and
> > recently got fixed. However, there's still an issue where the panel
> > backlight does not come on if the LCD drivers are built into the
> > kernel.
> > 
> > Fix the issue by registering the DPI LCD panel only after the twl4030
> > GPIO has probed.
> > 
> > Reported-by: Russell King <rmk+kernel@arm.linux.org.uk>
> > Signed-off-by: Tony Lindgren <tony@atomide.com>
> > 
> > --- a/arch/arm/mach-omap2/board-ldp.c
> > +++ b/arch/arm/mach-omap2/board-ldp.c
> > @@ -248,7 +248,7 @@ static int ldp_twl_gpio_setup(struct device *dev, unsigned gpio, unsigned ngpio)
> >  	/* Backlight enable GPIO */
> >  	ldp_lcd_pdata.backlight_gpio = gpio + 15;
> >  
> > -	return 0;
> > +	return platform_device_register(&ldp_lcd_device);
> >  }
> >  
> >  static struct twl4030_gpio_platform_data ldp_gpio_data = {
> > @@ -346,7 +346,6 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
> >  
> >  static struct platform_device *ldp_devices[] __initdata = {
> >  	&ldp_gpio_keys_device,
> > -	&ldp_lcd_device,
> >  };
> >  
> >  #ifdef CONFIG_OMAP_MUX
> 
> I've added it to the test build for tonight (only as an uncommitted
> modification) so we'll see what happens tomorrow morning.

BTW, yes, this does result in the display working again on the LDP.

OMAP display subsystem - does it work?

[Russell King - ARM Linux]

On Sat, Dec 21, 2013 at 12:59:41AM +0000, Russell King - ARM Linux wrote:
> On Fri, Dec 20, 2013 at 08:55:03AM -0800, Tony Lindgren wrote:
> > Yeah this seems to do the trick for me for the built-in DSS on LDP.
> > 
> > Tony
> > 
> > 8< -----------------------------------
> > From: Tony Lindgren <tony@atomide.com>
> > Date: Fri, 20 Dec 2013 08:53:27 -0800
> > Subject: [PATCH] ARM: OMAP2+: Fix LCD panel backlight regression for LDP legacy booting
> > 
> > Looks like the LCD panel on LDP has been broken quite a while, and
> > recently got fixed. However, there's still an issue where the panel
> > backlight does not come on if the LCD drivers are built into the
> > kernel.
> > 
> > Fix the issue by registering the DPI LCD panel only after the twl4030
> > GPIO has probed.
> > 
> > Reported-by: Russell King <rmk+kernel@arm.linux.org.uk>
> > Signed-off-by: Tony Lindgren <tony@atomide.com>
> > 
> > --- a/arch/arm/mach-omap2/board-ldp.c
> > +++ b/arch/arm/mach-omap2/board-ldp.c
> > @@ -248,7 +248,7 @@ static int ldp_twl_gpio_setup(struct device *dev, unsigned gpio, unsigned ngpio)
> >  	/* Backlight enable GPIO */
> >  	ldp_lcd_pdata.backlight_gpio = gpio + 15;
> >  
> > -	return 0;
> > +	return platform_device_register(&ldp_lcd_device);
> >  }
> >  
> >  static struct twl4030_gpio_platform_data ldp_gpio_data = {
> > @@ -346,7 +346,6 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
> >  
> >  static struct platform_device *ldp_devices[] __initdata = {
> >  	&ldp_gpio_keys_device,
> > -	&ldp_lcd_device,
> >  };
> >  
> >  #ifdef CONFIG_OMAP_MUX
> 
> I've added it to the test build for tonight (only as an uncommitted
> modification) so we'll see what happens tomorrow morning.

BTW, yes, this does result in the display working again on the LDP.