On Mon, Oct 28, 2013 at 2:32 PM, Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote:
> On 27/10/13 15:26, Javier Martinez Canillas wrote:
>
>> When booting with DT the omapfb's probe is deferred several times but
>> it always fails on dpi_connect() due not being able to get the
>> VDDS_DSI regulator:
>
> The problem with DT boot is that the VDDS_DSI is not linked to the DPI
> device. For omap4, we have a few hacks to go around this (see dsi.c,
> dsi_regulator_init()).
>
I see, I'll add a dpi_regulator_init() to
drivers/video/omap2/dss/dpi.c to workaround this.
>> So I tried adding this to my DT with no luck.
>>
>> diff --git a/arch/arm/boot/dts/omap3-igep0020.dts
>> b/arch/arm/boot/dts/omap3-igep0020.dts
>> index 17a6fc1..eaae935 100644
>> --- a/arch/arm/boot/dts/omap3-igep0020.dts
>> +++ b/arch/arm/boot/dts/omap3-igep0020.dts
>> @@ -256,3 +256,8 @@
>> &usbhsehci {
>> phys = <&hsusb1_phy>;
>> };
>> +
>> +&vpll2 {
>> + supply-dev = "omapdss_dpi.0";
>> + supply = "vdds_dsi";
>> +};
>
> I didn't see "supply-dev" defined in dt bindings documentation, is that
> supposed to work? If it should work, then the problem could be solved
> with the above. Otherwise I guess we must add more hacks to omapdss
> driver, to all places where it uses regulator_get...
>
Yes I didn't find on the DT binding documentation either but saw it
before on a DTS someone shared on linux-omap so I thought it was just
a matter of outdated documentation. But I guess it was the other way
around, that DTS was for a vendor kernel which added that supply-dev
property.
> Tomi
>
>
Thanks a lot for your help!
Javier
--
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
