Patchwork [GIT,PULL] at91: platform data for atmel-mci (for 3.5)

login
register
mail settings
Submitter Nicolas Ferre
Date May 24, 2012, 3:12 p.m.
Message ID <4FBE4FE7.3010005@atmel.com>
Download mbox
Permalink /patch/161152/
State New
Headers show

Pull-request

git://github.com/at91linux/linux-at91.git tags/at91-for-next-soc

Comments

Nicolas Ferre - May 24, 2012, 3:12 p.m.
Hi Arnd, hi Olof,

Here is an additional AT91 patch for 3.5 concerning platform data
related to atmel-mci driver. It is maybe a bit late on your side
but you can choose to sent it during 3.5-rc cycle considering the
reasons that I give in the tag comment...

If you feel it does not have to integrate 3.5, having it in
a kind of "staging" or "late" branch can help us to exercise it
in linux-next.

(is merges seamlessly with current Linus' tree as the commit that I have
based my tag upon is already integrated upstream)

The following changes since commit cce783c608fee0716cff65926d1835a5fd097b69:

  ARM: at91: Add DT description files for AT91SAM9N12-EK (2012-04-28 01:40:27 +0800)

are available in the git repository at:

  git://github.com/at91linux/linux-at91.git tags/at91-for-next-soc

for you to fetch changes up to 6df5c23817852e865c452e72414063acd0cd7309:

  ARM: at91: add atmel-mci support for chips and boards which can use it (2012-05-21 12:30:41 +0200)

----------------------------------------------------------------
This addition of platform data for atmel-mci driver in AT91 SoC & boards
will temporary overload the information for at91_mci driver.
This situation will end in 3.7 when the at91_mci driver marked deprecated
will be removed. At this time, all platform data for this old driver will
be erased from all SoC & boards files.
The sooner we provide elements for people to switch to this newer and more
stable driver, the better we will run this transition.

----------------------------------------------------------------
Ludovic Desroches (1):
      ARM: at91: add atmel-mci support for chips and boards which can use it

 arch/arm/mach-at91/at91rm9200_devices.c  |   99 ++++++++++++++++++
 arch/arm/mach-at91/at91sam9261_devices.c |   67 ++++++++++++
 arch/arm/mach-at91/at91sam9263.c         |    2 +
 arch/arm/mach-at91/at91sam9263_devices.c |  164 ++++++++++++++++++++++++++++++
 arch/arm/mach-at91/at91sam9rl_devices.c  |   70 +++++++++++++
 arch/arm/mach-at91/board-afeb-9260v1.c   |   14 +++
 arch/arm/mach-at91/board-carmeva.c       |   14 +++
 arch/arm/mach-at91/board-cpu9krea.c      |   14 +++
 arch/arm/mach-at91/board-cpuat91.c       |   14 +++
 arch/arm/mach-at91/board-csb337.c        |   14 +++
 arch/arm/mach-at91/board-eb9200.c        |   14 +++
 arch/arm/mach-at91/board-ecbat91.c       |   14 +++
 arch/arm/mach-at91/board-eco920.c        |   14 +++
 arch/arm/mach-at91/board-flexibity.c     |   14 +++
 arch/arm/mach-at91/board-foxg20.c        |   16 ++-
 arch/arm/mach-at91/board-kb9202.c        |   14 +++
 arch/arm/mach-at91/board-neocore926.c    |   14 +++
 arch/arm/mach-at91/board-picotux200.c    |   14 +++
 arch/arm/mach-at91/board-qil-a9260.c     |   14 +++
 arch/arm/mach-at91/board-rm9200dk.c      |   14 +++
 arch/arm/mach-at91/board-rm9200ek.c      |   14 +++
 arch/arm/mach-at91/board-rsi-ews.c       |   14 +++
 arch/arm/mach-at91/board-sam9-l9260.c    |   16 ++-
 arch/arm/mach-at91/board-sam9260ek.c     |   16 ++-
 arch/arm/mach-at91/board-sam9261ek.c     |   14 +++
 arch/arm/mach-at91/board-sam9263ek.c     |   14 +++
 arch/arm/mach-at91/board-sam9rlek.c      |   14 +++
 arch/arm/mach-at91/board-usb-a926x.c     |    2 +-
 arch/arm/mach-at91/board-yl-9200.c       |   14 +++
 29 files changed, 728 insertions(+), 4 deletions(-)

