From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: "Pavel Machek" <pavel@ucw.cz>, "Pali Rohár" <pali.rohar@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>,
linux-omap@vger.kernel.org, linux-fbdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
Aaro Koskinen <aaro.koskinen@iki.fi>,
Tony Lindgren <tony@atomide.com>
Subject: Re: [PATCH] omapfb: In omapfb_probe return -EPROBE_DEFER when display driver is not loaded yet
Date: Tue, 23 Jul 2013 13:01:39 +0300 [thread overview]
Message-ID: <51EE5483.7000201@ti.com> (raw)
In-Reply-To: <20130713182733.GA25019@amd.pavel.ucw.cz>
[-- 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 --]
next prev parent reply other threads:[~2013-07-23 10:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-10 13:08 [PATCH] omapfb: In omapfb_probe return -EPROBE_DEFER when display driver is not loaded yet Pali Rohár
2013-07-11 8:38 ` Archit Taneja
2013-07-13 18:27 ` Pavel Machek
2013-07-13 19:56 ` Pavel Machek
2013-07-23 10:01 ` Tomi Valkeinen [this message]
2013-08-04 8:36 ` Pali Rohár
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=51EE5483.7000201@ti.com \
--to=tomi.valkeinen@ti.com \
--cc=aaro.koskinen@iki.fi \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=pali.rohar@gmail.com \
--cc=pavel@ucw.cz \
--cc=plagnioj@jcrosoft.com \
--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 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).