linux-next: manual merge of the arm-soc tree with the omap_dss2 tree

linux-next: manual merge of the arm-soc tree with the omap_dss2 tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-omap1/board-palmtt.c between commit ddba6c7f7ec6 ("OMAP1:
pass LCD config with omapfb_set_lcd_config()") from the omap_dss2 tree
and commit 2e3ee9f45b3c ("ARM: OMAP1: Move most of plat/io.h into local
iomap.h") from the arm-soc 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-omap1/board-palmtt.c
index b63350b,acd1f36..0000000
--- a/arch/arm/mach-omap1/board-palmtt.c
+++ b/arch/arm/mach-omap1/board-palmtt.c
@@@ -24,9 -24,9 +24,10 @@@
  #include <linux/mtd/partitions.h>
  #include <linux/mtd/physmap.h>
  #include <linux/leds.h>
 +#include <linux/omapfb.h>
+ #include <linux/spi/spi.h>
+ #include <linux/spi/ads7846.h>
  
- #include <mach/hardware.h>
  #include <asm/mach-types.h>
  #include <asm/mach/arch.h>
  #include <asm/mach/map.h>

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

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

[Arnd Bergmann]

On Thursday 08 March 2012, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the arm-soc tree got a conflict in
> arch/arm/mach-omap1/board-palmtt.c between commit ddba6c7f7ec6 ("OMAP1:
> pass LCD config with omapfb_set_lcd_config()") from the omap_dss2 tree
> and commit 2e3ee9f45b3c ("ARM: OMAP1: Move most of plat/io.h into local
> iomap.h") from the arm-soc tree.
> 
> I fixed it up (see below) and can carry the fix as necessary.

Hi Stephen,

Thanks for fixing up all the conflicts between arm-soc and omap_dss2.
I think we should make sure they are resolved in one of the trees before
the merge window.

Tomi, what are your plans for the omap_dss2 branch to get merged?
Do you think you should send it to Linus first and we merge it into
arm-soc to resolve the conflicts?
Or do you want to merge it through the arm-soc tree?
Or should we go first and you fix up the conflicts by pulling in the
necessary topic branches from arm-soc into your tree?

	Arnd

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

[Tomi Valkeinen]

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

Hi,

On Thu, 2012-03-08 at 16:16 +0000, Arnd Bergmann wrote:
> On Thursday 08 March 2012, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Today's linux-next merge of the arm-soc tree got a conflict in
> > arch/arm/mach-omap1/board-palmtt.c between commit ddba6c7f7ec6 ("OMAP1:
> > pass LCD config with omapfb_set_lcd_config()") from the omap_dss2 tree
> > and commit 2e3ee9f45b3c ("ARM: OMAP1: Move most of plat/io.h into local
> > iomap.h") from the arm-soc tree.
> > 
> > I fixed it up (see below) and can carry the fix as necessary.
> 
> Hi Stephen,
> 
> Thanks for fixing up all the conflicts between arm-soc and omap_dss2.
> I think we should make sure they are resolved in one of the trees before
> the merge window.

Do we need to? The conflicts seemed to be trivial ones, like arm-soc
adds/removes something that just happens to be next to something else
that I add/remove.

My understanding is that it's better to leave those conflicts than to do
"trickery" to avoid them.

> Tomi, what are your plans for the omap_dss2 branch to get merged?

Normally my tree goes via fbdev-tree (Florian's tree) to mainline.

> Do you think you should send it to Linus first and we merge it into
> arm-soc to resolve the conflicts?
> Or do you want to merge it through the arm-soc tree?
> Or should we go first and you fix up the conflicts by pulling in the
> necessary topic branches from arm-soc into your tree?

If we want to resolve the conflicts, perhaps it's simplest if the dss
tree is merged to arm-soc.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Arnd Bergmann]

On Friday 09 March 2012, Tomi Valkeinen wrote:
> On Thu, 2012-03-08 at 16:16 +0000, Arnd Bergmann wrote:
> > On Thursday 08 March 2012, Stephen Rothwell wrote:
> > > Hi all,
> > > 
> > > Today's linux-next merge of the arm-soc tree got a conflict in
> > > arch/arm/mach-omap1/board-palmtt.c between commit ddba6c7f7ec6 ("OMAP1:
> > > pass LCD config with omapfb_set_lcd_config()") from the omap_dss2 tree
> > > and commit 2e3ee9f45b3c ("ARM: OMAP1: Move most of plat/io.h into local
> > > iomap.h") from the arm-soc tree.
> > > 
> > > I fixed it up (see below) and can carry the fix as necessary.
> > 
> > Hi Stephen,
> > 
> > Thanks for fixing up all the conflicts between arm-soc and omap_dss2.
> > I think we should make sure they are resolved in one of the trees before
> > the merge window.
> 
> Do we need to? The conflicts seemed to be trivial ones, like arm-soc
> adds/removes something that just happens to be next to something else
> that I add/remove.
> 
> My understanding is that it's better to leave those conflicts than to do
> "trickery" to avoid them.

Each of the conflicts is simple enough, but I feel it's worth resolving
them in this case because there are a number of them. Looking at them
again now, it's probably ok either way -- resolving them now or letting
Linus take care of them.

> > Tomi, what are your plans for the omap_dss2 branch to get merged?
> 
> Normally my tree goes via fbdev-tree (Florian's tree) to mainline.

ok.

> > Do you think you should send it to Linus first and we merge it into
> > arm-soc to resolve the conflicts?
> > Or do you want to merge it through the arm-soc tree?
> > Or should we go first and you fix up the conflicts by pulling in the
> > necessary topic branches from arm-soc into your tree?
> 
> If we want to resolve the conflicts, perhaps it's simplest if the dss
> tree is merged to arm-soc.

Ok. Maybe we'll just merge them in case Florian is upstream faster and
not merge them otherwise.

	Arnd

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

[Tomi Valkeinen]

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

On Fri, 2012-03-09 at 11:50 +0000, Arnd Bergmann wrote:
> On Friday 09 March 2012, Tomi Valkeinen wrote:
> > On Thu, 2012-03-08 at 16:16 +0000, Arnd Bergmann wrote:
> > > On Thursday 08 March 2012, Stephen Rothwell wrote:
> > > > Hi all,
> > > > 
> > > > Today's linux-next merge of the arm-soc tree got a conflict in
> > > > arch/arm/mach-omap1/board-palmtt.c between commit ddba6c7f7ec6 ("OMAP1:
> > > > pass LCD config with omapfb_set_lcd_config()") from the omap_dss2 tree
> > > > and commit 2e3ee9f45b3c ("ARM: OMAP1: Move most of plat/io.h into local
> > > > iomap.h") from the arm-soc tree.
> > > > 
> > > > I fixed it up (see below) and can carry the fix as necessary.
> > > 
> > > Hi Stephen,
> > > 
> > > Thanks for fixing up all the conflicts between arm-soc and omap_dss2.
> > > I think we should make sure they are resolved in one of the trees before
> > > the merge window.
> > 
> > Do we need to? The conflicts seemed to be trivial ones, like arm-soc
> > adds/removes something that just happens to be next to something else
> > that I add/remove.
> > 
> > My understanding is that it's better to leave those conflicts than to do
> > "trickery" to avoid them.
> 
> Each of the conflicts is simple enough, but I feel it's worth resolving
> them in this case because there are a number of them. Looking at them
> again now, it's probably ok either way -- resolving them now or letting
> Linus take care of them.

Florian, do you have an opinion about this?

Merging omapdss tree through arm-soc would make sense for avoiding
conflicts, because almost every merge window there are some conflicts as
I often need to edit arch/arm files also. But I'm not sure if we have
ever had a conflict in drivers/video.

But still, it's a video driver, and fbdev tree sounds more suited for a
video driver.

So I don't know =). Basically it's ok for me either way also. But it
would be nice to have a standard way of doing this, instead of, for
example, merging omapdss sometimes through fbdev, sometimes through
arm-soc, depending on the conflicts...

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Arnd Bergmann]

On Friday 09 March 2012, Tomi Valkeinen wrote:
>   On Fri, 2012-03-09 at 11:50 +0000, Arnd Bergmann wrote:
> > On Friday 09 March 2012, Tomi Valkeinen wrote:
> > > On Thu, 2012-03-08 at 16:16 +0000, Arnd Bergmann wrote:
> > > > On Thursday 08 March 2012, Stephen Rothwell wrote:
> > > > > Hi all,
> > > > > 
> > > > > Today's linux-next merge of the arm-soc tree got a conflict in
> > > > > arch/arm/mach-omap1/board-palmtt.c between commit ddba6c7f7ec6 ("OMAP1:
> > > > > pass LCD config with omapfb_set_lcd_config()") from the omap_dss2 tree
> > > > > and commit 2e3ee9f45b3c ("ARM: OMAP1: Move most of plat/io.h into local
> > > > > iomap.h") from the arm-soc tree.
> > > > > 
> > > > > I fixed it up (see below) and can carry the fix as necessary.
> > > > 
> > > > Hi Stephen,
> > > > 
> > > > Thanks for fixing up all the conflicts between arm-soc and omap_dss2.
> > > > I think we should make sure they are resolved in one of the trees before
> > > > the merge window.
> > > 
> > > Do we need to? The conflicts seemed to be trivial ones, like arm-soc
> > > adds/removes something that just happens to be next to something else
> > > that I add/remove.
> > > 
> > > My understanding is that it's better to leave those conflicts than to do
> > > "trickery" to avoid them.
> > 
> > Each of the conflicts is simple enough, but I feel it's worth resolving
> > them in this case because there are a number of them. Looking at them
> > again now, it's probably ok either way -- resolving them now or letting
> > Linus take care of them.
> 
> Florian, do you have an opinion about this?
> 
> Merging omapdss tree through arm-soc would make sense for avoiding
> conflicts, because almost every merge window there are some conflicts as
> I often need to edit arch/arm files also. But I'm not sure if we have
> ever had a conflict in drivers/video.
> 
> But still, it's a video driver, and fbdev tree sounds more suited for a
> video driver.
> 
> So I don't know =). Basically it's ok for me either way also. But it
> would be nice to have a standard way of doing this, instead of, for
> example, merging omapdss sometimes through fbdev, sometimes through
> arm-soc, depending on the conflicts...

Actually, I did not suggest omapdss through arm-soc, the idea was that
that the same branch gets merged into both the fbdev and the arm-soc
trees and let the fbdev tree go to Linus first.

	Arnd

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

[Tomi Valkeinen]

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

On Fri, 2012-03-09 at 12:26 +0000, Arnd Bergmann wrote:
> On Friday 09 March 2012, Tomi Valkeinen wrote:

> > Merging omapdss tree through arm-soc would make sense for avoiding
> > conflicts, because almost every merge window there are some conflicts as
> > I often need to edit arch/arm files also. But I'm not sure if we have
> > ever had a conflict in drivers/video.
> > 
> > But still, it's a video driver, and fbdev tree sounds more suited for a
> > video driver.
> > 
> > So I don't know =). Basically it's ok for me either way also. But it
> > would be nice to have a standard way of doing this, instead of, for
> > example, merging omapdss sometimes through fbdev, sometimes through
> > arm-soc, depending on the conflicts...
> 
> Actually, I did not suggest omapdss through arm-soc, the idea was that
> that the same branch gets merged into both the fbdev and the arm-soc
> trees and let the fbdev tree go to Linus first.

Ah, right, now I see. This sounds ok to me. I'll cc you when I send the
pull request to Florian (presuming the arrangement is fine for him).

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Arnd Bergmann]

On Tuesday 09 April 2013, Stephen Rothwell wrote:
> 
> - #if defined(CONFIG_SMC91X) || defined(CONFIG_SMC91x_MODULE)
>  -static void __init sdp2430_display_init(void)
>  -{
>  -      int r;
>  -
>  -      static struct gpio gpios[] __initdata = {
>  -              { SDP2430_LCD_PANEL_ENABLE_GPIO, GPIOF_OUT_INIT_LOW,
>  -                      "LCD reset" },
>  -              { SDP2430_LCD_PANEL_BACKLIGHT_GPIO, GPIOF_OUT_INIT_LOW,
>  -                      "LCD Backlight" },
>  -      };
>  -
>  -      r = gpio_request_array(gpios, ARRAY_SIZE(gpios));
>  -      if (r) {
>  -              pr_err("Cannot request LCD GPIOs, error %d\n", r);
>  -              return;
>  -      }
>  -
>  -      omap_display_init(&sdp2430_dss_data);
>  -}
>  -
> + #if IS_ENABLED(CONFIG_SMC91X)

Looks good, thanks!

	Arnd

linux-next: manual merge of the arm-soc tree with the omap_dss2 tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-omap2/board-2430sdp.c between commit 3b4ece75b9e9 ("arm:
omap: board-2430: use generic dpi panel's gpio handling") from the
omap_dss2 tree and commit 5b6513d27775 ("ARM: OMAP: fix typo
"CONFIG_SMC91x_MODULE"") from the arm-soc tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

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

diff --cc arch/arm/mach-omap2/board-2430sdp.c
index e551aae,cb0596b..0000000
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@@ -135,7 -146,27 +135,7 @@@ static struct omap_dss_board_info sdp24
  	.default_device	= &sdp2430_lcd_device,
  };
  
- #if defined(CONFIG_SMC91X) || defined(CONFIG_SMC91x_MODULE)
 -static void __init sdp2430_display_init(void)
 -{
 -	int r;
 -
 -	static struct gpio gpios[] __initdata = {
 -		{ SDP2430_LCD_PANEL_ENABLE_GPIO, GPIOF_OUT_INIT_LOW,
 -			"LCD reset" },
 -		{ SDP2430_LCD_PANEL_BACKLIGHT_GPIO, GPIOF_OUT_INIT_LOW,
 -			"LCD Backlight" },
 -	};
 -
 -	r = gpio_request_array(gpios, ARRAY_SIZE(gpios));
 -	if (r) {
 -		pr_err("Cannot request LCD GPIOs, error %d\n", r);
 -		return;
 -	}
 -
 -	omap_display_init(&sdp2430_dss_data);
 -}
 -
+ #if IS_ENABLED(CONFIG_SMC91X)
  
  static struct omap_smc91x_platform_data board_smc91x_data = {
  	.cs		= 5,

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

linux-next: manual merge of the arm-soc tree with the omap_dss2 tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
drivers/media/platform/omap/omap_vout.c between commit 950e2fb420d5
("[media] omap_vout: use omapdss's version instead of cpu_is_*") from the
omap_dss2 tree and commit 45c3eb7d3a07 ("ARM: OMAP: Move
plat-omap/dma-omap.h to include/linux/omap-dma.h") from the arm-soc tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

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

diff --cc drivers/media/platform/omap/omap_vout.c
index 718e5f6,9935040..0000000
--- a/drivers/media/platform/omap/omap_vout.c
+++ b/drivers/media/platform/omap/omap_vout.c
@@@ -44,6 -44,8 +44,7 @@@
  #include <media/v4l2-device.h>
  #include <media/v4l2-ioctl.h>
  
 -#include <plat/cpu.h>
+ #include <linux/omap-dma.h>
  #include <video/omapvrfb.h>
  #include <video/omapdss.h>
  

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

linux-next: manual merge of the arm-soc tree with the omap_dss2 tree

[Stephen Rothwell]

[-- Attachment #1.1: Type: text/plain, Size: 2956 bytes --]

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-davinci/devices-da8xx.c between commit 3b43ad201dea
("da8xx-fb: cleanup LCDC configurations") from the omap_dss2 tree and
commit 8e0d72d2c7a6 ("ARM: davinci: da8xx: add DA850 PRUSS support") from
the arm-soc tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

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

diff --cc arch/arm/mach-davinci/devices-da8xx.c
index fcb30d3,46c9a0c..0000000
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@@ -518,9 -520,98 +520,78 @@@ void __init da8xx_register_mcasp(int id
  	}
  }
  
+ static struct resource da8xx_pruss_resources[] = {
+ 	{
+ 		.start	= DA8XX_PRUSS_MEM_BASE,
+ 		.end	= DA8XX_PRUSS_MEM_BASE + 0xFFFF,
+ 		.flags	= IORESOURCE_MEM,
+ 	},
+ 	{
+ 		.start	= IRQ_DA8XX_EVTOUT0,
+ 		.end	= IRQ_DA8XX_EVTOUT0,
+ 		.flags	= IORESOURCE_IRQ,
+ 	},
+ 	{
+ 		.start	= IRQ_DA8XX_EVTOUT1,
+ 		.end	= IRQ_DA8XX_EVTOUT1,
+ 		.flags	= IORESOURCE_IRQ,
+ 	},
+ 	{
+ 		.start	= IRQ_DA8XX_EVTOUT2,
+ 		.end	= IRQ_DA8XX_EVTOUT2,
+ 		.flags	= IORESOURCE_IRQ,
+ 	},
+ 	{
+ 		.start	= IRQ_DA8XX_EVTOUT3,
+ 		.end	= IRQ_DA8XX_EVTOUT3,
+ 		.flags	= IORESOURCE_IRQ,
+ 	},
+ 	{
+ 		.start	= IRQ_DA8XX_EVTOUT4,
+ 		.end	= IRQ_DA8XX_EVTOUT4,
+ 		.flags	= IORESOURCE_IRQ,
+ 	},
+ 	{
+ 		.start	= IRQ_DA8XX_EVTOUT5,
+ 		.end	= IRQ_DA8XX_EVTOUT5,
+ 		.flags	= IORESOURCE_IRQ,
+ 	},
+ 	{
+ 		.start	= IRQ_DA8XX_EVTOUT6,
+ 		.end	= IRQ_DA8XX_EVTOUT6,
+ 		.flags	= IORESOURCE_IRQ,
+ 	},
+ 	{
+ 		.start	= IRQ_DA8XX_EVTOUT7,
+ 		.end	= IRQ_DA8XX_EVTOUT7,
+ 		.flags	= IORESOURCE_IRQ,
+ 	},
+ };
+ 
+ static struct uio_pruss_pdata da8xx_uio_pruss_pdata = {
+ 	.pintc_base	= 0x4000,
+ };
+ 
+ static struct platform_device da8xx_uio_pruss_dev = {
+ 	.name		= "pruss_uio",
+ 	.id		= -1,
+ 	.num_resources	= ARRAY_SIZE(da8xx_pruss_resources),
+ 	.resource	= da8xx_pruss_resources,
+ 	.dev		= {
+ 		.coherent_dma_mask	= DMA_BIT_MASK(32),
+ 		.platform_data		= &da8xx_uio_pruss_pdata,
+ 	}
+ };
+ 
+ int __init da8xx_register_uio_pruss(void)
+ {
+ 	da8xx_uio_pruss_pdata.sram_pool = sram_get_gen_pool();
+ 	return platform_device_register(&da8xx_uio_pruss_dev);
+ }
+ 
 -static const struct display_panel disp_panel = {
 -	QVGA,
 -	16,
 -	16,
 -	COLOR_ACTIVE,
 -};
 -
  static struct lcd_ctrl_config lcd_cfg = {
 -	&disp_panel,
 -	.ac_bias		= 255,
 -	.ac_bias_intrpt		= 0,
 -	.dma_burst_sz		= 16,
 +	.panel_shade		= COLOR_ACTIVE,
  	.bpp			= 16,
 -	.fdd			= 255,
 -	.tft_alt_mode		= 0,
 -	.stn_565_mode		= 0,
 -	.mono_8bit_mode		= 0,
 -	.invert_line_clock	= 1,
 -	.invert_frm_clock	= 1,
 -	.sync_edge		= 0,
 -	.sync_ctrl		= 1,
 -	.raster_order		= 0,
 -	.fifo_th		= 6,
  };
  
  struct da8xx_lcdc_platform_data sharp_lcd035q3dg01_pdata = {

[-- Attachment #1.2: Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Tony Lindgren]

* Stephen Rothwell <sfr@canb.auug.org.au> [121126 02:58]:
> Hi all,
> 
> Today's linux-next merge of the arm-soc tree got a conflict in
> arch/arm/plat-omap/common.c between commit b022e17b1c7e ("OMAP: common.c:
> remove init call to vram") from the omap_dss2 tree and commit
> f583f0f2c720 ("ARM: OMAP2+: Move omap_reserve() locally to mach-omap2")
> from the arm-soc tree.
> 
> I fixed it up (by deleting the file and adding the following patch) and
> can carry the fix as necessary (no action is required).

Thanks this is the correct fix.

Tony
 
> From 523f2987a07f97c946c63e0be4558b8332b46e8f Mon Sep 17 00:00:00 2001
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 26 Nov 2012 21:51:20 +1100
> Subject: [PATCH] OMAP: common.c: remove init call to vram fixup
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  arch/arm/mach-omap2/common.c |    3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
> index 5c2fd48..2dabb9e 100644
> --- a/arch/arm/mach-omap2/common.c
> +++ b/arch/arm/mach-omap2/common.c
> @@ -16,8 +16,6 @@
>  #include <linux/init.h>
>  #include <linux/platform_data/dsp-omap.h>
>  
> -#include <plat/vram.h>
> -
>  #include "common.h"
>  #include "omap-secure.h"
>  
> @@ -32,7 +30,6 @@ int __weak omap_secure_ram_reserve_memblock(void)
>  
>  void __init omap_reserve(void)
>  {
> -	omap_vram_reserve_sdram_memblock();
>  	omap_dsp_reserve_sdram_memblock();
>  	omap_secure_ram_reserve_memblock();
>  	omap_barrier_reserve_memblock();
> -- 
> 1.7.10.280.gaa39
> 
> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au

linux-next: manual merge of the arm-soc tree with the omap_dss2 tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/plat-omap/common.c between commit b022e17b1c7e ("OMAP: common.c:
remove init call to vram") from the omap_dss2 tree and commit
f583f0f2c720 ("ARM: OMAP2+: Move omap_reserve() locally to mach-omap2")
from the arm-soc tree.

I fixed it up (by deleting the file and adding the following patch) and
can carry the fix as necessary (no action is required).

From 523f2987a07f97c946c63e0be4558b8332b46e8f Mon Sep 17 00:00:00 2001
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 26 Nov 2012 21:51:20 +1100
Subject: [PATCH] OMAP: common.c: remove init call to vram fixup

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/arm/mach-omap2/common.c |    3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
index 5c2fd48..2dabb9e 100644
--- a/arch/arm/mach-omap2/common.c
+++ b/arch/arm/mach-omap2/common.c
@@ -16,8 +16,6 @@
 #include <linux/init.h>
 #include <linux/platform_data/dsp-omap.h>
 
-#include <plat/vram.h>
-
 #include "common.h"
 #include "omap-secure.h"
 
@@ -32,7 +30,6 @@ int __weak omap_secure_ram_reserve_memblock(void)
 
 void __init omap_reserve(void)
 {
-	omap_vram_reserve_sdram_memblock();
 	omap_dsp_reserve_sdram_memblock();
 	omap_secure_ram_reserve_memblock();
 	omap_barrier_reserve_memblock();
-- 
1.7.10.280.gaa39

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

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

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

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [120924 06:12]:
> Hi Arnd,
> 
> On Mon, 2012-09-24 at 12:43 +0000, Arnd Bergmann wrote:
> > On Monday 24 September 2012, Stephen Rothwell wrote:
> > > Today's linux-next merge of the arm-soc tree got a conflict in
> > > drivers/video/omap/lcd_ams_delta.c between commit 9586778de558 ("OMAPFB1:
> > > remove unnecessary includes") from the  tree and commit e27e35ec735f
> > > ("ARM: OMAP1: Move board-ams-delta.h from plat to mach") from the arm-soc
> > > tree.
> > > 
> > > The latter removed a superset of the former (as far as include files is
> > > concerned), so I used that and can carry the fix as necessary (no action
> > > is required).
> > > 
> > 
> > Hi Stephen,
> > 
> > I looked at all your reports and your fixes are looking good to me.
> > 
> > I'm already building all ARM defconfigs now and have fixup patches for the
> > instances that went wrong or introduced new warnings, I'll do that again
> > on top of today's linux-next tree.
> > 
> > The merge window is going to be fun with all those conflicts, but I don't
> > have a better idea either.
> 
> If there's a stable branch for the OMAP platform changes, I could merge
> it to omapdss tree and fix the conflicts. But if I've understood right,
> Linus doesn't really like merges just for the sake of fixing conflicts.
> 
> So far all the omapdss conflicts seem trivial, though.

Trivial ones should be OK, but maybe you find something
minimal with the following to find tags that you can pull
into your branch make things easier:

$ git log --pretty=oneline --merges v3.6-rc7..arm-soc/for-next arch/arm/*omap*/* | grep "Merge tag" | grep omap

Regards,

Tony

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

[Tomi Valkeinen]

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

Hi Arnd,

On Mon, 2012-09-24 at 12:43 +0000, Arnd Bergmann wrote:
> On Monday 24 September 2012, Stephen Rothwell wrote:
> > Today's linux-next merge of the arm-soc tree got a conflict in
> > drivers/video/omap/lcd_ams_delta.c between commit 9586778de558 ("OMAPFB1:
> > remove unnecessary includes") from the  tree and commit e27e35ec735f
> > ("ARM: OMAP1: Move board-ams-delta.h from plat to mach") from the arm-soc
> > tree.
> > 
> > The latter removed a superset of the former (as far as include files is
> > concerned), so I used that and can carry the fix as necessary (no action
> > is required).
> > 
> 
> Hi Stephen,
> 
> I looked at all your reports and your fixes are looking good to me.
> 
> I'm already building all ARM defconfigs now and have fixup patches for the
> instances that went wrong or introduced new warnings, I'll do that again
> on top of today's linux-next tree.
> 
> The merge window is going to be fun with all those conflicts, but I don't
> have a better idea either.

If there's a stable branch for the OMAP platform changes, I could merge
it to omapdss tree and fix the conflicts. But if I've understood right,
Linus doesn't really like merges just for the sake of fixing conflicts.

So far all the omapdss conflicts seem trivial, though.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Arnd Bergmann]

On Monday 24 September 2012, Stephen Rothwell wrote:
> Today's linux-next merge of the arm-soc tree got a conflict in
> drivers/video/omap/lcd_ams_delta.c between commit 9586778de558 ("OMAPFB1:
> remove unnecessary includes") from the  tree and commit e27e35ec735f
> ("ARM: OMAP1: Move board-ams-delta.h from plat to mach") from the arm-soc
> tree.
> 
> The latter removed a superset of the former (as far as include files is
> concerned), so I used that and can carry the fix as necessary (no action
> is required).
> 

Hi Stephen,

I looked at all your reports and your fixes are looking good to me.

I'm already building all ARM defconfigs now and have fixup patches for the
instances that went wrong or introduced new warnings, I'll do that again
on top of today's linux-next tree.

The merge window is going to be fun with all those conflicts, but I don't
have a better idea either.

	Arnd

linux-next: manual merge of the arm-soc tree with the omap_dss2 tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
drivers/video/omap/lcd_ams_delta.c between commit 9586778de558 ("OMAPFB1:
remove unnecessary includes") from the  tree and commit e27e35ec735f
("ARM: OMAP1: Move board-ams-delta.h from plat to mach") from the arm-soc
tree.

The latter removed a superset of the former (as far as include files is
concerned), so I used that and can carry the fix as necessary (no action
is required).

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

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

linux-next: manual merge of the arm-soc tree with the omap_dss2 tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in drivers/video/omap2/dss/dispc.c between commit fe6a466283cf ("OMAPDSS: remove unnecessary includes") from the omap_dss2 tree and commit 7d7e1eba7e92 ("ARM: OMAP2+: Prepare for irqs.h removal") from the arm-soc tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

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

diff --cc drivers/video/omap2/dss/dispc.c
index d512c38,ee9e296..0000000
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@@ -37,6 -37,9 +37,8 @@@
  #include <linux/platform_device.h>
  #include <linux/pm_runtime.h>
  
+ #include <plat/cpu.h>
 -#include <plat/clock.h>
+ 
  #include <video/omapdss.h>
  
  #include "dss.h"

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

linux-next: manual merge of the arm-soc tree with the omap_dss2 tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
drivers/video/omap2/displays/panel-taal.c between commit 9c3d5eb71b1f
("OMAP: DSS2: Remove suspicous and unused TAAL regulator API usage") from
the omap_dss2 tree and commit 3acc797c1db2 ("OMAPDSS: Taal: move reset
gpio handling to taal driver") from the arm-soc 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 drivers/video/omap2/displays/panel-taal.c
index 3053399,b2dd88b..0000000
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@@ -992,8 -1082,13 +1001,11 @@@ err_gpio
  	if (bldev != NULL)
  		backlight_device_unregister(bldev);
  err_bl:
+ 	if (gpio_is_valid(panel_data->reset_gpio))
+ 		gpio_free(panel_data->reset_gpio);
+ err_rst_gpio:
  	destroy_workqueue(td->workqueue);
  err_wq:
 -	free_regulators(panel_config->regulators, panel_config->num_regulators);
 -err_reg:
  	kfree(td);
  err:
  	return r;
@@@ -1030,6 -1125,12 +1042,9 @@@ static void __exit taal_remove(struct o
  	/* reset, to be sure that the panel is in a valid state */
  	taal_hw_reset(dssdev);
  
 -	free_regulators(td->panel_config->regulators,
 -			td->panel_config->num_regulators);
 -
+ 	if (gpio_is_valid(panel_data->reset_gpio))
+ 		gpio_free(panel_data->reset_gpio);
+ 
  	kfree(td);
  }
  

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

linux-next: manual merge of the arm-soc tree with the omap_dss2 tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-omap1/board-ams-delta.c between commit ddba6c7f7ec6
("OMAP1: pass LCD config with omapfb_set_lcd_config()") from the
omap_dss2 tree and commits 2e3ee9f45b3c ("ARM: OMAP1: Move most of
plat/io.h into local iomap.h") and several others from the arm-soc 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-omap1/board-ams-delta.c
index e0e8245,7dd3099..0000000
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@@ -18,9 -19,12 +19,13 @@@
  #include <linux/interrupt.h>
  #include <linux/leds.h>
  #include <linux/platform_device.h>
+ #include <linux/regulator/consumer.h>
+ #include <linux/regulator/fixed.h>
+ #include <linux/regulator/machine.h>
  #include <linux/serial_8250.h>
  #include <linux/export.h>
 +#include <linux/omapfb.h>
+ #include <linux/io.h>
  
  #include <media/soc_camera.h>
  
@@@ -170,6 -165,151 +166,147 @@@ static struct omap_usb_config ams_delta
  	.pins[0]	= 2,
  };
  
 -static struct omap_board_config_kernel ams_delta_config[] __initdata = {
 -	{ OMAP_TAG_LCD,		&ams_delta_lcd_config },
 -};
 -
+ #define LATCH1_GPIO_BASE	232
+ #define LATCH1_NGPIO		8
+ 
+ static struct resource latch1_resources[] = {
+ 	[0] = {
+ 		.name	= "dat",
+ 		.start	= LATCH1_PHYS,
+ 		.end	= LATCH1_PHYS + (LATCH1_NGPIO - 1) / 8,
+ 		.flags	= IORESOURCE_MEM,
+ 	},
+ };
+ 
+ static struct bgpio_pdata latch1_pdata = {
+ 	.base	= LATCH1_GPIO_BASE,
+ 	.ngpio	= LATCH1_NGPIO,
+ };
+ 
+ static struct platform_device latch1_gpio_device = {
+ 	.name		= "basic-mmio-gpio",
+ 	.id		= 0,
+ 	.resource	= latch1_resources,
+ 	.num_resources	= ARRAY_SIZE(latch1_resources),
+ 	.dev		= {
+ 		.platform_data	= &latch1_pdata,
+ 	},
+ };
+ 
+ static struct resource latch2_resources[] = {
+ 	[0] = {
+ 		.name	= "dat",
+ 		.start	= LATCH2_PHYS,
+ 		.end	= LATCH2_PHYS + (AMS_DELTA_LATCH2_NGPIO - 1) / 8,
+ 		.flags	= IORESOURCE_MEM,
+ 	},
+ };
+ 
+ static struct bgpio_pdata latch2_pdata = {
+ 	.base	= AMS_DELTA_LATCH2_GPIO_BASE,
+ 	.ngpio	= AMS_DELTA_LATCH2_NGPIO,
+ };
+ 
+ static struct platform_device latch2_gpio_device = {
+ 	.name		= "basic-mmio-gpio",
+ 	.id		= 1,
+ 	.resource	= latch2_resources,
+ 	.num_resources	= ARRAY_SIZE(latch2_resources),
+ 	.dev		= {
+ 		.platform_data	= &latch2_pdata,
+ 	},
+ };
+ 
+ static const struct gpio latch_gpios[] __initconst = {
+ 	{
+ 		.gpio	= LATCH1_GPIO_BASE + 6,
+ 		.flags	= GPIOF_OUT_INIT_LOW,
+ 		.label	= "dockit1",
+ 	},
+ 	{
+ 		.gpio	= LATCH1_GPIO_BASE + 7,
+ 		.flags	= GPIOF_OUT_INIT_LOW,
+ 		.label	= "dockit2",
+ 	},
+ 	{
+ 		.gpio	= AMS_DELTA_GPIO_PIN_SCARD_RSTIN,
+ 		.flags	= GPIOF_OUT_INIT_LOW,
+ 		.label	= "scard_rstin",
+ 	},
+ 	{
+ 		.gpio	= AMS_DELTA_GPIO_PIN_SCARD_CMDVCC,
+ 		.flags	= GPIOF_OUT_INIT_LOW,
+ 		.label	= "scard_cmdvcc",
+ 	},
+ 	{
+ 		.gpio	= AMS_DELTA_GPIO_PIN_MODEM_CODEC,
+ 		.flags	= GPIOF_OUT_INIT_LOW,
+ 		.label	= "modem_codec",
+ 	},
+ 	{
+ 		.gpio	= AMS_DELTA_LATCH2_GPIO_BASE + 14,
+ 		.flags	= GPIOF_OUT_INIT_LOW,
+ 		.label	= "hookflash1",
+ 	},
+ 	{
+ 		.gpio	= AMS_DELTA_LATCH2_GPIO_BASE + 15,
+ 		.flags	= GPIOF_OUT_INIT_LOW,
+ 		.label	= "hookflash2",
+ 	},
+ };
+ 
+ static struct regulator_consumer_supply modem_nreset_consumers[] = {
+ 	REGULATOR_SUPPLY("RESET#", "serial8250.1"),
+ 	REGULATOR_SUPPLY("POR", "cx20442-codec"),
+ };
+ 
+ static struct regulator_init_data modem_nreset_data = {
+ 	.constraints		= {
+ 		.valid_ops_mask		= REGULATOR_CHANGE_STATUS,
+ 		.boot_on		= 1,
+ 	},
+ 	.num_consumer_supplies	= ARRAY_SIZE(modem_nreset_consumers),
+ 	.consumer_supplies	= modem_nreset_consumers,
+ };
+ 
+ static struct fixed_voltage_config modem_nreset_config = {
+ 	.supply_name		= "modem_nreset",
+ 	.microvolts		= 3300000,
+ 	.gpio			= AMS_DELTA_GPIO_PIN_MODEM_NRESET,
+ 	.startup_delay		= 25000,
+ 	.enable_high		= 1,
+ 	.enabled_at_boot	= 1,
+ 	.init_data		= &modem_nreset_data,
+ };
+ 
+ static struct platform_device modem_nreset_device = {
+ 	.name	= "reg-fixed-voltage",
+ 	.id	= -1,
+ 	.dev	= {
+ 		.platform_data	= &modem_nreset_config,
+ 	},
+ };
+ 
+ struct modem_private_data {
+ 	struct regulator *regulator;
+ };
+ 
+ static struct modem_private_data modem_priv;
+ 
+ void ams_delta_latch_write(int base, int ngpio, u16 mask, u16 value)
+ {
+ 	int bit = 0;
+ 	u16 bitpos = 1 << bit;
+ 
+ 	for (; bit < ngpio; bit++, bitpos = bitpos << 1) {
+ 		if (!(mask & bitpos))
+ 			continue;
+ 		else
+ 			gpio_set_value(base + bit, (value & bitpos) != 0);
+ 	}
+ }
+ EXPORT_SYMBOL(ams_delta_latch_write);
+ 
  static struct resource ams_delta_nand_resources[] = {
  	[0] = {
  		.start	= OMAP1_MPUIO_BASE,
@@@ -316,14 -496,28 +491,30 @@@ static void __init ams_delta_init(void
  	ams_delta_init_fiq();
  
  	omap_writew(omap_readw(ARM_RSTCT1) | 0x0004, ARM_RSTCT1);
 +
 +	omapfb_set_lcd_config(&ams_delta_lcd_config);
  }
  
+ static void modem_pm(struct uart_port *port, unsigned int state, unsigned old)
+ {
+ 	struct modem_private_data *priv = port->private_data;
+ 
+ 	if (IS_ERR(priv->regulator))
+ 		return;
+ 
+ 	if (state == old)
+ 		return;
+ 
+ 	if (state == 0)
+ 		regulator_enable(priv->regulator);
+ 	else if (old == 0)
+ 		regulator_disable(priv->regulator);
+ }
+ 
  static struct plat_serial8250_port ams_delta_modem_ports[] = {
  	{
- 		.membase	= IOMEM(AMS_DELTA_MODEM_VIRT),
- 		.mapbase	= AMS_DELTA_MODEM_PHYS,
+ 		.membase	= IOMEM(MODEM_VIRT),
+ 		.mapbase	= MODEM_PHYS,
  		.irq		= -EINVAL, /* changed later */
  		.flags		= UPF_BOOT_AUTOCONF,
  		.irqflags	= IRQF_TRIGGER_RISING,

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

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

[Janusz Krzysztofik]

On Thursday 08 of March 2012 16:51:16 Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the arm-soc tree got a conflict in
> arch/arm/mach-omap1/board-ams-delta.c between commit ddba6c7f7ec6
> ("OMAP1: pass LCD config with omapfb_set_lcd_config()") from the
> omap_dss2 tree and commits 5ca6180fa6d7 ("ARM: OMAP1: ams-delta:
> supersede custom led device by leds-gpio") and 2e3ee9f45b3c ("ARM: OMAP1:
> Move most of plat/io.h into local iomap.h") from the arm-soc tree.
> 
> I fixed it up (see below) and can carry the fix as necessary.

Hi,
Your resolution looks good to me, thanks!
Janusz

linux-next: manual merge of the arm-soc tree with the omap_dss2 tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-omap1/board-palmz71.c between commit ddba6c7f7ec6 ("OMAP1:
pass LCD config with omapfb_set_lcd_config()") from the omap_dss2 tree
and commit 2e3ee9f45b3c ("ARM: OMAP1: Move most of plat/io.h into local
iomap.h") from the arm-soc 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-omap1/board-palmz71.c
index 9924c70,c1cd0f2..0000000
--- a/arch/arm/mach-omap1/board-palmz71.c
+++ b/arch/arm/mach-omap1/board-palmz71.c
@@@ -27,9 -27,9 +27,10 @@@
  #include <linux/mtd/mtd.h>
  #include <linux/mtd/partitions.h>
  #include <linux/mtd/physmap.h>
 +#include <linux/omapfb.h>
+ #include <linux/spi/spi.h>
+ #include <linux/spi/ads7846.h>
  
- #include <mach/hardware.h>
  #include <asm/mach-types.h>
  #include <asm/mach/arch.h>
  #include <asm/mach/map.h>

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

linux-next: manual merge of the arm-soc tree with the omap_dss2 tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-omap1/board-osk.c between commit ddba6c7f7ec6 ("OMAP1: pass
LCD config with omapfb_set_lcd_config()") from the omap_dss2 tree and
commit 2e3ee9f45b3c ("ARM: OMAP1: Move most of plat/io.h into local
iomap.h") from the arm-soc 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-omap1/board-osk.c
index ef87465,e2d7ae4..0000000
--- a/arch/arm/mach-omap1/board-osk.c
+++ b/arch/arm/mach-omap1/board-osk.c
@@@ -34,8 -34,6 +34,7 @@@
  #include <linux/i2c.h>
  #include <linux/leds.h>
  #include <linux/smc91x.h>
 +#include <linux/omapfb.h>
- 
  #include <linux/mtd/mtd.h>
  #include <linux/mtd/partitions.h>
  #include <linux/mtd/physmap.h>

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

linux-next: manual merge of the arm-soc tree with the omap_dss2 tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-omap1/board-nokia770.c between commit 58e0d6ab02eb ("OMAP:
N770: remove HWA742 platform data") from the omap_dss2 tree and commit
2e3ee9f45b3c ("ARM: OMAP1: Move most of plat/io.h into local iomap.h")
from the arm-soc 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-omap1/board-nokia770.c
index 9b6332a,abdbdb0..0000000
--- a/arch/arm/mach-omap1/board-nokia770.c
+++ b/arch/arm/mach-omap1/board-nokia770.c
@@@ -30,7 -29,7 +29,6 @@@
  #include <plat/usb.h>
  #include <plat/board.h>
  #include <plat/keypad.h>
- #include "common.h"
 -#include <plat/hwa742.h>
  #include <plat/lcd_mipid.h>
  #include <plat/mmc.h>
  #include <plat/clock.h>

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

linux-next: manual merge of the arm-soc tree with the omap_dss2 tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-omap1/board-ams-delta.c between commit ddba6c7f7ec6
("OMAP1: pass LCD config with omapfb_set_lcd_config()") from the
omap_dss2 tree and commits 5ca6180fa6d7 ("ARM: OMAP1: ams-delta:
supersede custom led device by leds-gpio") and 2e3ee9f45b3c ("ARM: OMAP1:
Move most of plat/io.h into local iomap.h") from the arm-soc 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-omap1/board-ams-delta.c
index e0e8245,c847597..0000000
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@@ -20,7 -21,7 +21,8 @@@
  #include <linux/platform_device.h>
  #include <linux/serial_8250.h>
  #include <linux/export.h>
 +#include <linux/omapfb.h>
+ #include <linux/io.h>
  
  #include <media/soc_camera.h>
  
@@@ -170,6 -162,117 +163,113 @@@ static struct omap_usb_config ams_delta
  	.pins[0]	= 2,
  };
  
 -static struct omap_board_config_kernel ams_delta_config[] __initdata = {
 -	{ OMAP_TAG_LCD,		&ams_delta_lcd_config },
 -};
 -
+ #define LATCH1_GPIO_BASE	232
+ #define LATCH1_NGPIO		8
+ 
+ static struct resource latch1_resources[] __initconst = {
+ 	[0] = {
+ 		.name	= "dat",
+ 		.start	= LATCH1_PHYS,
+ 		.end	= LATCH1_PHYS + (LATCH1_NGPIO - 1) / 8,
+ 		.flags	= IORESOURCE_MEM,
+ 	},
+ };
+ 
+ static struct bgpio_pdata latch1_pdata __initconst = {
+ 	.base	= LATCH1_GPIO_BASE,
+ 	.ngpio	= LATCH1_NGPIO,
+ };
+ 
+ static struct platform_device latch1_gpio_device = {
+ 	.name		= "basic-mmio-gpio",
+ 	.id		= 0,
+ 	.resource	= latch1_resources,
+ 	.num_resources	= ARRAY_SIZE(latch1_resources),
+ 	.dev		= {
+ 		.platform_data	= &latch1_pdata,
+ 	},
+ };
+ 
+ static struct resource latch2_resources[] __initconst = {
+ 	[0] = {
+ 		.name	= "dat",
+ 		.start	= LATCH2_PHYS,
+ 		.end	= LATCH2_PHYS + (AMS_DELTA_LATCH2_NGPIO - 1) / 8,
+ 		.flags	= IORESOURCE_MEM,
+ 	},
+ };
+ 
+ static struct bgpio_pdata latch2_pdata __initconst = {
+ 	.base	= AMS_DELTA_LATCH2_GPIO_BASE,
+ 	.ngpio	= AMS_DELTA_LATCH2_NGPIO,
+ };
+ 
+ static struct platform_device latch2_gpio_device = {
+ 	.name		= "basic-mmio-gpio",
+ 	.id		= 1,
+ 	.resource	= latch2_resources,
+ 	.num_resources	= ARRAY_SIZE(latch2_resources),
+ 	.dev		= {
+ 		.platform_data	= &latch2_pdata,
+ 	},
+ };
+ 
+ static struct gpio latch_gpios[] __initconst = {
+ 	{
+ 		.gpio	= LATCH1_GPIO_BASE + 6,
+ 		.flags	= GPIOF_OUT_INIT_LOW,
+ 		.label	= "dockit1",
+ 	},
+ 	{
+ 		.gpio	= LATCH1_GPIO_BASE + 7,
+ 		.flags	= GPIOF_OUT_INIT_LOW,
+ 		.label	= "dockit2",
+ 	},
+ 	{
+ 		.gpio	= AMS_DELTA_GPIO_PIN_SCARD_RSTIN,
+ 		.flags	= GPIOF_OUT_INIT_LOW,
+ 		.label	= "scard_rstin",
+ 	},
+ 	{
+ 		.gpio	= AMS_DELTA_GPIO_PIN_SCARD_CMDVCC,
+ 		.flags	= GPIOF_OUT_INIT_LOW,
+ 		.label	= "scard_cmdvcc",
+ 	},
+ 	{
+ 		.gpio	= AMS_DELTA_GPIO_PIN_MODEM_NRESET,
+ 		.flags	= GPIOF_OUT_INIT_LOW,
+ 		.label	= "modem_nreset",
+ 	},
+ 	{
+ 		.gpio	= AMS_DELTA_GPIO_PIN_MODEM_CODEC,
+ 		.flags	= GPIOF_OUT_INIT_LOW,
+ 		.label	= "modem_codec",
+ 	},
+ 	{
+ 		.gpio	= AMS_DELTA_LATCH2_GPIO_BASE + 14,
+ 		.flags	= GPIOF_OUT_INIT_LOW,
+ 		.label	= "hookflash1",
+ 	},
+ 	{
+ 		.gpio	= AMS_DELTA_LATCH2_GPIO_BASE + 15,
+ 		.flags	= GPIOF_OUT_INIT_LOW,
+ 		.label	= "hookflash2",
+ 	},
+ };
+ 
+ void ams_delta_latch_write(int base, int ngpio, u16 mask, u16 value)
+ {
+ 	int bit = 0;
+ 	u16 bitpos = 1 << bit;
+ 
+ 	for (; bit < ngpio; bit++, bitpos = bitpos << 1) {
+ 		if (!(mask & bitpos))
+ 			continue;
+ 		gpio_set_value(base + bit, (value & bitpos) != 0);
+ 	}
+ }
+ EXPORT_SYMBOL(ams_delta_latch_write);
+ 
  static struct resource ams_delta_nand_resources[] = {
  	[0] = {
  		.start	= OMAP1_MPUIO_BASE,

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