Thanks, best regards,
Nicolas Ferre - May 31, 2012, 7:50 a.m.
On 05/24/2012 05:12 PM, Nicolas Ferre :
> Hi Arnd, hi Olof,

Ping?

(or maybe you will have a look at this after the merge window...)

> Here is an additional AT91 patch for 3.5 concerning platform data
> related to atmel-mci driver. It is maybe a bit late on your side
> but you can choose to sent it during 3.5-rc cycle considering the
> reasons that I give in the tag comment...
> 
> If you feel it does not have to integrate 3.5, having it in
> a kind of "staging" or "late" branch can help us to exercise it
> in linux-next.
> 
> (is merges seamlessly with current Linus' tree as the commit that I have
> based my tag upon is already integrated upstream)
> 
> The following changes since commit cce783c608fee0716cff65926d1835a5fd097b69:
> 
>   ARM: at91: Add DT description files for AT91SAM9N12-EK (2012-04-28 01:40:27 +0800)
> 
> are available in the git repository at:
> 
>   git://github.com/at91linux/linux-at91.git tags/at91-for-next-soc
> 
> for you to fetch changes up to 6df5c23817852e865c452e72414063acd0cd7309:
> 
>   ARM: at91: add atmel-mci support for chips and boards which can use it (2012-05-21 12:30:41 +0200)
> 
> ----------------------------------------------------------------
> This addition of platform data for atmel-mci driver in AT91 SoC & boards
> will temporary overload the information for at91_mci driver.
> This situation will end in 3.7 when the at91_mci driver marked deprecated
> will be removed. At this time, all platform data for this old driver will
> be erased from all SoC & boards files.
> The sooner we provide elements for people to switch to this newer and more
> stable driver, the better we will run this transition.
> 
> ----------------------------------------------------------------
> Ludovic Desroches (1):
>       ARM: at91: add atmel-mci support for chips and boards which can use it
> 
>  arch/arm/mach-at91/at91rm9200_devices.c  |   99 ++++++++++++++++++
>  arch/arm/mach-at91/at91sam9261_devices.c |   67 ++++++++++++
>  arch/arm/mach-at91/at91sam9263.c         |    2 +
>  arch/arm/mach-at91/at91sam9263_devices.c |  164 ++++++++++++++++++++++++++++++
>  arch/arm/mach-at91/at91sam9rl_devices.c  |   70 +++++++++++++
>  arch/arm/mach-at91/board-afeb-9260v1.c   |   14 +++
>  arch/arm/mach-at91/board-carmeva.c       |   14 +++
>  arch/arm/mach-at91/board-cpu9krea.c      |   14 +++
>  arch/arm/mach-at91/board-cpuat91.c       |   14 +++
>  arch/arm/mach-at91/board-csb337.c        |   14 +++
>  arch/arm/mach-at91/board-eb9200.c        |   14 +++
>  arch/arm/mach-at91/board-ecbat91.c       |   14 +++
>  arch/arm/mach-at91/board-eco920.c        |   14 +++
>  arch/arm/mach-at91/board-flexibity.c     |   14 +++
>  arch/arm/mach-at91/board-foxg20.c        |   16 ++-
>  arch/arm/mach-at91/board-kb9202.c        |   14 +++
>  arch/arm/mach-at91/board-neocore926.c    |   14 +++
>  arch/arm/mach-at91/board-picotux200.c    |   14 +++
>  arch/arm/mach-at91/board-qil-a9260.c     |   14 +++
>  arch/arm/mach-at91/board-rm9200dk.c      |   14 +++
>  arch/arm/mach-at91/board-rm9200ek.c      |   14 +++
>  arch/arm/mach-at91/board-rsi-ews.c       |   14 +++
>  arch/arm/mach-at91/board-sam9-l9260.c    |   16 ++-
>  arch/arm/mach-at91/board-sam9260ek.c     |   16 ++-
>  arch/arm/mach-at91/board-sam9261ek.c     |   14 +++
>  arch/arm/mach-at91/board-sam9263ek.c     |   14 +++
>  arch/arm/mach-at91/board-sam9rlek.c      |   14 +++
>  arch/arm/mach-at91/board-usb-a926x.c     |    2 +-
>  arch/arm/mach-at91/board-yl-9200.c       |   14 +++
>  29 files changed, 728 insertions(+), 4 deletions(-)
> 
> Thanks, best regards,
Olof Johansson - May 31, 2012, 9:04 p.m.
Hi Nicolas,


