linux-next: manual merge of the omap_dss2 tree with the omap tree

linux-next: manual merge of the omap_dss2 tree with the omap tree

[Stephen Rothwell]

Hi Tomi,

Today's linux-next merge of the omap_dss2 tree got a conflict in
arch/arm/mach-omap2/board-rx51-peripherals.c between commit
e87da74e34ad151e6ae75ebb7a7bf447f02c0004 ("omap: rx51: Add supplies for
the tlv320aic3x codec driver") from the omap tree and commit
a693839eab0292aa234d7a6f48d40389389baebb ("OMAP: RX51: Add "vdds_sdi"
supply voltage for SDI") from the omap_dss2 tree.

Just overlapping additions. I fixed it up (see below) and can carry the
fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/arm/mach-omap2/board-rx51-peripherals.c
index 8179d55,020f354..0000000
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@@ -287,35 -315,19 +315,48 @@@ static struct regulator_consumer_suppl
  	.dev_name = "mmci-omap-hs.1",
  };
  
 +static struct regulator_consumer_supply rx51_vmmc2_supplies[] = {
 +	/* tlv320aic3x analog supplies */
 +	{
 +		.supply		= "AVDD",
 +		.dev_name	= "2-0018",
 +	},
 +	{
 +		.supply		= "DRVDD",
 +		.dev_name	= "2-0018",
 +	},
 +	/* Keep vmmc as last item. It is not iterated for newer boards */
 +	{
 +		.supply		= "vmmc",
 +		.dev_name	= "mmci-omap-hs.1",
 +	},
 +};
 +
 +static struct regulator_consumer_supply rx51_vio_supplies[] = {
 +	/* tlv320aic3x digital supplies */
 +	{
 +		.supply		= "IOVDD",
 +		.dev_name	= "2-0018"
 +	},
 +	{
 +		.supply		= "DVDD",
 +		.dev_name	= "2-0018"
 +	},
 +};
 +
+ #if defined(CONFIG_FB_OMAP2) || defined(CONFIG_FB_OMAP2_MODULE)
+ extern struct platform_device rx51_display_device;
+ #endif
+ 
+ static struct regulator_consumer_supply rx51_vaux1_consumers[] = {
+ #if defined(CONFIG_FB_OMAP2) || defined(CONFIG_FB_OMAP2_MODULE)
+ 	{
+ 		.supply	= "vdds_sdi",
+ 		.dev	= &rx51_display_device.dev,
+ 	},
+ #endif
+ };
+ 
  static struct regulator_init_data rx51_vaux1 = {
  	.constraints = {
  		.name			= "V28",

Re: linux-next: manual merge of the omap_dss2 tree with the omap tree

[Tony Lindgren]

* Stephen Rothwell <sfr@canb.auug.org.au> [100506 22:05]:
> Hi Tomi,
> 
> Today's linux-next merge of the omap_dss2 tree got a conflict in
> arch/arm/mach-omap2/board-rx51-peripherals.c between commit
> e87da74e34ad151e6ae75ebb7a7bf447f02c0004 ("omap: rx51: Add supplies for
> the tlv320aic3x codec driver") from the omap tree and commit
> a693839eab0292aa234d7a6f48d40389389baebb ("OMAP: RX51: Add "vdds_sdi"
> supply voltage for SDI") from the omap_dss2 tree.
> 
> Just overlapping additions. I fixed it up (see below) and can carry the
> fix as necessary.

Thanks again Stephen. We will move the conflicting DSS board-*.c
file changes over to omap for next.

Tomi, do you want to do a branch of board-*.c patches for me to
pull, or do you want me to just pick this one?

Regards,

Tony

Re: linux-next: manual merge of the omap_dss2 tree with the omap tree

[Tomi Valkeinen]

Hi,

On Mon, 2010-05-10 at 22:20 +0200, ext Tony Lindgren wrote:
> * Stephen Rothwell <sfr@canb.auug.org.au> [100506 22:05]:
> > Hi Tomi,
> > 
> > Today's linux-next merge of the omap_dss2 tree got a conflict in
> > arch/arm/mach-omap2/board-rx51-peripherals.c between commit
> > e87da74e34ad151e6ae75ebb7a7bf447f02c0004 ("omap: rx51: Add supplies for
> > the tlv320aic3x codec driver") from the omap tree and commit
> > a693839eab0292aa234d7a6f48d40389389baebb ("OMAP: RX51: Add "vdds_sdi"
> > supply voltage for SDI") from the omap_dss2 tree.
> > 
> > Just overlapping additions. I fixed it up (see below) and can carry the
> > fix as necessary.
> 
> Thanks again Stephen. We will move the conflicting DSS board-*.c
> file changes over to omap for next.
> 
> Tomi, do you want to do a branch of board-*.c patches for me to
> pull, or do you want me to just pick this one?

I think it's ok to pick just this one. It's just adds a regulator
supply, and doesn't interfere with anything. I just need to make sure
linux-omap's for-next is merged first, before I send my pull request.

I made a branch for it, based on linux-omap/for-next:
git://gitorious.org/linux-omap-dss2/linux.git for-tony

And I dropped the patch from my for-next branch.

 Tomi

Re: linux-next: manual merge of the omap_dss2 tree with the omap tree

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@nokia.com> [100512 01:54]:
> Hi,
> 
> On Mon, 2010-05-10 at 22:20 +0200, ext Tony Lindgren wrote:
> > * Stephen Rothwell <sfr@canb.auug.org.au> [100506 22:05]:
> > > Hi Tomi,
> > > 
> > > Today's linux-next merge of the omap_dss2 tree got a conflict in
> > > arch/arm/mach-omap2/board-rx51-peripherals.c between commit
> > > e87da74e34ad151e6ae75ebb7a7bf447f02c0004 ("omap: rx51: Add supplies for
> > > the tlv320aic3x codec driver") from the omap tree and commit
> > > a693839eab0292aa234d7a6f48d40389389baebb ("OMAP: RX51: Add "vdds_sdi"
> > > supply voltage for SDI") from the omap_dss2 tree.
> > > 
> > > Just overlapping additions. I fixed it up (see below) and can carry the
> > > fix as necessary.
> > 
> > Thanks again Stephen. We will move the conflicting DSS board-*.c
> > file changes over to omap for next.
> > 
> > Tomi, do you want to do a branch of board-*.c patches for me to
> > pull, or do you want me to just pick this one?
> 
> I think it's ok to pick just this one. It's just adds a regulator
> supply, and doesn't interfere with anything. I just need to make sure
> linux-omap's for-next is merged first, before I send my pull request.

Thanks, I've picked this patch.
 
> I made a branch for it, based on linux-omap/for-next:
> git://gitorious.org/linux-omap-dss2/linux.git for-tony
> 
> And I dropped the patch from my for-next branch.

Tomi, next time please check that your branch is based on
either the most recent tag by Linus, or in the conflicting
cases you can base on omap-for-linus branch. Please don't
base on for-next or other branches that are not yet
static, we don't want the merge history of duplicate branches.

Regards,

Tony

Re: linux-next: manual merge of the omap_dss2 tree with the omap tree

[Tomi Valkeinen]

On Fri, 2010-05-14 at 21:09 +0200, ext Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@nokia.com> [100512 01:54]:
> > Hi,
> > 
> > On Mon, 2010-05-10 at 22:20 +0200, ext Tony Lindgren wrote:
> > > * Stephen Rothwell <sfr@canb.auug.org.au> [100506 22:05]:
> > > > Hi Tomi,
> > > > 
> > > > Today's linux-next merge of the omap_dss2 tree got a conflict in
> > > > arch/arm/mach-omap2/board-rx51-peripherals.c between commit
> > > > e87da74e34ad151e6ae75ebb7a7bf447f02c0004 ("omap: rx51: Add supplies for
> > > > the tlv320aic3x codec driver") from the omap tree and commit
> > > > a693839eab0292aa234d7a6f48d40389389baebb ("OMAP: RX51: Add "vdds_sdi"
> > > > supply voltage for SDI") from the omap_dss2 tree.
> > > > 
> > > > Just overlapping additions. I fixed it up (see below) and can carry the
> > > > fix as necessary.
> > > 
> > > Thanks again Stephen. We will move the conflicting DSS board-*.c
> > > file changes over to omap for next.
> > > 
> > > Tomi, do you want to do a branch of board-*.c patches for me to
> > > pull, or do you want me to just pick this one?
> > 
> > I think it's ok to pick just this one. It's just adds a regulator
> > supply, and doesn't interfere with anything. I just need to make sure
> > linux-omap's for-next is merged first, before I send my pull request.
> 
> Thanks, I've picked this patch.
>  
> > I made a branch for it, based on linux-omap/for-next:
> > git://gitorious.org/linux-omap-dss2/linux.git for-tony
> > 
> > And I dropped the patch from my for-next branch.
> 
> Tomi, next time please check that your branch is based on
> either the most recent tag by Linus, or in the conflicting
> cases you can base on omap-for-linus branch. Please don't
> base on for-next or other branches that are not yet
> static, we don't want the merge history of duplicate branches.

Oh, that branch was just for you to cherry pick the one patch. My
"normal" branches are based on official tags.

 Tomi

Re: linux-next: manual merge of the omap_dss2 tree with the omap tree

[Tony Lindgren]

Hi,

* Tomi Valkeinen <tomi.valkeinen@ti.com> [110221 00:46]:
> 
> Tony, do you have such a semi-stable branch I could use as a base? Or
> any other ideas?

I guess you already figured this out.. The omap-for-linus branch should
have immutable commits. So you can merge with the earliest commit that
does the job for you from there.

Regards,

Tony

Re: linux-next: manual merge of the omap_dss2 tree with the omap tree

[Tomi Valkeinen]

Hi Stephen and Tony,

On Sun, 2011-02-20 at 21:16 -0600, Stephen Rothwell wrote:
> Hi Tomi,
> 
> Today's linux-next merge of the omap_dss2 tree got a conflict in
> arch/arm/mach-omap2/board-3430sdp.c between commits
> e109f171e2f4128e867b3445c369c18830c73751 ("omap3sdp: Fix regulator
> mapping for ads7846 TS controller") and
> 6b272c098f64f0451d2b19bb911d65c6cd11cfc7 ("omap3sdp: clean regulator
> supply mapping in board file") from the omap tree and various commits
> from the omap_dss2 tree.
> 
> So, I have no idea how to fix this up ... Can you guys come to some
> argreement about who does what, please?  I have ended up with the merge
> fix below, but I have no idea if it will even build, much less be
> semantically correct, sorry.
> 
> Do these trees get merged separately by Linus?  If not, then maybe I
> should just be merging the one tree that combines all the omap work and
> let you guys figure out the merge mess.

No, linux-omap tree is merged directly by Linus, and my display
subsystem tree goes through Paul Mundt's fbdev tree.

In theory the DSS tree should be just a driver, and there shouldn't be
conflicts with any other tree. In practice it seems that there are quite
often arch/arm/mach-omap2/ changes, which then conflict with linux-omap
tree. And especially in this and the next merge windows, as there are
lots of new OMAP4 code going in.

It would be nice to get all arch omap changes through Tony's tree, and
DSS changes through my tree. But more often than not the changes depend
on each other, and applying just the other would break the kernel.

I see the following options to fix this:

1) DSS tree would go through Tony, not through Paul. I think Tony is not
in favor of this.
2) I would keep DSS tree based on top of some (semi-)stable branch from
linux-omap (which?), and rebase/merge quite often to keep the tree
conflict free. I would also need to wait until Tony's tree is merged
into Linus' tree before sending a pull request for DSS tree.
3) Remove DSS tree from linux-next to prevent this conflict mess. I
would wait until Tony's tree is pulled, rebase/merge and fix the
conflicts, and send a pull request.

None of these is perfect, but perhaps the second one could be the best.
We would still get the benefit of linux-next, without putting any more
burden on Tony.

Tony, do you have such a semi-stable branch I could use as a base? Or
any other ideas?

 Tomi

linux-next: manual merge of the omap_dss2 tree with the omap tree

[Stephen Rothwell]

Hi Tomi,

Today's linux-next merge of the omap_dss2 tree got a conflict in
arch/arm/mach-omap2/board-3430sdp.c between commits
e109f171e2f4128e867b3445c369c18830c73751 ("omap3sdp: Fix regulator
mapping for ads7846 TS controller") and
6b272c098f64f0451d2b19bb911d65c6cd11cfc7 ("omap3sdp: clean regulator
supply mapping in board file") from the omap tree and various commits
from the omap_dss2 tree.

So, I have no idea how to fix this up ... Can you guys come to some
argreement about who does what, please?  I have ended up with the merge
fix below, but I have no idea if it will even build, much less be
semantically correct, sorry.

Do these trees get merged separately by Linus?  If not, then maybe I
should just be merging the one tree that combines all the omap work and
let you guys figure out the merge mess.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/arm/mach-omap2/board-3430sdp.c
index 76a260f,33ff4f6..0000000
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@@ -307,18 -307,9 +307,6 @@@ static struct omap_dss_board_info sdp34
  	.default_device	= &sdp3430_lcd_device,
  };
  
- static struct platform_device sdp3430_dss_device = {
- 	.name		= "omapdss",
- 	.id		= -1,
- 	.dev		= {
- 		.platform_data = &sdp3430_dss_data,
- 	},
- };
- 
- static struct platform_device *sdp3430_devices[] __initdata = {
- 	&sdp3430_dss_device,
- };
- 
 -static struct regulator_consumer_supply sdp3430_vdda_dac_supply =
 -	REGULATOR_SUPPLY("vdda_dac", "omap_venc");
 -
  static struct omap_board_config_kernel sdp3430_config[] __initdata = {
  };
  
@@@ -402,34 -413,6 +390,35 @@@ static struct twl4030_madc_platform_dat
  	.irq_line	= 1,
  };
  
 +/* regulator consumer mappings */
 +
 +/* ads7846 on SPI */
 +static struct regulator_consumer_supply sdp3430_vaux3_supplies[] = {
 +	REGULATOR_SUPPLY("vcc", "spi1.0"),
 +};
 +
 +static struct regulator_consumer_supply sdp3430_vdda_dac_supplies[] = {
 +	REGULATOR_SUPPLY("vdda_dac", "omapdss"),
 +};
 +
 +/* VPLL2 for digital video outputs */
 +static struct regulator_consumer_supply sdp3430_vpll2_supplies[] = {
 +	REGULATOR_SUPPLY("vdds_dsi", "omapdss"),
++	REGULATOR_SUPPLY("vdds_dsi", "omap_dsi1"),
 +};
 +
 +static struct regulator_consumer_supply sdp3430_vmmc1_supplies[] = {
 +	REGULATOR_SUPPLY("vmmc", "mmci-omap-hs.0"),
 +};
 +
 +static struct regulator_consumer_supply sdp3430_vsim_supplies[] = {
 +	REGULATOR_SUPPLY("vmmc_aux", "mmci-omap-hs.0"),
 +};
 +
 +static struct regulator_consumer_supply sdp3430_vmmc2_supplies[] = {
 +	REGULATOR_SUPPLY("vmmc", "mmci-omap-hs.1"),
 +};
 +
  /*
   * Apply all the fixed voltages since most versions of U-Boot
   * don't bother with that initialization.

linux-next: manual merge of the omap_dss2 tree with the omap tree

[Stephen Rothwell]

Hi Tomi,

Today's linux-next merge of the omap_dss2 tree got a conflict in
arch/arm/mach-omap2/board-am3517evm.c between commit
3dc3bad6f1b316d79d9d1d596a590b5097cb3dc4 ("ARM: OMAP2: use early init
hook") from the omap tree and commit
603aa0662c26ad05c3ecf1b912f8bebf76dab73d ("OMAP2, 3: DSS2: board files:
replace platform_device_register with omap_display_init()") from the
omap_dss2 tree.

Just context changes.  I fixed it up (see below) and can carry the fix as
necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/arm/mach-omap2/board-am3517evm.c
index d0d0f55,548f524..0000000
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@@ -392,11 -384,7 +384,7 @@@ static struct omap_dss_board_info am351
  static struct omap_board_config_kernel am3517_evm_config[] __initdata = {
  };
  
- static struct platform_device *am3517_evm_devices[] __initdata = {
- 	&am3517_evm_dss_device,
- };
- 
 -static void __init am3517_evm_init_irq(void)
 +static void __init am3517_evm_init_early(void)
  {
  	omap_board_config = am3517_evm_config;
  	omap_board_config_size = ARRAY_SIZE(am3517_evm_config);

linux-next: manual merge of the omap_dss2 tree with the omap tree

[Stephen Rothwell]

Hi Tomi,

Today's linux-next merge of the omap_dss2 tree got a conflict in
arch/arm/mach-omap2/omap_hwmod_2420_data.c between commit
eb969b4f07175960fa0b325e6c9bd2093ab49645 ("OMAP2420: hwmod data: Add
McSPI") from the omap tree and commit
e9ca66e751e89d2d5323d809ecb2b54f4e255d8d ("OMAP2420: hwmod data: add DSS
DISPC RFBI VENC") from the omap_dss2 tree.

I fixed it up (see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 7fffd34,21014de..0000000
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@@ -18,8 -18,8 +18,9 @@@
  #include <plat/serial.h>
  #include <plat/i2c.h>
  #include <plat/gpio.h>
 +#include <plat/mcspi.h>
- 
+ #include <plat/l3_2xxx.h>
+ #include <plat/l4_2xxx.h>
  #include "omap_hwmod_common_data.h"
  
  #include "cm-regbits-24xx.h"

linux-next: manual merge of the omap_dss2 tree with the omap tree

[Stephen Rothwell]

Hi Tomi,

Today's linux-next merge of the omap_dss2 tree got a conflict in
arch/arm/mach-omap2/omap_hwmod_2430_data.c between commit
1ae9e33689d1346f7f85845857639a923e0796e3 ("OMAP2430: hwmod data: Add
McSPI") from the omap tree and commit
452e3eed4ee6eb8d61b290dad53d48508a3438d8 ("OMAP2430: hwmod data: add DSS
DISPC RFBI VENC") from the omap_dss2 tree.

I fixed it up (see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 60fe4aa,1ef3f3f..0000000
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@@ -18,7 -18,7 +18,8 @@@
  #include <plat/serial.h>
  #include <plat/i2c.h>
  #include <plat/gpio.h>
 +#include <plat/mcspi.h>
+ #include <plat/l3_2xxx.h>
  
  #include "omap_hwmod_common_data.h"
  

Re: linux-next: manual merge of the omap_dss2 tree with the omap tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 281 bytes --]

Hi Tony,

On Thu, 11 Mar 2010 08:53:59 -0800 Tony Lindgren <tony@atomide.com> wrote:
>
> I'll split my patch in two parts, and let Tomi queue this fix.

OK, thanks.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: linux-next: manual merge of the omap_dss2 tree with the omap tree

[Tony Lindgren]

* Stephen Rothwell <sfr@canb.auug.org.au> [100310 20:15]:
> Hi Tomi,
> 
> Today's linux-next merge of the omap_dss2 tree got a conflict in
> drivers/video/omap2/vram.c between commit
> 4ff6baf45cd23593592e5786ccd607bdc8785f4c ("omap: Fix compile for
> early_param and omap_smc1") from the omap tree and commit
> 5c1f96f4cffbdde9e194f3ae5373953f3fa12836 ("OMAP: DSS2: VRAM: Fix
> early_param for vram") from the omap_dss2 tree.
> 
> Just two versions of the same fix to omap_vram_early_vram().  I used the
> omap tree version.

I'll split my patch in two parts, and let Tomi queue this fix.

Regards,

Tony

linux-next: manual merge of the omap_dss2 tree with the omap tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 564 bytes --]

Hi Tomi,

Today's linux-next merge of the omap_dss2 tree got a conflict in
drivers/video/omap2/vram.c between commit
4ff6baf45cd23593592e5786ccd607bdc8785f4c ("omap: Fix compile for
early_param and omap_smc1") from the omap tree and commit
5c1f96f4cffbdde9e194f3ae5373953f3fa12836 ("OMAP: DSS2: VRAM: Fix
early_param for vram") from the omap_dss2 tree.

Just two versions of the same fix to omap_vram_early_vram().  I used the
omap tree version.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

RE: linux-next: manual merge of the omap_dss2 tree with the omap tree

[Hiremath, Vaibhav]

Thanks,
Vaibhav Hiremath
Platform Support Products
Texas Instruments Inc
Ph: +91-80-25099927

> -----Original Message-----
> From: Stephen Rothwell [mailto:sfr@canb.auug.org.au]
> Sent: Monday, February 08, 2010 11:55 AM
> To: Tomi Valkeinen
> Cc: linux-next@vger.kernel.org; linux-kernel@vger.kernel.org;
> Hiremath, Vaibhav; Tony Lindgren; linux-omap@vger.kernel.org
> Subject: linux-next: manual merge of the omap_dss2 tree with the
> omap tree
> 
> Hi Tomi,
> 
> Today's linux-next merge of the omap_dss2 tree got a conflict in
> arch/arm/mach-omap2/board-am3517evm.c between commit
> 13560d875d67c06239c82a6148c1b87075701fe9 ("AM3517: Enable basic I2C
> Support") from the omap tree and commit
> 56a3d0235cd50d14d7bd4d45e55d192aa0e78cac ("OMAP: AM3517: Enable DSS2
> for
> AM3517EVM board") from the omap_dss2 tree.
> 
> Juts overlapping additions.   I fixed it up (see below) and can
> carry the
> fix as necessary.
> 
> P.S. Tomi, this omap_dss2 commit only has your Acked-by not Signed-
> off-by.
> --
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> 
> diff --cc arch/arm/mach-omap2/board-am3517evm.c
> index a166bcc,54af5f8..0000000
> --- a/arch/arm/mach-omap2/board-am3517evm.c
> +++ b/arch/arm/mach-omap2/board-am3517evm.c
> @@@ -33,15 -33,147 +34,156 @@@
> 
>   #include "mux.h"
> 
[Hiremath, Vaibhav] I don't see display.h being added here, but when I looked into linux-next repo, I could see that. I think the following commit only shows for the conflicted part, so should be ok.

Thanks,
Vaibhav

> + #define LCD_PANEL_PWR		176
> + #define LCD_PANEL_BKLIGHT_PWR	182
> + #define LCD_PANEL_PWM		181
> +
> + static int lcd_enabled;
> + static int dvi_enabled;
> +
> + static void __init am3517_evm_display_init(void)
> + {
> + 	int r;
> +
> + 	omap_mux_init_gpio(LCD_PANEL_PWR, OMAP_PIN_INPUT_PULLUP);
> + 	omap_mux_init_gpio(LCD_PANEL_BKLIGHT_PWR,
> OMAP_PIN_INPUT_PULLDOWN);
> + 	omap_mux_init_gpio(LCD_PANEL_PWM, OMAP_PIN_INPUT_PULLDOWN);
> + 	/*
> + 	 * Enable GPIO 182 = LCD Backlight Power
> + 	 */
> + 	r = gpio_request(LCD_PANEL_BKLIGHT_PWR, "lcd_backlight_pwr");
> + 	if (r) {
> + 		printk(KERN_ERR "failed to get lcd_backlight_pwr\n");
> + 		return;
> + 	}
> + 	gpio_direction_output(LCD_PANEL_BKLIGHT_PWR, 1);
> + 	/*
> + 	 * Enable GPIO 181 = LCD Panel PWM
> + 	 */
> + 	r = gpio_request(LCD_PANEL_PWM, "lcd_pwm");
> + 	if (r) {
> + 		printk(KERN_ERR "failed to get lcd_pwm\n");
> + 		goto err_1;
> + 	}
> + 	gpio_direction_output(LCD_PANEL_PWM, 1);
> + 	/*
> + 	 * Enable GPIO 176 = LCD Panel Power enable pin
> + 	 */
> + 	r = gpio_request(LCD_PANEL_PWR, "lcd_panel_pwr");
> + 	if (r) {
> + 		printk(KERN_ERR "failed to get lcd_panel_pwr\n");
> + 		goto err_2;
> + 	}
> + 	gpio_direction_output(LCD_PANEL_PWR, 1);
> +
> + 	printk(KERN_INFO "Display initialized successfully\n");
> + 	return;
> +
> + err_2:
> + 	gpio_free(LCD_PANEL_PWM);
> + err_1:
> + 	gpio_free(LCD_PANEL_BKLIGHT_PWR);
> + }
> +
> + static int am3517_evm_panel_enable_lcd(struct omap_dss_device
> *dssdev)
> + {
> + 	if (dvi_enabled) {
> + 		printk(KERN_ERR "cannot enable LCD, DVI is enabled\n");
> + 		return -EINVAL;
> + 	}
> + 	gpio_set_value(LCD_PANEL_PWR, 1);
> + 	lcd_enabled = 1;
> +
> + 	return 0;
> + }
> +
> + static void am3517_evm_panel_disable_lcd(struct omap_dss_device
> *dssdev)
> + {
> + 	gpio_set_value(LCD_PANEL_PWR, 0);
> + 	lcd_enabled = 0;
> + }
> +
> + static struct omap_dss_device am3517_evm_lcd_device = {
> + 	.type			= OMAP_DISPLAY_TYPE_DPI,
> + 	.name			= "lcd",
> + 	.driver_name		= "sharp_lq_panel",
> + 	.phy.dpi.data_lines 	= 16,
> + 	.platform_enable	= am3517_evm_panel_enable_lcd,
> + 	.platform_disable	= am3517_evm_panel_disable_lcd,
> + };
> +
> + static int am3517_evm_panel_enable_tv(struct omap_dss_device
> *dssdev)
> + {
> + 	return 0;
> + }
> +
> + static void am3517_evm_panel_disable_tv(struct omap_dss_device
> *dssdev)
> + {
> + }
> +
> + static struct omap_dss_device am3517_evm_tv_device = {
> + 	.type 			= OMAP_DISPLAY_TYPE_VENC,
> + 	.name 			= "tv",
> + 	.driver_name		= "venc",
> + 	.phy.venc.type		= OMAP_DSS_VENC_TYPE_SVIDEO,
> + 	.platform_enable	= am3517_evm_panel_enable_tv,
> + 	.platform_disable	= am3517_evm_panel_disable_tv,
> + };
> +
> + static int am3517_evm_panel_enable_dvi(struct omap_dss_device
> *dssdev)
> + {
> + 	if (lcd_enabled) {
> + 		printk(KERN_ERR "cannot enable DVI, LCD is enabled\n");
> + 		return -EINVAL;
> + 	}
> + 	dvi_enabled = 1;
> +
> + 	return 0;
> + }
> +
> + static void am3517_evm_panel_disable_dvi(struct omap_dss_device
> *dssdev)
> + {
> + 	dvi_enabled = 0;
> + }
> +
> + static struct omap_dss_device am3517_evm_dvi_device = {
> + 	.type			= OMAP_DISPLAY_TYPE_DPI,
> + 	.name			= "dvi",
> + 	.driver_name		= "generic_panel",
> + 	.phy.dpi.data_lines	= 24,
> + 	.platform_enable	= am3517_evm_panel_enable_dvi,
> + 	.platform_disable	= am3517_evm_panel_disable_dvi,
> + };
> +
> + static struct omap_dss_device *am3517_evm_dss_devices[] = {
> + 	&am3517_evm_lcd_device,
> + 	&am3517_evm_tv_device,
> + 	&am3517_evm_dvi_device,
> + };
> +
> + static struct omap_dss_board_info am3517_evm_dss_data = {
> + 	.num_devices	= ARRAY_SIZE(am3517_evm_dss_devices),
> + 	.devices	= am3517_evm_dss_devices,
> + 	.default_device	= &am3517_evm_lcd_device,
> + };
> +
> + struct platform_device am3517_evm_dss_device = {
> + 	.name		= "omapdss",
> + 	.id		= -1,
> + 	.dev		= {
> + 		.platform_data	= &am3517_evm_dss_data,
> + 	},
> + };
> +
>  +static int __init am3517_evm_i2c_init(void)
>  +{
>  +	omap_register_i2c_bus(1, 400, NULL, 0);
>  +	omap_register_i2c_bus(2, 400, NULL, 0);
>  +	omap_register_i2c_bus(3, 400, NULL, 0);
>  +
>  +	return 0;
>  +}
>  +
>   /*
>    * Board initialization
>    */

Re: linux-next: manual merge of the omap_dss2 tree with the omap tree

[Tomi Valkeinen]

On Tue, 2010-02-09 at 17:52 +0100, ext Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@nokia.com> [100208 01:23]:
> > On Mon, 2010-02-08 at 07:25 +0100, ext Stephen Rothwell wrote:
> > > Hi Tomi,
> > > 
> > > Today's linux-next merge of the omap_dss2 tree got a conflict in
> > > arch/arm/mach-omap2/board-am3517evm.c between commit
> > > 13560d875d67c06239c82a6148c1b87075701fe9 ("AM3517: Enable basic I2C
> > > Support") from the omap tree and commit
> > > 56a3d0235cd50d14d7bd4d45e55d192aa0e78cac ("OMAP: AM3517: Enable DSS2 for
> > > AM3517EVM board") from the omap_dss2 tree.
> > > 
> > > Juts overlapping additions.   I fixed it up (see below) and can carry the
> > > fix as necessary.
> > 
> > Thanks. I guess we can't properly fix this until the patch from omap
> > tree goes into mainline.
> 
> Let's move the AM3517 DSS2 board patch from Tomi's tree to omap for-next
> tree.
>  
> > Tony, do you think this current way, in which we have board file changes
> > in both linux-omap and the dss tree, is best we can do? Or should all
> > the board file changes go through linux-omap? I fear that we will have
> > conflicts with every new board.
> 
> Yeah we should just move the conflicting files into omap for-next. The board
> file changes conflict easily when new platform device init code is being
> added.
> 
> Tomi, how about you ack and let me know about the patches (or git branch)
> you want me to add into omap for-next? Otherwise I'll assume anything
> DSS2 related is yours.

This sounds good. However, we need to be careful that there are no
dependencies from the board file patches to the DSS patches (like panel
drivers).

But this is getting out of topic for this mail thread, let's deal with
this separately =).

 Tomi

Re: linux-next: manual merge of the omap_dss2 tree with the omap tree

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@nokia.com> [100208 01:23]:
> On Mon, 2010-02-08 at 07:25 +0100, ext Stephen Rothwell wrote:
> > Hi Tomi,
> > 
> > Today's linux-next merge of the omap_dss2 tree got a conflict in
> > arch/arm/mach-omap2/board-am3517evm.c between commit
> > 13560d875d67c06239c82a6148c1b87075701fe9 ("AM3517: Enable basic I2C
> > Support") from the omap tree and commit
> > 56a3d0235cd50d14d7bd4d45e55d192aa0e78cac ("OMAP: AM3517: Enable DSS2 for
> > AM3517EVM board") from the omap_dss2 tree.
> > 
> > Juts overlapping additions.   I fixed it up (see below) and can carry the
> > fix as necessary.
> 
> Thanks. I guess we can't properly fix this until the patch from omap
> tree goes into mainline.

Let's move the AM3517 DSS2 board patch from Tomi's tree to omap for-next
tree.
 
> Tony, do you think this current way, in which we have board file changes
> in both linux-omap and the dss tree, is best we can do? Or should all
> the board file changes go through linux-omap? I fear that we will have
> conflicts with every new board.

Yeah we should just move the conflicting files into omap for-next. The board
file changes conflict easily when new platform device init code is being
added.

Tomi, how about you ack and let me know about the patches (or git branch)
you want me to add into omap for-next? Otherwise I'll assume anything
DSS2 related is yours.

Regards,

Tony

Re: linux-next: manual merge of the omap_dss2 tree with the omap tree

[Tomi Valkeinen]

Hi,

On Mon, 2010-02-08 at 11:57 +0100, ext Stephen Rothwell wrote:
> Hi Tomi,
> 
> On Mon, 08 Feb 2010 11:29:06 +0200 Tomi Valkeinen <tomi.valkeinen@nokia.com> wrote:
> >
> > > P.S. Tomi, this omap_dss2 commit only has your Acked-by not Signed-off-by.
> > 
> > Hmm, do you mean there's something wrong with that, or "jfyi"? Aren't I,
> > as a subsys maintainer, supposed to ack the patches?
> 
> If a patch goes through your tree, you are supposed to add a Signed-off-by
> line.  See Documentation/SubmittingPatches section called "Sign your
> work".

So it is. Thanks for pointing this out, I'll change the acks to
signed-offs.

 Tomi

Re: linux-next: manual merge of the omap_dss2 tree with the omap tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 581 bytes --]

Hi Tomi,

On Mon, 08 Feb 2010 11:29:06 +0200 Tomi Valkeinen <tomi.valkeinen@nokia.com> wrote:
>
> > P.S. Tomi, this omap_dss2 commit only has your Acked-by not Signed-off-by.
> 
> Hmm, do you mean there's something wrong with that, or "jfyi"? Aren't I,
> as a subsys maintainer, supposed to ack the patches?

If a patch goes through your tree, you are supposed to add a Signed-off-by
line.  See Documentation/SubmittingPatches section called "Sign your
work".

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: linux-next: manual merge of the omap_dss2 tree with the omap tree

[Tomi Valkeinen]

On Mon, 2010-02-08 at 07:25 +0100, ext Stephen Rothwell wrote:
> Hi Tomi,
> 
> Today's linux-next merge of the omap_dss2 tree got a conflict in
> arch/arm/mach-omap2/board-am3517evm.c between commit
> 13560d875d67c06239c82a6148c1b87075701fe9 ("AM3517: Enable basic I2C
> Support") from the omap tree and commit
> 56a3d0235cd50d14d7bd4d45e55d192aa0e78cac ("OMAP: AM3517: Enable DSS2 for
> AM3517EVM board") from the omap_dss2 tree.
> 
> Juts overlapping additions.   I fixed it up (see below) and can carry the
> fix as necessary.

Thanks. I guess we can't properly fix this until the patch from omap
tree goes into mainline.

Tony, do you think this current way, in which we have board file changes
in both linux-omap and the dss tree, is best we can do? Or should all
the board file changes go through linux-omap? I fear that we will have
conflicts with every new board.

> P.S. Tomi, this omap_dss2 commit only has your Acked-by not Signed-off-by.

Hmm, do you mean there's something wrong with that, or "jfyi"? Aren't I,
as a subsys maintainer, supposed to ack the patches?

 Tomi

linux-next: manual merge of the omap_dss2 tree with the omap tree

[Stephen Rothwell]

Hi Tomi,

Today's linux-next merge of the omap_dss2 tree got a conflict in
arch/arm/mach-omap2/board-am3517evm.c between commit
13560d875d67c06239c82a6148c1b87075701fe9 ("AM3517: Enable basic I2C
Support") from the omap tree and commit
56a3d0235cd50d14d7bd4d45e55d192aa0e78cac ("OMAP: AM3517: Enable DSS2 for
AM3517EVM board") from the omap_dss2 tree.

Juts overlapping additions.   I fixed it up (see below) and can carry the
fix as necessary.

P.S. Tomi, this omap_dss2 commit only has your Acked-by not Signed-off-by.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/arm/mach-omap2/board-am3517evm.c
index a166bcc,54af5f8..0000000
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@@ -33,15 -33,147 +34,156 @@@
  
  #include "mux.h"
  
+ #define LCD_PANEL_PWR		176
+ #define LCD_PANEL_BKLIGHT_PWR	182
+ #define LCD_PANEL_PWM		181
+ 
+ static int lcd_enabled;
+ static int dvi_enabled;
+ 
+ static void __init am3517_evm_display_init(void)
+ {
+ 	int r;
+ 
+ 	omap_mux_init_gpio(LCD_PANEL_PWR, OMAP_PIN_INPUT_PULLUP);
+ 	omap_mux_init_gpio(LCD_PANEL_BKLIGHT_PWR, OMAP_PIN_INPUT_PULLDOWN);
+ 	omap_mux_init_gpio(LCD_PANEL_PWM, OMAP_PIN_INPUT_PULLDOWN);
+ 	/*
+ 	 * Enable GPIO 182 = LCD Backlight Power
+ 	 */
+ 	r = gpio_request(LCD_PANEL_BKLIGHT_PWR, "lcd_backlight_pwr");
+ 	if (r) {
+ 		printk(KERN_ERR "failed to get lcd_backlight_pwr\n");
+ 		return;
+ 	}
+ 	gpio_direction_output(LCD_PANEL_BKLIGHT_PWR, 1);
+ 	/*
+ 	 * Enable GPIO 181 = LCD Panel PWM
+ 	 */
+ 	r = gpio_request(LCD_PANEL_PWM, "lcd_pwm");
+ 	if (r) {
+ 		printk(KERN_ERR "failed to get lcd_pwm\n");
+ 		goto err_1;
+ 	}
+ 	gpio_direction_output(LCD_PANEL_PWM, 1);
+ 	/*
+ 	 * Enable GPIO 176 = LCD Panel Power enable pin
+ 	 */
+ 	r = gpio_request(LCD_PANEL_PWR, "lcd_panel_pwr");
+ 	if (r) {
+ 		printk(KERN_ERR "failed to get lcd_panel_pwr\n");
+ 		goto err_2;
+ 	}
+ 	gpio_direction_output(LCD_PANEL_PWR, 1);
+ 
+ 	printk(KERN_INFO "Display initialized successfully\n");
+ 	return;
+ 
+ err_2:
+ 	gpio_free(LCD_PANEL_PWM);
+ err_1:
+ 	gpio_free(LCD_PANEL_BKLIGHT_PWR);
+ }
+ 
+ static int am3517_evm_panel_enable_lcd(struct omap_dss_device *dssdev)
+ {
+ 	if (dvi_enabled) {
+ 		printk(KERN_ERR "cannot enable LCD, DVI is enabled\n");
+ 		return -EINVAL;
+ 	}
+ 	gpio_set_value(LCD_PANEL_PWR, 1);
+ 	lcd_enabled = 1;
+ 
+ 	return 0;
+ }
+ 
+ static void am3517_evm_panel_disable_lcd(struct omap_dss_device *dssdev)
+ {
+ 	gpio_set_value(LCD_PANEL_PWR, 0);
+ 	lcd_enabled = 0;
+ }
+ 
+ static struct omap_dss_device am3517_evm_lcd_device = {
+ 	.type			= OMAP_DISPLAY_TYPE_DPI,
+ 	.name			= "lcd",
+ 	.driver_name		= "sharp_lq_panel",
+ 	.phy.dpi.data_lines 	= 16,
+ 	.platform_enable	= am3517_evm_panel_enable_lcd,
+ 	.platform_disable	= am3517_evm_panel_disable_lcd,
+ };
+ 
+ static int am3517_evm_panel_enable_tv(struct omap_dss_device *dssdev)
+ {
+ 	return 0;
+ }
+ 
+ static void am3517_evm_panel_disable_tv(struct omap_dss_device *dssdev)
+ {
+ }
+ 
+ static struct omap_dss_device am3517_evm_tv_device = {
+ 	.type 			= OMAP_DISPLAY_TYPE_VENC,
+ 	.name 			= "tv",
+ 	.driver_name		= "venc",
+ 	.phy.venc.type		= OMAP_DSS_VENC_TYPE_SVIDEO,
+ 	.platform_enable	= am3517_evm_panel_enable_tv,
+ 	.platform_disable	= am3517_evm_panel_disable_tv,
+ };
+ 
+ static int am3517_evm_panel_enable_dvi(struct omap_dss_device *dssdev)
+ {
+ 	if (lcd_enabled) {
+ 		printk(KERN_ERR "cannot enable DVI, LCD is enabled\n");
+ 		return -EINVAL;
+ 	}
+ 	dvi_enabled = 1;
+ 
+ 	return 0;
+ }
+ 
+ static void am3517_evm_panel_disable_dvi(struct omap_dss_device *dssdev)
+ {
+ 	dvi_enabled = 0;
+ }
+ 
+ static struct omap_dss_device am3517_evm_dvi_device = {
+ 	.type			= OMAP_DISPLAY_TYPE_DPI,
+ 	.name			= "dvi",
+ 	.driver_name		= "generic_panel",
+ 	.phy.dpi.data_lines	= 24,
+ 	.platform_enable	= am3517_evm_panel_enable_dvi,
+ 	.platform_disable	= am3517_evm_panel_disable_dvi,
+ };
+ 
+ static struct omap_dss_device *am3517_evm_dss_devices[] = {
+ 	&am3517_evm_lcd_device,
+ 	&am3517_evm_tv_device,
+ 	&am3517_evm_dvi_device,
+ };
+ 
+ static struct omap_dss_board_info am3517_evm_dss_data = {
+ 	.num_devices	= ARRAY_SIZE(am3517_evm_dss_devices),
+ 	.devices	= am3517_evm_dss_devices,
+ 	.default_device	= &am3517_evm_lcd_device,
+ };
+ 
+ struct platform_device am3517_evm_dss_device = {
+ 	.name		= "omapdss",
+ 	.id		= -1,
+ 	.dev		= {
+ 		.platform_data	= &am3517_evm_dss_data,
+ 	},
+ };
+ 
 +static int __init am3517_evm_i2c_init(void)
 +{
 +	omap_register_i2c_bus(1, 400, NULL, 0);
 +	omap_register_i2c_bus(2, 400, NULL, 0);
 +	omap_register_i2c_bus(3, 400, NULL, 0);
 +
 +	return 0;
 +}
 +
  /*
   * Board initialization
   */

Re: linux-next: manual merge of the omap_dss2 tree with the omap tree

[Tomi Valkeinen]

On Wed, 2010-02-03 at 18:12 +0100, ext Tony Lindgren wrote:
> * Grazvydas Ignotas <notasas@gmail.com> [100203 04:27]:
> > hi,
> > 
> > On Wed, Feb 3, 2010 at 6:29 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > Hi Tomi,
> > >
> > > Today's linux-next merge of the omap_dss2 tree got a conflict in
> > > arch/arm/mach-omap2/board-omap3pandora.c between commit
> > > f8b6f704105164eac7c043a48f79c4234e03e4b2 ("omap: Rename hsmmc symbols to
> > > reflect independence from twl4030") from the omap tree and commit
> > > aacb4387a1e6f3b57977375532c6d8e47fcd5652 ("OMAP: pandora: add DSS2
> > > support and related regulators") from the omap_dss2 tree.
> > 
> > I've rebased my patch against linux-omap/for-next (attached). To fix
> > the conflict, Tomi can rebase his queue on linux-omap/for-next, or
> > Tony can simply take this to his queue - this has no "hard"
> > dependencies on other queued DSS2 changes, has only board file changes
> > and builds fine in linux-omap/for-next. I would prefer the second
> > option, as I plan sending more boardfile changes to linux-omap.
> 
> Thanks Stephen and Grazvydas.
> 
> This sounds good to me, I've added this patch into omap for-next.
> 
> Tomi can you please drop the earlier version from your branch?

Sounds good to me. I dropped the patch from my tree.

 Tomi

Re: linux-next: manual merge of the omap_dss2 tree with the omap tree

[Tony Lindgren]

* Grazvydas Ignotas <notasas@gmail.com> [100203 04:27]:
> hi,
> 
> On Wed, Feb 3, 2010 at 6:29 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > Hi Tomi,
> >
> > Today's linux-next merge of the omap_dss2 tree got a conflict in
> > arch/arm/mach-omap2/board-omap3pandora.c between commit
> > f8b6f704105164eac7c043a48f79c4234e03e4b2 ("omap: Rename hsmmc symbols to
> > reflect independence from twl4030") from the omap tree and commit
> > aacb4387a1e6f3b57977375532c6d8e47fcd5652 ("OMAP: pandora: add DSS2
> > support and related regulators") from the omap_dss2 tree.
> 
> I've rebased my patch against linux-omap/for-next (attached). To fix
> the conflict, Tomi can rebase his queue on linux-omap/for-next, or
> Tony can simply take this to his queue - this has no "hard"
> dependencies on other queued DSS2 changes, has only board file changes
> and builds fine in linux-omap/for-next. I would prefer the second
> option, as I plan sending more boardfile changes to linux-omap.

Thanks Stephen and Grazvydas.

This sounds good to me, I've added this patch into omap for-next.

Tomi can you please drop the earlier version from your branch?

Regards,

Tony

Re: linux-next: manual merge of the omap_dss2 tree with the omap tree

[Grazvydas Ignotas]

[-- Attachment #1: Type: text/plain, Size: 3513 bytes --]

hi,

On Wed, Feb 3, 2010 at 6:29 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Tomi,
>
> Today's linux-next merge of the omap_dss2 tree got a conflict in
> arch/arm/mach-omap2/board-omap3pandora.c between commit
> f8b6f704105164eac7c043a48f79c4234e03e4b2 ("omap: Rename hsmmc symbols to
> reflect independence from twl4030") from the omap tree and commit
> aacb4387a1e6f3b57977375532c6d8e47fcd5652 ("OMAP: pandora: add DSS2
> support and related regulators") from the omap_dss2 tree.

I've rebased my patch against linux-omap/for-next (attached). To fix
the conflict, Tomi can rebase his queue on linux-omap/for-next, or
Tony can simply take this to his queue - this has no "hard"
dependencies on other queued DSS2 changes, has only board file changes
and builds fine in linux-omap/for-next. I would prefer the second
option, as I plan sending more boardfile changes to linux-omap.

>
> I fixed it up (see below) and can carry the fix as necessary.
> --
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
>
> diff --cc arch/arm/mach-omap2/board-omap3pandora.c
> index 9967b5d,bd3e577..0000000
> --- a/arch/arm/mach-omap2/board-omap3pandora.c
> +++ b/arch/arm/mach-omap2/board-omap3pandora.c
> @@@ -192,7 -193,62 +193,62 @@@ static struct twl4030_keypad_data pando
>        .rep            = 1,
>  };
>
> + static struct omap_dss_device pandora_lcd_device = {
> +       .name                   = "lcd",
> +       .driver_name            = "tpo_td043mtea1_panel",
> +       .type                   = OMAP_DISPLAY_TYPE_DPI,
> +       .phy.dpi.data_lines     = 24,
> +       .reset_gpio             = 157,
> + };
> +
> + static struct omap_dss_device pandora_tv_device = {
> +       .name                   = "tv",
> +       .driver_name            = "venc",
> +       .type                   = OMAP_DISPLAY_TYPE_VENC,
> +       .phy.venc.type          = OMAP_DSS_VENC_TYPE_SVIDEO,
> + };
> +
> + static struct omap_dss_device *pandora_dss_devices[] = {
> +       &pandora_lcd_device,
> +       &pandora_tv_device,
> + };
> +
> + static struct omap_dss_board_info pandora_dss_data = {
> +       .num_devices    = ARRAY_SIZE(pandora_dss_devices),
> +       .devices        = pandora_dss_devices,
> +       .default_device = &pandora_lcd_device,
> + };
> +
> + static struct platform_device pandora_dss_device = {
> +       .name           = "omapdss",
> +       .id             = -1,
> +       .dev            = {
> +               .platform_data = &pandora_dss_data,
> +       },
> + };
> +
> + static struct regulator_consumer_supply pandora_vcc_lcd_supply = {
> +       .supply         = "vcc",
> +       .dev            = &pandora_lcd_device.dev,
> + };
> +
> + static struct regulator_consumer_supply pandora_vdda_dac_supply = {
> +       .supply         = "vdda_dac",
> +       .dev            = &pandora_dss_device.dev,
> + };
> +
> + static struct regulator_consumer_supply pandora_vdds_supplies[] = {
> +       {
> +               .supply         = "vdds_sdi",
> +               .dev            = &pandora_dss_device.dev,
> +       },
> +       {
> +               .supply         = "vdds_dsi",
> +               .dev            = &pandora_dss_device.dev,
> +       },
> + };
> +
>  -static struct twl4030_hsmmc_info omap3pandora_mmc[] = {
>  +static struct omap2_hsmmc_info omap3pandora_mmc[] = {
>        {
>                .mmc            = 1,
>                .wires          = 4,
>

[-- Attachment #2: 0001-OMAP-pandora-add-DSS2-support-and-related-regulato.patch --]
[-- Type: text/x-patch, Size: 4930 bytes --]

From 6ef850a159b4e57b792d7f84e18c443ef15fe3e5 Mon Sep 17 00:00:00 2001
From: Grazvydas Ignotas <notasas@gmail.com>
Date: Wed, 13 Jan 2010 22:19:07 +0100
Subject: [PATCH] OMAP: pandora: add DSS2 support and related regulators

This patch adds configuration data for DSS2 and sets up
display related regulators.

Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Acked-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
---
 arch/arm/mach-omap2/board-omap3pandora.c |  111 ++++++++++++++++++++++++++++++
 1 files changed, 111 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3pandora.c b/arch/arm/mach-omap2/board-omap3pandora.c
index 9967b5d..7ea3894 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -40,6 +40,7 @@
 #include <mach/hardware.h>
 #include <plat/mcspi.h>
 #include <plat/usb.h>
+#include <plat/display.h>
 
 #include "mux.h"
 #include "sdram-micron-mt46h32m32lf-6.h"
@@ -192,6 +193,61 @@ static struct twl4030_keypad_data pandora_kp_data = {
 	.rep		= 1,
 };
 
+static struct omap_dss_device pandora_lcd_device = {
+	.name			= "lcd",
+	.driver_name		= "tpo_td043mtea1_panel",
+	.type			= OMAP_DISPLAY_TYPE_DPI,
+	.phy.dpi.data_lines	= 24,
+	.reset_gpio		= 157,
+};
+
+static struct omap_dss_device pandora_tv_device = {
+	.name			= "tv",
+	.driver_name		= "venc",
+	.type			= OMAP_DISPLAY_TYPE_VENC,
+	.phy.venc.type		= OMAP_DSS_VENC_TYPE_SVIDEO,
+};
+
+static struct omap_dss_device *pandora_dss_devices[] = {
+	&pandora_lcd_device,
+	&pandora_tv_device,
+};
+
+static struct omap_dss_board_info pandora_dss_data = {
+	.num_devices	= ARRAY_SIZE(pandora_dss_devices),
+	.devices	= pandora_dss_devices,
+	.default_device	= &pandora_lcd_device,
+};
+
+static struct platform_device pandora_dss_device = {
+	.name		= "omapdss",
+	.id		= -1,
+	.dev		= {
+		.platform_data = &pandora_dss_data,
+	},
+};
+
+static struct regulator_consumer_supply pandora_vcc_lcd_supply = {
+	.supply		= "vcc",
+	.dev		= &pandora_lcd_device.dev,
+};
+
+static struct regulator_consumer_supply pandora_vdda_dac_supply = {
+	.supply		= "vdda_dac",
+	.dev		= &pandora_dss_device.dev,
+};
+
+static struct regulator_consumer_supply pandora_vdds_supplies[] = {
+	{
+		.supply		= "vdds_sdi",
+		.dev		= &pandora_dss_device.dev,
+	},
+	{
+		.supply		= "vdds_dsi",
+		.dev		= &pandora_dss_device.dev,
+	},
+};
+
 static struct omap2_hsmmc_info omap3pandora_mmc[] = {
 	{
 		.mmc		= 1,
@@ -277,6 +333,51 @@ static struct regulator_init_data pandora_vmmc2 = {
 	.consumer_supplies	= &pandora_vmmc2_supply,
 };
 
+/* VDAC for DSS driving S-Video */
+static struct regulator_init_data pandora_vdac = {
+	.constraints = {
+		.min_uV			= 1800000,
+		.max_uV			= 1800000,
+		.apply_uV		= true,
+		.valid_modes_mask	= REGULATOR_MODE_NORMAL
+					| REGULATOR_MODE_STANDBY,
+		.valid_ops_mask		= REGULATOR_CHANGE_MODE
+					| REGULATOR_CHANGE_STATUS,
+	},
+	.num_consumer_supplies	= 1,
+	.consumer_supplies	= &pandora_vdda_dac_supply,
+};
+
+/* VPLL2 for digital video outputs */
+static struct regulator_init_data pandora_vpll2 = {
+	.constraints = {
+		.min_uV			= 1800000,
+		.max_uV			= 1800000,
+		.apply_uV		= true,
+		.valid_modes_mask	= REGULATOR_MODE_NORMAL
+					| REGULATOR_MODE_STANDBY,
+		.valid_ops_mask		= REGULATOR_CHANGE_MODE
+					| REGULATOR_CHANGE_STATUS,
+	},
+	.num_consumer_supplies	= ARRAY_SIZE(pandora_vdds_supplies),
+	.consumer_supplies	= pandora_vdds_supplies,
+};
+
+/* VAUX1 for LCD */
+static struct regulator_init_data pandora_vaux1 = {
+	.constraints = {
+		.min_uV			= 3000000,
+		.max_uV			= 3000000,
+		.apply_uV		= true,
+		.valid_modes_mask	= REGULATOR_MODE_NORMAL
+					| REGULATOR_MODE_STANDBY,
+		.valid_ops_mask		= REGULATOR_CHANGE_MODE
+					| REGULATOR_CHANGE_STATUS,
+	},
+	.num_consumer_supplies	= 1,
+	.consumer_supplies	= &pandora_vcc_lcd_supply,
+};
+
 static struct twl4030_usb_data omap3pandora_usb_data = {
 	.usb_mode	= T2_USB_MODE_ULPI,
 };
@@ -298,6 +399,9 @@ static struct twl4030_platform_data omap3pandora_twldata = {
 	.codec		= &omap3pandora_codec_data,
 	.vmmc1		= &pandora_vmmc1,
 	.vmmc2		= &pandora_vmmc2,
+	.vdac		= &pandora_vdac,
+	.vpll2		= &pandora_vpll2,
+	.vaux1		= &pandora_vaux1,
 	.keypad		= &pandora_kp_data,
 };
 
@@ -365,6 +469,12 @@ static struct spi_board_info omap3pandora_spi_board_info[] __initdata = {
 		.controller_data	= &ads7846_mcspi_config,
 		.irq			= OMAP_GPIO_IRQ(OMAP3_PANDORA_TS_GPIO),
 		.platform_data		= &ads7846_config,
+	}, {
+		.modalias		= "tpo_td043mtea1_panel_spi",
+		.bus_num		= 1,
+		.chip_select		= 1,
+		.max_speed_hz		= 375000,
+		.platform_data		= &pandora_lcd_device,
 	}
 };
 
@@ -379,6 +489,7 @@ static void __init omap3pandora_init_irq(void)
 static struct platform_device *omap3pandora_devices[] __initdata = {
 	&pandora_leds_gpio,
 	&pandora_keys_gpio,
+	&pandora_dss_device,
 };
 
 static struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
-- 
1.5.6.3

linux-next: manual merge of the omap_dss2 tree with the omap tree

[Stephen Rothwell]

Hi Tomi,

Today's linux-next merge of the omap_dss2 tree got a conflict in
arch/arm/mach-omap2/board-omap3pandora.c between commit
f8b6f704105164eac7c043a48f79c4234e03e4b2 ("omap: Rename hsmmc symbols to
reflect independence from twl4030") from the omap tree and commit
aacb4387a1e6f3b57977375532c6d8e47fcd5652 ("OMAP: pandora: add DSS2
support and related regulators") from the omap_dss2 tree.

I fixed it up (see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/arm/mach-omap2/board-omap3pandora.c
index 9967b5d,bd3e577..0000000
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@@ -192,7 -193,62 +193,62 @@@ static struct twl4030_keypad_data pando
  	.rep		= 1,
  };
  
+ static struct omap_dss_device pandora_lcd_device = {
+ 	.name			= "lcd",
+ 	.driver_name		= "tpo_td043mtea1_panel",
+ 	.type			= OMAP_DISPLAY_TYPE_DPI,
+ 	.phy.dpi.data_lines	= 24,
+ 	.reset_gpio		= 157,
+ };
+ 
+ static struct omap_dss_device pandora_tv_device = {
+ 	.name			= "tv",
+ 	.driver_name		= "venc",
+ 	.type			= OMAP_DISPLAY_TYPE_VENC,
+ 	.phy.venc.type		= OMAP_DSS_VENC_TYPE_SVIDEO,
+ };
+ 
+ static struct omap_dss_device *pandora_dss_devices[] = {
+ 	&pandora_lcd_device,
+ 	&pandora_tv_device,
+ };
+ 
+ static struct omap_dss_board_info pandora_dss_data = {
+ 	.num_devices	= ARRAY_SIZE(pandora_dss_devices),
+ 	.devices	= pandora_dss_devices,
+ 	.default_device	= &pandora_lcd_device,
+ };
+ 
+ static struct platform_device pandora_dss_device = {
+ 	.name		= "omapdss",
+ 	.id		= -1,
+ 	.dev		= {
+ 		.platform_data = &pandora_dss_data,
+ 	},
+ };
+ 
+ static struct regulator_consumer_supply pandora_vcc_lcd_supply = {
+ 	.supply		= "vcc",
+ 	.dev		= &pandora_lcd_device.dev,
+ };
+ 
+ static struct regulator_consumer_supply pandora_vdda_dac_supply = {
+ 	.supply		= "vdda_dac",
+ 	.dev		= &pandora_dss_device.dev,
+ };
+ 
+ static struct regulator_consumer_supply pandora_vdds_supplies[] = {
+ 	{
+ 		.supply		= "vdds_sdi",
+ 		.dev		= &pandora_dss_device.dev,
+ 	},
+ 	{
+ 		.supply		= "vdds_dsi",
+ 		.dev		= &pandora_dss_device.dev,
+ 	},
+ };
+ 
 -static struct twl4030_hsmmc_info omap3pandora_mmc[] = {
 +static struct omap2_hsmmc_info omap3pandora_mmc[] = {
  	{
  		.mmc		= 1,
  		.wires		= 4,

linux-next: manual merge of the omap_dss2 tree with the omap tree

[Stephen Rothwell]

Hi Tomi,

Today's linux-next merge of the omap_dss2 tree got a conflict in
arch/arm/mach-omap2/io.c between commit
c88aa7d24b59035da46d02b9534d8036a6af0b44 ("omap: mux: Remove old mux code
for 34xx") from the omap tree and commit
24cb56c4f0c1f6485b601ad7aa665f829edae290 ("OMAP: Add VRAM manager") from
the omap_dss2 tree.

Just overlapping additions.  I fixed it up (see below) and can carry the
fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/arm/mach-omap2/io.c
index 7d344d0,6a4d8e4..0000000
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@@ -33,7 -33,7 +33,8 @@@
  #include <plat/sdrc.h>
  #include <plat/gpmc.h>
  #include <plat/serial.h>
 +#include <plat/mux.h>
+ #include <plat/vram.h>
  
  #ifndef CONFIG_ARCH_OMAP4	/* FIXME: Remove this once clkdev is ready */
  #include "clock.h"

Re: linux-next: manual merge of the omap_dss2 tree with the omap tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 561 bytes --]

Hi Tomi,

On Tue, 17 Nov 2009 12:00:31 +0200 Tomi Valkeinen <tomi.valkeinen@nokia.com> wrote:
>
> On Mon, 2009-11-16 at 19:34 +0100, ext Tony Lindgren wrote:
> > Tomi, please update your patch by leaving out the now unnecessary
> > TWL4030 and regulator sections. See also the updated version of
> > your patch attached.
> 
> Thanks, updated. Now I'm able to merge linux-omap/for-next and
> dss/for-next without conflicts.

Great, thanks.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: linux-next: manual merge of the omap_dss2 tree with the omap tree

[Tomi Valkeinen]

On Mon, 2009-11-16 at 19:34 +0100, ext Tony Lindgren wrote:
> Tomi, please update your patch by leaving out the now unnecessary
> TWL4030 and regulator sections. See also the updated version of
> your patch attached.

Thanks, updated. Now I'm able to merge linux-omap/for-next and
dss/for-next without conflicts.

 Tomi

Re: linux-next: manual merge of the omap_dss2 tree with the omap tree

[Tony Lindgren]

[-- Attachment #1: Type: text/plain, Size: 1330 bytes --]

* Tomi Valkeinen <tomi.valkeinen@nokia.com> [091116 02:06]:
> On Mon, 2009-11-16 at 06:04 +0100, ext Stephen Rothwell wrote:
> > Hi Tomi,
> > 
> > Today's linux-next merge of the omap_dss2 tree got a conflict in
> > arch/arm/configs/omap_3430sdp_defconfig between the omap tree and the
> > omap_dss2 tree.
> > 
> > I just used the version from the omap tree as I can't figure out anything
> > better, sorry.
> 
> Tony, 
> 
> These patches in omap tree seem to cause the conflicts. Are they stable,
> ie. can I cherry pick them to my for-next tree, and put my patches on
> top of them?

Well all the board-*.c patches are still getting shuffled around
this week a bit.. But we can resolve it with the following two changes.
 
> b30dcf5f37023d591caee80c233bf33706bc5a21
> omap3: 3430sdp: Enable Linux Regulator framework

This we should keep as it is, but the commit ID may still change.
 
> fc89f86e06c11b8828ce1d6c669f724877546c03
> ARM: OMAP3: Fix 3430SDP defconfig

I've cut out the CONFIG_FB related sections of this patch in
omap for-next branch, see below.

Tomi, please update your patch by leaving out the now unnecessary
TWL4030 and regulator sections. See also the updated version of
your patch attached.

And please also use the static commit id I gave earlier, the other
patches can still change a bit.

Regards,

Tony

[-- Attachment #2: sdp3430-defconfig-nofb.patch --]
[-- Type: text/x-diff, Size: 1274 bytes --]

I've left out the CONFIG_FB related parts of
"ARM: OMAP3: Fix 3430SDP defconfig" and renamed
it to "ARM: OMAP3: Update 3430SDP defconfig".

--- a/arch/arm/configs/omap_3430sdp_defconfig
+++ b/arch/arm/configs/omap_3430sdp_defconfig
@@ -940,11 +940,9 @@ CONFIG_TWL4030_CORE=y
 # Graphics support
 #
 # CONFIG_VGASTATE is not set
-# CONFIG_VIDEO_OUTPUT_CONTROL is not set
 CONFIG_FB=y
 # CONFIG_FIRMWARE_EDID is not set
 # CONFIG_FB_DDC is not set
-# CONFIG_FB_BOOT_VESA_SUPPORT is not set
 CONFIG_FB_CFB_FILLRECT=y
 CONFIG_FB_CFB_COPYAREA=y
 CONFIG_FB_CFB_IMAGEBLIT=y
@@ -965,13 +963,8 @@ CONFIG_FB_CFB_IMAGEBLIT=y
 #
 # CONFIG_FB_S1D13XXX is not set
 # CONFIG_FB_VIRTUAL is not set
-# CONFIG_FB_METRONOME is not set
-# CONFIG_FB_MB862XX is not set
-# CONFIG_FB_BROADSHEET is not set
 CONFIG_FB_OMAP=y
-# CONFIG_FB_OMAP_LCD_VGA is not set
 # CONFIG_FB_OMAP_LCDC_EXTERNAL is not set
-# CONFIG_FB_OMAP_LCD_MIPID is not set
 # CONFIG_FB_OMAP_BOOTLOADER_INIT is not set
 CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE=2
 # CONFIG_BACKLIGHT_LCD_SUPPORT is not set
@@ -979,7 +972,11 @@ CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE=2
 #
 # Display device support
 #
-# CONFIG_DISPLAY_SUPPORT is not set
+CONFIG_DISPLAY_SUPPORT=y
+
+#
+# Display hardware drivers
+#
 
 #
 # Console display driver support

[-- Attachment #3: tomi-3430sdp-v2.patch --]
[-- Type: text/x-diff, Size: 7277 bytes --]

>From 5fdd839b3fcf292c52fd68b76a6b254436c86c3e Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen <tomi.valkeinen@nokia.com>
Date: Wed, 5 Aug 2009 16:07:26 +0300
Subject: [PATCH] OMAP: SDP: Enable DSS2 for OMAP3 SDP board

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
Acked-by: Tony Lindgren <tony@atomide.com>

diff --git a/arch/arm/configs/omap_3430sdp_defconfig b/arch/arm/configs/omap_3430sdp_defconfig
index 8a4a7e2..730ada3 100644
--- a/arch/arm/configs/omap_3430sdp_defconfig
+++ b/arch/arm/configs/omap_3430sdp_defconfig
@@ -1336,10 +1338,33 @@ CONFIG_FB_CFB_IMAGEBLIT=y
 #
 # CONFIG_FB_S1D13XXX is not set
 # CONFIG_FB_VIRTUAL is not set
-CONFIG_FB_OMAP=y
-# CONFIG_FB_OMAP_LCDC_EXTERNAL is not set
+# CONFIG_FB_METRONOME is not set
+# CONFIG_FB_MB862XX is not set
+# CONFIG_FB_BROADSHEET is not set
+# CONFIG_FB_OMAP_LCD_VGA is not set
 # CONFIG_FB_OMAP_BOOTLOADER_INIT is not set
-CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE=2
+CONFIG_OMAP2_VRAM=y
+CONFIG_OMAP2_VRFB=y
+CONFIG_OMAP2_DSS=y
+CONFIG_OMAP2_VRAM_SIZE=4
+CONFIG_OMAP2_DSS_DEBUG_SUPPORT=y
+# CONFIG_OMAP2_DSS_RFBI is not set
+CONFIG_OMAP2_DSS_VENC=y
+# CONFIG_OMAP2_DSS_SDI is not set
+# CONFIG_OMAP2_DSS_DSI is not set
+# CONFIG_OMAP2_DSS_FAKE_VSYNC is not set
+CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK=0
+CONFIG_FB_OMAP2=y
+CONFIG_FB_OMAP2_DEBUG_SUPPORT=y
+# CONFIG_FB_OMAP2_FORCE_AUTO_UPDATE is not set
+CONFIG_FB_OMAP2_NUM_FBS=3
+
+#
+# OMAP2/3 Display Device Drivers
+#
+CONFIG_PANEL_GENERIC=y
+# CONFIG_PANEL_SAMSUNG_LTE430WQ_F0C is not set
+CONFIG_PANEL_SHARP_LS037V7DW01=y
 # CONFIG_BACKLIGHT_LCD_SUPPORT is not set
 
 #
diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board-3430sdp.c
index a2abac9..b697d50 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -37,6 +37,7 @@
 #include <plat/common.h>
 #include <plat/dma.h>
 #include <plat/gpmc.h>
+#include <plat/display.h>
 
 #include <plat/control.h>
 #include <plat/gpmc-smc91x.h>
@@ -152,31 +153,152 @@ static struct spi_board_info sdp3430_spi_board_info[] __initdata = {
 	},
 };
 
-static struct platform_device sdp3430_lcd_device = {
-	.name		= "sdp2430_lcd",
-	.id		= -1,
+
+#define SDP3430_LCD_PANEL_BACKLIGHT_GPIO	8
+#define SDP3430_LCD_PANEL_ENABLE_GPIO		5
+
+static unsigned backlight_gpio;
+static unsigned enable_gpio;
+static int lcd_enabled;
+static int dvi_enabled;
+
+static void __init sdp3430_display_init(void)
+{
+	int r;
+
+	enable_gpio    = SDP3430_LCD_PANEL_ENABLE_GPIO;
+	backlight_gpio = SDP3430_LCD_PANEL_BACKLIGHT_GPIO;
+
+	r = gpio_request(enable_gpio, "LCD reset");
+	if (r) {
+		printk(KERN_ERR "failed to get LCD reset GPIO\n");
+		goto err0;
+	}
+
+	r = gpio_request(backlight_gpio, "LCD Backlight");
+	if (r) {
+		printk(KERN_ERR "failed to get LCD backlight GPIO\n");
+		goto err1;
+	}
+
+	gpio_direction_output(enable_gpio, 0);
+	gpio_direction_output(backlight_gpio, 0);
+
+	return;
+err1:
+	gpio_free(enable_gpio);
+err0:
+	return;
+}
+
+static int sdp3430_panel_enable_lcd(struct omap_dss_device *dssdev)
+{
+	if (dvi_enabled) {
+		printk(KERN_ERR "cannot enable LCD, DVI is enabled\n");
+		return -EINVAL;
+	}
+
+	gpio_direction_output(enable_gpio, 1);
+	gpio_direction_output(backlight_gpio, 1);
+
+	lcd_enabled = 1;
+
+	return 0;
+}
+
+static void sdp3430_panel_disable_lcd(struct omap_dss_device *dssdev)
+{
+	lcd_enabled = 0;
+
+	gpio_direction_output(enable_gpio, 0);
+	gpio_direction_output(backlight_gpio, 0);
+}
+
+static int sdp3430_panel_enable_dvi(struct omap_dss_device *dssdev)
+{
+	if (lcd_enabled) {
+		printk(KERN_ERR "cannot enable DVI, LCD is enabled\n");
+		return -EINVAL;
+	}
+
+	dvi_enabled = 1;
+
+	return 0;
+}
+
+static void sdp3430_panel_disable_dvi(struct omap_dss_device *dssdev)
+{
+	dvi_enabled = 0;
+}
+
+static int sdp3430_panel_enable_tv(struct omap_dss_device *dssdev)
+{
+	return 0;
+}
+
+static void sdp3430_panel_disable_tv(struct omap_dss_device *dssdev)
+{
+}
+
+
+static struct omap_dss_device sdp3430_lcd_device = {
+	.name			= "lcd",
+	.driver_name		= "sharp_ls_panel",
+	.type			= OMAP_DISPLAY_TYPE_DPI,
+	.phy.dpi.data_lines	= 16,
+	.platform_enable	= sdp3430_panel_enable_lcd,
+	.platform_disable	= sdp3430_panel_disable_lcd,
 };
 
-static struct regulator_consumer_supply sdp3430_vdac_supply = {
-	.supply		= "vdac",
-	.dev		= &sdp3430_lcd_device.dev,
+static struct omap_dss_device sdp3430_dvi_device = {
+	.name			= "dvi",
+	.driver_name		= "generic_panel",
+	.type			= OMAP_DISPLAY_TYPE_DPI,
+	.phy.dpi.data_lines	= 24,
+	.platform_enable	= sdp3430_panel_enable_dvi,
+	.platform_disable	= sdp3430_panel_disable_dvi,
 };
 
-static struct regulator_consumer_supply sdp3430_vdvi_supply = {
-	.supply		= "vdvi",
-	.dev		= &sdp3430_lcd_device.dev,
+static struct omap_dss_device sdp3430_tv_device = {
+	.name			= "tv",
+	.driver_name		= "venc",
+	.type			= OMAP_DISPLAY_TYPE_VENC,
+	.phy.venc.type		= OMAP_DSS_VENC_TYPE_SVIDEO,
+	.platform_enable	= sdp3430_panel_enable_tv,
+	.platform_disable	= sdp3430_panel_disable_tv,
 };
 
-static struct platform_device *sdp3430_devices[] __initdata = {
+
+static struct omap_dss_device *sdp3430_dss_devices[] = {
 	&sdp3430_lcd_device,
+	&sdp3430_dvi_device,
+	&sdp3430_tv_device,
 };
 
-static struct omap_lcd_config sdp3430_lcd_config __initdata = {
-	.ctrl_name	= "internal",
+static struct omap_dss_board_info sdp3430_dss_data = {
+	.num_devices	= ARRAY_SIZE(sdp3430_dss_devices),
+	.devices	= sdp3430_dss_devices,
+	.default_device	= &sdp3430_lcd_device,
+};
+
+static struct platform_device sdp3430_dss_device = {
+	.name		= "omapdss",
+	.id		= -1,
+	.dev		= {
+		.platform_data = &sdp3430_dss_data,
+	},
+};
+
+static struct regulator_consumer_supply sdp3430_vdda_dac_supply = {
+	.supply		= "vdda_dac",
+	.dev		= &sdp3430_dss_device.dev,
+};
+
+static struct platform_device *sdp3430_devices[] __initdata = {
+	&sdp3430_dss_device,
 };
 
 static struct omap_board_config_kernel sdp3430_config[] __initdata = {
-	{ OMAP_TAG_LCD,		&sdp3430_lcd_config },
 };
 
 static void __init omap_3430sdp_init_irq(void)
@@ -392,22 +514,34 @@ static struct regulator_init_data sdp3430_vdac = {
 					| REGULATOR_CHANGE_STATUS,
 	},
 	.num_consumer_supplies	= 1,
-	.consumer_supplies	= &sdp3430_vdac_supply,
+	.consumer_supplies	= &sdp3430_vdda_dac_supply,
 };
 
 /* VPLL2 for digital video outputs */
+static struct regulator_consumer_supply sdp3430_vpll2_supplies[] = {
+	{
+		.supply		= "vdvi",
+		.dev		= &sdp3430_lcd_device.dev,
+	},
+	{
+		.supply		= "vdds_dsi",
+		.dev		= &sdp3430_dss_device.dev,
+	}
+};
+
 static struct regulator_init_data sdp3430_vpll2 = {
 	.constraints = {
 		.name			= "VDVI",
 		.min_uV			= 1800000,
 		.max_uV			= 1800000,
+		.apply_uV		= true,
 		.valid_modes_mask	= REGULATOR_MODE_NORMAL
 					| REGULATOR_MODE_STANDBY,
 		.valid_ops_mask		= REGULATOR_CHANGE_MODE
 					| REGULATOR_CHANGE_STATUS,
 	},
-	.num_consumer_supplies	= 1,
-	.consumer_supplies	= &sdp3430_vdvi_supply,
+	.num_consumer_supplies	= ARRAY_SIZE(sdp3430_vpll2_supplies),
+	.consumer_supplies	= sdp3430_vpll2_supplies,
 };
 
 static struct twl4030_platform_data sdp3430_twldata = {
@@ -499,6 +633,7 @@ static void __init omap_3430sdp_init(void)
 	omap_serial_init();
 	usb_musb_init();
 	board_smc91x_init();
+	sdp3430_display_init();
 	enable_board_wakeup_source();
 }
 

Re: linux-next: manual merge of the omap_dss2 tree with the omap tree

[Tomi Valkeinen]

On Mon, 2009-11-16 at 06:04 +0100, ext Stephen Rothwell wrote:
> Hi Tomi,
> 
> Today's linux-next merge of the omap_dss2 tree got a conflict in
> arch/arm/configs/omap_3430sdp_defconfig between the omap tree and the
> omap_dss2 tree.
> 
> I just used the version from the omap tree as I can't figure out anything
> better, sorry.

Tony, 

These patches in omap tree seem to cause the conflicts. Are they stable,
ie. can I cherry pick them to my for-next tree, and put my patches on
top of them?

b30dcf5f37023d591caee80c233bf33706bc5a21
omap3: 3430sdp: Enable Linux Regulator framework

fc89f86e06c11b8828ce1d6c669f724877546c03
ARM: OMAP3: Fix 3430SDP defconfig

 Tomi

linux-next: manual merge of the omap_dss2 tree with the omap tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 366 bytes --]

Hi Tomi,

Today's linux-next merge of the omap_dss2 tree got a conflict in
arch/arm/configs/omap_3430sdp_defconfig between the omap tree and the
omap_dss2 tree.

I just used the version from the omap tree as I can't figure out anything
better, sorry.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]