linux-next: manual merge of the sound tree with the arm tree

linux-next: manual merge of the sound tree with the arm tree

[Stephen Rothwell]

Hi Takashi,

Today's linux-next merge of the sound tree got a conflict in
arch/arm/mach-ep93xx/clock.c between commit
5c6649e3c1511b183f12d2e884d2c172fe9001e0 ("ARM: AMBA: Add pclk definition
for platforms using primecells") from the arm tree and commit
ed67ea82c0d9a163458dc6a69a7a3123db1a8b3b ("EP93xx: Add i2s core support")
from the sound tree.

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

diff --cc arch/arm/mach-ep93xx/clock.c
index d40826a,8031624..0000000
--- a/arch/arm/mach-ep93xx/clock.c
+++ b/arch/arm/mach-ep93xx/clock.c
@@@ -43,9 -43,9 +43,11 @@@ static unsigned long get_uart_rate(stru
  
  static int set_keytchclk_rate(struct clk *clk, unsigned long rate);
  static int set_div_rate(struct clk *clk, unsigned long rate);
+ static int set_i2s_sclk_rate(struct clk *clk, unsigned long rate);
+ static int set_i2s_lrclk_rate(struct clk *clk, unsigned long rate);
  
 +static struct clk dummy_apb_pclk;
 +
  static struct clk clk_xtali = {
  	.rate		= EP93XX_EXT_CLK_RATE,
  };

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

[Mark Brown]

On Mon, Jul 19, 2010 at 11:00:54AM +1000, Stephen Rothwell wrote:

> Today's linux-next merge of the sound tree got a conflict in
> arch/arm/mach-ep93xx/clock.c between commit
> 5c6649e3c1511b183f12d2e884d2c172fe9001e0 ("ARM: AMBA: Add pclk definition
> for platforms using primecells") from the arm tree and commit
> ed67ea82c0d9a163458dc6a69a7a3123db1a8b3b ("EP93xx: Add i2s core support")
> from the sound tree.

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

Ryan, can you investigate where (if anywhere is good) the best place to
carry the merge fixup is please?

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

[Ryan Mallon]

On 07/20/2010 09:03 PM, Mark Brown wrote:
> On Mon, Jul 19, 2010 at 11:00:54AM +1000, Stephen Rothwell wrote:
> 
>> Today's linux-next merge of the sound tree got a conflict in
>> arch/arm/mach-ep93xx/clock.c between commit
>> 5c6649e3c1511b183f12d2e884d2c172fe9001e0 ("ARM: AMBA: Add pclk definition
>> for platforms using primecells") from the arm tree and commit
>> ed67ea82c0d9a163458dc6a69a7a3123db1a8b3b ("EP93xx: Add i2s core support")
>> from the sound tree.
> 
>> Just overlapping additions.  I fixed it up (see below) and can carry the
>> fix as necessary.
> 
> Ryan, can you investigate where (if anywhere is good) the best place to
> carry the merge fixup is please?

The fix is fine. I don't really know much about how merge conflicts are
handled across trees, but I would think that it is probably easiest if
Stephen carries it.

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan@bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934

linux-next: manual merge of the sound tree with the arm tree

[Stephen Rothwell]

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

Hi Takashi,

Today's linux-next merge of the sound tree got a conflict in
arch/arm/mach-ep93xx/clock.c between commit
a99b53f80962ed98f4b598dc22f8c030b5dae55a ("ARM: AMBA: Add pclk support to
AMBA bus infrastructure") from the arm tree and commit
ed67ea82c0d9a163458dc6a69a7a3123db1a8b3b ("EP93xx: Add i2s core support")
from the sound tree.

Just context changes.  I fixed it up (it was just a blank line) and can
carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

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

[Takashi Iwai]

At Thu, 22 Jul 2010 11:28:31 +1000,
Stephen Rothwell wrote:
> 
> Hi Takashi,
> 
> Today's linux-next merge of the sound tree got a conflict in
> arch/arm/mach-ep93xx/clock.c between commit
> a99b53f80962ed98f4b598dc22f8c030b5dae55a ("ARM: AMBA: Add pclk support to
> AMBA bus infrastructure") from the arm tree and commit
> ed67ea82c0d9a163458dc6a69a7a3123db1a8b3b ("EP93xx: Add i2s core support")
> from the sound tree.
> 
> Just context changes.  I fixed it up (it was just a blank line) and can
> carry the fix as necessary.

Thanks!


Takashi

linux-next: manual merge of the sound tree with the arm tree

[Stephen Rothwell]

Hi Takashi,

Today's linux-next merge of the sound tree got a conflict in
arch/arm/mach-shark/include/mach/io.h between commit
eab184c2362567f2b2e951b7bd0e0d353a7e5091 ("[ARM] 5363/1: Shark cleanup
and new defconfig") from the arm tree and commit
8150bc886be5ce3cc301a2baca1fcf2cf7bd7f39 ("S3C24XX: Move and update IIS
headers") from the sound tree.

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

diff --cc arch/arm/mach-shark/include/mach/io.h
index 9ccbcec,8ca7d7f..0000000
--- a/arch/arm/mach-shark/include/mach/io.h
+++ b/arch/arm/mach-shark/include/mach/io.h
@@@ -11,10 -11,10 +11,10 @@@
  #ifndef __ASM_ARM_ARCH_IO_H
  #define __ASM_ARM_ARCH_IO_H
  
 -#define PCIO_BASE	0xe0000000
 -#define IO_SPACE_LIMIT	0xffffffff
 +#define IO_SPACE_LIMIT 0xffffffff
  
- #define __io(a)                 ((void __iomem *)(0xe0000000 + (a)))
 -#define __io(a)		__typesafe_io(PCIO_BASE + (a))
 -#define __mem_pci(addr)	(addr)
++#define __io(a)		__typesafe_io(0xe0000000 + (a))
 +
 +#define __mem_pci(addr) (addr)
  
  #endif

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

[Mark Brown]

On Tue, Mar 10, 2009 at 02:45:28PM +1100, Stephen Rothwell wrote:

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

I've pushed a patch which should do the equivalent thing to Takashi, it
should hopefully show up in -next soon via his tree.

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

[Stephen Rothwell]

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

Hi Mark,

On Tue, 10 Mar 2009 20:04:37 +0000 Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
>
> On Tue, Mar 10, 2009 at 02:45:28PM +1100, Stephen Rothwell wrote:
> 
> > I fixed it up (see below) and can carry the fix as necessary.
> 
> I've pushed a patch which should do the equivalent thing to Takashi, it
> should hopefully show up in -next soon via his tree.

Thanks.

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

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

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

[Takashi Iwai]

At Wed, 11 Mar 2009 11:41:47 +1100,
Stephen Rothwell wrote:
> 
> Hi Mark,
> 
> On Tue, 10 Mar 2009 20:04:37 +0000 Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
> >
> > On Tue, Mar 10, 2009 at 02:45:28PM +1100, Stephen Rothwell wrote:
> > 
> > > I fixed it up (see below) and can carry the fix as necessary.
> > 
> > I've pushed a patch which should do the equivalent thing to Takashi, it
> > should hopefully show up in -next soon via his tree.
> 
> Thanks.

I pulled and pushed out right now.  Hopefully it's not too late.


thanks,

Takashi

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

[Russell King]

On Tue, Mar 10, 2009 at 02:45:28PM +1100, Stephen Rothwell wrote:
> Hi Takashi,
> 
> Today's linux-next merge of the sound tree got a conflict in
> arch/arm/mach-shark/include/mach/io.h between commit
> eab184c2362567f2b2e951b7bd0e0d353a7e5091 ("[ARM] 5363/1: Shark cleanup
> and new defconfig") from the arm tree and commit
> 8150bc886be5ce3cc301a2baca1fcf2cf7bd7f39 ("S3C24XX: Move and update IIS
> headers") from the sound tree.
> 
> I fixed it up (see below) and can carry the fix as necessary.

NAK to this patch.

The greater concern is WTF are cleanup patches for the ARM architecture
going via the sound tree.  Especially patches which I have concerns about.

> --- a/arch/arm/mach-shark/include/mach/io.h
> +++ b/arch/arm/mach-shark/include/mach/io.h
> @@@ -11,10 -11,10 +11,10 @@@
>   #ifndef __ASM_ARM_ARCH_IO_H
>   #define __ASM_ARM_ARCH_IO_H
>   
>  -#define PCIO_BASE	0xe0000000
>  -#define IO_SPACE_LIMIT	0xffffffff
>  +#define IO_SPACE_LIMIT 0xffffffff
>   
> - #define __io(a)                 ((void __iomem *)(0xe0000000 + (a)))
>  -#define __io(a)		__typesafe_io(PCIO_BASE + (a))
>  -#define __mem_pci(addr)	(addr)
> ++#define __io(a)		__typesafe_io(0xe0000000 + (a))

Do not use __typesafe_io() with the addition here without first ensuring
that you've investigated whether it causes the compiler to mis-optimise
the code.

Takashi - please remove all such patches from the sound tree.  They
should not be in there.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

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

[Takashi Iwai]

At Wed, 11 Mar 2009 08:52:54 +0000,
Russell King wrote:
> 
> On Tue, Mar 10, 2009 at 02:45:28PM +1100, Stephen Rothwell wrote:
> > Hi Takashi,
> > 
> > Today's linux-next merge of the sound tree got a conflict in
> > arch/arm/mach-shark/include/mach/io.h between commit
> > eab184c2362567f2b2e951b7bd0e0d353a7e5091 ("[ARM] 5363/1: Shark cleanup
> > and new defconfig") from the arm tree and commit
> > 8150bc886be5ce3cc301a2baca1fcf2cf7bd7f39 ("S3C24XX: Move and update IIS
> > headers") from the sound tree.
> > 
> > I fixed it up (see below) and can carry the fix as necessary.
> 
> NAK to this patch.
> 
> The greater concern is WTF are cleanup patches for the ARM architecture
> going via the sound tree.  Especially patches which I have concerns about.
> 
> > --- a/arch/arm/mach-shark/include/mach/io.h
> > +++ b/arch/arm/mach-shark/include/mach/io.h
> > @@@ -11,10 -11,10 +11,10 @@@
> >   #ifndef __ASM_ARM_ARCH_IO_H
> >   #define __ASM_ARM_ARCH_IO_H
> >   
> >  -#define PCIO_BASE	0xe0000000
> >  -#define IO_SPACE_LIMIT	0xffffffff
> >  +#define IO_SPACE_LIMIT 0xffffffff
> >   
> > - #define __io(a)                 ((void __iomem *)(0xe0000000 + (a)))
> >  -#define __io(a)		__typesafe_io(PCIO_BASE + (a))
> >  -#define __mem_pci(addr)	(addr)
> > ++#define __io(a)		__typesafe_io(0xe0000000 + (a))
> 
> Do not use __typesafe_io() with the addition here without first ensuring
> that you've investigated whether it causes the compiler to mis-optimise
> the code.

Hrm, is that particular change also in ARM tree, no?  Judging from the
conflict-diff above, it looks like the patch just follows that...

> Takashi - please remove all such patches from the sound tree.  They
> should not be in there.

Oh, I thought Mark already sent you Ben's patches.
Sorry if it wasn't done yet.

Basically it's two patches to create a branch to move and update IIS
and audio.h headers.  Since some drivers require these changes, they
have to be in the sound tree, too.  Otherwise the tree gets
inconsistent and can't be built.

The relevant changes are in another branch (s3c-iis-header) of asoc
tree so that it can be easily pulled to another tree:
   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git s3c-iis-header

So, if you can pull these changes above into your GIT tree simply via
"git pull", everything will settle down (as both trees share the same
GIT objects).

Please let me know if any better solution comes up.


thanks,

Takashi

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

[Russell King]

On Wed, Mar 11, 2009 at 10:18:40AM +0100, Takashi Iwai wrote:
> At Wed, 11 Mar 2009 08:52:54 +0000,
> Russell King wrote:
> > 
> > On Tue, Mar 10, 2009 at 02:45:28PM +1100, Stephen Rothwell wrote:
> > > Hi Takashi,
> > > 
> > > Today's linux-next merge of the sound tree got a conflict in
> > > arch/arm/mach-shark/include/mach/io.h between commit
> > > eab184c2362567f2b2e951b7bd0e0d353a7e5091 ("[ARM] 5363/1: Shark cleanup
> > > and new defconfig") from the arm tree and commit
> > > 8150bc886be5ce3cc301a2baca1fcf2cf7bd7f39 ("S3C24XX: Move and update IIS
> > > headers") from the sound tree.
> > > 
> > > I fixed it up (see below) and can carry the fix as necessary.
> > 
> > NAK to this patch.
> > 
> > The greater concern is WTF are cleanup patches for the ARM architecture
> > going via the sound tree.  Especially patches which I have concerns about.
> > 
> > > --- a/arch/arm/mach-shark/include/mach/io.h
> > > +++ b/arch/arm/mach-shark/include/mach/io.h
> > > @@@ -11,10 -11,10 +11,10 @@@
> > >   #ifndef __ASM_ARM_ARCH_IO_H
> > >   #define __ASM_ARM_ARCH_IO_H
> > >   
> > >  -#define PCIO_BASE	0xe0000000
> > >  -#define IO_SPACE_LIMIT	0xffffffff
> > >  +#define IO_SPACE_LIMIT 0xffffffff
> > >   
> > > - #define __io(a)                 ((void __iomem *)(0xe0000000 + (a)))
> > >  -#define __io(a)		__typesafe_io(PCIO_BASE + (a))
> > >  -#define __mem_pci(addr)	(addr)
> > > ++#define __io(a)		__typesafe_io(0xe0000000 + (a))
> > 
> > Do not use __typesafe_io() with the addition here without first ensuring
> > that you've investigated whether it causes the compiler to mis-optimise
> > the code.
> 
> Hrm, is that particular change also in ARM tree, no?  Judging from the
> conflict-diff above, it looks like the patch just follows that...
> 
> > Takashi - please remove all such patches from the sound tree.  They
> > should not be in there.
> 
> Oh, I thought Mark already sent you Ben's patches.

What is in my tree is:

------
diff --git a/arch/arm/mach-shark/include/mach/io.h b/arch/arm/mach-shark/include/mach/io.h
index c5cee82..9ccbcec 100644
--- a/arch/arm/mach-shark/include/mach/io.h
+++ b/arch/arm/mach-shark/include/mach/io.h
@@ -11,10 +11,10 @@
 #ifndef __ASM_ARM_ARCH_IO_H
 #define __ASM_ARM_ARCH_IO_H

-#define PCIO_BASE      0xe0000000
-#define IO_SPACE_LIMIT 0xffffffff
+#define IO_SPACE_LIMIT 0xffffffff

-#define __io(a)                ((void __iomem *)(PCIO_BASE + (a)))
-#define __mem_pci(addr)        (addr)
+#define __io(a)                 ((void __iomem *)(0xe0000000 + (a)))
+
+#define __mem_pci(addr) (addr)

 #endif
------

which is basically the same thing from Alexander Schulz but without the
addition of __typesafe_io(), and it's that which I'm objecting to.

> Sorry if it wasn't done yet.

It seems not.  Searching for all messages from Mark containing the
string 'typesafe' results in no matches for messages since 1st January.

> Basically it's two patches to create a branch to move and update IIS
> and audio.h headers.  Since some drivers require these changes, they
> have to be in the sound tree, too.  Otherwise the tree gets
> inconsistent and can't be built.

Maybe, but the point here is that's not the only thing it does.  It also
makes other changes _as well_ that are not relevent to the changes you're
talking about above.

> The relevant changes are in another branch (s3c-iis-header) of asoc
> tree so that it can be easily pulled to another tree:
>    git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git s3c-iis-header
> 
> So, if you can pull these changes above into your GIT tree simply via
> "git pull", everything will settle down (as both trees share the same
> GIT objects).

Why do I want to pull stuff that I consider broken into my tree?  Please
get rid of the use of __typesafe_io in the shark io.h header in your tree
or drop these patches entirely and ask the submitter to fix (whatever's
easier for you.)

As I said when Daniel proposed the change to Footbridge and I avoided
his patch for footbridge's io.h:

| On Mon, Feb 02, 2009 at 03:59:56PM +0000, Daniel Silverstone wrote:
| > Footbridge: __io() should __force to __iomem pointer
| >
| > This trivial patch fixes many warnings (around 850) by forcing
| > the return from __io() to be 'void __iomem *'. This stops sparse
| > warning about the implicit casting into an address space.
| 
| I don't think gcc is bright enough to handle this - rather than doing
| the addition in the load/store instruction, I think you'll find that
| gcc will issue a separate add instruction with this.
| 
| That's why I never converted any of the __io() macros which have an
| addition in them to use __typesafe_io().

the same applies to shark's io.h.  The effect of this change has not been
evaluated and so should NOT be merged for mainline yet.

So, in case it still isn't clear, what I'm objecting to is replacing:

+#define __io(a)		 ((void __iomem *)(0xe0000000 + (a)))

with:

+#define __io(a)		__typesafe_io(0xe0000000 + (a))

I repeat: please back this change out of your tree.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

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

[Takashi Iwai]

At Wed, 11 Mar 2009 09:41:27 +0000,
Russell King wrote:
> 
> On Wed, Mar 11, 2009 at 10:18:40AM +0100, Takashi Iwai wrote:
> > At Wed, 11 Mar 2009 08:52:54 +0000,
> > Russell King wrote:
> > > 
> > > On Tue, Mar 10, 2009 at 02:45:28PM +1100, Stephen Rothwell wrote:
> > > > Hi Takashi,
> > > > 
> > > > Today's linux-next merge of the sound tree got a conflict in
> > > > arch/arm/mach-shark/include/mach/io.h between commit
> > > > eab184c2362567f2b2e951b7bd0e0d353a7e5091 ("[ARM] 5363/1: Shark cleanup
> > > > and new defconfig") from the arm tree and commit
> > > > 8150bc886be5ce3cc301a2baca1fcf2cf7bd7f39 ("S3C24XX: Move and update IIS
> > > > headers") from the sound tree.
> > > > 
> > > > I fixed it up (see below) and can carry the fix as necessary.
> > > 
> > > NAK to this patch.
> > > 
> > > The greater concern is WTF are cleanup patches for the ARM architecture
> > > going via the sound tree.  Especially patches which I have concerns about.
> > > 
> > > > --- a/arch/arm/mach-shark/include/mach/io.h
> > > > +++ b/arch/arm/mach-shark/include/mach/io.h
> > > > @@@ -11,10 -11,10 +11,10 @@@
> > > >   #ifndef __ASM_ARM_ARCH_IO_H
> > > >   #define __ASM_ARM_ARCH_IO_H
> > > >   
> > > >  -#define PCIO_BASE	0xe0000000
> > > >  -#define IO_SPACE_LIMIT	0xffffffff
> > > >  +#define IO_SPACE_LIMIT 0xffffffff
> > > >   
> > > > - #define __io(a)                 ((void __iomem *)(0xe0000000 + (a)))
> > > >  -#define __io(a)		__typesafe_io(PCIO_BASE + (a))
> > > >  -#define __mem_pci(addr)	(addr)
> > > > ++#define __io(a)		__typesafe_io(0xe0000000 + (a))
> > > 
> > > Do not use __typesafe_io() with the addition here without first ensuring
> > > that you've investigated whether it causes the compiler to mis-optimise
> > > the code.
> > 
> > Hrm, is that particular change also in ARM tree, no?  Judging from the
> > conflict-diff above, it looks like the patch just follows that...
> > 
> > > Takashi - please remove all such patches from the sound tree.  They
> > > should not be in there.
> > 
> > Oh, I thought Mark already sent you Ben's patches.
> 
> What is in my tree is:
> 
> ------
> diff --git a/arch/arm/mach-shark/include/mach/io.h b/arch/arm/mach-shark/include/mach/io.h
> index c5cee82..9ccbcec 100644
> --- a/arch/arm/mach-shark/include/mach/io.h
> +++ b/arch/arm/mach-shark/include/mach/io.h
> @@ -11,10 +11,10 @@
>  #ifndef __ASM_ARM_ARCH_IO_H
>  #define __ASM_ARM_ARCH_IO_H
> 
> -#define PCIO_BASE      0xe0000000
> -#define IO_SPACE_LIMIT 0xffffffff
> +#define IO_SPACE_LIMIT 0xffffffff
> 
> -#define __io(a)                ((void __iomem *)(PCIO_BASE + (a)))
> -#define __mem_pci(addr)        (addr)
> +#define __io(a)                 ((void __iomem *)(0xe0000000 + (a)))
> +
> +#define __mem_pci(addr) (addr)
> 
>  #endif
> ------
> 
> which is basically the same thing from Alexander Schulz but without the
> addition of __typesafe_io(), and it's that which I'm objecting to.

OK, fair enough.

> > Sorry if it wasn't done yet.
> 
> It seems not.  Searching for all messages from Mark containing the
> string 'typesafe' results in no matches for messages since 1st January.

Hm, looks like there was some misunderstanding in communications.

> > Basically it's two patches to create a branch to move and update IIS
> > and audio.h headers.  Since some drivers require these changes, they
> > have to be in the sound tree, too.  Otherwise the tree gets
> > inconsistent and can't be built.
> 
> Maybe, but the point here is that's not the only thing it does.  It also
> makes other changes _as well_ that are not relevent to the changes you're
> talking about above.
> 
> > The relevant changes are in another branch (s3c-iis-header) of asoc
> > tree so that it can be easily pulled to another tree:
> >    git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git s3c-iis-header
> > 
> > So, if you can pull these changes above into your GIT tree simply via
> > "git pull", everything will settle down (as both trees share the same
> > GIT objects).
> 
> Why do I want to pull stuff that I consider broken into my tree?  Please
> get rid of the use of __typesafe_io in the shark io.h header in your tree
> or drop these patches entirely and ask the submitter to fix (whatever's
> easier for you.)

It's not too big issue to revert the changes, but it'd be better to
fix the spot as Mark suggested.  The continuous GIT tree history makes
the life of others easier a lot.


Thanks,

Takashi

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

[Russell King]

On Wed, Mar 11, 2009 at 11:02:47AM +0100, Takashi Iwai wrote:
> At Wed, 11 Mar 2009 09:41:27 +0000, Russell King wrote:
> > Why do I want to pull stuff that I consider broken into my tree?  Please
> > get rid of the use of __typesafe_io in the shark io.h header in your tree
> > or drop these patches entirely and ask the submitter to fix (whatever's
> > easier for you.)
> 
> It's not too big issue to revert the changes, but it'd be better to
> fix the spot as Mark suggested.  The continuous GIT tree history makes
> the life of others easier a lot.

Continuous git tree history is something that can be achieved if you're
either at the top of the submission tree, or if you're extremely good
at reviewing patches and throwing out anything which might be the
slightest bit controversial until such things have been agreed.

The issue here is that an inappropriate tree has accepted unreviewed
and questionable ARM specific changes as part of a different set of
patches.  That's partly the fault of the submitter for mixing up the
patch set with irrelevant changes for the tree to which he's submitting
his changes.

There used to be a mantra with the kernel community: one patch to make
one logical change.  That's very much the issue here - it sounds like
there was one patch making several changes, some of which were relevent
to the ALSA tree and others which weren't.

But, at the end of the day, these things have to be fixed one way or
other, whether that be by removing the offending commits, by reverting
the patches, or patching the specific bad changes back to how they
originally were.  I really don't mind which option is taken, just so
long as the final outcome is the right one.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

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

[Mark Brown]

On Wed, Mar 11, 2009 at 10:40:49AM +0000, Russell King wrote:

> But, at the end of the day, these things have to be fixed one way or
> other, whether that be by removing the offending commits, by reverting
> the patches, or patching the specific bad changes back to how they
> originally were.  I really don't mind which option is taken, just so
> long as the final outcome is the right one.

Let's go with reverting things, then - that avoids having to drop the
audio drivers and the subsequent work that was done on them.

Takashi, here's an initial revert of the two hunks I mentioned
previously - I've not checked the other two hunks yet.

The following changes since commit f455dfb106916d855d59686fe16575c2ceb2cb2a:
  Mark Brown (1):
        ASoC: Fix up merge with the ARM tree

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git for-2.6.30

Mark Brown (2):
      [ARM] Revert extraneous changes from the S3C audio header move
      Merge branch 's3c-iis-header' into for-2.6.30

 arch/arm/mach-s3c2410/include/mach/hardware.h |    3 +++
 arch/arm/mach-shark/include/mach/io.h         |    3 +--
 2 files changed, 4 insertions(+), 2 deletions(-)

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

[Takashi Iwai]

At Wed, 11 Mar 2009 11:24:43 +0000,
Mark Brown wrote:
> 
> On Wed, Mar 11, 2009 at 10:40:49AM +0000, Russell King wrote:
> 
> > But, at the end of the day, these things have to be fixed one way or
> > other, whether that be by removing the offending commits, by reverting
> > the patches, or patching the specific bad changes back to how they
> > originally were.  I really don't mind which option is taken, just so
> > long as the final outcome is the right one.
> 
> Let's go with reverting things, then - that avoids having to drop the
> audio drivers and the subsequent work that was done on them.
> 
> Takashi, here's an initial revert of the two hunks I mentioned
> previously - I've not checked the other two hunks yet.

OK, pulled that now.

Thanks,

Takashi


> 
> The following changes since commit f455dfb106916d855d59686fe16575c2ceb2cb2a:
>   Mark Brown (1):
>         ASoC: Fix up merge with the ARM tree
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git for-2.6.30
> 
> Mark Brown (2):
>       [ARM] Revert extraneous changes from the S3C audio header move
>       Merge branch 's3c-iis-header' into for-2.6.30
> 
>  arch/arm/mach-s3c2410/include/mach/hardware.h |    3 +++
>  arch/arm/mach-shark/include/mach/io.h         |    3 +--
>  2 files changed, 4 insertions(+), 2 deletions(-)
> 

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

[Mark Brown]

On Wed, Mar 11, 2009 at 02:28:35PM +0100, Takashi Iwai wrote:
> Mark Brown wrote:

> > Takashi, here's an initial revert of the two hunks I mentioned
> > previously - I've not checked the other two hunks yet.

> OK, pulled that now.

I've just sent a further patch to Takashi reverting the other two hunks
I identified in my earlier mail.

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

[Stephen Rothwell]

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

Hi Mark,

On Wed, 11 Mar 2009 22:32:10 +0000 Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
>
> I've just sent a further patch to Takashi reverting the other two hunks
> I identified in my earlier mail.

Thanks for that.

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

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

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

[Mark Brown]

On Wed, Mar 11, 2009 at 08:52:54AM +0000, Russell King wrote:

> The greater concern is WTF are cleanup patches for the ARM architecture
> going via the sound tree.  Especially patches which I have concerns about.

The reason they're going via the ALSA tree is that Ben has also
submitted patches adding S3C64xx audio support which depends strongly on
the ARM tree changes moving the header files about.  The ARM-generic
changes are also available in a split out branch via:

	git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git
	s3c-iis-header

Sorry about this - I'd been expecting Ben to also include this branch in
the code he's pushing to you and obviously hadn't reviewed them as well
as possible.

> Takashi - please remove all such patches from the sound tree.  They
> should not be in there.

Could we instead revert the bits that cause issues?  It'd be really good
to be able to get the audio drivers into the next merge window.

Re-reviewing the commit it looks like the shark header update that
changes to using typesafe_io() is just completely unrelated to the rest
of the series (commit 8150bc886be5ce3cc301a2baca1fcf2cf7bd7f39 does that
change in an isolated hunk).  I'll push a revert of that hunk to Takashi
this morning.

I'll also remove the change below which looks like a good change in
itself but doesn't appear to be relevant to the header renames:

diff --git a/arch/arm/mach-s3c2410/include/mach/hardware.h b/arch/arm/mach-s3c24
index 74d5a1a..db72beb 100644
--- a/arch/arm/mach-s3c2410/include/mach/hardware.h
+++ b/arch/arm/mach-s3c2410/include/mach/hardware.h
@@ -131,7 +131,4 @@ extern int s3c2412_gpio_set_sleepcfg(unsigned int
pin, unsig
 
 /* machine specific hardware definitions should go after this */
 
-/* currently here until moved into config (todo) */
-#define CONFIG_NO_MULTIWORD_IO
-
 #endif /* __ASM_ARCH_HARDWARE_H */

There are a couple of other hunks which look like they may warrant the
same treatment but I want to re-check just to make sure:

diff --git a/arch/arm/mach-s3c2410/include/mach/io.h b/arch/arm/mach-s3c2410/inc
lude/mach/io.h
index 9813dbf..c477771 100644
--- a/arch/arm/mach-s3c2410/include/mach/io.h
+++ b/arch/arm/mach-s3c2410/include/mach/io.h
@@ -9,7 +9,7 @@
 #ifndef __ASM_ARM_ARCH_IO_H
 #define __ASM_ARM_ARCH_IO_H
 
-#include <mach/hardware.h>
+#include <mach/map.h>
 
 #define IO_SPACE_LIMIT 0xffffffff
 
diff --git a/arch/arm/plat-s3c24xx/clock-dclk.c b/arch/arm/plat-s3c24xx/clock-dclk.c
index 5b75a79..35219dc 100644
--- a/arch/arm/plat-s3c24xx/clock-dclk.c
+++ b/arch/arm/plat-s3c24xx/clock-dclk.c
@@ -18,6 +18,7 @@
 
 #include <mach/regs-clock.h>
 #include <mach/regs-gpio.h>
+#include <mach/hardware.h>
 
 #include <plat/clock.h>
 #include <plat/cpu.h>