Multiple issues with omap4 panda es in linux next

[Grygorii Strashko]

On 04/22/2013 09:08 PM, Tony Lindgren wrote:
> * Grygorii Strashko <grygorii.strashko at ti.com> [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 at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html