Re: [PATCH] omapfb: In omapfb_probe return -EPROBE_DEFER when display driver is not loaded yet

From: Pali RohÃr
Date: Mon Aug 05 2013 - 02:46:00 EST


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@xxxxxxxxx>
> >
> > Tested-by: Pavel Machek <pavel@xxxxxx>
>
> 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@xxxxxx>
> 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@xxxxxx>
>
> 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@xxxxxxxxx

Attachment: signature.asc
Description: This is a digitally signed message part.