| Message ID | 51EE5483.7000201@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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; > }
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; }