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

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

[Stephen Rothwell]

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

Hi Mauro,

Today's linux-next merge of the v4l-dvb tree got a conflict in
arch/arm/mach-omap2/devices.c between commit e7e42b9d2a7f ("ARM:
OMAP4+: Remove unused omap_l3_noc platform init") from the arm-soc tree
and commit 1b65729a186b ("[media] mach-omap2: remove deprecated
VIDEO_OMAP2 support") from the v4l-dvb 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/devices.c
index 492ef1607115,1b623a06cdcd..000000000000
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@@ -67,28 -67,40 +67,6 @@@ static int __init omap3_l3_init(void
  }
  omap_postcore_initcall(omap3_l3_init);
  
- #if defined(CONFIG_VIDEO_OMAP2) || defined(CONFIG_VIDEO_OMAP2_MODULE)
 -static int __init omap4_l3_init(void)
 -{
 -	int i;
 -	struct omap_hwmod *oh[3];
 -	struct platform_device *pdev;
 -	char oh_name[L3_MODULES_MAX_LEN];
--
- static struct resource omap2cam_resources[] = {
- 	{
- 		.start		= OMAP24XX_CAMERA_BASE,
- 		.end		= OMAP24XX_CAMERA_BASE + 0xfff,
- 		.flags		= IORESOURCE_MEM,
- 	},
- 	{
- 		.start		= 24 + OMAP_INTC_START,
- 		.flags		= IORESOURCE_IRQ,
 -	/* If dtb is there, the devices will be created dynamically */
 -	if (of_have_populated_dt())
 -		return -ENODEV;
 -
 -	/*
 -	 * To avoid code running on other OMAPs in
 -	 * multi-omap builds
 -	 */
 -	if (!cpu_is_omap44xx() && !soc_is_omap54xx())
 -		return -ENODEV;
 -
 -	for (i = 0; i < L3_MODULES; i++) {
 -		snprintf(oh_name, L3_MODULES_MAX_LEN, "l3_main_%d", i+1);
 -
 -		oh[i] = omap_hwmod_lookup(oh_name);
 -		if (!(oh[i]))
 -			pr_err("could not look up %s\n", oh_name);
--	}
- };
--
- static struct platform_device omap2cam_device = {
- 	.name		= "omap24xxcam",
- 	.id		= -1,
- 	.num_resources	= ARRAY_SIZE(omap2cam_resources),
- 	.resource	= omap2cam_resources,
- };
- #endif
 -	pdev = omap_device_build_ss("omap_l3_noc", 0, oh, 3, NULL, 0);
 -
 -	WARN(IS_ERR(pdev), "could not build omap_device for %s\n", oh_name);
 -
 -	return PTR_RET(pdev);
 -}
 -omap_postcore_initcall(omap4_l3_init);
--
  #if defined(CONFIG_IOMMU_API)
  
  #include <linux/platform_data/iommu-omap.h>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Stephen Rothwell]

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

Hi Mauro,

Today's linux-next merge of the v4l-dvb tree got a conflict in
arch/arm/mach-omap2/devices.c between commit e7e42b9d2a7f ("ARM:
OMAP4+: Remove unused omap_l3_noc platform init") from the arm-soc tree
and commit 1b65729a186b ("[media] mach-omap2: remove deprecated
VIDEO_OMAP2 support") from the v4l-dvb 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/devices.c
index 492ef1607115,1b623a06cdcd..000000000000
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@@ -67,28 -67,40 +67,6 @@@ static int __init omap3_l3_init(void
  }
  omap_postcore_initcall(omap3_l3_init);
  
- #if defined(CONFIG_VIDEO_OMAP2) || defined(CONFIG_VIDEO_OMAP2_MODULE)
 -static int __init omap4_l3_init(void)
 -{
 -	int i;
 -	struct omap_hwmod *oh[3];
 -	struct platform_device *pdev;
 -	char oh_name[L3_MODULES_MAX_LEN];
--
- static struct resource omap2cam_resources[] = {
- 	{
- 		.start		= OMAP24XX_CAMERA_BASE,
- 		.end		= OMAP24XX_CAMERA_BASE + 0xfff,
- 		.flags		= IORESOURCE_MEM,
- 	},
- 	{
- 		.start		= 24 + OMAP_INTC_START,
- 		.flags		= IORESOURCE_IRQ,
 -	/* If dtb is there, the devices will be created dynamically */
 -	if (of_have_populated_dt())
 -		return -ENODEV;
 -
 -	/*
 -	 * To avoid code running on other OMAPs in
 -	 * multi-omap builds
 -	 */
 -	if (!cpu_is_omap44xx() && !soc_is_omap54xx())
 -		return -ENODEV;
 -
 -	for (i = 0; i < L3_MODULES; i++) {
 -		snprintf(oh_name, L3_MODULES_MAX_LEN, "l3_main_%d", i+1);
 -
 -		oh[i] = omap_hwmod_lookup(oh_name);
 -		if (!(oh[i]))
 -			pr_err("could not look up %s\n", oh_name);
--	}
- };
--
- static struct platform_device omap2cam_device = {
- 	.name		= "omap24xxcam",
- 	.id		= -1,
- 	.num_resources	= ARRAY_SIZE(omap2cam_resources),
- 	.resource	= omap2cam_resources,
- };
- #endif
 -	pdev = omap_device_build_ss("omap_l3_noc", 0, oh, 3, NULL, 0);
 -
 -	WARN(IS_ERR(pdev), "could not build omap_device for %s\n", oh_name);
 -
 -	return PTR_RET(pdev);
 -}
 -omap_postcore_initcall(omap4_l3_init);
--
  #if defined(CONFIG_IOMMU_API)
  
  #include <linux/platform_data/iommu-omap.h>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Stephen Rothwell]

Hi Mauro,

Today's linux-next merge of the v4l-dvb tree got a conflict in
arch/arm/mach-omap2/devices.c between commit e7e42b9d2a7f ("ARM:
OMAP4+: Remove unused omap_l3_noc platform init") from the arm-soc tree
and commit 1b65729a186b ("[media] mach-omap2: remove deprecated
VIDEO_OMAP2 support") from the v4l-dvb tree.

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

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

diff --cc arch/arm/mach-omap2/devices.c
index 492ef1607115,1b623a06cdcd..000000000000
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@@ -67,28 -67,40 +67,6 @@@ static int __init omap3_l3_init(void
  }
  omap_postcore_initcall(omap3_l3_init);
  
- #if defined(CONFIG_VIDEO_OMAP2) || defined(CONFIG_VIDEO_OMAP2_MODULE)
 -static int __init omap4_l3_init(void)
 -{
 -	int i;
 -	struct omap_hwmod *oh[3];
 -	struct platform_device *pdev;
 -	char oh_name[L3_MODULES_MAX_LEN];
--
- static struct resource omap2cam_resources[] = {
- 	{
- 		.start		= OMAP24XX_CAMERA_BASE,
- 		.end		= OMAP24XX_CAMERA_BASE + 0xfff,
- 		.flags		= IORESOURCE_MEM,
- 	},
- 	{
- 		.start		= 24 + OMAP_INTC_START,
- 		.flags		= IORESOURCE_IRQ,
 -	/* If dtb is there, the devices will be created dynamically */
 -	if (of_have_populated_dt())
 -		return -ENODEV;
 -
 -	/*
 -	 * To avoid code running on other OMAPs in
 -	 * multi-omap builds
 -	 */
 -	if (!cpu_is_omap44xx() && !soc_is_omap54xx())
 -		return -ENODEV;
 -
 -	for (i = 0; i < L3_MODULES; i++) {
 -		snprintf(oh_name, L3_MODULES_MAX_LEN, "l3_main_%d", i+1);
 -
 -		oh[i] = omap_hwmod_lookup(oh_name);
 -		if (!(oh[i]))
 -			pr_err("could not look up %s\n", oh_name);
--	}
- };
--
- static struct platform_device omap2cam_device = {
- 	.name		= "omap24xxcam",
- 	.id		= -1,
- 	.num_resources	= ARRAY_SIZE(omap2cam_resources),
- 	.resource	= omap2cam_resources,
- };
- #endif
 -	pdev = omap_device_build_ss("omap_l3_noc", 0, oh, 3, NULL, 0);
 -
 -	WARN(IS_ERR(pdev), "could not build omap_device for %s\n", oh_name);
 -
 -	return PTR_RET(pdev);
 -}
 -omap_postcore_initcall(omap4_l3_init);
--
  #if defined(CONFIG_IOMMU_API)
  
  #include <linux/platform_data/iommu-omap.h>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141124/0c4e081f/attachment.sig>

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

[Tony Lindgren]

* Stephen Rothwell <sfr@canb.auug.org.au> [141123 18:24]:
> Hi Mauro,
> 
> Today's linux-next merge of the v4l-dvb tree got a conflict in
> arch/arm/mach-omap2/devices.c between commit e7e42b9d2a7f ("ARM:
> OMAP4+: Remove unused omap_l3_noc platform init") from the arm-soc tree
> and commit 1b65729a186b ("[media] mach-omap2: remove deprecated
> VIDEO_OMAP2 support") from the v4l-dvb tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Oops, that's a self-inflicted merge conflict, sorry. I should have
waited a bit longer on the removal of the now unnecessary l3_init.

Anyways, the resolution is correct thanks.

Regards,

Tony

> diff --cc arch/arm/mach-omap2/devices.c
> index 492ef1607115,1b623a06cdcd..000000000000
> --- a/arch/arm/mach-omap2/devices.c
> +++ b/arch/arm/mach-omap2/devices.c
> @@@ -67,28 -67,40 +67,6 @@@ static int __init omap3_l3_init(void
>   }
>   omap_postcore_initcall(omap3_l3_init);
>   
> - #if defined(CONFIG_VIDEO_OMAP2) || defined(CONFIG_VIDEO_OMAP2_MODULE)
>  -static int __init omap4_l3_init(void)
>  -{
>  -	int i;
>  -	struct omap_hwmod *oh[3];
>  -	struct platform_device *pdev;
>  -	char oh_name[L3_MODULES_MAX_LEN];
> --
> - static struct resource omap2cam_resources[] = {
> - 	{
> - 		.start		= OMAP24XX_CAMERA_BASE,
> - 		.end		= OMAP24XX_CAMERA_BASE + 0xfff,
> - 		.flags		= IORESOURCE_MEM,
> - 	},
> - 	{
> - 		.start		= 24 + OMAP_INTC_START,
> - 		.flags		= IORESOURCE_IRQ,
>  -	/* If dtb is there, the devices will be created dynamically */
>  -	if (of_have_populated_dt())
>  -		return -ENODEV;
>  -
>  -	/*
>  -	 * To avoid code running on other OMAPs in
>  -	 * multi-omap builds
>  -	 */
>  -	if (!cpu_is_omap44xx() && !soc_is_omap54xx())
>  -		return -ENODEV;
>  -
>  -	for (i = 0; i < L3_MODULES; i++) {
>  -		snprintf(oh_name, L3_MODULES_MAX_LEN, "l3_main_%d", i+1);
>  -
>  -		oh[i] = omap_hwmod_lookup(oh_name);
>  -		if (!(oh[i]))
>  -			pr_err("could not look up %s\n", oh_name);
> --	}
> - };
> --
> - static struct platform_device omap2cam_device = {
> - 	.name		= "omap24xxcam",
> - 	.id		= -1,
> - 	.num_resources	= ARRAY_SIZE(omap2cam_resources),
> - 	.resource	= omap2cam_resources,
> - };
> - #endif
>  -	pdev = omap_device_build_ss("omap_l3_noc", 0, oh, 3, NULL, 0);
>  -
>  -	WARN(IS_ERR(pdev), "could not build omap_device for %s\n", oh_name);
>  -
>  -	return PTR_RET(pdev);
>  -}
>  -omap_postcore_initcall(omap4_l3_init);
> --
>   #if defined(CONFIG_IOMMU_API)
>   
>   #include <linux/platform_data/iommu-omap.h>

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

[Tony Lindgren]

* Stephen Rothwell <sfr@canb.auug.org.au> [141123 18:24]:
> Hi Mauro,
> 
> Today's linux-next merge of the v4l-dvb tree got a conflict in
> arch/arm/mach-omap2/devices.c between commit e7e42b9d2a7f ("ARM:
> OMAP4+: Remove unused omap_l3_noc platform init") from the arm-soc tree
> and commit 1b65729a186b ("[media] mach-omap2: remove deprecated
> VIDEO_OMAP2 support") from the v4l-dvb tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Oops, that's a self-inflicted merge conflict, sorry. I should have
waited a bit longer on the removal of the now unnecessary l3_init.

Anyways, the resolution is correct thanks.

Regards,

Tony

> diff --cc arch/arm/mach-omap2/devices.c
> index 492ef1607115,1b623a06cdcd..000000000000
> --- a/arch/arm/mach-omap2/devices.c
> +++ b/arch/arm/mach-omap2/devices.c
> @@@ -67,28 -67,40 +67,6 @@@ static int __init omap3_l3_init(void
>   }
>   omap_postcore_initcall(omap3_l3_init);
>   
> - #if defined(CONFIG_VIDEO_OMAP2) || defined(CONFIG_VIDEO_OMAP2_MODULE)
>  -static int __init omap4_l3_init(void)
>  -{
>  -	int i;
>  -	struct omap_hwmod *oh[3];
>  -	struct platform_device *pdev;
>  -	char oh_name[L3_MODULES_MAX_LEN];
> --
> - static struct resource omap2cam_resources[] = {
> - 	{
> - 		.start		= OMAP24XX_CAMERA_BASE,
> - 		.end		= OMAP24XX_CAMERA_BASE + 0xfff,
> - 		.flags		= IORESOURCE_MEM,
> - 	},
> - 	{
> - 		.start		= 24 + OMAP_INTC_START,
> - 		.flags		= IORESOURCE_IRQ,
>  -	/* If dtb is there, the devices will be created dynamically */
>  -	if (of_have_populated_dt())
>  -		return -ENODEV;
>  -
>  -	/*
>  -	 * To avoid code running on other OMAPs in
>  -	 * multi-omap builds
>  -	 */
>  -	if (!cpu_is_omap44xx() && !soc_is_omap54xx())
>  -		return -ENODEV;
>  -
>  -	for (i = 0; i < L3_MODULES; i++) {
>  -		snprintf(oh_name, L3_MODULES_MAX_LEN, "l3_main_%d", i+1);
>  -
>  -		oh[i] = omap_hwmod_lookup(oh_name);
>  -		if (!(oh[i]))
>  -			pr_err("could not look up %s\n", oh_name);
> --	}
> - };
> --
> - static struct platform_device omap2cam_device = {
> - 	.name		= "omap24xxcam",
> - 	.id		= -1,
> - 	.num_resources	= ARRAY_SIZE(omap2cam_resources),
> - 	.resource	= omap2cam_resources,
> - };
> - #endif
>  -	pdev = omap_device_build_ss("omap_l3_noc", 0, oh, 3, NULL, 0);
>  -
>  -	WARN(IS_ERR(pdev), "could not build omap_device for %s\n", oh_name);
>  -
>  -	return PTR_RET(pdev);
>  -}
>  -omap_postcore_initcall(omap4_l3_init);
> --
>   #if defined(CONFIG_IOMMU_API)
>   
>   #include <linux/platform_data/iommu-omap.h>

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

[Mauro Carvalho Chehab]

HI Stephen/Arnd/Olof,

Em Tue, 15 Dec 2020 07:30:37 +1100
Stephen Rothwell <sfr@canb.auug.org.au> escreveu:

> Hi all,
> 
> On Tue, 8 Dec 2020 11:04:13 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Today's linux-next merge of the v4l-dvb tree got a conflict in:
> > 
> >   drivers/staging/media/sunxi/cedrus/cedrus.c
> > 
> > between commit:
> > 
> >   c6e95daab1cc ("media: cedrus: Remove the MBUS quirks")
> > 
> > from the arm-soc tree and commits:
> > 
> >   503dab0b8a56 ("media: cedrus: Register all codecs as capability")
> >   68b4a01f88af ("media: cedrus: Make VP8 codec as capability")
> > 
> > from the v4l-dvb tree.
> > 
> > I fixed it up (see below) and can carry the fix as necessary. This
> > is now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your tree
> > is submitted for merging.  You may also want to consider cooperating
> > with the maintainer of the conflicting tree to minimise any particularly
> > complex conflicts.
> > 
> > -- 
> > Cheers,
> > Stephen Rothwell
> > 
> > diff --cc drivers/staging/media/sunxi/cedrus/cedrus.c
> > index d5fca10ea5b4,18d54f9fd715..000000000000
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus.c
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
> > @@@ -522,7 -584,11 +584,10 @@@ static const struct cedrus_variant sun5
> >   
> >   static const struct cedrus_variant sun50i_h6_cedrus_variant = {
> >   	.capabilities	= CEDRUS_CAPABILITY_UNTILED |
> > - 			  CEDRUS_CAPABILITY_H265_DEC,
> > + 			  CEDRUS_CAPABILITY_MPEG2_DEC |
> > + 			  CEDRUS_CAPABILITY_H264_DEC |
> > + 			  CEDRUS_CAPABILITY_H265_DEC |
> > + 			  CEDRUS_CAPABILITY_VP8_DEC,
> >  -	.quirks		= CEDRUS_QUIRK_NO_DMA_OFFSET,
> >   	.mod_rate	= 600000000,
> >   };
> >     
> 
> Just a reminder that this conflict still exists.

Thanks for the reminder! I ended forgetting about it.
Last week was hard for me, as I had several things to solve
before taking some vacations, including preparing for a talk on
an user's group that happened last Saturday.

In any case, Linus already pulled from my tree:

	https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fab0fca1da5cdc48be051715cd9787df04fdce3a

So, I guess the best would be to either let Linus know about that
when he would be pulling from arm-soc, or to solve such conflict 
between upstream and arm-soc.

As I'm in PTO those days, in order to avoid further conflicts with
linux-next, I'll pull from Linus tree today.

Thanks,
Mauro

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

[Mauro Carvalho Chehab]

HI Stephen/Arnd/Olof,

Em Tue, 15 Dec 2020 07:30:37 +1100
Stephen Rothwell <sfr@canb.auug.org.au> escreveu:

> Hi all,
> 
> On Tue, 8 Dec 2020 11:04:13 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Today's linux-next merge of the v4l-dvb tree got a conflict in:
> > 
> >   drivers/staging/media/sunxi/cedrus/cedrus.c
> > 
> > between commit:
> > 
> >   c6e95daab1cc ("media: cedrus: Remove the MBUS quirks")
> > 
> > from the arm-soc tree and commits:
> > 
> >   503dab0b8a56 ("media: cedrus: Register all codecs as capability")
> >   68b4a01f88af ("media: cedrus: Make VP8 codec as capability")
> > 
> > from the v4l-dvb tree.
> > 
> > I fixed it up (see below) and can carry the fix as necessary. This
> > is now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your tree
> > is submitted for merging.  You may also want to consider cooperating
> > with the maintainer of the conflicting tree to minimise any particularly
> > complex conflicts.
> > 
> > -- 
> > Cheers,
> > Stephen Rothwell
> > 
> > diff --cc drivers/staging/media/sunxi/cedrus/cedrus.c
> > index d5fca10ea5b4,18d54f9fd715..000000000000
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus.c
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
> > @@@ -522,7 -584,11 +584,10 @@@ static const struct cedrus_variant sun5
> >   
> >   static const struct cedrus_variant sun50i_h6_cedrus_variant = {
> >   	.capabilities	= CEDRUS_CAPABILITY_UNTILED |
> > - 			  CEDRUS_CAPABILITY_H265_DEC,
> > + 			  CEDRUS_CAPABILITY_MPEG2_DEC |
> > + 			  CEDRUS_CAPABILITY_H264_DEC |
> > + 			  CEDRUS_CAPABILITY_H265_DEC |
> > + 			  CEDRUS_CAPABILITY_VP8_DEC,
> >  -	.quirks		= CEDRUS_QUIRK_NO_DMA_OFFSET,
> >   	.mod_rate	= 600000000,
> >   };
> >     
> 
> Just a reminder that this conflict still exists.

Thanks for the reminder! I ended forgetting about it.
Last week was hard for me, as I had several things to solve
before taking some vacations, including preparing for a talk on
an user's group that happened last Saturday.

In any case, Linus already pulled from my tree:

	https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fab0fca1da5cdc48be051715cd9787df04fdce3a

So, I guess the best would be to either let Linus know about that
when he would be pulling from arm-soc, or to solve such conflict 
between upstream and arm-soc.

As I'm in PTO those days, in order to avoid further conflicts with
linux-next, I'll pull from Linus tree today.

Thanks,
Mauro

_______________________________________________
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 v4l-dvb tree with the arm-soc tree

[Stephen Rothwell]

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

Hi all,

On Tue, 8 Dec 2020 11:04:13 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the v4l-dvb tree got a conflict in:
> 
>   drivers/staging/media/sunxi/cedrus/cedrus.c
> 
> between commit:
> 
>   c6e95daab1cc ("media: cedrus: Remove the MBUS quirks")
> 
> from the arm-soc tree and commits:
> 
>   503dab0b8a56 ("media: cedrus: Register all codecs as capability")
>   68b4a01f88af ("media: cedrus: Make VP8 codec as capability")
> 
> from the v4l-dvb tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/staging/media/sunxi/cedrus/cedrus.c
> index d5fca10ea5b4,18d54f9fd715..000000000000
> --- a/drivers/staging/media/sunxi/cedrus/cedrus.c
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
> @@@ -522,7 -584,11 +584,10 @@@ static const struct cedrus_variant sun5
>   
>   static const struct cedrus_variant sun50i_h6_cedrus_variant = {
>   	.capabilities	= CEDRUS_CAPABILITY_UNTILED |
> - 			  CEDRUS_CAPABILITY_H265_DEC,
> + 			  CEDRUS_CAPABILITY_MPEG2_DEC |
> + 			  CEDRUS_CAPABILITY_H264_DEC |
> + 			  CEDRUS_CAPABILITY_H265_DEC |
> + 			  CEDRUS_CAPABILITY_VP8_DEC,
>  -	.quirks		= CEDRUS_QUIRK_NO_DMA_OFFSET,
>   	.mod_rate	= 600000000,
>   };
>   

Just a reminder that this conflict still exists.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

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

Hi all,

On Tue, 8 Dec 2020 11:04:13 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the v4l-dvb tree got a conflict in:
> 
>   drivers/staging/media/sunxi/cedrus/cedrus.c
> 
> between commit:
> 
>   c6e95daab1cc ("media: cedrus: Remove the MBUS quirks")
> 
> from the arm-soc tree and commits:
> 
>   503dab0b8a56 ("media: cedrus: Register all codecs as capability")
>   68b4a01f88af ("media: cedrus: Make VP8 codec as capability")
> 
> from the v4l-dvb tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/staging/media/sunxi/cedrus/cedrus.c
> index d5fca10ea5b4,18d54f9fd715..000000000000
> --- a/drivers/staging/media/sunxi/cedrus/cedrus.c
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
> @@@ -522,7 -584,11 +584,10 @@@ static const struct cedrus_variant sun5
>   
>   static const struct cedrus_variant sun50i_h6_cedrus_variant = {
>   	.capabilities	= CEDRUS_CAPABILITY_UNTILED |
> - 			  CEDRUS_CAPABILITY_H265_DEC,
> + 			  CEDRUS_CAPABILITY_MPEG2_DEC |
> + 			  CEDRUS_CAPABILITY_H264_DEC |
> + 			  CEDRUS_CAPABILITY_H265_DEC |
> + 			  CEDRUS_CAPABILITY_VP8_DEC,
>  -	.quirks		= CEDRUS_QUIRK_NO_DMA_OFFSET,
>   	.mod_rate	= 600000000,
>   };
>   

Just a reminder that this conflict still exists.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 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

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

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the v4l-dvb tree got a conflict in:

  drivers/staging/media/sunxi/cedrus/cedrus.c

between commit:

  c6e95daab1cc ("media: cedrus: Remove the MBUS quirks")

from the arm-soc tree and commits:

  503dab0b8a56 ("media: cedrus: Register all codecs as capability")
  68b4a01f88af ("media: cedrus: Make VP8 codec as capability")

from the v4l-dvb tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/staging/media/sunxi/cedrus/cedrus.c
index d5fca10ea5b4,18d54f9fd715..000000000000
--- a/drivers/staging/media/sunxi/cedrus/cedrus.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
@@@ -522,7 -584,11 +584,10 @@@ static const struct cedrus_variant sun5
  
  static const struct cedrus_variant sun50i_h6_cedrus_variant = {
  	.capabilities	= CEDRUS_CAPABILITY_UNTILED |
- 			  CEDRUS_CAPABILITY_H265_DEC,
+ 			  CEDRUS_CAPABILITY_MPEG2_DEC |
+ 			  CEDRUS_CAPABILITY_H264_DEC |
+ 			  CEDRUS_CAPABILITY_H265_DEC |
+ 			  CEDRUS_CAPABILITY_VP8_DEC,
 -	.quirks		= CEDRUS_QUIRK_NO_DMA_OFFSET,
  	.mod_rate	= 600000000,
  };
  

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the v4l-dvb tree got a conflict in:

  drivers/staging/media/sunxi/cedrus/cedrus.c

between commit:

  c6e95daab1cc ("media: cedrus: Remove the MBUS quirks")

from the arm-soc tree and commits:

  503dab0b8a56 ("media: cedrus: Register all codecs as capability")
  68b4a01f88af ("media: cedrus: Make VP8 codec as capability")

from the v4l-dvb tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/staging/media/sunxi/cedrus/cedrus.c
index d5fca10ea5b4,18d54f9fd715..000000000000
--- a/drivers/staging/media/sunxi/cedrus/cedrus.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
@@@ -522,7 -584,11 +584,10 @@@ static const struct cedrus_variant sun5
  
  static const struct cedrus_variant sun50i_h6_cedrus_variant = {
  	.capabilities	= CEDRUS_CAPABILITY_UNTILED |
- 			  CEDRUS_CAPABILITY_H265_DEC,
+ 			  CEDRUS_CAPABILITY_MPEG2_DEC |
+ 			  CEDRUS_CAPABILITY_H264_DEC |
+ 			  CEDRUS_CAPABILITY_H265_DEC |
+ 			  CEDRUS_CAPABILITY_VP8_DEC,
 -	.quirks		= CEDRUS_QUIRK_NO_DMA_OFFSET,
  	.mod_rate	= 600000000,
  };
  

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 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 v4l-dvb tree with the arm-soc tree

[Stephen Rothwell]

Hi all,

On Tue, 22 Aug 2017 10:55:34 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the v4l-dvb tree got a conflict in:
> 
>   arch/arm/configs/imx_v6_v7_defconfig
> 
> between commit:
> 
>   b834bc1c52b8 ("ARM: imx_v6_v7_defconfig: Enable staging video4linux drivers")
> 
> from the arm-soc tree and commit:
> 
>   b9e1486e0e4b ("media: rc-core: do not depend on MEDIA_SUPPORT")
> 
> from the v4l-dvb tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc arch/arm/configs/imx_v6_v7_defconfig
> index 3a48ad809731,1736813bdea7..000000000000
> --- a/arch/arm/configs/imx_v6_v7_defconfig
> +++ b/arch/arm/configs/imx_v6_v7_defconfig
> @@@ -230,9 -226,7 +230,9 @@@ CONFIG_REGULATOR_MC13892=
>   CONFIG_REGULATOR_PFUZE100=y
>   CONFIG_MEDIA_SUPPORT=y
>   CONFIG_MEDIA_CAMERA_SUPPORT=y
> - CONFIG_MEDIA_RC_SUPPORT=y
> + CONFIG_RC_CORE=y
>  +CONFIG_MEDIA_CONTROLLER=y
>  +CONFIG_VIDEO_V4L2_SUBDEV_API=y
>   CONFIG_RC_DEVICES=y
>   CONFIG_IR_GPIO_CIR=y
>   CONFIG_MEDIA_USB_SUPPORT=y

Just a reminder that this conflict still exists.

-- 
Cheers,
Stephen Rothwell

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

[Stephen Rothwell]

Hi all,

On Tue, 22 Aug 2017 10:55:34 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the v4l-dvb tree got a conflict in:
> 
>   arch/arm/configs/imx_v6_v7_defconfig
> 
> between commit:
> 
>   b834bc1c52b8 ("ARM: imx_v6_v7_defconfig: Enable staging video4linux drivers")
> 
> from the arm-soc tree and commit:
> 
>   b9e1486e0e4b ("media: rc-core: do not depend on MEDIA_SUPPORT")
> 
> from the v4l-dvb tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc arch/arm/configs/imx_v6_v7_defconfig
> index 3a48ad809731,1736813bdea7..000000000000
> --- a/arch/arm/configs/imx_v6_v7_defconfig
> +++ b/arch/arm/configs/imx_v6_v7_defconfig
> @@@ -230,9 -226,7 +230,9 @@@ CONFIG_REGULATOR_MC13892=
>   CONFIG_REGULATOR_PFUZE100=y
>   CONFIG_MEDIA_SUPPORT=y
>   CONFIG_MEDIA_CAMERA_SUPPORT=y
> - CONFIG_MEDIA_RC_SUPPORT=y
> + CONFIG_RC_CORE=y
>  +CONFIG_MEDIA_CONTROLLER=y
>  +CONFIG_VIDEO_V4L2_SUBDEV_API=y
>   CONFIG_RC_DEVICES=y
>   CONFIG_IR_GPIO_CIR=y
>   CONFIG_MEDIA_USB_SUPPORT=y

Just a reminder that this conflict still exists.

-- 
Cheers,
Stephen Rothwell

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

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the v4l-dvb tree got a conflict in:

  arch/arm/configs/imx_v6_v7_defconfig

between commit:

  b834bc1c52b8 ("ARM: imx_v6_v7_defconfig: Enable staging video4linux drivers")

from the arm-soc tree and commit:

  b9e1486e0e4b ("media: rc-core: do not depend on MEDIA_SUPPORT")

from the v4l-dvb tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm/configs/imx_v6_v7_defconfig
index 3a48ad809731,1736813bdea7..000000000000
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@@ -230,9 -226,7 +230,9 @@@ CONFIG_REGULATOR_MC13892=
  CONFIG_REGULATOR_PFUZE100=y
  CONFIG_MEDIA_SUPPORT=y
  CONFIG_MEDIA_CAMERA_SUPPORT=y
- CONFIG_MEDIA_RC_SUPPORT=y
+ CONFIG_RC_CORE=y
 +CONFIG_MEDIA_CONTROLLER=y
 +CONFIG_VIDEO_V4L2_SUBDEV_API=y
  CONFIG_RC_DEVICES=y
  CONFIG_IR_GPIO_CIR=y
  CONFIG_MEDIA_USB_SUPPORT=y

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

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the v4l-dvb tree got a conflict in:

  arch/arm/configs/imx_v6_v7_defconfig

between commit:

  b834bc1c52b8 ("ARM: imx_v6_v7_defconfig: Enable staging video4linux drivers")

from the arm-soc tree and commit:

  b9e1486e0e4b ("media: rc-core: do not depend on MEDIA_SUPPORT")

from the v4l-dvb tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm/configs/imx_v6_v7_defconfig
index 3a48ad809731,1736813bdea7..000000000000
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@@ -230,9 -226,7 +230,9 @@@ CONFIG_REGULATOR_MC13892=
  CONFIG_REGULATOR_PFUZE100=y
  CONFIG_MEDIA_SUPPORT=y
  CONFIG_MEDIA_CAMERA_SUPPORT=y
- CONFIG_MEDIA_RC_SUPPORT=y
+ CONFIG_RC_CORE=y
 +CONFIG_MEDIA_CONTROLLER=y
 +CONFIG_VIDEO_V4L2_SUBDEV_API=y
  CONFIG_RC_DEVICES=y
  CONFIG_IR_GPIO_CIR=y
  CONFIG_MEDIA_USB_SUPPORT=y

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

[Mark Brown]

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

Hi Mauro,

Today's linux-next merge of the v4l-dvb tree got a conflict in
arch/arm/mach-pxa/palmz72.c, arch/arm/mach-pxa/palmtreo.c and
arch/arm/mach-pxa/mioa701.c between commit 4c25c5d2985c1 ("ARM:
pxa: make more mach/*.h files local") from the arm-soc tree and commit a71daaa10ec2e325f ("[media] move media platform data to
linux/platform_data/media") from the v4l-dvb tree.

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

diff --cc arch/arm/mach-pxa/mioa701.c
index a315f6e3c4a6,ccfd2b63c6a4..000000000000
--- a/arch/arm/mach-pxa/mioa701.c
+++ b/arch/arm/mach-pxa/mioa701.c
@@@ -52,9 -52,9 +52,9 @@@
  #include <linux/platform_data/keypad-pxa27x.h>
  #include <linux/platform_data/video-pxafb.h>
  #include <linux/platform_data/mmc-pxamci.h>
 -#include <mach/udc.h>
 -#include <mach/pxa27x-udc.h>
 +#include "udc.h"
 +#include "pxa27x-udc.h"
- #include <linux/platform_data/camera-pxa.h>
+ #include <linux/platform_data/media/camera-pxa.h>
  #include <mach/audio.h>
  #include <mach/smemc.h>
  #include <media/soc_camera.h>
diff --cc arch/arm/mach-pxa/palmtreo.c
index b2aae54bed42,2dc56062fb7e..000000000000
--- a/arch/arm/mach-pxa/palmtreo.c
+++ b/arch/arm/mach-pxa/palmtreo.c
@@@ -43,8 -43,8 +43,8 @@@
  #include <linux/platform_data/usb-ohci-pxa27x.h>
  #include <mach/pxa2xx-regs.h>
  #include <linux/platform_data/asoc-palm27x.h>
- #include <linux/platform_data/camera-pxa.h>
+ #include <linux/platform_data/media/camera-pxa.h>
 -#include <mach/palm27x.h>
 +#include "palm27x.h"
  
  #include <sound/pxa2xx-lib.h>
  
diff --cc arch/arm/mach-pxa/palmz72.c
index abba86f3e254,e3df17a7e8d4..000000000000
--- a/arch/arm/mach-pxa/palmz72.c
+++ b/arch/arm/mach-pxa/palmz72.c
@@@ -44,12 -44,12 +44,12 @@@
  #include <linux/platform_data/video-pxafb.h>
  #include <linux/platform_data/irda-pxaficp.h>
  #include <linux/platform_data/keypad-pxa27x.h>
 -#include <mach/udc.h>
 +#include "udc.h"
  #include <linux/platform_data/asoc-palm27x.h>
 -#include <mach/palm27x.h>
 +#include "palm27x.h"
  
 -#include <mach/pm.h>
 +#include "pm.h"
- #include <linux/platform_data/camera-pxa.h>
+ #include <linux/platform_data/media/camera-pxa.h>
  
  #include <media/soc_camera.h>
  

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

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

[Mark Brown]

Hi Mauro,

Today's linux-next merge of the v4l-dvb tree got a conflict in
arch/arm/mach-pxa/palmz72.c, arch/arm/mach-pxa/palmtreo.c and
arch/arm/mach-pxa/mioa701.c between commit 4c25c5d2985c1 ("ARM:
pxa: make more mach/*.h files local") from the arm-soc tree and commit a71daaa10ec2e325f ("[media] move media platform data to
linux/platform_data/media") from the v4l-dvb tree.

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

diff --cc arch/arm/mach-pxa/mioa701.c
index a315f6e3c4a6,ccfd2b63c6a4..000000000000
--- a/arch/arm/mach-pxa/mioa701.c
+++ b/arch/arm/mach-pxa/mioa701.c
@@@ -52,9 -52,9 +52,9 @@@
  #include <linux/platform_data/keypad-pxa27x.h>
  #include <linux/platform_data/video-pxafb.h>
  #include <linux/platform_data/mmc-pxamci.h>
 -#include <mach/udc.h>
 -#include <mach/pxa27x-udc.h>
 +#include "udc.h"
 +#include "pxa27x-udc.h"
- #include <linux/platform_data/camera-pxa.h>
+ #include <linux/platform_data/media/camera-pxa.h>
  #include <mach/audio.h>
  #include <mach/smemc.h>
  #include <media/soc_camera.h>
diff --cc arch/arm/mach-pxa/palmtreo.c
index b2aae54bed42,2dc56062fb7e..000000000000
--- a/arch/arm/mach-pxa/palmtreo.c
+++ b/arch/arm/mach-pxa/palmtreo.c
@@@ -43,8 -43,8 +43,8 @@@
  #include <linux/platform_data/usb-ohci-pxa27x.h>
  #include <mach/pxa2xx-regs.h>
  #include <linux/platform_data/asoc-palm27x.h>
- #include <linux/platform_data/camera-pxa.h>
+ #include <linux/platform_data/media/camera-pxa.h>
 -#include <mach/palm27x.h>
 +#include "palm27x.h"
  
  #include <sound/pxa2xx-lib.h>
  
diff --cc arch/arm/mach-pxa/palmz72.c
index abba86f3e254,e3df17a7e8d4..000000000000
--- a/arch/arm/mach-pxa/palmz72.c
+++ b/arch/arm/mach-pxa/palmz72.c
@@@ -44,12 -44,12 +44,12 @@@
  #include <linux/platform_data/video-pxafb.h>
  #include <linux/platform_data/irda-pxaficp.h>
  #include <linux/platform_data/keypad-pxa27x.h>
 -#include <mach/udc.h>
 +#include "udc.h"
  #include <linux/platform_data/asoc-palm27x.h>
 -#include <mach/palm27x.h>
 +#include "palm27x.h"
  
 -#include <mach/pm.h>
 +#include "pm.h"
- #include <linux/platform_data/camera-pxa.h>
+ #include <linux/platform_data/media/camera-pxa.h>
  
  #include <media/soc_camera.h>
  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20151202/b60da1fc/attachment.sig>

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

[Stephen Rothwell]

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

Hi Mauro,

Today's linux-next merge of the v4l-dvb tree got a conflict in
arch/arm/boot/dts/meson.dtsi between commit 8fba96fac1c4 ("ARM: dts:
meson: add I2C controller nodes") from the arm-soc tree and commit
ac61e3787315 ("[media] ARM: dts: meson: add IR receiver node") from the
v4l-dvb 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/boot/dts/meson.dtsi
index 03bcff87bd27,6a37f15e8627..000000000000
--- a/arch/arm/boot/dts/meson.dtsi
+++ b/arch/arm/boot/dts/meson.dtsi
@@@ -114,34 -107,11 +114,41 @@@
  			status = "disabled";
  		};
  
 +		i2c_AO: i2c@c8100500 {
 +			compatible = "amlogic,meson6-i2c";
 +			reg = <0xc8100500 0x20>;
 +			interrupts = <0 92 1>;
 +			clocks = <&clk81>;
 +			#address-cells = <1>;
 +			#size-cells = <0>;
 +			status = "disabled";
 +		};
 +
 +		i2c_A: i2c@c1108500 {
 +			compatible = "amlogic,meson6-i2c";
 +			reg = <0xc1108500 0x20>;
 +			interrupts = <0 21 1>;
 +			clocks = <&clk81>;
 +			#address-cells = <1>;
 +			#size-cells = <0>;
 +			status = "disabled";
 +		};
 +
 +		i2c_B: i2c@c11087c0 {
 +			compatible = "amlogic,meson6-i2c";
 +			reg = <0xc11087c0 0x20>;
 +			interrupts = <0 128 1>;
 +			clocks = <&clk81>;
 +			#address-cells = <1>;
 +			#size-cells = <0>;
 +			status = "disabled";
 +		};
++
+ 		ir_receiver: ir-receiver@c8100480 {
+ 			compatible= "amlogic,meson6-ir";
+ 			reg = <0xc8100480 0x20>;
+ 			interrupts = <0 15 1>;
+ 			status = "disabled";
+ 		};
  	};
  }; /* end of / */

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Stephen Rothwell]

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

Hi Mauro,

Today's linux-next merge of the v4l-dvb tree got a conflict in
arch/arm/boot/dts/meson.dtsi between commit 8fba96fac1c4 ("ARM: dts:
meson: add I2C controller nodes") from the arm-soc tree and commit
ac61e3787315 ("[media] ARM: dts: meson: add IR receiver node") from the
v4l-dvb 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/boot/dts/meson.dtsi
index 03bcff87bd27,6a37f15e8627..000000000000
--- a/arch/arm/boot/dts/meson.dtsi
+++ b/arch/arm/boot/dts/meson.dtsi
@@@ -114,34 -107,11 +114,41 @@@
  			status = "disabled";
  		};
  
 +		i2c_AO: i2c@c8100500 {
 +			compatible = "amlogic,meson6-i2c";
 +			reg = <0xc8100500 0x20>;
 +			interrupts = <0 92 1>;
 +			clocks = <&clk81>;
 +			#address-cells = <1>;
 +			#size-cells = <0>;
 +			status = "disabled";
 +		};
 +
 +		i2c_A: i2c@c1108500 {
 +			compatible = "amlogic,meson6-i2c";
 +			reg = <0xc1108500 0x20>;
 +			interrupts = <0 21 1>;
 +			clocks = <&clk81>;
 +			#address-cells = <1>;
 +			#size-cells = <0>;
 +			status = "disabled";
 +		};
 +
 +		i2c_B: i2c@c11087c0 {
 +			compatible = "amlogic,meson6-i2c";
 +			reg = <0xc11087c0 0x20>;
 +			interrupts = <0 128 1>;
 +			clocks = <&clk81>;
 +			#address-cells = <1>;
 +			#size-cells = <0>;
 +			status = "disabled";
 +		};
++
+ 		ir_receiver: ir-receiver@c8100480 {
+ 			compatible= "amlogic,meson6-ir";
+ 			reg = <0xc8100480 0x20>;
+ 			interrupts = <0 15 1>;
+ 			status = "disabled";
+ 		};
  	};
  }; /* end of / */

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Stephen Rothwell]

Hi Mauro,

Today's linux-next merge of the v4l-dvb tree got a conflict in
arch/arm/boot/dts/meson.dtsi between commit 8fba96fac1c4 ("ARM: dts:
meson: add I2C controller nodes") from the arm-soc tree and commit
ac61e3787315 ("[media] ARM: dts: meson: add IR receiver node") from the
v4l-dvb tree.

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

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

diff --cc arch/arm/boot/dts/meson.dtsi
index 03bcff87bd27,6a37f15e8627..000000000000
--- a/arch/arm/boot/dts/meson.dtsi
+++ b/arch/arm/boot/dts/meson.dtsi
@@@ -114,34 -107,11 +114,41 @@@
  			status = "disabled";
  		};
  
 +		i2c_AO: i2c at c8100500 {
 +			compatible = "amlogic,meson6-i2c";
 +			reg = <0xc8100500 0x20>;
 +			interrupts = <0 92 1>;
 +			clocks = <&clk81>;
 +			#address-cells = <1>;
 +			#size-cells = <0>;
 +			status = "disabled";
 +		};
 +
 +		i2c_A: i2c at c1108500 {
 +			compatible = "amlogic,meson6-i2c";
 +			reg = <0xc1108500 0x20>;
 +			interrupts = <0 21 1>;
 +			clocks = <&clk81>;
 +			#address-cells = <1>;
 +			#size-cells = <0>;
 +			status = "disabled";
 +		};
 +
 +		i2c_B: i2c at c11087c0 {
 +			compatible = "amlogic,meson6-i2c";
 +			reg = <0xc11087c0 0x20>;
 +			interrupts = <0 128 1>;
 +			clocks = <&clk81>;
 +			#address-cells = <1>;
 +			#size-cells = <0>;
 +			status = "disabled";
 +		};
++
+ 		ir_receiver: ir-receiver at c8100480 {
+ 			compatible= "amlogic,meson6-ir";
+ 			reg = <0xc8100480 0x20>;
+ 			interrupts = <0 15 1>;
+ 			status = "disabled";
+ 		};
  	};
  }; /* end of / */
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141205/9726ffdc/attachment.sig>

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

[Stephen Rothwell]

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

Hi Mauro,

Today's linux-next merge of the v4l-dvb tree got a conflict in
arch/arm/mach-omap2/board-rx51-peripherals.c between commit
e639cd5bfc03 ("ARM: OMAP2+: Prepare to move GPMC to drivers by platform
data header") from the arm-soc tree and commit 68a3c0433077 ("[media]
ARM: OMAP2: RX-51: update si4713 platform data") from the v4l-dvb 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-rx51-peripherals.c
index e2ad48b5d9c0,ec2e4101988b..000000000000
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@@ -23,7 -23,7 +23,8 @@@
  #include <linux/regulator/machine.h>
  #include <linux/gpio.h>
  #include <linux/gpio_keys.h>
+ #include <linux/gpio/machine.h>
 +#include <linux/omap-gpmc.h>
  #include <linux/mmc/host.h>
  #include <linux/power/isp1704_charger.h>
  #include <linux/platform_data/spi-omap2-mcspi.h>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Stephen Rothwell]

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

Hi Mauro,

Today's linux-next merge of the v4l-dvb tree got a conflict in
arch/arm/mach-omap2/board-rx51-peripherals.c between commit
e639cd5bfc03 ("ARM: OMAP2+: Prepare to move GPMC to drivers by platform
data header") from the arm-soc tree and commit 68a3c0433077 ("[media]
ARM: OMAP2: RX-51: update si4713 platform data") from the v4l-dvb 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-rx51-peripherals.c
index e2ad48b5d9c0,ec2e4101988b..000000000000
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@@ -23,7 -23,7 +23,8 @@@
  #include <linux/regulator/machine.h>
  #include <linux/gpio.h>
  #include <linux/gpio_keys.h>
+ #include <linux/gpio/machine.h>
 +#include <linux/omap-gpmc.h>
  #include <linux/mmc/host.h>
  #include <linux/power/isp1704_charger.h>
  #include <linux/platform_data/spi-omap2-mcspi.h>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Stephen Rothwell]

Hi Mauro,

Today's linux-next merge of the v4l-dvb tree got a conflict in
arch/arm/mach-omap2/board-rx51-peripherals.c between commit
e639cd5bfc03 ("ARM: OMAP2+: Prepare to move GPMC to drivers by platform
data header") from the arm-soc tree and commit 68a3c0433077 ("[media]
ARM: OMAP2: RX-51: update si4713 platform data") from the v4l-dvb tree.

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

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

diff --cc arch/arm/mach-omap2/board-rx51-peripherals.c
index e2ad48b5d9c0,ec2e4101988b..000000000000
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@@ -23,7 -23,7 +23,8 @@@
  #include <linux/regulator/machine.h>
  #include <linux/gpio.h>
  #include <linux/gpio_keys.h>
+ #include <linux/gpio/machine.h>
 +#include <linux/omap-gpmc.h>
  #include <linux/mmc/host.h>
  #include <linux/power/isp1704_charger.h>
  #include <linux/platform_data/spi-omap2-mcspi.h>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141201/97d434f4/attachment.sig>

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

[Mauro Carvalho Chehab]

On 11-01-2012 14:44, Olof Johansson wrote:
> Hi,
> 
> On Wed, Jan 11, 2012 at 7:57 AM, Nicolas Ferre <nicolas.ferre@atmel.com> wrote:
>> On 01/11/2012 03:50 PM, Arnd Bergmann :
>>> On Wednesday 11 January 2012, Mauro Carvalho Chehab wrote:
>>>> What I and Guennadi agreed (http://linuxtv.org/irc/v4l/index.php?date=2012-01-05)
>>>> were to do just the reverse:
>>>>
>>>> He would be sending you one single patch with my ack, that would allow the
>>>> arm tree to be merged [1], I would wait for a few days for the arm tree to
>>>> be pulled, and then I would rebase my -next tree to remove that patch
>>>> from it.
>>>>
>>>> [1] http://git.linuxtv.org/gliakhovetski/v4l-dvb.git/commitdiff/88c6599d97b489ac543fa352159a81f60bddded7
>>>
>>> It's just not what happened. I got this series from Nicolas:
>>>
>>> 7a1834b ARM: at91: Update struct atmel_nand_data to support PMECC
>>> 9356fba ARM: at91/dma: DMA controller registering with DT support
>>> 31527e7 ARM: at91/dma: remove platform data from DMA controller
>>> 226e3aa ARM: at91: add Atmel ISI and ov2640 support on sam9m10g45 board
>>> e889a64 ARM: at91: add clock selection parameter for at91_add_device_isi()
>>> 7a13e73 media i.MX27 camera: Fix field_count handling.
>>> 166b37f media i.MX27 camera: add support for YUV420 format.
>>> 88c6599 V4L: atmel-isi: add code to enable/disable ISI_MCK clock
>>> ... (the rest of v4l at the time)
>>>
>>> and I merged it into the next/drivers2 branch, explaining that I would
>>> merge these as soon as the dependencies in v4l are merged. :(
>>>
>>>> My -next tree were never meant to be stable. It is just a patch repository
>>>> where I merge from the real development repository, in order to test them
>>>> against the hole changes. From time to time, when bad things happen
>>>> (patch conflicts, compilation breakages, requests to remove bad patches),
>>>> I just rebase it.
>>>
>>> Ok, thanks for the confirmation.
>>>
>>>> I prefer if you could just pick this patch from Guennadi's tree:
>>>>  http://git.linuxtv.org/gliakhovetski/v4l-dvb.git/commitdiff/88c6599d97b489ac543fa352159a81f60bddded7
>>>>
>>>> and add my ack on it, removing the v4l-dvb merge from yours.
>>>>
>>>> Linus seems to prefer to have the arch trees merged before the drivers
>>>> tree, with makes sense.
>>>
>>> I think it's better for you to just send everything you have right away,
>>> including the atmel-isi patch.
>>>
>>> I'll drop the remaining atmel patches from my next/drivers2 branch and let
>>> Nicolas send me a new rebased pull request for 3.4. The patches in question
>>> look simple enough, but if the developers can't get a simple dependency right
>>> after discussing it for weeks, I'd rather not take it this time.
>>
>> I am so astonished and sad about all this! I have the feeling of having
>> done exactly what Guennadi and Olof had asked me to do: What I get at
>> the end: people having a bad feeling about my work, not expected merge
>> conflicts which annoy everybody (only for a ridiculous amount of code),
>> my patches delayed and a comment saying that I cannot handle simple
>> dependency...
>> Nice result!
> 
> Personally, I don't blame you in this case, you're the victim.
> 
>> - Guennadi did not want to take SoC/board code in his tree
>> => I had to take those lines of code through at91/arm-soc breaking the
>>   patch series and allowing the introduction of an out-of-sync merge
> 
> It was actually me who said we prefer to take the board code through
> arm-soc, and given how conflict-ridden this merge window has been, I
> think that has been a good decision. Otherwise even more conflicts
> would have needed to be resolved at Linus' pulls, and while he's OK
> with doing some of them, we should still try to keep them at a
> reasonable level.
> 
>> - I built a pull request with only the SoC/board code on top of a
>>  Linus' -rc tag (yes, that was breaking compilation on certain
>>  configurations in the meantime)
>> => I was told that I should bring the v4l dependency with my branch
> 
> This is where things broke down. The one thing I told Guennadi was
> that the branch that we merge in *must not be rebased*. In hindsight,
> I should have asked him to stage a minimal topic branch with _just_
> the patches you needed, and pulled that in as the dependency instead
> of the whole v4l tree.
> 
>> - I resent a "pull request" on top of v4l branch after a discussion
>>  between Guennadi, Olof and me. The conclusion of this discussion was
>>  quite obvious:
>> http://article.gmane.org/gmane.linux.ports.arm.kernel/145196
>> => It was supposed to be the last time I moved those patches around...
> 
> Yep. The main problem is that the branch was not stable. Not your fault.
> 
>> I have understood and approved all the reasons for the requested
>> changes, of course. But for which gain?
>>
>> Ok... well, it looks like a massive incomprehension which took us time
>> and ends up by wastefulness.

Yes, unfortunately.

> If you prepare a branch with just your changes, I'll pull it in as a
> late/* branch and we can try to get it merged in for 3.3. That
> requires that Mauro gets his pull done with enough margin to get our
> late merge request sorted out and sent in though. I.e. his tree would
> need to go in soon, not next week right before the window closes.

I'm ready to send my pull request to Linus. I'll prepare the
pull request message and send it in the sequence.

Regards,
Mauro.

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

[Mauro Carvalho Chehab]

On 11-01-2012 14:44, Olof Johansson wrote:
> Hi,
> 
> On Wed, Jan 11, 2012 at 7:57 AM, Nicolas Ferre <nicolas.ferre@atmel.com> wrote:
>> On 01/11/2012 03:50 PM, Arnd Bergmann :
>>> On Wednesday 11 January 2012, Mauro Carvalho Chehab wrote:
>>>> What I and Guennadi agreed (http://linuxtv.org/irc/v4l/index.php?date=2012-01-05)
>>>> were to do just the reverse:
>>>>
>>>> He would be sending you one single patch with my ack, that would allow the
>>>> arm tree to be merged [1], I would wait for a few days for the arm tree to
>>>> be pulled, and then I would rebase my -next tree to remove that patch
>>>> from it.
>>>>
>>>> [1] http://git.linuxtv.org/gliakhovetski/v4l-dvb.git/commitdiff/88c6599d97b489ac543fa352159a81f60bddded7
>>>
>>> It's just not what happened. I got this series from Nicolas:
>>>
>>> 7a1834b ARM: at91: Update struct atmel_nand_data to support PMECC
>>> 9356fba ARM: at91/dma: DMA controller registering with DT support
>>> 31527e7 ARM: at91/dma: remove platform data from DMA controller
>>> 226e3aa ARM: at91: add Atmel ISI and ov2640 support on sam9m10g45 board
>>> e889a64 ARM: at91: add clock selection parameter for at91_add_device_isi()
>>> 7a13e73 media i.MX27 camera: Fix field_count handling.
>>> 166b37f media i.MX27 camera: add support for YUV420 format.
>>> 88c6599 V4L: atmel-isi: add code to enable/disable ISI_MCK clock
>>> ... (the rest of v4l at the time)
>>>
>>> and I merged it into the next/drivers2 branch, explaining that I would
>>> merge these as soon as the dependencies in v4l are merged. :(
>>>
>>>> My -next tree were never meant to be stable. It is just a patch repository
>>>> where I merge from the real development repository, in order to test them
>>>> against the hole changes. From time to time, when bad things happen
>>>> (patch conflicts, compilation breakages, requests to remove bad patches),
>>>> I just rebase it.
>>>
>>> Ok, thanks for the confirmation.
>>>
>>>> I prefer if you could just pick this patch from Guennadi's tree:
>>>>  http://git.linuxtv.org/gliakhovetski/v4l-dvb.git/commitdiff/88c6599d97b489ac543fa352159a81f60bddded7
>>>>
>>>> and add my ack on it, removing the v4l-dvb merge from yours.
>>>>
>>>> Linus seems to prefer to have the arch trees merged before the drivers
>>>> tree, with makes sense.
>>>
>>> I think it's better for you to just send everything you have right away,
>>> including the atmel-isi patch.
>>>
>>> I'll drop the remaining atmel patches from my next/drivers2 branch and let
>>> Nicolas send me a new rebased pull request for 3.4. The patches in question
>>> look simple enough, but if the developers can't get a simple dependency right
>>> after discussing it for weeks, I'd rather not take it this time.
>>
>> I am so astonished and sad about all this! I have the feeling of having
>> done exactly what Guennadi and Olof had asked me to do: What I get at
>> the end: people having a bad feeling about my work, not expected merge
>> conflicts which annoy everybody (only for a ridiculous amount of code),
>> my patches delayed and a comment saying that I cannot handle simple
>> dependency...
>> Nice result!
> 
> Personally, I don't blame you in this case, you're the victim.
> 
>> - Guennadi did not want to take SoC/board code in his tree
>> => I had to take those lines of code through at91/arm-soc breaking the
>>   patch series and allowing the introduction of an out-of-sync merge
> 
> It was actually me who said we prefer to take the board code through
> arm-soc, and given how conflict-ridden this merge window has been, I
> think that has been a good decision. Otherwise even more conflicts
> would have needed to be resolved at Linus' pulls, and while he's OK
> with doing some of them, we should still try to keep them at a
> reasonable level.
> 
>> - I built a pull request with only the SoC/board code on top of a
>>  Linus' -rc tag (yes, that was breaking compilation on certain
>>  configurations in the meantime)
>> => I was told that I should bring the v4l dependency with my branch
> 
> This is where things broke down. The one thing I told Guennadi was
> that the branch that we merge in *must not be rebased*. In hindsight,
> I should have asked him to stage a minimal topic branch with _just_
> the patches you needed, and pulled that in as the dependency instead
> of the whole v4l tree.
> 
>> - I resent a "pull request" on top of v4l branch after a discussion
>>  between Guennadi, Olof and me. The conclusion of this discussion was
>>  quite obvious:
>> http://article.gmane.org/gmane.linux.ports.arm.kernel/145196
>> => It was supposed to be the last time I moved those patches around...
> 
> Yep. The main problem is that the branch was not stable. Not your fault.
> 
>> I have understood and approved all the reasons for the requested
>> changes, of course. But for which gain?
>>
>> Ok... well, it looks like a massive incomprehension which took us time
>> and ends up by wastefulness.

Yes, unfortunately.

> If you prepare a branch with just your changes, I'll pull it in as a
> late/* branch and we can try to get it merged in for 3.3. That
> requires that Mauro gets his pull done with enough margin to get our
> late merge request sorted out and sent in though. I.e. his tree would
> need to go in soon, not next week right before the window closes.

I'm ready to send my pull request to Linus. I'll prepare the
pull request message and send it in the sequence.

Regards,
Mauro.

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

[Guennadi Liakhovetski]

On Wed, 11 Jan 2012, Arnd Bergmann wrote:

> My impression is that Guennadi simply didn't know what he was doing
> when he sent you a patch based on a branch that was clearly not
> stable.

I don't think I'm interested in discussing this here now. If you (or 
anyone for that matter) are interested, I can explain to you personally 
who, what and how screwed up, ok?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

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

[Guennadi Liakhovetski]

On Wed, 11 Jan 2012, Arnd Bergmann wrote:

> My impression is that Guennadi simply didn't know what he was doing
> when he sent you a patch based on a branch that was clearly not
> stable.

I don't think I'm interested in discussing this here now. If you (or 
anyone for that matter) are interested, I can explain to you personally 
who, what and how screwed up, ok?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

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

[Olof Johansson]

On Wed, Jan 11, 2012 at 8:46 AM, Arnd Bergmann <arnd@arndb.de> wrote:

> Agreed. How about if you rebase the few other (non-ISI) patches that
> I had in arm-soc onto v3.2 and send me an updated pull request so
> I can send them on? There's no reason to hold them up.

Just to clarify: The late/* branch that I was referring to in my email
would just then contain the ISI patches, the rest would be in the
above branch.


-Olof

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

[Olof Johansson]

On Wed, Jan 11, 2012 at 8:46 AM, Arnd Bergmann <arnd@arndb.de> wrote:

> Agreed. How about if you rebase the few other (non-ISI) patches that
> I had in arm-soc onto v3.2 and send me an updated pull request so
> I can send them on? There's no reason to hold them up.

Just to clarify: The late/* branch that I was referring to in my email
would just then contain the ISI patches, the rest would be in the
above branch.


-Olof

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

[Arnd Bergmann]

On Wednesday 11 January 2012, Nicolas Ferre wrote:
> I am so astonished and sad about all this! I have the feeling of having
> done exactly what Guennadi and Olof had asked me to do: What I get at
> the end: people having a bad feeling about my work, not expected merge
> conflicts which annoy everybody (only for a ridiculous amount of code),
> my patches delayed and a comment saying that I cannot handle simple
> dependency...
> Nice result!

I'm sorry for accusing you, you are right. You did exactly what was
agreed on in the mail thread, I just reread the history.

My impression is that Guennadi simply didn't know what he was doing
when he sent you a patch based on a branch that was clearly not
stable.

> - Guennadi did not want to take SoC/board code in his tree
> => I had to take those lines of code through at91/arm-soc breaking the
>    patch series and allowing the introduction of an out-of-sync merge

This was probably the first mistake. It would have been trivial
to handle all this if we had just stuck the same commit into both
trees.

> I have understood and approved all the reasons for the requested
> changes, of course. But for which gain?
> 
> Ok... well, it looks like a massive incomprehension which took us time
> and ends up by wastefulness.

Agreed. How about if you rebase the few other (non-ISI) patches that
I had in arm-soc onto v3.2 and send me an updated pull request so
I can send them on? There's no reason to hold them up.

	Arnd

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

[Arnd Bergmann]

On Wednesday 11 January 2012, Nicolas Ferre wrote:
> I am so astonished and sad about all this! I have the feeling of having
> done exactly what Guennadi and Olof had asked me to do: What I get at
> the end: people having a bad feeling about my work, not expected merge
> conflicts which annoy everybody (only for a ridiculous amount of code),
> my patches delayed and a comment saying that I cannot handle simple
> dependency...
> Nice result!

I'm sorry for accusing you, you are right. You did exactly what was
agreed on in the mail thread, I just reread the history.

My impression is that Guennadi simply didn't know what he was doing
when he sent you a patch based on a branch that was clearly not
stable.

> - Guennadi did not want to take SoC/board code in his tree
> => I had to take those lines of code through at91/arm-soc breaking the
>    patch series and allowing the introduction of an out-of-sync merge

This was probably the first mistake. It would have been trivial
to handle all this if we had just stuck the same commit into both
trees.

> I have understood and approved all the reasons for the requested
> changes, of course. But for which gain?
> 
> Ok... well, it looks like a massive incomprehension which took us time
> and ends up by wastefulness.

Agreed. How about if you rebase the few other (non-ISI) patches that
I had in arm-soc onto v3.2 and send me an updated pull request so
I can send them on? There's no reason to hold them up.

	Arnd

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

[Olof Johansson]

Hi,

On Wed, Jan 11, 2012 at 7:57 AM, Nicolas Ferre <nicolas.ferre@atmel.com> wrote:
> On 01/11/2012 03:50 PM, Arnd Bergmann :
>> On Wednesday 11 January 2012, Mauro Carvalho Chehab wrote:
>>> What I and Guennadi agreed (http://linuxtv.org/irc/v4l/index.php?date=2012-01-05)
>>> were to do just the reverse:
>>>
>>> He would be sending you one single patch with my ack, that would allow the
>>> arm tree to be merged [1], I would wait for a few days for the arm tree to
>>> be pulled, and then I would rebase my -next tree to remove that patch
>>> from it.
>>>
>>> [1] http://git.linuxtv.org/gliakhovetski/v4l-dvb.git/commitdiff/88c6599d97b489ac543fa352159a81f60bddded7
>>
>> It's just not what happened. I got this series from Nicolas:
>>
>> 7a1834b ARM: at91: Update struct atmel_nand_data to support PMECC
>> 9356fba ARM: at91/dma: DMA controller registering with DT support
>> 31527e7 ARM: at91/dma: remove platform data from DMA controller
>> 226e3aa ARM: at91: add Atmel ISI and ov2640 support on sam9m10g45 board
>> e889a64 ARM: at91: add clock selection parameter for at91_add_device_isi()
>> 7a13e73 media i.MX27 camera: Fix field_count handling.
>> 166b37f media i.MX27 camera: add support for YUV420 format.
>> 88c6599 V4L: atmel-isi: add code to enable/disable ISI_MCK clock
>> ... (the rest of v4l at the time)
>>
>> and I merged it into the next/drivers2 branch, explaining that I would
>> merge these as soon as the dependencies in v4l are merged. :(
>>
>>> My -next tree were never meant to be stable. It is just a patch repository
>>> where I merge from the real development repository, in order to test them
>>> against the hole changes. From time to time, when bad things happen
>>> (patch conflicts, compilation breakages, requests to remove bad patches),
>>> I just rebase it.
>>
>> Ok, thanks for the confirmation.
>>
>>> I prefer if you could just pick this patch from Guennadi's tree:
>>>  http://git.linuxtv.org/gliakhovetski/v4l-dvb.git/commitdiff/88c6599d97b489ac543fa352159a81f60bddded7
>>>
>>> and add my ack on it, removing the v4l-dvb merge from yours.
>>>
>>> Linus seems to prefer to have the arch trees merged before the drivers
>>> tree, with makes sense.
>>
>> I think it's better for you to just send everything you have right away,
>> including the atmel-isi patch.
>>
>> I'll drop the remaining atmel patches from my next/drivers2 branch and let
>> Nicolas send me a new rebased pull request for 3.4. The patches in question
>> look simple enough, but if the developers can't get a simple dependency right
>> after discussing it for weeks, I'd rather not take it this time.
>
> I am so astonished and sad about all this! I have the feeling of having
> done exactly what Guennadi and Olof had asked me to do: What I get at
> the end: people having a bad feeling about my work, not expected merge
> conflicts which annoy everybody (only for a ridiculous amount of code),
> my patches delayed and a comment saying that I cannot handle simple
> dependency...
> Nice result!

Personally, I don't blame you in this case, you're the victim.

> - Guennadi did not want to take SoC/board code in his tree
> => I had to take those lines of code through at91/arm-soc breaking the
>   patch series and allowing the introduction of an out-of-sync merge

It was actually me who said we prefer to take the board code through
arm-soc, and given how conflict-ridden this merge window has been, I
think that has been a good decision. Otherwise even more conflicts
would have needed to be resolved at Linus' pulls, and while he's OK
with doing some of them, we should still try to keep them at a
reasonable level.

> - I built a pull request with only the SoC/board code on top of a
>  Linus' -rc tag (yes, that was breaking compilation on certain
>  configurations in the meantime)
> => I was told that I should bring the v4l dependency with my branch

This is where things broke down. The one thing I told Guennadi was
that the branch that we merge in *must not be rebased*. In hindsight,
I should have asked him to stage a minimal topic branch with _just_
the patches you needed, and pulled that in as the dependency instead
of the whole v4l tree.

> - I resent a "pull request" on top of v4l branch after a discussion
>  between Guennadi, Olof and me. The conclusion of this discussion was
>  quite obvious:
> http://article.gmane.org/gmane.linux.ports.arm.kernel/145196
> => It was supposed to be the last time I moved those patches around...

Yep. The main problem is that the branch was not stable. Not your fault.

> I have understood and approved all the reasons for the requested
> changes, of course. But for which gain?
>
> Ok... well, it looks like a massive incomprehension which took us time
> and ends up by wastefulness.

If you prepare a branch with just your changes, I'll pull it in as a
late/* branch and we can try to get it merged in for 3.3. That
requires that Mauro gets his pull done with enough margin to get our
late merge request sorted out and sent in though. I.e. his tree would
need to go in soon, not next week right before the window closes.


-Olof

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

[Olof Johansson]

Hi,

On Wed, Jan 11, 2012 at 7:57 AM, Nicolas Ferre <nicolas.ferre@atmel.com> wrote:
> On 01/11/2012 03:50 PM, Arnd Bergmann :
>> On Wednesday 11 January 2012, Mauro Carvalho Chehab wrote:
>>> What I and Guennadi agreed (http://linuxtv.org/irc/v4l/index.php?date=2012-01-05)
>>> were to do just the reverse:
>>>
>>> He would be sending you one single patch with my ack, that would allow the
>>> arm tree to be merged [1], I would wait for a few days for the arm tree to
>>> be pulled, and then I would rebase my -next tree to remove that patch
>>> from it.
>>>
>>> [1] http://git.linuxtv.org/gliakhovetski/v4l-dvb.git/commitdiff/88c6599d97b489ac543fa352159a81f60bddded7
>>
>> It's just not what happened. I got this series from Nicolas:
>>
>> 7a1834b ARM: at91: Update struct atmel_nand_data to support PMECC
>> 9356fba ARM: at91/dma: DMA controller registering with DT support
>> 31527e7 ARM: at91/dma: remove platform data from DMA controller
>> 226e3aa ARM: at91: add Atmel ISI and ov2640 support on sam9m10g45 board
>> e889a64 ARM: at91: add clock selection parameter for at91_add_device_isi()
>> 7a13e73 media i.MX27 camera: Fix field_count handling.
>> 166b37f media i.MX27 camera: add support for YUV420 format.
>> 88c6599 V4L: atmel-isi: add code to enable/disable ISI_MCK clock
>> ... (the rest of v4l at the time)
>>
>> and I merged it into the next/drivers2 branch, explaining that I would
>> merge these as soon as the dependencies in v4l are merged. :(
>>
>>> My -next tree were never meant to be stable. It is just a patch repository
>>> where I merge from the real development repository, in order to test them
>>> against the hole changes. From time to time, when bad things happen
>>> (patch conflicts, compilation breakages, requests to remove bad patches),
>>> I just rebase it.
>>
>> Ok, thanks for the confirmation.
>>
>>> I prefer if you could just pick this patch from Guennadi's tree:
>>> ?http://git.linuxtv.org/gliakhovetski/v4l-dvb.git/commitdiff/88c6599d97b489ac543fa352159a81f60bddded7
>>>
>>> and add my ack on it, removing the v4l-dvb merge from yours.
>>>
>>> Linus seems to prefer to have the arch trees merged before the drivers
>>> tree, with makes sense.
>>
>> I think it's better for you to just send everything you have right away,
>> including the atmel-isi patch.
>>
>> I'll drop the remaining atmel patches from my next/drivers2 branch and let
>> Nicolas send me a new rebased pull request for 3.4. The patches in question
>> look simple enough, but if the developers can't get a simple dependency right
>> after discussing it for weeks, I'd rather not take it this time.
>
> I am so astonished and sad about all this! I have the feeling of having
> done exactly what Guennadi and Olof had asked me to do: What I get at
> the end: people having a bad feeling about my work, not expected merge
> conflicts which annoy everybody (only for a ridiculous amount of code),
> my patches delayed and a comment saying that I cannot handle simple
> dependency...
> Nice result!

Personally, I don't blame you in this case, you're the victim.

> - Guennadi did not want to take SoC/board code in his tree
> => I had to take those lines of code through at91/arm-soc breaking the
> ? patch series and allowing the introduction of an out-of-sync merge

It was actually me who said we prefer to take the board code through
arm-soc, and given how conflict-ridden this merge window has been, I
think that has been a good decision. Otherwise even more conflicts
would have needed to be resolved at Linus' pulls, and while he's OK
with doing some of them, we should still try to keep them at a
reasonable level.

> - I built a pull request with only the SoC/board code on top of a
> ?Linus' -rc tag (yes, that was breaking compilation on certain
> ?configurations in the meantime)
> => I was told that I should bring the v4l dependency with my branch

This is where things broke down. The one thing I told Guennadi was
that the branch that we merge in *must not be rebased*. In hindsight,
I should have asked him to stage a minimal topic branch with _just_
the patches you needed, and pulled that in as the dependency instead
of the whole v4l tree.

> - I resent a "pull request" on top of v4l branch after a discussion
> ?between Guennadi, Olof and me. The conclusion of this discussion was
> ?quite obvious:
> http://article.gmane.org/gmane.linux.ports.arm.kernel/145196
> => It was supposed to be the last time I moved those patches around...

Yep. The main problem is that the branch was not stable. Not your fault.

> I have understood and approved all the reasons for the requested
> changes, of course. But for which gain?
>
> Ok... well, it looks like a massive incomprehension which took us time
> and ends up by wastefulness.

If you prepare a branch with just your changes, I'll pull it in as a
late/* branch and we can try to get it merged in for 3.3. That
requires that Mauro gets his pull done with enough margin to get our
late merge request sorted out and sent in though. I.e. his tree would
need to go in soon, not next week right before the window closes.


-Olof

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

[Nicolas Ferre]

On 01/11/2012 03:50 PM, Arnd Bergmann :
> On Wednesday 11 January 2012, Mauro Carvalho Chehab wrote:
>> What I and Guennadi agreed (http://linuxtv.org/irc/v4l/index.php?date=2012-01-05)
>> were to do just the reverse:
>>
>> He would be sending you one single patch with my ack, that would allow the 
>> arm tree to be merged [1], I would wait for a few days for the arm tree to
>> be pulled, and then I would rebase my -next tree to remove that patch
>> from it.
>>
>> [1] http://git.linuxtv.org/gliakhovetski/v4l-dvb.git/commitdiff/88c6599d97b489ac543fa352159a81f60bddded7
> 
> It's just not what happened. I got this series from Nicolas:
> 
> 7a1834b ARM: at91: Update struct atmel_nand_data to support PMECC
> 9356fba ARM: at91/dma: DMA controller registering with DT support
> 31527e7 ARM: at91/dma: remove platform data from DMA controller
> 226e3aa ARM: at91: add Atmel ISI and ov2640 support on sam9m10g45 board
> e889a64 ARM: at91: add clock selection parameter for at91_add_device_isi()
> 7a13e73 media i.MX27 camera: Fix field_count handling.
> 166b37f media i.MX27 camera: add support for YUV420 format.
> 88c6599 V4L: atmel-isi: add code to enable/disable ISI_MCK clock
> ... (the rest of v4l at the time)
> 
> and I merged it into the next/drivers2 branch, explaining that I would
> merge these as soon as the dependencies in v4l are merged. :(
> 
>> My -next tree were never meant to be stable. It is just a patch repository
>> where I merge from the real development repository, in order to test them
>> against the hole changes. From time to time, when bad things happen
>> (patch conflicts, compilation breakages, requests to remove bad patches),
>> I just rebase it.
> 
> Ok, thanks for the confirmation.
> 
>> I prefer if you could just pick this patch from Guennadi's tree:
>>  http://git.linuxtv.org/gliakhovetski/v4l-dvb.git/commitdiff/88c6599d97b489ac543fa352159a81f60bddded7
>>
>> and add my ack on it, removing the v4l-dvb merge from yours.
>>
>> Linus seems to prefer to have the arch trees merged before the drivers
>> tree, with makes sense.
> 
> I think it's better for you to just send everything you have right away,
> including the atmel-isi patch.
> 
> I'll drop the remaining atmel patches from my next/drivers2 branch and let
> Nicolas send me a new rebased pull request for 3.4. The patches in question
> look simple enough, but if the developers can't get a simple dependency right
> after discussing it for weeks, I'd rather not take it this time.

I am so astonished and sad about all this! I have the feeling of having
done exactly what Guennadi and Olof had asked me to do: What I get at
the end: people having a bad feeling about my work, not expected merge
conflicts which annoy everybody (only for a ridiculous amount of code),
my patches delayed and a comment saying that I cannot handle simple
dependency...
Nice result!

- Guennadi did not want to take SoC/board code in his tree
=> I had to take those lines of code through at91/arm-soc breaking the
   patch series and allowing the introduction of an out-of-sync merge

- I built a pull request with only the SoC/board code on top of a
  Linus' -rc tag (yes, that was breaking compilation on certain
  configurations in the meantime)
=> I was told that I should bring the v4l dependency with my branch

- I resent a "pull request" on top of v4l branch after a discussion
  between Guennadi, Olof and me. The conclusion of this discussion was
  quite obvious:
http://article.gmane.org/gmane.linux.ports.arm.kernel/145196
=> It was supposed to be the last time I moved those patches around...

I have understood and approved all the reasons for the requested
changes, of course. But for which gain?

Ok... well, it looks like a massive incomprehension which took us time
and ends up by wastefulness.

Best regards,
-- 
Nicolas Ferre

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

[Nicolas Ferre]

On 01/11/2012 03:50 PM, Arnd Bergmann :
> On Wednesday 11 January 2012, Mauro Carvalho Chehab wrote:
>> What I and Guennadi agreed (http://linuxtv.org/irc/v4l/index.php?date=2012-01-05)
>> were to do just the reverse:
>>
>> He would be sending you one single patch with my ack, that would allow the 
>> arm tree to be merged [1], I would wait for a few days for the arm tree to
>> be pulled, and then I would rebase my -next tree to remove that patch
>> from it.
>>
>> [1] http://git.linuxtv.org/gliakhovetski/v4l-dvb.git/commitdiff/88c6599d97b489ac543fa352159a81f60bddded7
> 
> It's just not what happened. I got this series from Nicolas:
> 
> 7a1834b ARM: at91: Update struct atmel_nand_data to support PMECC
> 9356fba ARM: at91/dma: DMA controller registering with DT support
> 31527e7 ARM: at91/dma: remove platform data from DMA controller
> 226e3aa ARM: at91: add Atmel ISI and ov2640 support on sam9m10g45 board
> e889a64 ARM: at91: add clock selection parameter for at91_add_device_isi()
> 7a13e73 media i.MX27 camera: Fix field_count handling.
> 166b37f media i.MX27 camera: add support for YUV420 format.
> 88c6599 V4L: atmel-isi: add code to enable/disable ISI_MCK clock
> ... (the rest of v4l at the time)
> 
> and I merged it into the next/drivers2 branch, explaining that I would
> merge these as soon as the dependencies in v4l are merged. :(
> 
>> My -next tree were never meant to be stable. It is just a patch repository
>> where I merge from the real development repository, in order to test them
>> against the hole changes. From time to time, when bad things happen
>> (patch conflicts, compilation breakages, requests to remove bad patches),
>> I just rebase it.
> 
> Ok, thanks for the confirmation.
> 
>> I prefer if you could just pick this patch from Guennadi's tree:
>>  http://git.linuxtv.org/gliakhovetski/v4l-dvb.git/commitdiff/88c6599d97b489ac543fa352159a81f60bddded7
>>
>> and add my ack on it, removing the v4l-dvb merge from yours.
>>
>> Linus seems to prefer to have the arch trees merged before the drivers
>> tree, with makes sense.
> 
> I think it's better for you to just send everything you have right away,
> including the atmel-isi patch.
> 
> I'll drop the remaining atmel patches from my next/drivers2 branch and let
> Nicolas send me a new rebased pull request for 3.4. The patches in question
> look simple enough, but if the developers can't get a simple dependency right
> after discussing it for weeks, I'd rather not take it this time.

I am so astonished and sad about all this! I have the feeling of having
done exactly what Guennadi and Olof had asked me to do: What I get at
the end: people having a bad feeling about my work, not expected merge
conflicts which annoy everybody (only for a ridiculous amount of code),
my patches delayed and a comment saying that I cannot handle simple
dependency...
Nice result!

- Guennadi did not want to take SoC/board code in his tree
=> I had to take those lines of code through at91/arm-soc breaking the
   patch series and allowing the introduction of an out-of-sync merge

- I built a pull request with only the SoC/board code on top of a
  Linus' -rc tag (yes, that was breaking compilation on certain
  configurations in the meantime)
=> I was told that I should bring the v4l dependency with my branch

- I resent a "pull request" on top of v4l branch after a discussion
  between Guennadi, Olof and me. The conclusion of this discussion was
  quite obvious:
http://article.gmane.org/gmane.linux.ports.arm.kernel/145196
=> It was supposed to be the last time I moved those patches around...

I have understood and approved all the reasons for the requested
changes, of course. But for which gain?

Ok... well, it looks like a massive incomprehension which took us time
and ends up by wastefulness.

Best regards,
-- 
Nicolas Ferre

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

[Olof Johansson]

Hi,

On Wed, Jan 11, 2012 at 6:50 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> I'll drop the remaining atmel patches from my next/drivers2 branch and let
> Nicolas send me a new rebased pull request for 3.4. The patches in question
> look simple enough, but if the developers can't get a simple dependency right
> after discussing it for weeks, I'd rather not take it this time.

Sounds good to me.


-Olof

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

[Olof Johansson]

Hi,

On Wed, Jan 11, 2012 at 6:50 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> I'll drop the remaining atmel patches from my next/drivers2 branch and let
> Nicolas send me a new rebased pull request for 3.4. The patches in question
> look simple enough, but if the developers can't get a simple dependency right
> after discussing it for weeks, I'd rather not take it this time.

Sounds good to me.


-Olof

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

[Arnd Bergmann]

On Wednesday 11 January 2012, Mauro Carvalho Chehab wrote:
> What I and Guennadi agreed (http://linuxtv.org/irc/v4l/index.php?date=2012-01-05)
> were to do just the reverse:
> 
> He would be sending you one single patch with my ack, that would allow the 
> arm tree to be merged [1], I would wait for a few days for the arm tree to
> be pulled, and then I would rebase my -next tree to remove that patch
> from it.
> 
> [1] http://git.linuxtv.org/gliakhovetski/v4l-dvb.git/commitdiff/88c6599d97b489ac543fa352159a81f60bddded7

It's just not what happened. I got this series from Nicolas:

7a1834b ARM: at91: Update struct atmel_nand_data to support PMECC
9356fba ARM: at91/dma: DMA controller registering with DT support
31527e7 ARM: at91/dma: remove platform data from DMA controller
226e3aa ARM: at91: add Atmel ISI and ov2640 support on sam9m10g45 board
e889a64 ARM: at91: add clock selection parameter for at91_add_device_isi()
7a13e73 media i.MX27 camera: Fix field_count handling.
166b37f media i.MX27 camera: add support for YUV420 format.
88c6599 V4L: atmel-isi: add code to enable/disable ISI_MCK clock
... (the rest of v4l at the time)

and I merged it into the next/drivers2 branch, explaining that I would
merge these as soon as the dependencies in v4l are merged. :(

> My -next tree were never meant to be stable. It is just a patch repository
> where I merge from the real development repository, in order to test them
> against the hole changes. From time to time, when bad things happen
> (patch conflicts, compilation breakages, requests to remove bad patches),
> I just rebase it.

Ok, thanks for the confirmation.

> I prefer if you could just pick this patch from Guennadi's tree:
>  http://git.linuxtv.org/gliakhovetski/v4l-dvb.git/commitdiff/88c6599d97b489ac543fa352159a81f60bddded7
>
> and add my ack on it, removing the v4l-dvb merge from yours.
>
> Linus seems to prefer to have the arch trees merged before the drivers
> tree, with makes sense.

I think it's better for you to just send everything you have right away,
including the atmel-isi patch.

I'll drop the remaining atmel patches from my next/drivers2 branch and let
Nicolas send me a new rebased pull request for 3.4. The patches in question
look simple enough, but if the developers can't get a simple dependency right
after discussing it for weeks, I'd rather not take it this time.

	Arnd

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

[Arnd Bergmann]

On Wednesday 11 January 2012, Mauro Carvalho Chehab wrote:
> What I and Guennadi agreed (http://linuxtv.org/irc/v4l/index.php?date=2012-01-05)
> were to do just the reverse:
> 
> He would be sending you one single patch with my ack, that would allow the 
> arm tree to be merged [1], I would wait for a few days for the arm tree to
> be pulled, and then I would rebase my -next tree to remove that patch
> from it.
> 
> [1] http://git.linuxtv.org/gliakhovetski/v4l-dvb.git/commitdiff/88c6599d97b489ac543fa352159a81f60bddded7

It's just not what happened. I got this series from Nicolas:

7a1834b ARM: at91: Update struct atmel_nand_data to support PMECC
9356fba ARM: at91/dma: DMA controller registering with DT support
31527e7 ARM: at91/dma: remove platform data from DMA controller
226e3aa ARM: at91: add Atmel ISI and ov2640 support on sam9m10g45 board
e889a64 ARM: at91: add clock selection parameter for at91_add_device_isi()
7a13e73 media i.MX27 camera: Fix field_count handling.
166b37f media i.MX27 camera: add support for YUV420 format.
88c6599 V4L: atmel-isi: add code to enable/disable ISI_MCK clock
... (the rest of v4l at the time)

and I merged it into the next/drivers2 branch, explaining that I would
merge these as soon as the dependencies in v4l are merged. :(

> My -next tree were never meant to be stable. It is just a patch repository
> where I merge from the real development repository, in order to test them
> against the hole changes. From time to time, when bad things happen
> (patch conflicts, compilation breakages, requests to remove bad patches),
> I just rebase it.

Ok, thanks for the confirmation.

> I prefer if you could just pick this patch from Guennadi's tree:
>  http://git.linuxtv.org/gliakhovetski/v4l-dvb.git/commitdiff/88c6599d97b489ac543fa352159a81f60bddded7
>
> and add my ack on it, removing the v4l-dvb merge from yours.
>
> Linus seems to prefer to have the arch trees merged before the drivers
> tree, with makes sense.

I think it's better for you to just send everything you have right away,
including the atmel-isi patch.

I'll drop the remaining atmel patches from my next/drivers2 branch and let
Nicolas send me a new rebased pull request for 3.4. The patches in question
look simple enough, but if the developers can't get a simple dependency right
after discussing it for weeks, I'd rather not take it this time.

	Arnd

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

[Mauro Carvalho Chehab]

On 11-01-2012 06:36, Guennadi Liakhovetski wrote:
> On Tue, 10 Jan 2012, Olof Johansson wrote:
> 
>> On Tue, Jan 10, 2012 at 6:31 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>> Hi Mauro,
>>>
>>> Today's linux-next merge of the v4l-dvb tree got conflicts in a large
>>> number of files between commits from the arm-soc tree and commits from the
>>> v4l-dvb tree.  You have rebased the v4l-dvb tree onto v3.2 while the
>>> arm-soc tree had merged a previous version. you have then added a lot
>>> more commits on top of the result - which produces all the conflicts.  :-(
>>>
>>> This is exactly the sort of pain I alluded to when I first noted that the
>>> v4l-dvb tree had been merged into the arm-soc tree ...
>>
>> We do this every now and then though, it's not an issue as long as
>> nothing stupid is done with the dependent branch at the other end.
>> I.e. if it's actually a stable branch (which we got promised that it
>> was).
>>
>> So, why was the whole v4l tree rebased? Guennadi, you said it was
>> going to be a stable branch? What happened?
> 
> Sorry, I don't think I _promised_ anything, I even don't think I said 
> anything at all about the stability of that branch. On the contrary - I 
> suggested you to only take _one_ patch, about which we knew, that some ARM 
> patches depended upon, for which I've got Mauro's ack. This has been done 
> with the sole purpose for you to avoid any dependencies. Instead you 
> decided to pull the whole branch.

What I and Guennadi agreed (http://linuxtv.org/irc/v4l/index.php?date=2012-01-05)
were to do just the reverse:

He would be sending you one single patch with my ack, that would allow the 
arm tree to be merged [1], I would wait for a few days for the arm tree to
be pulled, and then I would rebase my -next tree to remove that patch
from it.

[1] http://git.linuxtv.org/gliakhovetski/v4l-dvb.git/commitdiff/88c6599d97b489ac543fa352159a81f60bddded7

My -next tree were never meant to be stable. It is just a patch repository
where I merge from the real development repository, in order to test them
against the hole changes. From time to time, when bad things happen
(patch conflicts, compilation breakages, requests to remove bad patches),
I just rebase it.

The media stable tree is stored elsewhere, but it contains the sort of patches
that Linus once asked me to not send him: merge patches from upstream
that are sometimes needed, due to some conflict dependencies. This time,
there are two of such patches inside my tree. That's a second reason
for me to rebase.

>>> Not happy.
>>
>> No kidding.  Mauro, can you undo your rebase or should I remove the
>> dependent branch (and the at91 branch that needs it) from arm-soc
>> instead?

I prefer if you could just pick this patch from Guennadi's tree:
 http://git.linuxtv.org/gliakhovetski/v4l-dvb.git/commitdiff/88c6599d97b489ac543fa352159a81f60bddded7

and add my ack on it, removing the v4l-dvb merge from yours.

Linus seems to prefer to have the arch trees merged before the drivers
tree, with makes sense.

Regards,
Mauro
> 
> Thanks
> Guennadi
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-next" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Mauro Carvalho Chehab]

On 11-01-2012 06:36, Guennadi Liakhovetski wrote:
> On Tue, 10 Jan 2012, Olof Johansson wrote:
> 
>> On Tue, Jan 10, 2012 at 6:31 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>> Hi Mauro,
>>>
>>> Today's linux-next merge of the v4l-dvb tree got conflicts in a large
>>> number of files between commits from the arm-soc tree and commits from the
>>> v4l-dvb tree.  You have rebased the v4l-dvb tree onto v3.2 while the
>>> arm-soc tree had merged a previous version. you have then added a lot
>>> more commits on top of the result - which produces all the conflicts.  :-(
>>>
>>> This is exactly the sort of pain I alluded to when I first noted that the
>>> v4l-dvb tree had been merged into the arm-soc tree ...
>>
>> We do this every now and then though, it's not an issue as long as
>> nothing stupid is done with the dependent branch at the other end.
>> I.e. if it's actually a stable branch (which we got promised that it
>> was).
>>
>> So, why was the whole v4l tree rebased? Guennadi, you said it was
>> going to be a stable branch? What happened?
> 
> Sorry, I don't think I _promised_ anything, I even don't think I said 
> anything at all about the stability of that branch. On the contrary - I 
> suggested you to only take _one_ patch, about which we knew, that some ARM 
> patches depended upon, for which I've got Mauro's ack. This has been done 
> with the sole purpose for you to avoid any dependencies. Instead you 
> decided to pull the whole branch.

What I and Guennadi agreed (http://linuxtv.org/irc/v4l/index.php?date=2012-01-05)
were to do just the reverse:

He would be sending you one single patch with my ack, that would allow the 
arm tree to be merged [1], I would wait for a few days for the arm tree to
be pulled, and then I would rebase my -next tree to remove that patch
from it.

[1] http://git.linuxtv.org/gliakhovetski/v4l-dvb.git/commitdiff/88c6599d97b489ac543fa352159a81f60bddded7

My -next tree were never meant to be stable. It is just a patch repository
where I merge from the real development repository, in order to test them
against the hole changes. From time to time, when bad things happen
(patch conflicts, compilation breakages, requests to remove bad patches),
I just rebase it.

The media stable tree is stored elsewhere, but it contains the sort of patches
that Linus once asked me to not send him: merge patches from upstream
that are sometimes needed, due to some conflict dependencies. This time,
there are two of such patches inside my tree. That's a second reason
for me to rebase.

>>> Not happy.
>>
>> No kidding.  Mauro, can you undo your rebase or should I remove the
>> dependent branch (and the at91 branch that needs it) from arm-soc
>> instead?

I prefer if you could just pick this patch from Guennadi's tree:
 http://git.linuxtv.org/gliakhovetski/v4l-dvb.git/commitdiff/88c6599d97b489ac543fa352159a81f60bddded7

and add my ack on it, removing the v4l-dvb merge from yours.

Linus seems to prefer to have the arch trees merged before the drivers
tree, with makes sense.

Regards,
Mauro
> 
> Thanks
> Guennadi
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-next" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Guennadi Liakhovetski]

On Tue, 10 Jan 2012, Olof Johansson wrote:

> On Tue, Jan 10, 2012 at 6:31 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > Hi Mauro,
> >
> > Today's linux-next merge of the v4l-dvb tree got conflicts in a large
> > number of files between commits from the arm-soc tree and commits from the
> > v4l-dvb tree.  You have rebased the v4l-dvb tree onto v3.2 while the
> > arm-soc tree had merged a previous version. you have then added a lot
> > more commits on top of the result - which produces all the conflicts.  :-(
> >
> > This is exactly the sort of pain I alluded to when I first noted that the
> > v4l-dvb tree had been merged into the arm-soc tree ...
> 
> We do this every now and then though, it's not an issue as long as
> nothing stupid is done with the dependent branch at the other end.
> I.e. if it's actually a stable branch (which we got promised that it
> was).
> 
> So, why was the whole v4l tree rebased? Guennadi, you said it was
> going to be a stable branch? What happened?

Sorry, I don't think I _promised_ anything, I even don't think I said 
anything at all about the stability of that branch. On the contrary - I 
suggested you to only take _one_ patch, about which we knew, that some ARM 
patches depended upon, for which I've got Mauro's ack. This has been done 
with the sole purpose for you to avoid any dependencies. Instead you 
decided to pull the whole branch.

> > Not happy.
> 
> No kidding.  Mauro, can you undo your rebase or should I remove the
> dependent branch (and the at91 branch that needs it) from arm-soc
> instead?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

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

[Guennadi Liakhovetski]

On Tue, 10 Jan 2012, Olof Johansson wrote:

> On Tue, Jan 10, 2012 at 6:31 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > Hi Mauro,
> >
> > Today's linux-next merge of the v4l-dvb tree got conflicts in a large
> > number of files between commits from the arm-soc tree and commits from the
> > v4l-dvb tree. ?You have rebased the v4l-dvb tree onto v3.2 while the
> > arm-soc tree had merged a previous version. you have then added a lot
> > more commits on top of the result - which produces all the conflicts. ?:-(
> >
> > This is exactly the sort of pain I alluded to when I first noted that the
> > v4l-dvb tree had been merged into the arm-soc tree ...
> 
> We do this every now and then though, it's not an issue as long as
> nothing stupid is done with the dependent branch at the other end.
> I.e. if it's actually a stable branch (which we got promised that it
> was).
> 
> So, why was the whole v4l tree rebased? Guennadi, you said it was
> going to be a stable branch? What happened?

Sorry, I don't think I _promised_ anything, I even don't think I said 
anything at all about the stability of that branch. On the contrary - I 
suggested you to only take _one_ patch, about which we knew, that some ARM 
patches depended upon, for which I've got Mauro's ack. This has been done 
with the sole purpose for you to avoid any dependencies. Instead you 
decided to pull the whole branch.

> > Not happy.
> 
> No kidding.  Mauro, can you undo your rebase or should I remove the
> dependent branch (and the at91 branch that needs it) from arm-soc
> instead?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

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

[Olof Johansson]

On Tue, Jan 10, 2012 at 6:31 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Mauro,
>
> Today's linux-next merge of the v4l-dvb tree got conflicts in a large
> number of files between commits from the arm-soc tree and commits from the
> v4l-dvb tree.  You have rebased the v4l-dvb tree onto v3.2 while the
> arm-soc tree had merged a previous version. you have then added a lot
> more commits on top of the result - which produces all the conflicts.  :-(
>
> This is exactly the sort of pain I alluded to when I first noted that the
> v4l-dvb tree had been merged into the arm-soc tree ...

We do this every now and then though, it's not an issue as long as
nothing stupid is done with the dependent branch at the other end.
I.e. if it's actually a stable branch (which we got promised that it
was).

So, why was the whole v4l tree rebased? Guennadi, you said it was
going to be a stable branch? What happened?

> Not happy.

No kidding.  Mauro, can you undo your rebase or should I remove the
dependent branch (and the at91 branch that needs it) from arm-soc
instead?


-Olof

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

[Olof Johansson]

On Tue, Jan 10, 2012 at 6:31 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Mauro,
>
> Today's linux-next merge of the v4l-dvb tree got conflicts in a large
> number of files between commits from the arm-soc tree and commits from the
> v4l-dvb tree. ?You have rebased the v4l-dvb tree onto v3.2 while the
> arm-soc tree had merged a previous version. you have then added a lot
> more commits on top of the result - which produces all the conflicts. ?:-(
>
> This is exactly the sort of pain I alluded to when I first noted that the
> v4l-dvb tree had been merged into the arm-soc tree ...

We do this every now and then though, it's not an issue as long as
nothing stupid is done with the dependent branch at the other end.
I.e. if it's actually a stable branch (which we got promised that it
was).

So, why was the whole v4l tree rebased? Guennadi, you said it was
going to be a stable branch? What happened?

> Not happy.

No kidding.  Mauro, can you undo your rebase or should I remove the
dependent branch (and the at91 branch that needs it) from arm-soc
instead?


-Olof

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

[Stephen Rothwell]

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

Hi Mauro,

Today's linux-next merge of the v4l-dvb tree got conflicts in a large
number of files between commits from the arm-soc tree and commits from the
v4l-dvb tree.  You have rebased the v4l-dvb tree onto v3.2 while the
arm-soc tree had merged a previous version. you have then added a lot
more commits on top of the result - which produces all the conflicts.  :-(

This is exactly the sort of pain I alluded to when I first noted that the
v4l-dvb tree had been merged into the arm-soc tree ...

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

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

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

[Stephen Rothwell]

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

Hi Mauro,

Today's linux-next merge of the v4l-dvb tree got conflicts in a large
number of files between commits from the arm-soc tree and commits from the
v4l-dvb tree.  You have rebased the v4l-dvb tree onto v3.2 while the
arm-soc tree had merged a previous version. you have then added a lot
more commits on top of the result - which produces all the conflicts.  :-(

This is exactly the sort of pain I alluded to when I first noted that the
v4l-dvb tree had been merged into the arm-soc tree ...

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

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

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

[Stephen Rothwell]

Hi Mauro,

Today's linux-next merge of the v4l-dvb tree got conflicts in a large
number of files between commits from the arm-soc tree and commits from the
v4l-dvb tree.  You have rebased the v4l-dvb tree onto v3.2 while the
arm-soc tree had merged a previous version. you have then added a lot
more commits on top of the result - which produces all the conflicts.  :-(

This is exactly the sort of pain I alluded to when I first noted that the
v4l-dvb tree had been merged into the arm-soc tree ...

Not happy.
-- 
Cheers,
Stephen Rothwell                    sfr at canb.auug.org.au
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120111/3b0aa678/attachment.sig>