Hi Dan,
Today's linux-next merge of the async_tx tree got a conflict in
arch/arm/mach-ux500/devices-db8500.c between commit
6055930cba8fdb2c8855b32bae262aaf69c1fdb4 ("ARM: 6266/1: ux500: add
separate irq lists for DB8500 and DB5500") from the arm tree and commit
5aa12e8c9c57741606e52f43e62ab1b9dc8e9dcc ("DMAENGINE: ste_dma40: arch
updates for LCLA and LCPA") from the async_tx tree.
I fixed it up (I think - see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell [email protected]
diff --cc arch/arm/mach-ux500/devices-db8500.c
index 654fca9,c62cdbe..0000000
--- a/arch/arm/mach-ux500/devices-db8500.c
+++ b/arch/arm/mach-ux500/devices-db8500.c
@@@ -119,20 -119,15 +119,15 @@@ static struct resource dma40_resources[
},
[1] = {
.start = U8500_DMA_LCPA_BASE,
- .end = U8500_DMA_LCPA_BASE + SZ_4K - 1,
+ .end = U8500_DMA_LCPA_BASE + 2 * SZ_1K - 1,
.flags = IORESOURCE_MEM,
- .name = "lcpa",
+ .name = "lcpa",
},
[2] = {
- .start = U8500_DMA_LCLA_BASE,
- .end = U8500_DMA_LCLA_BASE + 16 * 1024 - 1,
- .flags = IORESOURCE_MEM,
- .name = "lcla",
- },
- [3] = {
- .start = IRQ_DMA,
- .end = IRQ_DMA,
+ .start = IRQ_DB8500_DMA,
+ .end = IRQ_DB8500_DMA,
- .flags = IORESOURCE_IRQ}
+ .flags = IORESOURCE_IRQ,
+ }
};
/* Default configuration for physcial memcpy */
Hi Stephen,
On Tue, Jul 27, 2010 at 04:08:05 +0200, Stephen Rothwell wrote:
> Today's linux-next merge of the async_tx tree got a conflict in
> arch/arm/mach-ux500/devices-db8500.c between commit
> 6055930cba8fdb2c8855b32bae262aaf69c1fdb4 ("ARM: 6266/1: ux500: add
> separate irq lists for DB8500 and DB5500") from the arm tree and commit
> 5aa12e8c9c57741606e52f43e62ab1b9dc8e9dcc ("DMAENGINE: ste_dma40: arch
> updates for LCLA and LCPA") from the async_tx tree.
>
> I fixed it up (I think - see below) and can carry the fix as necessary.
The fixup is correct, thanks.
Rabin
Hi Rabin,
On Wed, 28 Jul 2010 09:28:49 +0530 Rabin VINCENT <[email protected]> wrote:
>
> The fixup is correct, thanks.
Thanks for the confirmation.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
On Mon, Jul 26, 2010 at 7:08 PM, Stephen Rothwell <[email protected]> wrote:
> Hi Dan,
>
> Today's linux-next merge of the async_tx tree got a conflict in
> arch/arm/mach-ux500/devices-db8500.c between commit
> 6055930cba8fdb2c8855b32bae262aaf69c1fdb4 ("ARM: 6266/1: ux500: add
> separate irq lists for DB8500 and DB5500") from the arm tree and commit
> 5aa12e8c9c57741606e52f43e62ab1b9dc8e9dcc ("DMAENGINE: ste_dma40: arch
> updates for LCLA and LCPA") from the async_tx tree.
>
> I fixed it up (I think - see below) and can carry the fix as necessary.
> --
Thanks Stephen!
Russell, the dma40 driver updates and related arch fixups have been
sitting in next for a month, I'd prefer not to lose this baseline.
Assuming this change is brand new any chance the dma40 specific part
of this patch can be peeled off and sent through my tree, or are you
in a similar "can't/won't" rebase position?
--
Dan
On Wed, Jul 28, 2010 at 12:11:19AM -0700, Dan Williams wrote:
> On Mon, Jul 26, 2010 at 7:08 PM, Stephen Rothwell <[email protected]> wrote:
> > Hi Dan,
> >
> > Today's linux-next merge of the async_tx tree got a conflict in
> > arch/arm/mach-ux500/devices-db8500.c between commit
> > 6055930cba8fdb2c8855b32bae262aaf69c1fdb4 ("ARM: 6266/1: ux500: add
> > separate irq lists for DB8500 and DB5500") from the arm tree and commit
> > 5aa12e8c9c57741606e52f43e62ab1b9dc8e9dcc ("DMAENGINE: ste_dma40: arch
> > updates for LCLA and LCPA") from the async_tx tree.
> >
> > I fixed it up (I think - see below) and can carry the fix as necessary.
> > --
>
> Thanks Stephen!
>
> Russell, the dma40 driver updates and related arch fixups have been
> sitting in next for a month, I'd prefer not to lose this baseline.
> Assuming this change is brand new any chance the dma40 specific part
> of this patch can be peeled off and sent through my tree, or are you
> in a similar "can't/won't" rebase position?
I don't see how the change in the ARM tree could be reasonably split.
Up to Rabin/Linus to decide what they want to do about this.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
2010/7/28 Russell King <[email protected]>:
> On Wed, Jul 28, 2010 at 12:11:19AM -0700, Dan Williams wrote:
>> On Mon, Jul 26, 2010 at 7:08 PM, Stephen Rothwell <[email protected]> wrote:
>> > Hi Dan,
>> >
>> > Today's linux-next merge of the async_tx tree got a conflict in
>> > arch/arm/mach-ux500/devices-db8500.c between commit
>> > 6055930cba8fdb2c8855b32bae262aaf69c1fdb4 ("ARM: 6266/1: ux500: add
>> > separate irq lists for DB8500 and DB5500") from the arm tree and commit
>> > 5aa12e8c9c57741606e52f43e62ab1b9dc8e9dcc ("DMAENGINE: ste_dma40: arch
>> > updates for LCLA and LCPA") from the async_tx tree.
>> >
>> > I fixed it up (I think - see below) and can carry the fix as necessary.
>> > --
>>
>> Thanks Stephen!
>>
>> Russell, the dma40 driver updates and related arch fixups have been
>> sitting in next for a month, I'd prefer not to lose this baseline.
>> Assuming this change is brand new any chance the dma40 specific part
>> of this patch can be peeled off and sent through my tree, or are you
>> in a similar "can't/won't" rebase position?
>
> I don't see how the change in the ARM tree could be reasonably split.
> Up to Rabin/Linus to decide what they want to do about this.
Actually the way subsystem maintainers fix up conflicts and resolve them
is a bit of opaque to me, I'd be happy to help in any way possible.
Isn't it so that whoever hits the merge window first goes in and the
other apply Stephens patch before issuing any pull request and be
done with it? That was my na?ve idea about these things...
Yours,
Linus Walleij
On Wed, Jul 28, 2010 at 4:50 PM, Linus Walleij
<[email protected]> wrote:
> 2010/7/28 Russell King <[email protected]>:
>> On Wed, Jul 28, 2010 at 12:11:19AM -0700, Dan Williams wrote:
>>> On Mon, Jul 26, 2010 at 7:08 PM, Stephen Rothwell <[email protected]> wrote:
>>> > Hi Dan,
>>> >
>>> > Today's linux-next merge of the async_tx tree got a conflict in
>>> > arch/arm/mach-ux500/devices-db8500.c between commit
>>> > 6055930cba8fdb2c8855b32bae262aaf69c1fdb4 ("ARM: 6266/1: ux500: add
>>> > separate irq lists for DB8500 and DB5500") from the arm tree and commit
>>> > 5aa12e8c9c57741606e52f43e62ab1b9dc8e9dcc ("DMAENGINE: ste_dma40: arch
>>> > updates for LCLA and LCPA") from the async_tx tree.
>>> >
>>> > I fixed it up (I think - see below) and can carry the fix as necessary.
>>> > --
>>>
>>> Thanks Stephen!
>>>
>>> Russell, the dma40 driver updates and related arch fixups have been
>>> sitting in next for a month, I'd prefer not to lose this baseline.
>>> Assuming this change is brand new any chance the dma40 specific part
>>> of this patch can be peeled off and sent through my tree, or are you
>>> in a similar "can't/won't" rebase position?
>>
>> I don't see how the change in the ARM tree could be reasonably split.
>> Up to Rabin/Linus to decide what they want to do about this.
>
> Actually the way subsystem maintainers fix up conflicts and resolve them
> is a bit of opaque to me, I'd be happy to help in any way possible.
>
> Isn't it so that whoever hits the merge window first goes in and the
> other apply Stephens patch before issuing any pull request and be
> done with it? That was my na?ve idea about these things...
>
It's a bag of dirty choices:
1/ Do nothing: LinusT will need to fix up the conflict in the same way
that Stephen has done.
2/ Drop the new patch from the ARM tree as the conflict could have
been seen ahead of time and send it later in the merge window after
async_tx.git has been merged, but this might involve rebasing the ARM
tree.
3/ Back merge the ARM tree after it goes upstream so the conflict is
resolved before Linus pulls async_tx.git, but this makes the history
ugly
4/ Rewind the async_tx.git tree so we at least keep the same branch
point, but this still screws up people who use git pull to track
async_tx.git.
Option 1 is probably the lesser evil as Linus has said he does not
mind the occasional conflict, but it still feels wrong to push any
pain upstream when the conflict could have been seen ahead of time.
--
Dan