On Thu, May 31, 2012 at 12:50 AM, Nicolas Ferre <nicolas.ferre@atmel.com>wrote:

> On 05/24/2012 05:12 PM, Nicolas Ferre :
> > Hi Arnd, hi Olof,
>
> Ping?
>
> (or maybe you will have a look at this after the merge window...)
>

So, I looked at this branch yesterday but I wasn't entirely happy with the
number of ifdefs it adds.

If the idea is to deprecate the old driver, wouldn't it make more sense to
just cut everyone over instead of having both sets of setup in the kernel?


-Olof
Nicolas Ferre - June 4, 2012, 3:48 p.m.
On 05/31/2012 11:04 PM, Olof Johansson :
> Hi Nicolas,
> 
> On Thu, May 31, 2012 at 12:50 AM, Nicolas Ferre <nicolas.ferre@atmel.com
> <mailto:nicolas.ferre@atmel.com>> wrote:
> 
>     On 05/24/2012 05:12 PM, Nicolas Ferre :
>     > Hi Arnd, hi Olof,
> 
>     Ping?
> 
>     (or maybe you will have a look at this after the merge window...)
> 
> 
> So, I looked at this branch yesterday but I wasn't entirely happy with
> the number of ifdefs it adds.

Unfortunately, this is the usual shape of any devices/boards files on
AT91. This amount will be reduced when we remove the old driver and when
we move newer/popular devices to Device Tree...

> If the idea is to deprecate the old driver, wouldn't it make more sense
> to just cut everyone over instead of having both sets of setup in the
> kernel?

Well, the old driver has existed since a very long time and I think that
people are used to it on oldest platforms. This is why we put in place a
overlapping period. This way we hope that the transition will be smoother.
On the other hand, the old code will be removed in 3.7 so the
overlapping period will not be so long.
I hope that it will allow people to track bugs if some are remaining and
switch to newer driver easily.

Best regards,
Nicolas Ferre - June 13, 2012, 4:48 p.m.
On 06/04/2012 05:48 PM, Nicolas Ferre :
> On 05/31/2012 11:04 PM, Olof Johansson :
>> Hi Nicolas,
>>
>> On Thu, May 31, 2012 at 12:50 AM, Nicolas Ferre <nicolas.ferre@atmel.com
>> <mailto:nicolas.ferre@atmel.com>> wrote:
>>
>>     On 05/24/2012 05:12 PM, Nicolas Ferre :
>>     > Hi Arnd, hi Olof,
>>
>>     Ping?
>>
>>     (or maybe you will have a look at this after the merge window...)
>>
>>
>> So, I looked at this branch yesterday but I wasn't entirely happy with
>> the number of ifdefs it adds.
> 
> Unfortunately, this is the usual shape of any devices/boards files on
> AT91. This amount will be reduced when we remove the old driver and when
> we move newer/popular devices to Device Tree...
> 
>> If the idea is to deprecate the old driver, wouldn't it make more sense
>> to just cut everyone over instead of having both sets of setup in the
>> kernel?
> 
> Well, the old driver has existed since a very long time and I think that
> people are used to it on oldest platforms. This is why we put in place a
> overlapping period. This way we hope that the transition will be smoother.
> On the other hand, the old code will be removed in 3.7 so the
> overlapping period will not be so long.
> I hope that it will allow people to track bugs if some are remaining and
> switch to newer driver easily.

Olof, Arnd,

So, do you have made up your mind about this pull request?

Best regards,
Olof Johansson - June 18, 2012, 1:49 p.m.
Hi,

On Wed, Jun 13, 2012 at 9:48 AM, Nicolas Ferre <nicolas.ferre@atmel.com> wrote:
> On 06/04/2012 05:48 PM, Nicolas Ferre :
>> On 05/31/2012 11:04 PM, Olof Johansson :
>>> Hi Nicolas,
>>>
>>> On Thu, May 31, 2012 at 12:50 AM, Nicolas Ferre <nicolas.ferre@atmel.com
>>> <mailto:nicolas.ferre@atmel.com>> wrote:
>>>
>>>     On 05/24/2012 05:12 PM, Nicolas Ferre :
>>>     > Hi Arnd, hi Olof,
>>>
>>>     Ping?
>>>
>>>     (or maybe you will have a look at this after the merge window...)
>>>
>>>
>>> So, I looked at this branch yesterday but I wasn't entirely happy with
>>> the number of ifdefs it adds.
>>
>> Unfortunately, this is the usual shape of any devices/boards files on
>> AT91. This amount will be reduced when we remove the old driver and when
>> we move newer/popular devices to Device Tree...
>>
>>> If the idea is to deprecate the old driver, wouldn't it make more sense
>>> to just cut everyone over instead of having both sets of setup in the
>>> kernel?
>>
>> Well, the old driver has existed since a very long time and I think that
>> people are used to it on oldest platforms. This is why we put in place a
>> overlapping period. This way we hope that the transition will be smoother.
>> On the other hand, the old code will be removed in 3.7 so the
>> overlapping period will not be so long.
>> I hope that it will allow people to track bugs if some are remaining and
>> switch to newer driver easily.
>
> Olof, Arnd,
>
> So, do you have made up your mind about this pull request?

