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. Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
