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/
Tomi
--
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
