On 04/22/2013 09:08 PM, Tony Lindgren wrote:
* Grygorii Strashko <grygorii.strashko@xxxxxx> [130422 05:27]:
On 04/22/2013 01:24 PM, Tomi Valkeinen wrote:
On 2013-04-22 12:08, Tomi Valkeinen wrote:
On 2013-04-19 20:13, Tony Lindgren wrote:
3. DSS fails with DT booting
Works with legacy booting but fails with DT. I'm almost certain
the DT booting was working last week or so?
This is what I now get with DT booting:
omapdss DSI error: can't get VDDS_DSI regulator
omapdss HDMI error: can't get VDDA_HDMI_DAC regulator
omapdss HDMI error: device hdmi init failed: -517
omapdss CORE error: driver probe failed: -22
...
I think this is the issue Christoph Fritz reported earlier, DSS is being
initialized before TWL, and thus DSS doesn't find the regulators.
The proper fix is of course to make DSS support EPROBE_DEFER, but that's
easier said than done. I'll have a look if I can get it working enough
to fix this issue.
Yes, it seems delayed regulator initialization brought up this issue.
I hacked DSI driver of omapdss and Taal panel driver to somewhat work
with EPROBE_DEFER. But then the issue was with omapfb.
omapfb is currently set to start at late_initcall, so that omapdss and
panels are loaded before omapfb. But even that's not late enough to get
the regulators for omapdss. It seems the regulators get also initialized
at the late_initcall level. Changing omapfb to late_initcall_sync was
late enough to get things working.
Again, making omapdss, panel drivers and omapfb support EPROBE_DEFER and
dynamic panel driver insertion is the proper fix, but it's a big job,
and there are "interesting" issues with it (like how to know if a panel
device will ever get a driver loaded).
But is there something wrong with the TWL and regulators? late_initcall
sounds rather late for such a core resource. Even if all drivers
supported EPROBE_DEFER, won't it cause extra delays in the boot as
drivers are getting probed multiple times?
As for fixing the DSS problem for 3.10, I don't have any ideas except
pure hacks. I'll continue studying this.
Hi Tomi,
twl is not initialized because of I2C,
I2C is not initialized because of pinctrl-single,
pinctrl-single is initialized at mudule/device init time.
So, most everything will be shifted at late_initcall time.
Hack that sequence is here - https://patchwork.kernel.org/patch/2444501/
Hmm I'm pretty sure the LCD was working on panda with DT
few weeks ago?
In any case, all those drivers should be just module_init
so we get out of the race to bottom to initialize drivers
early. Pinctrl is already before i2c in drivers/Makefile.
I suspect there may be some recent regression that has
happened in linux next over past few weeks.
Hi Tony,
I've posted two patches to fix I2C/TWL initialization and they should fix
DSS indirectly (if not - DSS need to be shifted to init later).
lkml.org/lkml/2013/4/23/215
lkml.org/lkml/2013/4/23/217
In addition, It seems, possibly :), drivers/Makefile might need to be
changed a bit:
- move generic drivers framework to be initialized first ("base", "clk");
- move "i2c" buses initialization as early as possible (but after
"pinctrl" and "gpio")
- move "mfd" initialization before "regulators"
- move "video" initialization down after "regulators" (as minimum).
Regards
-grygorii
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
