at91: Error while registering DMA controller in 3.3-rc

at91: Error while registering DMA controller in 3.3-rc

[Nicolas Ferre]

Arnd, Olof,

We currently have a regression on 3.3-rc kernels about the DMA
controller registration.

http://article.gmane.org/gmane.linux.kernel.mmc/13014

This is due to the DMA driver having seen an update during the 3.3 merge
window  but the AT91 device files not having the corresponding
modifications.

Maybe you remember, those modifications where part of the famous AT91
board/device series that was postponed to 3.4 due to a flood of issues...

So now, I would like to know if it is possible to resolve this problem
by queuing the DMA related patches that we have already in
at91/device-board branch to mainline before 3.3-final?

The patches that I am talking about are:

bdad0b9 ARM: at91/dma: remove platform data from DMA controller
and
2756bf5 ARM: at91/dma: DMA controller registering with DT support

I do think it is pretty silly to try to resolve this issue by not taking
those two little patches and modifying source code to workaround this
issue. If we do this, we will get conflicts and need to rework the
already queued 3.4 material.

Do you want me to prepare a new at91-fixes branch with those two patches
or you can take them yourself?

Thanks for your help, best regards,
-- 
Nicolas Ferre

Re: at91: Error while registering DMA controller in 3.3-rc

[Arnd Bergmann]

On Thursday 01 March 2012, Nicolas Ferre wrote:
> We currently have a regression on 3.3-rc kernels about the DMA
> controller registration.
> 
> http://article.gmane.org/gmane.linux.kernel.mmc/13014
> 
> This is due to the DMA driver having seen an update during the 3.3 merge
> window  but the AT91 device files not having the corresponding
> modifications.
> 
> Maybe you remember, those modifications where part of the famous AT91
> board/device series that was postponed to 3.4 due to a flood of issues...
> 
> So now, I would like to know if it is possible to resolve this problem
> by queuing the DMA related patches that we have already in
> at91/device-board branch to mainline before 3.3-final?

Yes, that should be possible. We try not have the same patches in multiple
branches, but since this is a regression, I think we should do it anyway.

> The patches that I am talking about are:
> 
> bdad0b9 ARM: at91/dma: remove platform data from DMA controller
> and
> 2756bf5 ARM: at91/dma: DMA controller registering with DT support
> 
> I do think it is pretty silly to try to resolve this issue by not taking
> those two little patches and modifying source code to workaround this
> issue. If we do this, we will get conflicts and need to rework the
> already queued 3.4 material.
> 
> Do you want me to prepare a new at91-fixes branch with those two patches
> or you can take them yourself?

Better send me a pull request so that you can do some testing on the
exact branch that you send me. I would probably end up with the
same tree and I'm not worried about doing it, but we should make sure
that it actually works.

	Arnd

[GIT PULL] at91: fixes for DMA registration (3.3-rc)

[Nicolas Ferre]

Hi Arnd,

As discussed on the mailing-list, we experience an out-of-sync situation
between the DMA controller driver and the related code in AT91 devices files.

Those two patches already queued for 3.4 are correcting the problem that we found on
the current 3.3-rc kernels. I have tested that the DMA driver is registering well
with those fixes applied.

Can you please pull them in a "fixes" branch and send them to Linus before 3.3-final?

Thanks for your help.

The following changes since commit 6b21d18ed50c7d145220b0724ea7f2613abf0f95:

  Linux 3.3-rc5 (2012-02-25 12:18:16 -0800)

are available in the git repository at:

  git://github.com/at91linux/linux-at91.git at91-fixes

for you to fetch changes up to 851c52b23c5c27047f1438684750e28c44d73191:

  ARM: at91/dma: DMA controller registering with DT support (2012-02-29 18:20:39 +0100)

----------------------------------------------------------------
Nicolas Ferre (2):
      ARM: at91/dma: remove platform data from DMA controller
      ARM: at91/dma: DMA controller registering with DT support

 arch/arm/mach-at91/at91sam9g45_devices.c |   19 ++++++++++---------
 arch/arm/mach-at91/at91sam9rl_devices.c  |    8 +-------
 2 files changed, 11 insertions(+), 16 deletions(-)

Best regards,
-- 
Nicolas Ferre

Re: [GIT PULL] at91: fixes for DMA registration (3.3-rc)

[Arnd Bergmann]

On Thursday 01 March 2012, Nicolas Ferre wrote:
> As discussed on the mailing-list, we experience an out-of-sync situation
> between the DMA controller driver and the related code in AT91 devices files.
> 
> Those two patches already queued for 3.4 are correcting the problem that we found on
> the current 3.3-rc kernels. I have tested that the DMA driver is registering well
> with those fixes applied.
> 
> Can you please pull them in a "fixes" branch and send them to Linus before 3.3-final?

Hi Nicolas,

I've just sent a pull request for bug fixes yesterday, so I'll wait
until Linus has pulled that one and probably a few days before I
send another one.

I have applied it to the fixes branch now but not updated the
tag that I sent him.

	Arnd

Re: [GIT PULL] at91: fixes for DMA registration (3.3-rc)

[Nicolas Ferre]

On 03/01/2012 03:03 PM, Arnd Bergmann :
> On Thursday 01 March 2012, Nicolas Ferre wrote:
>> As discussed on the mailing-list, we experience an out-of-sync situation
>> between the DMA controller driver and the related code in AT91 devices files.
>>
>> Those two patches already queued for 3.4 are correcting the problem that we found on
>> the current 3.3-rc kernels. I have tested that the DMA driver is registering well
>> with those fixes applied.
>>
>> Can you please pull them in a "fixes" branch and send them to Linus before 3.3-final?
> 
> Hi Nicolas,
> 
> I've just sent a pull request for bug fixes yesterday, so I'll wait
> until Linus has pulled that one and probably a few days before I
> send another one.

Sure.

> I have applied it to the fixes branch now but not updated the
> tag that I sent him.

Ok, thanks a lot for your quick help.

Best regards,
-- 
Nicolas Ferre