omap3: Adding vdd_sdi regulator supply to OMAP3EVM

From: Mathieu J. Poirier <mathieu.poirier@canonical.com>

https://bugs.launchpad.net/bugs/630885

When booting, the omapdss subsystem is looking for a regulator named
"vdds_sdi". When the regulator is not found the initialisation sequence
is aborted resulting in omapfb not finding a display to work with.  This
patch allows the omapfb sub system to complete its initialisation
properly and enable LCD display. The problem was fixed by lumping a
"vdds_sdi" with the already existing "vdds_dsi" regulator. This fix
takes its root from work done on the Beagle board and the Pandora board.

Signed-off-by: Mathieu Poirier <mathieu.poirier@canonical.com>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
---
 arch/arm/mach-omap2/board-omap3evm.c |   10 ++++++----
 1 files changed, 6 insertions(+), 4 deletions(-)

Hi, would you guys take a look at this?

Thanks,
-Bryan

On Thu, Feb 17, 2011 at 4:11 PM, Bryan Wu <bryan.wu@canonical.com> wrote:
> From: Mathieu J. Poirier <mathieu.poirier@canonical.com>
>
> https://bugs.launchpad.net/bugs/630885
>
> When booting, the omapdss subsystem is looking for a regulator named
> "vdds_sdi". When the regulator is not found the initialisation sequence
> is aborted resulting in omapfb not finding a display to work with.  This
> patch allows the omapfb sub system to complete its initialisation
> properly and enable LCD display. The problem was fixed by lumping a
> "vdds_sdi" with the already existing "vdds_dsi" regulator. This fix
> takes its root from work done on the Beagle board and the Pandora board.
>
> Signed-off-by: Mathieu Poirier <mathieu.poirier@canonical.com>
> Signed-off-by: Andy Whitcroft <apw@canonical.com>
> Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
> ---
>  arch/arm/mach-omap2/board-omap3evm.c |   10 ++++++----
>  1 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
> index c2a0fca..8b8eb36 100644
> --- a/arch/arm/mach-omap2/board-omap3evm.c
> +++ b/arch/arm/mach-omap2/board-omap3evm.c
> @@ -521,8 +521,10 @@ static struct regulator_init_data omap3_evm_vdac = {
>  };
>
>  /* VPLL2 for digital video outputs */
> -static struct regulator_consumer_supply omap3_evm_vpll2_supply =
> -       REGULATOR_SUPPLY("vdds_dsi", "omapdss");
> +static struct regulator_consumer_supply omap3_evm_vdds_supplies[] = {
> +       REGULATOR_SUPPLY("vdds_sdi", "omapdss"),
> +       REGULATOR_SUPPLY("vdds_dsi", "omapdss"),
> +};
>
>  static struct regulator_init_data omap3_evm_vpll2 = {
>        .constraints = {
> @@ -534,8 +536,8 @@ static struct regulator_init_data omap3_evm_vpll2 = {
>                .valid_ops_mask         = REGULATOR_CHANGE_MODE
>                                        | REGULATOR_CHANGE_STATUS,
>        },
> -       .num_consumer_supplies  = 1,
> -       .consumer_supplies      = &omap3_evm_vpll2_supply,
> +       .num_consumer_supplies  = ARRAY_SIZE(omap3_evm_vdds_supplies),
> +       .consumer_supplies      = omap3_evm_vdds_supplies,
>  };
>
>  static struct twl4030_platform_data omap3evm_twldata = {
> --
> 1.7.1
>
> --
> 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
>

Hi,

On Monday 21 February 2011 12:32 PM, Bryan Wu wrote:
> Hi, would you guys take a look at this?
>
> Thanks,
> -Bryan
>
> On Thu, Feb 17, 2011 at 4:11 PM, Bryan Wu<bryan.wu@canonical.com>  wrote:
>> From: Mathieu J. Poirier<mathieu.poirier@canonical.com>
>>
>> https://bugs.launchpad.net/bugs/630885
>>
>> When booting, the omapdss subsystem is looking for a regulator named
>> "vdds_sdi". When the regulator is not found the initialisation sequence
>> is aborted resulting in omapfb not finding a display to work with.  This
>> patch allows the omapfb sub system to complete its initialisation
>> properly and enable LCD display. The problem was fixed by lumping a
>> "vdds_sdi" with the already existing "vdds_dsi" regulator. This fix
>> takes its root from work done on the Beagle board and the Pandora board.
>>
>> Signed-off-by: Mathieu Poirier<mathieu.poirier@canonical.com>
>> Signed-off-by: Andy Whitcroft<apw@canonical.com>
>> Signed-off-by: Bryan Wu<bryan.wu@canonical.com>
>> ---
>>   arch/arm/mach-omap2/board-omap3evm.c |   10 ++++++----
>>   1 files changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
>> index c2a0fca..8b8eb36 100644
>> --- a/arch/arm/mach-omap2/board-omap3evm.c
>> +++ b/arch/arm/mach-omap2/board-omap3evm.c
>> @@ -521,8 +521,10 @@ static struct regulator_init_data omap3_evm_vdac = {
>>   };
>>
>>   /* VPLL2 for digital video outputs */
>> -static struct regulator_consumer_supply omap3_evm_vpll2_supply =
>> -       REGULATOR_SUPPLY("vdds_dsi", "omapdss");
>> +static struct regulator_consumer_supply omap3_evm_vdds_supplies[] = {
>> +       REGULATOR_SUPPLY("vdds_sdi", "omapdss"),
>> +       REGULATOR_SUPPLY("vdds_dsi", "omapdss"),
>> +};

I agree that this is needed. Currently, in omap_dss_probe() in core.c we 
call sdi_init even if its not selected in menuconfig. The same goes for 
other modules.

There is no harm adding this as. But we will probably need a cleaner way 
to handle initialization of the DSS interface modules in the DSS2 code.

Regards,
Archit

Hi,

On Thu, 2011-02-17 at 08:11 +0000, Bryan Wu wrote:
> From: Mathieu J. Poirier <mathieu.poirier@canonical.com>
> 
> https://bugs.launchpad.net/bugs/630885
> 
> When booting, the omapdss subsystem is looking for a regulator named
> "vdds_sdi". When the regulator is not found the initialisation sequence
> is aborted resulting in omapfb not finding a display to work with.  This
> patch allows the omapfb sub system to complete its initialisation
> properly and enable LCD display. The problem was fixed by lumping a
> "vdds_sdi" with the already existing "vdds_dsi" regulator. This fix
> takes its root from work done on the Beagle board and the Pandora board.

This isn't a correct fix.

If we would add the sdi regulator to remove the problem we would need to
add the sdi regulator to all boards, not just EVM.

However, I wouldn't go adding them. The proper fix is to make sdi.c only
use the regulator if SDI is actually used. Currently it tries to acquire
it always.

A simple "fix" for this is to disable SDI from Kconfig, presuming you
don't have boards that use SDI interface. N900 is the only board that I
know of which uses SDI.

 Tomi