[1/6] ARM: OMAP2+: Remove board-4430sdp.c

Commit Message

Javier Martinez Canillas Oct. 27, 2013, 1:26 p.m. UTC

Hi Tomi,

On Mon, Jul 22, 2013 at 11:40 AM, Tomi Valkeinen <[e-mail]> wrote:
> On 08/07/13 17:21, Russell King - ARM Linux wrote:
>
>> Also looks like the nonfunctional video stuff is even more nonfunctional
>> than usual:
>>
>> omapdss DSI error: can't get VDDS_DSI regulator
>> omapdss HDMI error: can't get VDDA_HDMI_DAC regulator

I have the same issue when trying to get VDI output working on a IGEPv2 board.

>
> Those should be followed by "...requests probe deferral", and the driver
> is probed again later.
>

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:

[    3.186035] OMAPFB: omapfb_probe
[    3.190704] omapdss DPI error: can't get VDDS_DSI regulator
[    3.196594] omapfb omapfb: failed to connect default display
[    3.202667] omapfb omapfb: failed to init overlay connections
[    3.208892] OMAPFB: free_resources
[    3.212493] OMAPFB: free all fbmem
[    3.216735] omapfb omapfb: failed to setup omapfb
[    3.221832] platform omapfb: Driver omapfb requests probe deferral
[    3.231689] OMAPFB: omapfb_probe
[    3.236175] omapdss DPI error: can't get VDDS_DSI regulator
[    3.242248] omapfb omapfb: failed to connect default display
[    3.248291] omapfb omapfb: failed to init overlay connections
[    3.254394] OMAPFB: free_resources
[    3.258026] OMAPFB: free all fbmem
[    3.262268] omapfb omapfb: failed to setup omapfb
[    3.267303] platform omapfb: Driver omapfb requests probe deferral

My complete boot log is [1]

I tracked down to dpi_init_regulator in drivers/video/omap2/dss/dpi.c

static int dpi_init_regulator(void)
{
....
        vdds_dsi = devm_regulator_get(&dpi.pdev->dev, "vdds_dsi");
        if (IS_ERR(vdds_dsi)) {
                DSSERR("can't get VDDS_DSI regulator\n");
                return PTR_ERR(vdds_dsi);
        }
....
}

So I tried adding this to my DT with no luck.



Now what you said does indeed happen when booting with the legacy
board file. omapfb fails the first time with "can't get VDDS_DSI
regulator"
but the driver is probed again and it succeeds.

I tried to spot a difference but didn't find it...

> The log
> http://www.arm.linux.org.uk/developer/build/result.php?type=boot&idx=946
> shows "taal display2: panel revision e3.83.7d" which hints that the
> panel (and DSS) was initialized properly.
>
> Those error prints should probably be tuned down a bit now that the
> driver uses probe deferral.
>
>  Tomi
>
>

fwiw, my wip branch is [2]:

Javier Martinez Canillas (3):
      ARM: dts: omap3-igep0020: Add pinmux setup for i2c devices
      ARM: dts: omap3-igep0020: Add pinmuxig for DVI output
      ARM: OMAP: dss-common: change IGEP's DVI DDC i2c bus

Any hints will be highly appreciated.

Thanks a lot and best regards,
Javier

[1]: http://fpaste.org/49736/79384138/raw/
[2]: https://github.com/martinezjavier/linux/commits/igep-video-wip

Comments

Tomi Valkeinen Oct. 28, 2013, 1:32 p.m. UTC | #1

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

Javier Martinez Canillas Oct. 28, 2013, 2:25 p.m. UTC | #2

On Mon, Oct 28, 2013 at 2:32 PM, Tomi Valkeinen <[e-mail]> 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

Patch

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";
+};