Sorry for the delays in handling this, I should have been quicker at replying.

That said, the driver is staged for removal in 3.7, and this patch is
3.6 material at this time. But I think it makes sense to cut every
in-tree board over completely one release before the driver is
removed, and thus not keep the old platform data around for them.

That way the out-of-tree users still have a one-release grace period,
but everyone with an in-tree board (and the reference platforms) will
move over sooner. I think I would prefer that over having all these
ifdefs in the tree, even if it's just for one release.

I could be convinced otherwise if there's a good reason though. Either
way, 3.6 is the way to go.

-Olof
Nicolas Ferre - June 20, 2012, 7:45 a.m.
On 06/18/2012 03:49 PM, Olof Johansson :
> Hi,
> 
> On Wed, Jun 13, 2012 at 9:48 AM, Nicolas Ferre <nicolas.ferre@atmel.com> wrote:
>> On 06/04/2012 05:48 PM, Nicolas Ferre :
>>> On 05/31/2012 11:04 PM, Olof Johansson :
>>>> Hi Nicolas,
>>>>
>>>> On Thu, May 31, 2012 at 12:50 AM, Nicolas Ferre <nicolas.ferre@atmel.com
>>>> <mailto:nicolas.ferre@atmel.com>> wrote:
>>>>
>>>>     On 05/24/2012 05:12 PM, Nicolas Ferre :
>>>>     > Hi Arnd, hi Olof,
>>>>
>>>>     Ping?
>>>>
>>>>     (or maybe you will have a look at this after the merge window...)
>>>>
>>>>
>>>> So, I looked at this branch yesterday but I wasn't entirely happy with
>>>> the number of ifdefs it adds.
>>>
>>> Unfortunately, this is the usual shape of any devices/boards files on
>>> AT91. This amount will be reduced when we remove the old driver and when
>>> we move newer/popular devices to Device Tree...
>>>
>>>> If the idea is to deprecate the old driver, wouldn't it make more sense
>>>> to just cut everyone over instead of having both sets of setup in the
>>>> kernel?
>>>
>>> Well, the old driver has existed since a very long time and I think that
>>> people are used to it on oldest platforms. This is why we put in place a
>>> overlapping period. This way we hope that the transition will be smoother.
>>> On the other hand, the old code will be removed in 3.7 so the
>>> overlapping period will not be so long.
>>> I hope that it will allow people to track bugs if some are remaining and
>>> switch to newer driver easily.
>>
>> Olof, Arnd,
>>
>> So, do you have made up your mind about this pull request?
> 
> Sorry for the delays in handling this, I should have been quicker at replying.
> 
> That said, the driver is staged for removal in 3.7, and this patch is
> 3.6 material at this time. But I think it makes sense to cut every
> in-tree board over completely one release before the driver is
> removed, and thus not keep the old platform data around for them.
> 
> That way the out-of-tree users still have a one-release grace period,
> but everyone with an in-tree board (and the reference platforms) will
> move over sooner. I think I would prefer that over having all these
> ifdefs in the tree, even if it's just for one release.
> 
> I could be convinced otherwise if there's a good reason though. Either
> way, 3.6 is the way to go.

Fair enough, we will prepare a patch to remove the old platform data
combined with this patch. We will integrate in an "at91-3.6-soc"
series/branch that we will submit to you soon.

Thanks, best regards,
Arnd Bergmann - July 25, 2012, 8:06 p.m.
On Thursday 31 May 2012, Nicolas Ferre wrote:
> 
> On 05/24/2012 05:12 PM, Nicolas Ferre :
> > Hi Arnd, hi Olof,
> 
> Ping?
> 
> (or maybe you will have a look at this after the merge window...)
> 

