* =?UTF-8?q?=5BPATCH=5D=20omapfb=3A=20In=20omapfb=5Fprobe=20return=20-EPROBE=5FDEFER=20when=20display= @ 2013-07-10 13:08 Pali Rohár 2013-07-11 8:50 ` [PATCH] omapfb: In omapfb_probe return -EPROBE_DEFER when display driver is not loaded yet Archit Taneja 2013-07-13 18:27 ` Pavel Machek 0 siblings, 2 replies; 6+ messages in thread From: Pali Rohár @ 2013-07-10 13:08 UTC (permalink / raw) To: Tomi Valkeinen, Jean-Christophe Plagniol-Villard Cc: linux-omap, linux-fbdev, linux-kernel, Pavel Machek, Aaro Koskinen, Tony Lindgren, Pali Rohár * 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 <pali.rohar@gmail.com> --- drivers/video/omap2/omapfb/omapfb-main.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c index 856917b..93e7c84 100644 --- a/drivers/video/omap2/omapfb/omapfb-main.c +++ b/drivers/video/omap2/omapfb/omapfb-main.c @@ -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; -- 1.7.10.4 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] omapfb: In omapfb_probe return -EPROBE_DEFER when display driver is not loaded yet 2013-07-10 13:08 =?UTF-8?q?=5BPATCH=5D=20omapfb=3A=20In=20omapfb=5Fprobe=20return=20-EPROBE=5FDEFER=20when=20display= Pali Rohár @ 2013-07-11 8:50 ` Archit Taneja 2013-07-13 18:27 ` Pavel Machek 1 sibling, 0 replies; 6+ messages in thread From: Archit Taneja @ 2013-07-11 8:50 UTC (permalink / raw) To: Pali Rohár Cc: Tomi Valkeinen, Jean-Christophe Plagniol-Villard, linux-omap, linux-fbdev, linux-kernel, Pavel Machek, Aaro Koskinen, Tony Lindgren Hi, On Wednesday 10 July 2013 06:38 PM, 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 <pali.rohar@gmail.com> > --- > drivers/video/omap2/omapfb/omapfb-main.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c > index 856917b..93e7c84 100644 > --- a/drivers/video/omap2/omapfb/omapfb-main.c > +++ b/drivers/video/omap2/omapfb/omapfb-main.c > @@ -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; > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] omapfb: In omapfb_probe return -EPROBE_DEFER when display driver is not loaded yet 2013-07-10 13:08 =?UTF-8?q?=5BPATCH=5D=20omapfb=3A=20In=20omapfb=5Fprobe=20return=20-EPROBE=5FDEFER=20when=20display= Pali Rohár 2013-07-11 8:50 ` [PATCH] omapfb: In omapfb_probe return -EPROBE_DEFER when display driver is not loaded yet Archit Taneja @ 2013-07-13 18:27 ` Pavel Machek 2013-07-13 19:56 ` Pavel Machek 2013-07-23 10:01 ` Tomi Valkeinen 1 sibling, 2 replies; 6+ messages in thread From: Pavel Machek @ 2013-07-13 18:27 UTC (permalink / raw) To: Pali Rohár Cc: Tomi Valkeinen, Jean-Christophe Plagniol-Villard, linux-omap, linux-fbdev, linux-kernel, Aaro Koskinen, Tony Lindgren 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 <pali.rohar@gmail.com> Tested-by: Pavel Machek <pavel@ucw.cz> (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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] omapfb: In omapfb_probe return -EPROBE_DEFER when display driver is not loaded yet 2013-07-13 18:27 ` Pavel Machek @ 2013-07-13 19:56 ` Pavel Machek 2013-07-23 10:01 ` Tomi Valkeinen 1 sibling, 0 replies; 6+ messages in thread From: Pavel Machek @ 2013-07-13 19:56 UTC (permalink / raw) To: Pali Rohár Cc: Tomi Valkeinen, Jean-Christophe Plagniol-Villard, linux-omap, linux-fbdev, linux-kernel, Aaro Koskinen, Tony Lindgren 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. Aha, normal console=ttyO2 option. Got it now :-). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] omapfb: In omapfb_probe return -EPROBE_DEFER when display driver is not loaded yet 2013-07-13 18:27 ` Pavel Machek 2013-07-13 19:56 ` Pavel Machek @ 2013-07-23 10:01 ` Tomi Valkeinen 2013-08-04 8:36 ` Pali Rohár 1 sibling, 1 reply; 6+ messages in thread From: Tomi Valkeinen @ 2013-07-23 10:01 UTC (permalink / raw) To: Pavel Machek, Pali Rohár Cc: Jean-Christophe Plagniol-Villard, linux-omap, linux-fbdev, linux-kernel, Aaro Koskinen, Tony Lindgren [-- Attachment #1: Type: text/plain, Size: 2852 bytes --] On 13/07/13 21:27, Pavel Machek wrote: > 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 <pali.rohar@gmail.com> > > Tested-by: Pavel Machek <pavel@ucw.cz> 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 <tomi.valkeinen@ti.com> 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 <tomi.valkeinen@ti.com> diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c index 528e453..27d6905 100644 --- a/drivers/video/omap2/omapfb/omapfb-main.c +++ b/drivers/video/omap2/omapfb/omapfb-main.c @@ -2503,7 +2503,7 @@ static int omapfb_probe(struct platform_device *pdev) if (def_display == NULL) { dev_err(fbdev->dev, "failed to find default display\n"); - r = -EINVAL; + r = -EPROBE_DEFER; goto cleanup; } [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 901 bytes --] ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] omapfb: In omapfb_probe return -EPROBE_DEFER when display driver is not loaded yet 2013-07-23 10:01 ` Tomi Valkeinen @ 2013-08-04 8:36 ` Pali Rohár 0 siblings, 0 replies; 6+ messages in thread From: Pali Rohár @ 2013-08-04 8:36 UTC (permalink / raw) To: Tomi Valkeinen Cc: Pavel Machek, Jean-Christophe Plagniol-Villard, linux-omap, linux-fbdev, linux-kernel, Aaro Koskinen, Tony Lindgren [-- Attachment #1: Type: Text/Plain, Size: 3217 bytes --] Hello, On Tuesday 23 July 2013 12:01:39 Tomi Valkeinen wrote: > On 13/07/13 21:27, Pavel Machek wrote: > > 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 <pali.rohar@gmail.com> > > > > Tested-by: Pavel Machek <pavel@ucw.cz> > > 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. > > > (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. > commit e9f322b4913e5d3e5c5d21dc462ca6f8a86e1df1 > Author: Tomi Valkeinen <tomi.valkeinen@ti.com> > 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 <tomi.valkeinen@ti.com> > > diff --git a/drivers/video/omap2/omapfb/omapfb-main.c > b/drivers/video/omap2/omapfb/omapfb-main.c index > 528e453..27d6905 100644 > --- a/drivers/video/omap2/omapfb/omapfb-main.c > +++ b/drivers/video/omap2/omapfb/omapfb-main.c > @@ -2503,7 +2503,7 @@ static int omapfb_probe(struct > platform_device *pdev) > > if (def_display == NULL) { > dev_err(fbdev->dev, "failed to find default > display\n"); - r = -EINVAL; > + r = -EPROBE_DEFER; > goto cleanup; > } -- Pali Rohár pali.rohar@gmail.com [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-08-04 8:36 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-07-10 13:08 =?UTF-8?q?=5BPATCH=5D=20omapfb=3A=20In=20omapfb=5Fprobe=20return=20-EPROBE=5FDEFER=20when=20display= Pali Rohár 2013-07-11 8:50 ` [PATCH] omapfb: In omapfb_probe return -EPROBE_DEFER when display driver is not loaded yet Archit Taneja 2013-07-13 18:27 ` Pavel Machek 2013-07-13 19:56 ` Pavel Machek 2013-07-23 10:01 ` Tomi Valkeinen 2013-08-04 8:36 ` Pali Rohár
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).