| Message ID | 4FBE4FE7.3010005@atmel.com |
|---|---|
| State | New |
| Headers | show |
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,
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
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,
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,
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
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,
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
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
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,
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,
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,