All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org,
	Tony Lindgren <tony@atomide.com>
Subject: Re: OMAP display subsystem - does it work?
Date: Wed, 18 Dec 2013 15:54:42 +0200	[thread overview]
Message-ID: <52B1A922.6020901@ti.com> (raw)
In-Reply-To: <20131218120023.GG4360@n2100.arm.linux.org.uk>

[-- 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 --]

WARNING: multiple messages have this Message-ID (diff)
From: tomi.valkeinen@ti.com (Tomi Valkeinen)
To: linux-arm-kernel@lists.infradead.org
Subject: OMAP display subsystem - does it work?
Date: Wed, 18 Dec 2013 15:54:42 +0200	[thread overview]
Message-ID: <52B1A922.6020901@ti.com> (raw)
In-Reply-To: <20131218120023.GG4360@n2100.arm.linux.org.uk>

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>

  reply	other threads:[~2013-12-18 13:55 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-18 12:00 OMAP display subsystem - does it work? Russell King - ARM Linux
2013-12-18 12:00 ` Russell King - ARM Linux
2013-12-18 13:54 ` Tomi Valkeinen [this message]
2013-12-18 13:54   ` Tomi Valkeinen
2013-12-18 15:29   ` Russell King - ARM Linux
2013-12-18 15:29     ` Russell King - ARM Linux
2013-12-18 16:03     ` Tomi Valkeinen
2013-12-18 16:03       ` Tomi Valkeinen
2013-12-18 18:23   ` Tony Lindgren
2013-12-18 18:23     ` Tony Lindgren
2013-12-19  5:23     ` Tomi Valkeinen
2013-12-19  5:23       ` Tomi Valkeinen
2013-12-19 16:56       ` Tony Lindgren
2013-12-19 16:56         ` Tony Lindgren
2013-12-20  7:45         ` Tomi Valkeinen
2013-12-20  7:45           ` Tomi Valkeinen
2013-12-19 17:56     ` Russell King - ARM Linux
2013-12-19 17:56       ` Russell King - ARM Linux
2013-12-19 18:22       ` Tony Lindgren
2013-12-19 18:22         ` Tony Lindgren
2013-12-20 11:27         ` Russell King - ARM Linux
2013-12-20 11:27           ` Russell King - ARM Linux
2013-12-20 11:48           ` Russell King - ARM Linux
2013-12-20 11:48             ` Russell King - ARM Linux
2013-12-20 13:43             ` Tomi Valkeinen
2013-12-20 13:43               ` Tomi Valkeinen
2013-12-20 16:04               ` Tony Lindgren
2013-12-20 16:04                 ` Tony Lindgren
2013-12-20 16:55                 ` Tony Lindgren
2013-12-20 16:55                   ` Tony Lindgren
2013-12-21  0:59                   ` Russell King - ARM Linux
2013-12-21  0:59                     ` Russell King - ARM Linux
2013-12-28 23:30                     ` Russell King - ARM Linux
2013-12-28 23:30                       ` Russell King - ARM Linux
2013-12-23  7:53                   ` Tomi Valkeinen
2013-12-23  7:53                     ` Tomi Valkeinen
2013-12-27 18:11                     ` Tony Lindgren
2013-12-27 18:11                       ` Tony Lindgren
2013-12-23  7:49                 ` Tomi Valkeinen
2013-12-23  7:49                   ` Tomi Valkeinen
2013-12-20 16:10           ` Tony Lindgren
2013-12-20 16:10             ` Tony Lindgren
2013-12-19 17:53   ` Russell King - ARM Linux
2013-12-19 17:53     ` Russell King - ARM Linux

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52B1A922.6020901@ti.com \
    --to=tomi.valkeinen@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=tony@atomide.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.