[GIT PULL] ste_dma40 updates for 3.9

[GIT PULL] ste_dma40 updates for 3.9

[Fabio Baltieri]

Hello Arnd, Olof,

This contains a series of updates and fixes for the ste_dma40 driver.

The driver is specific for the ux500, and the patches were acked by both Linus
Walleij, and Vinod Koul (dmaengine), who agreed to push this through arm-soc.

Can you please pull those in for -next?

Thanks,
Fabio


The following changes since commit d1c3ed669a2d452cacfb48c2d171a1f364dae2ed:

  Linux 3.8-rc2 (2013-01-02 18:13:21 -0800)

are available in the git repository at:

  git://git.linaro.org/people/fabiobaltieri/linux.git tags/ux500-dma40

for you to fetch changes up to da2ac56a1bc9c6c56244aa9ca990d5c5c7574b5f:

  dmaengine: set_dma40: balance clock in probe fail code (2013-01-14 10:51:16 +0100)

----------------------------------------------------------------
Various fixes and updates for the ste_dma40 driver.

----------------------------------------------------------------
Fabio Baltieri (7):
      dmaengine: ste_dma40: add a done queue for completed descriptors
      dmaengine: ste_dma40: add missing kernel-doc entry
      dmaengine: ste_dma40: minor cosmetic fixes
      dmaengine: ste_dma40: minor code readability fixes
      dmaengine: ste_dma40: add software lli support
      dmaengine: set_dma40: ignore spurious interrupts
      dmaengine: set_dma40: balance clock in probe fail code

Gerald Baeza (2):
      dmaengine: ste_dma40: support fixed physical channel allocation
      dmaengine: ste_dma40: physical channels number correction

Narayanan (1):
      dmaengine: ste_dma40: reset priority bit for logical channels

Narayanan G (1):
      dmaengine: ste_dma40: don't check for pm_runtime_suspended()

Per Forlin (3):
      dmaengine: ste_dma40: use writel_relaxed for lcxa
      dmaengine: ste_dma40: set dma max seg size
      dmaengine: ste_dma40: limit burst size to 16

Rabin Vincent (1):
      dmaengine: ste_dma40: don't allow high priority dest event lines

Tong Liu (1):
      dmaengine: ste_dma40: support more than 128 event lines

 drivers/dma/ste_dma40.c                     | 489 +++++++++++++++++++++-------
 drivers/dma/ste_dma40_ll.c                  |  29 +-
 drivers/dma/ste_dma40_ll.h                  | 130 +++++++-
 include/linux/platform_data/dma-ste-dma40.h |  13 +
 4 files changed, 518 insertions(+), 143 deletions(-)

-- 
Fabio Baltieri

[GIT PULL] ste_dma40 updates for 3.9

[Olof Johansson]

Hi,

On Mon, Jan 14, 2013 at 2:15 AM, Fabio Baltieri
<fabio.baltieri@linaro.org> wrote:
> Hello Arnd, Olof,
>
> This contains a series of updates and fixes for the ste_dma40 driver.
>
> The driver is specific for the ux500, and the patches were acked by both Linus
> Walleij, and Vinod Koul (dmaengine), who agreed to push this through arm-soc.
>
> Can you please pull those in for -next?

While I don't mind taking this through arm-soc, I don't see a strong
reason to do so?

This series of patches only modify the ste_dma40 driver, there are no
corresponding changes under arch/arm that need to be coordinated or
considered w.r.t. merge conflicts. I.e. they all seem nicely isolated
to only the driver.

So is there a specific reason for why these shouldn't just go in
through the dmaengine tree?


Thanks,

-Olof

[GIT PULL] ste_dma40 updates for 3.9

[Linus Walleij]

On Tue, Jan 15, 2013 at 7:48 AM, Olof Johansson <olof@lixom.net> wrote:

> This series of patches only modify the ste_dma40 driver, there are no
> corresponding changes under arch/arm that need to be coordinated or
> considered w.r.t. merge conflicts. I.e. they all seem nicely isolated
> to only the driver.
>
> So is there a specific reason for why these shouldn't just go in
> through the dmaengine tree?

One reason would be if there are DMA bindings to device tree coming
this merge window, as I'm told, and it implicates a lot of platform code
changes on top of this as we adopt to it.

But maybe this will be wholly confined to the DMAengine tree?

Yours,
Linus Walleij

[GIT PULL] ste_dma40 updates for 3.9

[Fabio Baltieri]

Hello Olof,

On Mon, Jan 14, 2013 at 10:48:15PM -0800, Olof Johansson wrote:
> > This contains a series of updates and fixes for the ste_dma40 driver.
> >
> > The driver is specific for the ux500, and the patches were acked by both Linus
> > Walleij, and Vinod Koul (dmaengine), who agreed to push this through arm-soc.
> >
> > Can you please pull those in for -next?
> 
> While I don't mind taking this through arm-soc, I don't see a strong
> reason to do so?
> 
> This series of patches only modify the ste_dma40 driver, there are no
> corresponding changes under arch/arm that need to be coordinated or
> considered w.r.t. merge conflicts. I.e. they all seem nicely isolated
> to only the driver.
> 
> So is there a specific reason for why these shouldn't just go in
> through the dmaengine tree?

The idea was to have this in the same tree as other ux500 specific
driver patches to easy up testing a bit, but now that you point it out
I see that current arm-soc tree is pretty clear of driver patches (mmci
was what I had in mind) and those should end up to other trees anyway,
so you're probably right and these should go in dmaengine tree.

