| Message ID | CAAwP0s2pGM6RRhkzhZ+_8BsCKP0posFrn7buTwUzLWWC5apE2A@mail.gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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()). > 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... Tomi
On Mon, Oct 28, 2013 at 2:32 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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"; +};