* On RX-51 probing for acx565akm driver is later then for omapfb which cause that omapfb probe fail and framebuffer is not working
* EPROBE_DEFER causing that kernel try to probe for omapfb later again which fixing this problem
* Without this patch display on Nokia RX-51 (N900) phone not working
Signed-off-by: Pali Rohár <redacted>
---
drivers/video/omap2/omapfb/omapfb-main.c | 9 +++++++++
1 file changed, 9 insertions(+)
@@ -2419,6 +2419,15 @@ static int omapfb_probe(struct platform_device *pdev)if(omapdss_is_initialized()=false)return-EPROBE_DEFER;+dssdev=NULL;+for_each_dss_dev(dssdev){+if(!dssdev->driver){+dev_warn(&pdev->dev,"no driver for display: %s\n",+dssdev->name);+return-EPROBE_DEFER;+}+}+if(pdev->num_resources!=0){dev_err(&pdev->dev,"probed for an unknown device\n");r=-ENODEV;
Hi,
On Wednesday 10 July 2013 06:38 PM, Pali Rohár wrote:
quoted hunk
* On RX-51 probing for acx565akm driver is later then for omapfb which cause that omapfb probe fail and framebuffer is not working
* EPROBE_DEFER causing that kernel try to probe for omapfb later again which fixing this problem
* Without this patch display on Nokia RX-51 (N900) phone not working
Signed-off-by: Pali Rohár <redacted>
---
drivers/video/omap2/omapfb/omapfb-main.c | 9 +++++++++
1 file changed, 9 insertions(+)
@@ -2419,6 +2419,15 @@ static int omapfb_probe(struct platform_device *pdev)if(omapdss_is_initialized()=false)return-EPROBE_DEFER;+dssdev=NULL;+for_each_dss_dev(dssdev){+if(!dssdev->driver){+dev_warn(&pdev->dev,"no driver for display: %s\n",+dssdev->name);+return-EPROBE_DEFER;
This will make omapfb probe defer till the time every panel has a
driver. It's possible that all the panel driver modules are never
interested by userspace. This will lead to the panels having drivers
also not work.
I think Tomi was working on this, it was something like making omapfb
defer only if the default display doesn't have a driver. We can wait for
his comment.
Archit
+ }
+ }
+
if (pdev->num_resources != 0) {
dev_err(&pdev->dev, "probed for an unknown device\n");
r = -ENODEV;
From: Pavel Machek <hidden> Date: 2013-07-13 18:27:39
On Wed 2013-07-10 15:08:59, Pali Rohár wrote:
* On RX-51 probing for acx565akm driver is later then for omapfb which cause that omapfb probe fail and framebuffer is not working
* EPROBE_DEFER causing that kernel try to probe for omapfb later again which fixing this problem
* Without this patch display on Nokia RX-51 (N900) phone not working
Signed-off-by: Pali Rohár <redacted>
Tested-by: Pavel Machek <redacted>
(Actually, do we know which commit broke the ordering? We may want to
simply revert that one...)
BTW I'm currently trying to set-up automated scripts for n900/qemu
testing. I guess I'll try to run them on mainline kernel to catch such
stuff earlier.
One thing I'd like to know: how do you configure kernel to get output
on qemu? I was doing CONFIG_DEBUG_LL with specific uart, but that
needed patching the kernel, you apparently have something more clever.
I tried doing:
# CONFIG_DEBUG_LL is not set
CONFIG_DEBUG_LL_INCLUDE="mach/debug-macro.S"
CONFIG_UNCOMPRESS_INCLUDE="debug/uncompress.h"
but no output on console...
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
From: Pavel Machek <hidden> Date: 2013-07-13 19:56:58
Hi!
One thing I'd like to know: how do you configure kernel to get output
on qemu? I was doing CONFIG_DEBUG_LL with specific uart, but that
needed patching the kernel, you apparently have something more
clever.
From: Tomi Valkeinen <hidden> Date: 2013-07-23 10:02:16
On 13/07/13 21:27, Pavel Machek wrote:
On Wed 2013-07-10 15:08:59, Pali Rohár wrote:
quoted
* On RX-51 probing for acx565akm driver is later then for omapfb which cause that omapfb probe fail and framebuffer is not working
* EPROBE_DEFER causing that kernel try to probe for omapfb later again which fixing this problem
* Without this patch display on Nokia RX-51 (N900) phone not working
Signed-off-by: Pali Rohár <redacted>
Tested-by: Pavel Machek <redacted>
Which kernel version is this? Does it have
dfbc32316c6991010328c21e6046b05bac57eb84 (OMAPFB: defer probe if no displays)?
Then again, rx51 has tv-output, which probably gets probed early. So omapfb
does see one functional display, and starts, even if the LCD is not available
yet.
(Actually, do we know which commit broke the ordering? We may want to
simply revert that one...)
Well, my understand that this is how it's supposed to work. There's no defined
order with the driver probes, and the drivers just have to deal with their
dependencies not being there yet.
I don't have a perfect solution for this problem for omapfb. omapfb doesn't
support dynamically adding displays, so all the displays it uses have to be
probed before omapfb. And omapfb doesn't know which displays will be probed.
The patch below was added for 3.11. Does it fix the issue for you? Perhaps it
should be added for 3.10 also.
Tomi
commit e9f322b4913e5d3e5c5d21dc462ca6f8a86e1df1
Author: Tomi Valkeinen [off-list ref]
Date: Thu May 23 16:41:25 2013 +0300
OMAPFB: use EPROBE_DEFER if default display is not present
Currently omapfb returns EPROBE_DEFER if no displays have been probed at
the time omapfb is probed. However, sometimes some of the displays have
been probed at that time, but not all. We can't return EPROBE_DEFER in
that case, because then one missing driver would cause omapfb to defer
always, preventing any display from working.
However, if the user has defined a default display, we can presume that
the driver for that display is eventually loaded. Thus, this patch
changes omapfb to return EPROBE_DEFER in case default display is not
found.
Signed-off-by: Tomi Valkeinen [off-list ref]
Hello,
On Tuesday 23 July 2013 12:01:39 Tomi Valkeinen wrote:
On 13/07/13 21:27, Pavel Machek wrote:
quoted
On Wed 2013-07-10 15:08:59, Pali Rohár wrote:
quoted
* On RX-51 probing for acx565akm driver is later then for
omapfb which cause that omapfb probe fail and framebuffer
is not working * EPROBE_DEFER causing that kernel try to
probe for omapfb later again which fixing this problem
* Without this patch display on Nokia RX-51 (N900) phone
not working
Signed-off-by: Pali Rohár <redacted>
Tested-by: Pavel Machek <redacted>
Which kernel version is this? Does it have
dfbc32316c6991010328c21e6046b05bac57eb84 (OMAPFB: defer probe
if no displays)?
Kernel 3.10, so it have above commit.
Then again, rx51 has tv-output, which probably gets probed
early. So omapfb does see one functional display, and starts,
even if the LCD is not available yet.
quoted
(Actually, do we know which commit broke the ordering? We
may want to simply revert that one...)
Well, my understand that this is how it's supposed to work.
There's no defined order with the driver probes, and the
drivers just have to deal with their dependencies not being
there yet.
I don't have a perfect solution for this problem for omapfb.
omapfb doesn't support dynamically adding displays, so all
the displays it uses have to be probed before omapfb. And
omapfb doesn't know which displays will be probed.
The patch below was added for 3.11. Does it fix the issue for
you? Perhaps it should be added for 3.10 also.
Tomi
I tested patch below and it fixing our problem too. So it could be
added to 3.10.
quoted hunk
commit e9f322b4913e5d3e5c5d21dc462ca6f8a86e1df1
Author: Tomi Valkeinen [off-list ref]
Date: Thu May 23 16:41:25 2013 +0300
OMAPFB: use EPROBE_DEFER if default display is not present
Currently omapfb returns EPROBE_DEFER if no displays have
been probed at the time omapfb is probed. However, sometimes
some of the displays have been probed at that time, but not
all. We can't return EPROBE_DEFER in that case, because then
one missing driver would cause omapfb to defer always,
preventing any display from working.
However, if the user has defined a default display, we can
presume that the driver for that display is eventually
loaded. Thus, this patch changes omapfb to return
EPROBE_DEFER in case default display is not found.
Signed-off-by: Tomi Valkeinen [off-list ref]