I've just gone through all old pull requests that I had somewhere in
my inbox and this turned out to be one that we never pulled.

It looks like it still applies and we should send it to Linus as as
late branch this time, given that we screwed up and it was there
all the time.

Nicolas, can you please confirm?

	Arnd
ludovic.desroches@atmel.com - July 26, 2012, 8:35 a.m.
Hi Arnd,

Le 07/25/2012 10:06 PM, Arnd Bergmann a écrit :
> On Thursday 31 May 2012, Nicolas Ferre wrote:
>>
>> On 05/24/2012 05:12 PM, Nicolas Ferre :
>>> Hi Arnd, hi Olof,
>>
>> Ping?
>>
>> (or maybe you will have a look at this after the merge window...)
>>
>
> I've just gone through all old pull requests that I had somewhere in
> my inbox and this turned out to be one that we never pulled.
>
> It looks like it still applies and we should send it to Linus as as
> late branch this time, given that we screwed up and it was there
> all the time.
>
> Nicolas, can you please confirm?
>

Nicolas is on vacation, he'll be back on week 32.

Nicolas and Olof discussed about this addition of ifdefs to manage the 
two drivers. They agreed to remove platform data for the old driver.

It will be great to go ahead with this patch. I see three solutions:
- take the patch and we will do a new patch to remove old platform data 
for 3.7 when at91-mci will be totally removed but it seems that Olof 
doesn't like this solution.
- I can write a new patch to remove old platform data as planned by 
Nicolas. If Jean-Christophe gives his acked-by, you could take it.
- wait Nicolas' return but it may be too late then we won't have the 
smooth transition we wanted.


Regards

Ludovic
Nicolas Ferre - Aug. 7, 2012, 1:05 p.m.
On 07/26/2012 10:35 AM, ludovic.desroches :
> Hi Arnd,
> 
> Le 07/25/2012 10:06 PM, Arnd Bergmann a écrit :
>> On Thursday 31 May 2012, Nicolas Ferre wrote:
>>>
>>> On 05/24/2012 05:12 PM, Nicolas Ferre :
>>>> Hi Arnd, hi Olof,
>>>
>>> Ping?
>>>
>>> (or maybe you will have a look at this after the merge window...)
>>>
>>
>> I've just gone through all old pull requests that I had somewhere in
>> my inbox and this turned out to be one that we never pulled.
>>
>> It looks like it still applies and we should send it to Linus as as
>> late branch this time, given that we screwed up and it was there
>> all the time.
>>
>> Nicolas, can you please confirm?
>>
> 
> Nicolas is on vacation, he'll be back on week 32.
> 
> Nicolas and Olof discussed about this addition of ifdefs to manage the
> two drivers. They agreed to remove platform data for the old driver.
> 
> It will be great to go ahead with this patch. I see three solutions:
> - take the patch and we will do a new patch to remove old platform data
> for 3.7 when at91-mci will be totally removed but it seems that Olof
> doesn't like this solution.
> - I can write a new patch to remove old platform data as planned by
> Nicolas. If Jean-Christophe gives his acked-by, you could take it.
> - wait Nicolas' return but it may be too late then we won't have the
> smooth transition we wanted.

I am back in the game ;-)

I am about to rebuild a pull-request with what we discussed with Olof:
complete removal of old driver's platform data.

You still have the possibility to queue it as a late branch for 3.6...
(I keep it based on 3.5-rc, but I can rebase it on 3.6-rc1 to ease one
conflict resolution when merging with current Linus' tree).

Bye,
Nicolas Ferre - Aug. 10, 2012, 7:46 a.m.
On 07/25/2012 10:06 PM, Arnd Bergmann :
> On Thursday 31 May 2012, Nicolas Ferre wrote:
>>
>> On 05/24/2012 05:12 PM, Nicolas Ferre :
>>> Hi Arnd, hi Olof,
>>
>> Ping?
>>
>> (or maybe you will have a look at this after the merge window...)
>>
> 
> I've just gone through all old pull requests that I had somewhere in
> my inbox and this turned out to be one that we never pulled.
> 
> It looks like it still applies and we should send it to Linus as as
> late branch this time, given that we screwed up and it was there
> all the time.
> 
> Nicolas, can you please confirm?

Arnd,

I have sent to you a pull-request covering this work several days ago
([GIT PULL] at91: soc update (for 3.6)): what is your feeling about it:
do you think that it will still go upstream for 3.6?

Thanks, bye,