Vinod, would you please consider pulling these into dmaengine's next
tree?

Thanks,
Fabio

-- 
Fabio Baltieri

[GIT PULL] ste_dma40 updates for 3.9

[Olof Johansson]

On Tue, Jan 15, 2013 at 09:53:05AM +0100, Linus Walleij wrote:
> On Tue, Jan 15, 2013 at 7:48 AM, Olof Johansson <olof@lixom.net> wrote:
> 
> > This series of patches only modify the ste_dma40 driver, there are no
> > corresponding changes under arch/arm that need to be coordinated or
> > considered w.r.t. merge conflicts. I.e. they all seem nicely isolated
> > to only the driver.
> >
> > So is there a specific reason for why these shouldn't just go in
> > through the dmaengine tree?
> 
> One reason would be if there are DMA bindings to device tree coming
> this merge window, as I'm told, and it implicates a lot of platform code
> changes on top of this as we adopt to it.
> 
> But maybe this will be wholly confined to the DMAengine tree?

Changing platform code in the driver trees is asking for conflicts at
merge time and a grumpy Linus, I'd prefer to merge arch/arm/* through
arm-soc in that case.

Either way, this branch can be merged into dmaengine as a branch pull,
and if needed we can bring it in as a dependency on arm-soc. We would
need the same for the dmaengine DT bindings branch as a base. Of course,
that requires that Vinod doesn't rebase his branch and keeps the merge
intact. Vinod, is that compatible with your workflow?


-Olof

[GIT PULL] ste_dma40 updates for 3.9

[Vinod Koul]

On Tue, Jan 15, 2013 at 11:14:50AM -0800, Olof Johansson wrote:
> On Tue, Jan 15, 2013 at 09:53:05AM +0100, Linus Walleij wrote:
> > On Tue, Jan 15, 2013 at 7:48 AM, Olof Johansson <olof@lixom.net> wrote:
> > 
> > > This series of patches only modify the ste_dma40 driver, there are no
> > > corresponding changes under arch/arm that need to be coordinated or
> > > considered w.r.t. merge conflicts. I.e. they all seem nicely isolated
> > > to only the driver.
> > >
> > > So is there a specific reason for why these shouldn't just go in
> > > through the dmaengine tree?
> > 
> > One reason would be if there are DMA bindings to device tree coming
> > this merge window, as I'm told, and it implicates a lot of platform code
> > changes on top of this as we adopt to it.
> > 
> > But maybe this will be wholly confined to the DMAengine tree?
> 
> Changing platform code in the driver trees is asking for conflicts at
> merge time and a grumpy Linus, I'd prefer to merge arch/arm/* through
> arm-soc in that case.
> 
> Either way, this branch can be merged into dmaengine as a branch pull,
> and if needed we can bring it in as a dependency on arm-soc. We would
> need the same for the dmaengine DT bindings branch as a base. Of course,
> that requires that Vinod doesn't rebase his branch and keeps the merge
> intact. Vinod, is that compatible with your workflow?
Yes it is.

Is this series dependent on dmaengine dt-bindings. If so then it wont apply to
arm tree. Btw I dont mind it getting merged to any of the trees as long as we
keep dependecies and avoid major conflicts :)

--
~Vinod

[GIT PULL] ste_dma40 updates for 3.9

[Fabio Baltieri]

On Sun, Jan 20, 2013 at 06:07:33AM -0800, Vinod Koul wrote:
> On Tue, Jan 15, 2013 at 11:14:50AM -0800, Olof Johansson wrote:
> > On Tue, Jan 15, 2013 at 09:53:05AM +0100, Linus Walleij wrote:
> > > On Tue, Jan 15, 2013 at 7:48 AM, Olof Johansson <olof@lixom.net> wrote:
> > > 
> > > > This series of patches only modify the ste_dma40 driver, there are no
> > > > corresponding changes under arch/arm that need to be coordinated or
> > > > considered w.r.t. merge conflicts. I.e. they all seem nicely isolated
> > > > to only the driver.
> > > >
> > > > So is there a specific reason for why these shouldn't just go in
> > > > through the dmaengine tree?
> > > 
> > > One reason would be if there are DMA bindings to device tree coming
> > > this merge window, as I'm told, and it implicates a lot of platform code
> > > changes on top of this as we adopt to it.
> > > 
> > > But maybe this will be wholly confined to the DMAengine tree?
> > 
> > Changing platform code in the driver trees is asking for conflicts at
> > merge time and a grumpy Linus, I'd prefer to merge arch/arm/* through
> > arm-soc in that case.
> > 
> > Either way, this branch can be merged into dmaengine as a branch pull,
> > and if needed we can bring it in as a dependency on arm-soc. We would
> > need the same for the dmaengine DT bindings branch as a base. Of course,
> > that requires that Vinod doesn't rebase his branch and keeps the merge
> > intact. Vinod, is that compatible with your workflow?
> Yes it is.
> 
> Is this series dependent on dmaengine dt-bindings. If so then it wont apply to
> arm tree. Btw I dont mind it getting merged to any of the trees as long as we
> keep dependecies and avoid major conflicts :)

So, would you accept my original pull-request in the dmaengine tree?

Thanks,
Fabio

-- 
Fabio Baltieri

[GIT PULL] ste_dma40 updates for 3.9

[Vinod Koul]

On Tue, Jan 15, 2013 at 09:55:00AM +0100, Fabio Baltieri wrote:
> Vinod, would you please consider pulling these into dmaengine's next
> tree?
Yes merged thanks

--
~Vinod