| Message ID | 1400059162-630-1-git-send-email-nicolas.ferre@atmel.com |
|---|---|
| State | New |
| Headers | show |
On Wed, May 14, 2014 at 11:19:22AM +0200, Nicolas Ferre wrote: > Arnd, Olof, Kevin, > > More DT material for AT91. Some fixes that apply on what was merged for 3.15 > but that are not very critical. > The other patches are feature additions to old or very recent product/board: > at91sam9261 or sama5d3 Xplained. > > Thanks, best regards, > > The following changes since commit 27a96a0364787d2b41d2a72d08143d95263e1b07: > > ARM: at91: sama5d3: clock for ssc from rk pin (2014-04-18 22:43:44 +0200) > > are available in the git repository at: > > git://github.com/at91linux/linux-at91.git tags/at91-dt2 > > for you to fetch changes up to a93f9c88b7701d1c4c3b22d39d64a408f000a6ef: > > ARM: at91/dt: at91-sama5d3_xplained: add the regulator device node (2014-05-12 16:48:54 +0200) Merged, but: > arch/arm/boot/dts/at91-sama5d3_xplained.dts | 62 +++++++++++++++ > arch/arm/boot/dts/at91sam9261.dtsi | 114 ++++++++++++++++++++++++++-- > arch/arm/boot/dts/at91sam9rl.dtsi | 7 +- > arch/arm/boot/dts/sama5d3.dtsi | 78 +++++++++++++++++++ Grmbl. I remember being somewhat annoyed that you didn't use at91 prefix when you introduced the sama5d3 dtsi files, but please don't start using it on a random board like this, especially when other boards just use the sama5d3_<board>.dts format. Care to fix this up in time for 3.16 merge window? Thanks, -Olof
On 20/05/2014 07:50, Olof Johansson : > On Wed, May 14, 2014 at 11:19:22AM +0200, Nicolas Ferre wrote: >> Arnd, Olof, Kevin, >> >> More DT material for AT91. Some fixes that apply on what was merged for 3.15 >> but that are not very critical. >> The other patches are feature additions to old or very recent product/board: >> at91sam9261 or sama5d3 Xplained. >> >> Thanks, best regards, >> >> The following changes since commit 27a96a0364787d2b41d2a72d08143d95263e1b07: >> >> ARM: at91: sama5d3: clock for ssc from rk pin (2014-04-18 22:43:44 +0200) >> >> are available in the git repository at: >> >> git://github.com/at91linux/linux-at91.git tags/at91-dt2 >> >> for you to fetch changes up to a93f9c88b7701d1c4c3b22d39d64a408f000a6ef: >> >> ARM: at91/dt: at91-sama5d3_xplained: add the regulator device node (2014-05-12 16:48:54 +0200) > > Merged, but: > >> arch/arm/boot/dts/at91-sama5d3_xplained.dts | 62 +++++++++++++++ >> arch/arm/boot/dts/at91sam9261.dtsi | 114 ++++++++++++++++++++++++++-- >> arch/arm/boot/dts/at91sam9rl.dtsi | 7 +- >> arch/arm/boot/dts/sama5d3.dtsi | 78 +++++++++++++++++++ > > Grmbl. I remember being somewhat annoyed that you didn't use at91 prefix > when you introduced the sama5d3 dtsi files, but please don't start using > it on a random board like this, especially when other boards just use > the sama5d3_<board>.dts format. Well, I don't understand completely. Since our discussion during 3.10 merge window ([GIT PULL] at91: DT changes for 3.10 #2), I try to conform to this rule: 1/ all pre-3.10 and 3.10 device tree file names stay unchanged -> sama5d3.dti (SoC) -> sama5d35ek.dts (board) 2/ all *SoC* DT files conform to their marking: at91sam9263.dtsi at91sam9rl.dtsi sama5d3.dtsi, sama5d36.dtsi sama5d4.dtsi, sama5d46.dtsi (maybe in the future, who knows...) 3/ all post-3.10 *boards* have the "at91-" prefix, whether they are populated with sam9 or sama5: at91-ariag25.dts (since 3.10, using a at91sam9g25) at91-qil_a9260.dts (since 3.14, using at91sam9260) at91-sama5d3_xplained.dts (since 3.14, using sama5d36) The rule for AT91 has never been to prefix the board DT filename with the name of the SoC or SoC family. > Care to fix this up in time for 3.16 merge window? Well, I do not know what to fix as the files were already present in mainline before this kernel revision and that I am a little bit reluctant to change file names after they are merged in mainline. Now, can we keep the current policy described above (somehow weird, I admit) for future SoCs and boards? Best regards,
Hi, On Tue, May 20, 2014 at 05:19:24PM +0200, Nicolas Ferre wrote: > On 20/05/2014 07:50, Olof Johansson : > > On Wed, May 14, 2014 at 11:19:22AM +0200, Nicolas Ferre wrote: > >> Arnd, Olof, Kevin, > >> > >> More DT material for AT91. Some fixes that apply on what was merged for 3.15 > >> but that are not very critical. > >> The other patches are feature additions to old or very recent product/board: > >> at91sam9261 or sama5d3 Xplained. > >> > >> Thanks, best regards, > >> > >> The following changes since commit 27a96a0364787d2b41d2a72d08143d95263e1b07: > >> > >> ARM: at91: sama5d3: clock for ssc from rk pin (2014-04-18 22:43:44 +0200) > >> > >> are available in the git repository at: > >> > >> git://github.com/at91linux/linux-at91.git tags/at91-dt2 > >> > >> for you to fetch changes up to a93f9c88b7701d1c4c3b22d39d64a408f000a6ef: > >> > >> ARM: at91/dt: at91-sama5d3_xplained: add the regulator device node (2014-05-12 16:48:54 +0200) > > > > Merged, but: > > > >> arch/arm/boot/dts/at91-sama5d3_xplained.dts | 62 +++++++++++++++ > >> arch/arm/boot/dts/at91sam9261.dtsi | 114 ++++++++++++++++++++++++++-- > >> arch/arm/boot/dts/at91sam9rl.dtsi | 7 +- > >> arch/arm/boot/dts/sama5d3.dtsi | 78 +++++++++++++++++++ > > > > Grmbl. I remember being somewhat annoyed that you didn't use at91 prefix > > when you introduced the sama5d3 dtsi files, but please don't start using > > it on a random board like this, especially when other boards just use > > the sama5d3_<board>.dts format. > > Well, I don't understand completely. Since our discussion during 3.10 > merge window ([GIT PULL] at91: DT changes for 3.10 #2), I try to conform > to this rule: > > 1/ all pre-3.10 and 3.10 device tree file names stay unchanged > -> sama5d3.dti (SoC) > -> sama5d35ek.dts (board) > > 2/ all *SoC* DT files conform to their marking: > at91sam9263.dtsi > at91sam9rl.dtsi > sama5d3.dtsi, sama5d36.dtsi > sama5d4.dtsi, sama5d46.dtsi (maybe in the future, who knows...) > > 3/ all post-3.10 *boards* have the "at91-" prefix, whether they are > populated with sam9 or sama5: > at91-ariag25.dts (since 3.10, using a at91sam9g25) > at91-qil_a9260.dts (since 3.14, using at91sam9260) > at91-sama5d3_xplained.dts (since 3.14, using sama5d36) > > The rule for AT91 has never been to prefix the board DT filename with > the name of the SoC or SoC family. So, going back and looking at the discussion from a year ago, I think the disconnect was in what consistency we were looking for. Yes, we would have preferred to prefix the sama5d3* dts/dtsis with at91, and you even offered to do it. ;-) But I think even more important for sanity is to stay consistent with how we handle all platforms, which is that the board dts files are prefixed with the SoC name. In the past, we've had cases where this didn't happen, but these days we have tried to be very consistent on it. I.e. omap3*, exynos<##>*, etc. So, if you have at91- as a prefix, have the SoC as the second component. But that gets awkward too, so I would juts use the current SoC dtsi as the prefix at91sam9263-<boardname>.dts, or sama5d35_<boardname>.dts. > > Care to fix this up in time for 3.16 merge window? > > Well, I do not know what to fix as the files were already present in > mainline before this kernel revision and that I am a little bit > reluctant to change file names after they are merged in mainline. > > Now, can we keep the current policy described above (somehow weird, I > admit) for future SoCs and boards? It is unfortunate that I didn't catch this for 3.14 so that name has been there in a release. I guess the least disruptive thing for now would be to change over to use the SoC dtsi prefix for any new board files from here on out, and treat at91-sama5d3_xplained as a one-time thing. -Olof
On May 20, 2014, at 1:50 PM, Olof Johansson <olof@lixom.net> wrote: > > On Wed, May 14, 2014 at 11:19:22AM +0200, Nicolas Ferre wrote: >> Arnd, Olof, Kevin, >> >> More DT material for AT91. Some fixes that apply on what was merged for 3.15 >> but that are not very critical. >> The other patches are feature additions to old or very recent product/board: >> at91sam9261 or sama5d3 Xplained. >> >> Thanks, best regards, >> >> The following changes since commit 27a96a0364787d2b41d2a72d08143d95263e1b07: >> >> ARM: at91: sama5d3: clock for ssc from rk pin (2014-04-18 22:43:44 +0200) >> >> are available in the git repository at: >> >> git://github.com/at91linux/linux-at91.git tags/at91-dt2 >> >> for you to fetch changes up to a93f9c88b7701d1c4c3b22d39d64a408f000a6ef: >> >> ARM: at91/dt: at91-sama5d3_xplained: add the regulator device node (2014-05-12 16:48:54 +0200) > > Merged, but: > >> arch/arm/boot/dts/at91-sama5d3_xplained.dts | 62 +++++++++++++++ >> arch/arm/boot/dts/at91sam9261.dtsi | 114 ++++++++++++++++++++++++++-- >> arch/arm/boot/dts/at91sam9rl.dtsi | 7 +- >> arch/arm/boot/dts/sama5d3.dtsi | 78 +++++++++++++++++++ > > Grmbl. I remember being somewhat annoyed that you didn't use at91 prefix > when you introduced the sama5d3 dtsi files, but please don't start using > it on a random board like this, especially when other boards just use > the sama5d3_<board>.dts format. > > Care to fix this up in time for 3.16 merge window? there is a small issue here Atmel drop the at91 in the soc name Best Regards, J. > > > Thanks, > > -Olof
On 20/05/2014 18:47, Olof Johansson : > Hi, > > On Tue, May 20, 2014 at 05:19:24PM +0200, Nicolas Ferre wrote: >> On 20/05/2014 07:50, Olof Johansson : >>> On Wed, May 14, 2014 at 11:19:22AM +0200, Nicolas Ferre wrote: >>>> Arnd, Olof, Kevin, >>>> >>>> More DT material for AT91. Some fixes that apply on what was merged for 3.15 >>>> but that are not very critical. >>>> The other patches are feature additions to old or very recent product/board: >>>> at91sam9261 or sama5d3 Xplained. >>>> >>>> Thanks, best regards, >>>> >>>> The following changes since commit 27a96a0364787d2b41d2a72d08143d95263e1b07: >>>> >>>> ARM: at91: sama5d3: clock for ssc from rk pin (2014-04-18 22:43:44 +0200) >>>> >>>> are available in the git repository at: >>>> >>>> git://github.com/at91linux/linux-at91.git tags/at91-dt2 >>>> >>>> for you to fetch changes up to a93f9c88b7701d1c4c3b22d39d64a408f000a6ef: >>>> >>>> ARM: at91/dt: at91-sama5d3_xplained: add the regulator device node (2014-05-12 16:48:54 +0200) >>> >>> Merged, but: >>> >>>> arch/arm/boot/dts/at91-sama5d3_xplained.dts | 62 +++++++++++++++ >>>> arch/arm/boot/dts/at91sam9261.dtsi | 114 ++++++++++++++++++++++++++-- >>>> arch/arm/boot/dts/at91sam9rl.dtsi | 7 +- >>>> arch/arm/boot/dts/sama5d3.dtsi | 78 +++++++++++++++++++ >>> >>> Grmbl. I remember being somewhat annoyed that you didn't use at91 prefix >>> when you introduced the sama5d3 dtsi files, but please don't start using >>> it on a random board like this, especially when other boards just use >>> the sama5d3_<board>.dts format. >> >> Well, I don't understand completely. Since our discussion during 3.10 >> merge window ([GIT PULL] at91: DT changes for 3.10 #2), I try to conform >> to this rule: >> >> 1/ all pre-3.10 and 3.10 device tree file names stay unchanged >> -> sama5d3.dti (SoC) >> -> sama5d35ek.dts (board) >> >> 2/ all *SoC* DT files conform to their marking: >> at91sam9263.dtsi >> at91sam9rl.dtsi >> sama5d3.dtsi, sama5d36.dtsi >> sama5d4.dtsi, sama5d46.dtsi (maybe in the future, who knows...) >> >> 3/ all post-3.10 *boards* have the "at91-" prefix, whether they are >> populated with sam9 or sama5: >> at91-ariag25.dts (since 3.10, using a at91sam9g25) >> at91-qil_a9260.dts (since 3.14, using at91sam9260) >> at91-sama5d3_xplained.dts (since 3.14, using sama5d36) >> >> The rule for AT91 has never been to prefix the board DT filename with >> the name of the SoC or SoC family. > > So, going back and looking at the discussion from a year ago, I think the > disconnect was in what consistency we were looking for. Yes, we would have > preferred to prefix the sama5d3* dts/dtsis with at91, and you even > offered to do it. ;-) But I think even more important for sanity is > to stay consistent with how we handle all platforms, which is that the > board dts files are prefixed with the SoC name. > > In the past, we've had cases where this didn't happen, but these days we have > tried to be very consistent on it. I.e. omap3*, exynos<##>*, etc. Okay, but once again, I tried to deal with the existing files, not break any user's habit, before any convention had been clearly established, and now... we are reaching a deadlock having to re-consider again our DT filenames? > So, if you have at91- as a prefix, have the SoC as the second component. But > that gets awkward too, so I would juts use the current SoC dtsi as the prefix > at91sam9263-<boardname>.dts, or sama5d35_<boardname>.dts. > >>> Care to fix this up in time for 3.16 merge window? >> >> Well, I do not know what to fix as the files were already present in >> mainline before this kernel revision and that I am a little bit >> reluctant to change file names after they are merged in mainline. >> >> Now, can we keep the current policy described above (somehow weird, I >> admit) for future SoCs and boards? > > It is unfortunate that I didn't catch this for 3.14 so that name has been > there in a release. I guess the least disruptive thing for now would be > to change over to use the SoC dtsi prefix for any new board files from > here on out, and treat at91-sama5d3_xplained as a one-time thing. That is not only about sama5d3, what about sam9-based boards? Several of them already have this "at91-" prefix (and not a soc prefix). So this will introduce another temporary naming convention for these files which are actually used by people: everyone will be puzzled. Okay, there are two ways to escape this situation: 1/ change nothing and conform to what I stated above. It is more like finding a rationale to an existing situation than a real neat policy, but hey, "nobody's perfect". 2/ change *everything* in AT91 DT file naming with a schema that we will have to validate with care (<soc family> or <soc>, "_" or "-", what about boards with modules, etc.). That will certainly disturb many of our users without a real benefit. This directory is flat, the board names are chosen by companies and people that we do not control, a user tend to like finding his preferred board dtb file unchanged from a kernel revision to another... Well all this lead me to think that we don't have to loose too much time thinking about a new strict convention for this file naming or changing all this once again just for the sake of it. Other SoC maintainers beautifully designed from the beginning the naming scheme of their DT files, fine. AT91 did not and forgive me but when opening arch/arm/boot/dts/Makefile file and seeing some file names, I'm not ashamed. Moreover, now that I said to everybody since 3.10 to prefix their *board* name with "at91-", I have to say something else, I don't think it is worth it. Bye,
On Wed, May 21, 2014 at 12:17:09PM +0200, Nicolas Ferre wrote: > On 20/05/2014 18:47, Olof Johansson : > > Hi, > > > > On Tue, May 20, 2014 at 05:19:24PM +0200, Nicolas Ferre wrote: > >> On 20/05/2014 07:50, Olof Johansson : > >>> On Wed, May 14, 2014 at 11:19:22AM +0200, Nicolas Ferre wrote: > >>>> Arnd, Olof, Kevin, > >>>> > >>>> More DT material for AT91. Some fixes that apply on what was merged for 3.15 > >>>> but that are not very critical. > >>>> The other patches are feature additions to old or very recent product/board: > >>>> at91sam9261 or sama5d3 Xplained. > >>>> > >>>> Thanks, best regards, > >>>> > >>>> The following changes since commit 27a96a0364787d2b41d2a72d08143d95263e1b07: > >>>> > >>>> ARM: at91: sama5d3: clock for ssc from rk pin (2014-04-18 22:43:44 +0200) > >>>> > >>>> are available in the git repository at: > >>>> > >>>> git://github.com/at91linux/linux-at91.git tags/at91-dt2 > >>>> > >>>> for you to fetch changes up to a93f9c88b7701d1c4c3b22d39d64a408f000a6ef: > >>>> > >>>> ARM: at91/dt: at91-sama5d3_xplained: add the regulator device node (2014-05-12 16:48:54 +0200) > >>> > >>> Merged, but: > >>> > >>>> arch/arm/boot/dts/at91-sama5d3_xplained.dts | 62 +++++++++++++++ > >>>> arch/arm/boot/dts/at91sam9261.dtsi | 114 ++++++++++++++++++++++++++-- > >>>> arch/arm/boot/dts/at91sam9rl.dtsi | 7 +- > >>>> arch/arm/boot/dts/sama5d3.dtsi | 78 +++++++++++++++++++ > >>> > >>> Grmbl. I remember being somewhat annoyed that you didn't use at91 prefix > >>> when you introduced the sama5d3 dtsi files, but please don't start using > >>> it on a random board like this, especially when other boards just use > >>> the sama5d3_<board>.dts format. > >> > >> Well, I don't understand completely. Since our discussion during 3.10 > >> merge window ([GIT PULL] at91: DT changes for 3.10 #2), I try to conform > >> to this rule: > >> > >> 1/ all pre-3.10 and 3.10 device tree file names stay unchanged > >> -> sama5d3.dti (SoC) > >> -> sama5d35ek.dts (board) > >> > >> 2/ all *SoC* DT files conform to their marking: > >> at91sam9263.dtsi > >> at91sam9rl.dtsi > >> sama5d3.dtsi, sama5d36.dtsi > >> sama5d4.dtsi, sama5d46.dtsi (maybe in the future, who knows...) > >> > >> 3/ all post-3.10 *boards* have the "at91-" prefix, whether they are > >> populated with sam9 or sama5: > >> at91-ariag25.dts (since 3.10, using a at91sam9g25) > >> at91-qil_a9260.dts (since 3.14, using at91sam9260) > >> at91-sama5d3_xplained.dts (since 3.14, using sama5d36) > >> > >> The rule for AT91 has never been to prefix the board DT filename with > >> the name of the SoC or SoC family. > > > > So, going back and looking at the discussion from a year ago, I think the > > disconnect was in what consistency we were looking for. Yes, we would have > > preferred to prefix the sama5d3* dts/dtsis with at91, and you even > > offered to do it. ;-) But I think even more important for sanity is > > to stay consistent with how we handle all platforms, which is that the > > board dts files are prefixed with the SoC name. > > > > In the past, we've had cases where this didn't happen, but these days we have > > tried to be very consistent on it. I.e. omap3*, exynos<##>*, etc. > > Okay, but once again, I tried to deal with the existing files, not break > any user's habit, before any convention had been clearly established, > and now... we are reaching a deadlock having to re-consider again our DT > filenames? I don't think we're at a deadlock here. We're trying to figure out the best way forward. > > > So, if you have at91- as a prefix, have the SoC as the second component. But > > that gets awkward too, so I would juts use the current SoC dtsi as the prefix > > at91sam9263-<boardname>.dts, or sama5d35_<boardname>.dts. > > > >>> Care to fix this up in time for 3.16 merge window? > >> > >> Well, I do not know what to fix as the files were already present in > >> mainline before this kernel revision and that I am a little bit > >> reluctant to change file names after they are merged in mainline. > >> > >> Now, can we keep the current policy described above (somehow weird, I > >> admit) for future SoCs and boards? > > > > It is unfortunate that I didn't catch this for 3.14 so that name has been > > there in a release. I guess the least disruptive thing for now would be > > to change over to use the SoC dtsi prefix for any new board files from > > here on out, and treat at91-sama5d3_xplained as a one-time thing. > > That is not only about sama5d3, what about sam9-based boards? Several of > them already have this "at91-" prefix (and not a soc prefix). > > So this will introduce another temporary naming convention for these > files which are actually used by people: everyone will be puzzled. Yes, everyone is already puzzled though. > Okay, there are two ways to escape this situation: > 1/ change nothing and conform to what I stated above. It is more like > finding a rationale to an existing situation than a real neat > policy, but hey, "nobody's perfect". > 2/ change *everything* in AT91 DT file naming with a schema that > we will have to validate with care (<soc family> or <soc>, > "_" or "-", what about boards with modules, etc.). > That will certainly disturb many of our users without a real benefit. I don't think it's worth renaming everything at this time. > This directory is flat, the board names are chosen by companies and > people that we do not control, a user tend to like finding his preferred > board dtb file unchanged from a kernel revision to another... > Well all this lead me to think that we don't have to loose too much time > thinking about a new strict convention for this file naming or changing > all this once again just for the sake of it. > > Other SoC maintainers beautifully designed from the beginning the naming > scheme of their DT files, fine. AT91 did not and forgive me but when > opening arch/arm/boot/dts/Makefile file and seeing some file names, I'm > not ashamed. Moreover, now that I said to everybody since 3.10 to prefix > their *board* name with "at91-", I have to say something else, I don't > think it is worth it. I don't agree with everything above, but it's not worth arguing for the sake of arguing. :) I think we can tweak what you're doing now and get things to work well by merging new dts files with at91-<soc>-board.dts as the name. As mentioned, don't worry about the existing files. This shouldn't be a significiant change to what you've been telling people since 3.10 to cause much confusion. -Olof
On Wed, May 21, 2014 at 2:11 PM, Olof Johansson <olof@lixom.net> wrote: > I don't agree with everything above, but it's not worth arguing for the > sake of arguing. :) I think we can tweak what you're doing now and get > things to work well by merging new dts files with at91-<soc>-board.dts > as the name. As mentioned, don't worry about the existing files. This > shouldn't be a significiant change to what you've been telling people > since 3.10 to cause much confusion. A the end of the day, as long as you have at91- as prefix we'll be OK I think. If you can consistently add the SoC into the prefix as above, we'll be even better. But I'm not going to spend more time arguing it. :) Either way, consistency (going forward) with at91- is good. -Olof
Hi, On 21/05/2014 at 14:11:05 -0700, Olof Johansson wrote : > > This directory is flat, the board names are chosen by companies and > > people that we do not control, a user tend to like finding his preferred > > board dtb file unchanged from a kernel revision to another... > > Well all this lead me to think that we don't have to loose too much time > > thinking about a new strict convention for this file naming or changing > > all this once again just for the sake of it. > > > > Other SoC maintainers beautifully designed from the beginning the naming > > scheme of their DT files, fine. AT91 did not and forgive me but when > > opening arch/arm/boot/dts/Makefile file and seeing some file names, I'm > > not ashamed. Moreover, now that I said to everybody since 3.10 to prefix > > their *board* name with "at91-", I have to say something else, I don't > > think it is worth it. > > I don't agree with everything above, but it's not worth arguing for the > sake of arguing. :) I think we can tweak what you're doing now and get > things to work well by merging new dts files with at91-<soc>-board.dts > as the name. As mentioned, don't worry about the existing files. This > shouldn't be a significiant change to what you've been telling people > since 3.10 to cause much confusion. > I'm not sure we should keep the at91 prefix. The sama5d3 series is not at91. I would suggest using <soc>-<vendor>-<board> in the future, like what is done for mvebu, berlin and some omap3 and freescale boards. I would however make an exception for the evaluation kits and keep the current "<soc>ek" name (else we would get sama5d3-atmel-sama5d3ek). I also got confused by the at91- prefix when looking for a few dts files but I think it is too late to rename now or maybe we could do it all at once for a long term release (provided we know which one it will be). For reference, the list of files that would need renaming: animeo_ip.dts at91-ariag25.dts at91-cosino.dtsi at91-cosino_mega2560.dts at91-foxg20.dts at91-qil_a9260.dts ethernut5.dts ge863-pro3.dtsi kizbox.dts mpa1600.dts pm9g45.dts tny_a9260.dts tny_a9263.dts tny_a9g20.dts usb_a9260.dts usb_a9263.dts usb_a9g20_common.dtsi aks-cdu.dts evk-pro3.dts at91-sama5d3_xplained.dts
On Wed, May 21, 2014 at 2:42 PM, Alexandre Belloni <alexandre.belloni@free-electrons.com> wrote: > Hi, > > On 21/05/2014 at 14:11:05 -0700, Olof Johansson wrote : >> > This directory is flat, the board names are chosen by companies and >> > people that we do not control, a user tend to like finding his preferred >> > board dtb file unchanged from a kernel revision to another... >> > Well all this lead me to think that we don't have to loose too much time >> > thinking about a new strict convention for this file naming or changing >> > all this once again just for the sake of it. >> > >> > Other SoC maintainers beautifully designed from the beginning the naming >> > scheme of their DT files, fine. AT91 did not and forgive me but when >> > opening arch/arm/boot/dts/Makefile file and seeing some file names, I'm >> > not ashamed. Moreover, now that I said to everybody since 3.10 to prefix >> > their *board* name with "at91-", I have to say something else, I don't >> > think it is worth it. >> >> I don't agree with everything above, but it's not worth arguing for the >> sake of arguing. :) I think we can tweak what you're doing now and get >> things to work well by merging new dts files with at91-<soc>-board.dts >> as the name. As mentioned, don't worry about the existing files. This >> shouldn't be a significiant change to what you've been telling people >> since 3.10 to cause much confusion. >> > > I'm not sure we should keep the at91 prefix. The sama5d3 series is not > at91. *headdesk* It's part of mach-at91. For all intents and purposes, the label fits. > I would suggest using <soc>-<vendor>-<board> in the future, like what is > done for mvebu, berlin and some omap3 and freescale boards. I would > however make an exception for the evaluation kits and keep the current > "<soc>ek" name (else we would get sama5d3-atmel-sama5d3ek). Nack on this as a hard rule. As long as there's a vendor or (large family) SoC prefix I don't care about the rest of the structure. Really, let's not waste time on it at this time. > I also got confused by the at91- prefix when looking for a few dts files > but I think it is too late to rename now or maybe we could do it all at > once for a long term release (provided we know which one it will be). > > For reference, the list of files that would need renaming: > animeo_ip.dts > at91-ariag25.dts > at91-cosino.dtsi > at91-cosino_mega2560.dts > at91-foxg20.dts > at91-qil_a9260.dts > ethernut5.dts > ge863-pro3.dtsi > kizbox.dts > mpa1600.dts > pm9g45.dts > tny_a9260.dts > tny_a9263.dts > tny_a9g20.dts > usb_a9260.dts > usb_a9263.dts > usb_a9g20_common.dtsi > aks-cdu.dts > evk-pro3.dts > at91-sama5d3_xplained.dts The DTS name is somewhat irritating in that installers and other environments (my own tester included) rely on file names. There's been a bunch of discussion about this in the past, but at the end of the day, you end up irritating people when you rename the resulting dtbs. As long as we don't keep adding random names beyond those, we should be OK. -Olof
On 21/05/2014 23:51, Olof Johansson : > On Wed, May 21, 2014 at 2:42 PM, Alexandre Belloni > <alexandre.belloni@free-electrons.com> wrote: >> Hi, >> >> On 21/05/2014 at 14:11:05 -0700, Olof Johansson wrote : >>>> This directory is flat, the board names are chosen by companies and >>>> people that we do not control, a user tend to like finding his preferred >>>> board dtb file unchanged from a kernel revision to another... >>>> Well all this lead me to think that we don't have to loose too much time >>>> thinking about a new strict convention for this file naming or changing >>>> all this once again just for the sake of it. >>>> >>>> Other SoC maintainers beautifully designed from the beginning the naming >>>> scheme of their DT files, fine. AT91 did not and forgive me but when >>>> opening arch/arm/boot/dts/Makefile file and seeing some file names, I'm >>>> not ashamed. Moreover, now that I said to everybody since 3.10 to prefix >>>> their *board* name with "at91-", I have to say something else, I don't >>>> think it is worth it. >>> >>> I don't agree with everything above, but it's not worth arguing for the >>> sake of arguing. :) I think we can tweak what you're doing now and get >>> things to work well by merging new dts files with at91-<soc>-board.dts >>> as the name. As mentioned, don't worry about the existing files. This >>> shouldn't be a significiant change to what you've been telling people >>> since 3.10 to cause much confusion. >>> >> >> I'm not sure we should keep the at91 prefix. The sama5d3 series is not >> at91. > > *headdesk* It's part of mach-at91. For all intents and purposes, the label fits. *double facepalm* Alexandre... always teasing ;-) (found "double facepalm" while searching for headdesk in google image, was fun...) >> I would suggest using <soc>-<vendor>-<board> in the future, like what is >> done for mvebu, berlin and some omap3 and freescale boards. I would >> however make an exception for the evaluation kits and keep the current >> "<soc>ek" name (else we would get sama5d3-atmel-sama5d3ek). > > Nack on this as a hard rule. As long as there's a vendor or (large > family) SoC prefix I don't care about the rest of the structure. > Really, let's not waste time on it at this time. > >> I also got confused by the at91- prefix when looking for a few dts files >> but I think it is too late to rename now or maybe we could do it all at >> once for a long term release (provided we know which one it will be). >> >> For reference, the list of files that would need renaming: >> animeo_ip.dts >> at91-ariag25.dts >> at91-cosino.dtsi >> at91-cosino_mega2560.dts >> at91-foxg20.dts >> at91-qil_a9260.dts >> ethernut5.dts >> ge863-pro3.dtsi >> kizbox.dts >> mpa1600.dts >> pm9g45.dts >> tny_a9260.dts >> tny_a9263.dts >> tny_a9g20.dts >> usb_a9260.dts >> usb_a9263.dts >> usb_a9g20_common.dtsi >> aks-cdu.dts >> evk-pro3.dts >> at91-sama5d3_xplained.dts > > The DTS name is somewhat irritating in that installers and other > environments (my own tester included) rely on file names. There's been > a bunch of discussion about this in the past, but at the end of the > day, you end up irritating people when you rename the resulting dtbs. > > As long as we don't keep adding random names beyond those, we should be OK. I okay with all you said Olof. I'll try to keep this file naming sensible even with all the legacy that we already have. Bye,
Arnd, Olof, Kevin, More DT material for AT91. Some fixes that apply on what was merged for 3.15 but that are not very critical. The other patches are feature additions to old or very recent product/board: at91sam9261 or sama5d3 Xplained. Thanks, best regards, The following changes since commit 27a96a0364787d2b41d2a72d08143d95263e1b07: ARM: at91: sama5d3: clock for ssc from rk pin (2014-04-18 22:43:44 +0200) are available in the git repository at: git://github.com/at91linux/linux-at91.git tags/at91-dt2 for you to fetch changes up to a93f9c88b7701d1c4c3b22d39d64a408f000a6ef: ARM: at91/dt: at91-sama5d3_xplained: add the regulator device node (2014-05-12 16:48:54 +0200) ---------------------------------------------------------------- 3.16: second DT series: - at91sam9rl and at91sam9261 fixes about PLL ranges - at91sam9261 more comprehensive support for SSC - sama5d3 Xplained: addition of pull-ups, PWM and PMIC (regulator) ---------------------------------------------------------------- Alexandre Belloni (3): ARM: at91/dt: sam9261: Fix PLL output ranges and other clocks divisors ARM: at91/dt: sam9261: Add ssc2, SSC clocks and pcks ARM: at91/dt: sam9rl: Fix PLL output range and mck divisors Nicolas Ferre (3): ARM: at91: add pull-up to i2c[02] on SAMA5D3 Xplained ARM: at91: add PWM pinctrl to SAMA5D3 ARM: at91: add 2 PWM outputs to SAMA5D3 Xplained Wenyou Yang (1): ARM: at91/dt: at91-sama5d3_xplained: add the regulator device node arch/arm/boot/dts/at91-sama5d3_xplained.dts | 62 +++++++++++++++ arch/arm/boot/dts/at91sam9261.dtsi | 114 ++++++++++++++++++++++++++-- arch/arm/boot/dts/at91sam9rl.dtsi | 7 +- arch/arm/boot/dts/sama5d3.dtsi | 78 +++++++++++++++++++ 4 files changed, 253 insertions(+), 8 deletions(-)