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


--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team

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
>

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team

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

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team

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



--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team