Message ID | 1364569179-24773-1-git-send-email-nicolas.ferre@atmel.com |
---|---|
State | New |
Headers | show |
On Fri, Mar 29, 2013 at 03:59:39PM +0100, Nicolas Ferre wrote: > Arnd, Olof, > > Here is a pull-request for AT91 that is dedicated to Device Tree > modifications. It is stacked on the material that you already have > for 3.10 in your arm-soc/at91/dt branch. > Following our discussion with Arnd, I added the non-urgent patches that I > already proposed too late for 3.9. I also included the moving of macb node > and kept the original patch. > > Thanks, best regards, > > The following changes since commit 6901d947be5ba1245a0f63271355b95f9056a362: > > ARM: at91/at91sam9x5cm: add 1-wire chip on CM board (2013-03-21 16:07:15 +0100) > > are available in the git repository at: > > git://github.com/at91linux/linux-at91.git tags/at91-dt > > for you to fetch changes up to cc2e191b0ccc5a987fdb29261ab9c264c608924d: > > ARM: at91/dt: fix macb node declaration (2013-03-29 10:02:04 +0100) > > ---------------------------------------------------------------- > One macb DT node move for 9x5 family: 9g15 doesn't > have an Ethernet interface. > Little fixes mainly related to at91sam9x5 DT and the > RTC addition. > Addition of the Acme Systems Aria G25 board. > > ---------------------------------------------------------------- > Douglas Gilbert (1): > ARM: at91: add Acme Systems Aria G25 board Hi, I just replied to the above patch -- please prefix the dts files with the platform so it's easier to navigate the directory. Otherwise the branch contents looks good, so send a fresh request when you've respun. Also, the new dts isn't added to the Makefile, please add it. -Olof
On 04/02/2013 08:49 PM, Olof Johansson : > On Fri, Mar 29, 2013 at 03:59:39PM +0100, Nicolas Ferre wrote: >> Arnd, Olof, >> >> Here is a pull-request for AT91 that is dedicated to Device Tree >> modifications. It is stacked on the material that you already have >> for 3.10 in your arm-soc/at91/dt branch. >> Following our discussion with Arnd, I added the non-urgent patches that I >> already proposed too late for 3.9. I also included the moving of macb node >> and kept the original patch. >> >> Thanks, best regards, >> >> The following changes since commit 6901d947be5ba1245a0f63271355b95f9056a362: >> >> ARM: at91/at91sam9x5cm: add 1-wire chip on CM board (2013-03-21 16:07:15 +0100) >> >> are available in the git repository at: >> >> git://github.com/at91linux/linux-at91.git tags/at91-dt >> >> for you to fetch changes up to cc2e191b0ccc5a987fdb29261ab9c264c608924d: >> >> ARM: at91/dt: fix macb node declaration (2013-03-29 10:02:04 +0100) >> >> ---------------------------------------------------------------- >> One macb DT node move for 9x5 family: 9g15 doesn't >> have an Ethernet interface. >> Little fixes mainly related to at91sam9x5 DT and the >> RTC addition. >> Addition of the Acme Systems Aria G25 board. >> >> ---------------------------------------------------------------- >> Douglas Gilbert (1): >> ARM: at91: add Acme Systems Aria G25 board > > Hi, > > I just replied to the above patch -- please prefix the dts files with the > platform so it's easier to navigate the directory. Yes, I have to make sure that everybody agree on our side... > Otherwise the branch contents looks good, so send a fresh request when you've > respun. > > Also, the new dts isn't added to the Makefile, please add it. Ok, I will do. Maybe I can also stack a DT related patch about ADC support that I was planning to add in another pull-request covering the same topic. Thanks, best regards,
On 04/03/2013 09:45 AM, Nicolas Ferre : > On 04/02/2013 08:49 PM, Olof Johansson : >> On Fri, Mar 29, 2013 at 03:59:39PM +0100, Nicolas Ferre wrote: >>> Arnd, Olof, >>> >>> Here is a pull-request for AT91 that is dedicated to Device Tree >>> modifications. It is stacked on the material that you already have >>> for 3.10 in your arm-soc/at91/dt branch. >>> Following our discussion with Arnd, I added the non-urgent patches that I >>> already proposed too late for 3.9. I also included the moving of macb node >>> and kept the original patch. >>> >>> Thanks, best regards, >>> >>> The following changes since commit 6901d947be5ba1245a0f63271355b95f9056a362: >>> >>> ARM: at91/at91sam9x5cm: add 1-wire chip on CM board (2013-03-21 16:07:15 +0100) >>> >>> are available in the git repository at: >>> >>> git://github.com/at91linux/linux-at91.git tags/at91-dt >>> >>> for you to fetch changes up to cc2e191b0ccc5a987fdb29261ab9c264c608924d: >>> >>> ARM: at91/dt: fix macb node declaration (2013-03-29 10:02:04 +0100) >>> >>> ---------------------------------------------------------------- >>> One macb DT node move for 9x5 family: 9g15 doesn't >>> have an Ethernet interface. >>> Little fixes mainly related to at91sam9x5 DT and the >>> RTC addition. >>> Addition of the Acme Systems Aria G25 board. >>> >>> ---------------------------------------------------------------- >>> Douglas Gilbert (1): >>> ARM: at91: add Acme Systems Aria G25 board >> >> Hi, >> >> I just replied to the above patch -- please prefix the dts files with the >> platform so it's easier to navigate the directory. I do not want to spark a debate here, but moving to directories per "mach" earlier would have made things easier. If I recall well, Jean-Christophe has proposed it a long time ago... > Yes, I have to make sure that everybody agree on our side... The difficult point with this prefix... well it is difficult to tell... our product will never be called "at91" again! So, yes, our Linux identity is still "at91" and we are pretty attached to it but our newer products are named "sam" + "core" + "product family" which results in our newer family: "sama5d3" (note the at91 is missing)... => anyway, we think that the at91 prefix is still vivid in Linux community and we consider it as a good choice for now. So, I may rename the newly introduced "sama5d3*.dts[i]" files with "at91-sama5d3*.dts[i]" (while .c/.h files will remain the same). >> Otherwise the branch contents looks good, so send a fresh request when you've >> respun. >> >> Also, the new dts isn't added to the Makefile, please add it. > > Ok, I will do. Maybe I can also stack a DT related patch about ADC > support that I was planning to add in another pull-request covering the > same topic. > > Thanks, best regards, >
On Thu, Apr 4, 2013 at 2:37 AM, Nicolas Ferre <nicolas.ferre@atmel.com> wrote: > On 04/03/2013 09:45 AM, Nicolas Ferre : >> On 04/02/2013 08:49 PM, Olof Johansson : >>> On Fri, Mar 29, 2013 at 03:59:39PM +0100, Nicolas Ferre wrote: >>>> Arnd, Olof, >>>> >>>> Here is a pull-request for AT91 that is dedicated to Device Tree >>>> modifications. It is stacked on the material that you already have >>>> for 3.10 in your arm-soc/at91/dt branch. >>>> Following our discussion with Arnd, I added the non-urgent patches that I >>>> already proposed too late for 3.9. I also included the moving of macb node >>>> and kept the original patch. >>>> >>>> Thanks, best regards, >>>> >>>> The following changes since commit 6901d947be5ba1245a0f63271355b95f9056a362: >>>> >>>> ARM: at91/at91sam9x5cm: add 1-wire chip on CM board (2013-03-21 16:07:15 +0100) >>>> >>>> are available in the git repository at: >>>> >>>> git://github.com/at91linux/linux-at91.git tags/at91-dt >>>> >>>> for you to fetch changes up to cc2e191b0ccc5a987fdb29261ab9c264c608924d: >>>> >>>> ARM: at91/dt: fix macb node declaration (2013-03-29 10:02:04 +0100) >>>> >>>> ---------------------------------------------------------------- >>>> One macb DT node move for 9x5 family: 9g15 doesn't >>>> have an Ethernet interface. >>>> Little fixes mainly related to at91sam9x5 DT and the >>>> RTC addition. >>>> Addition of the Acme Systems Aria G25 board. >>>> >>>> ---------------------------------------------------------------- >>>> Douglas Gilbert (1): >>>> ARM: at91: add Acme Systems Aria G25 board >>> >>> Hi, >>> >>> I just replied to the above patch -- please prefix the dts files with the >>> platform so it's easier to navigate the directory. > > I do not want to spark a debate here, but moving to directories per > "mach" earlier would have made things easier. If I recall well, > Jean-Christophe has proposed it a long time ago... Yeah, we're at a size where it's starting to be warranted (powerpc does so already). It does cut down on the cross-exposure and review though and puts everyone in their own little sandbox, so there's some benefit in keeping it flat. I think that benefit is losing its appeal though. But let's hold off for another couple of releases with the churn of moving things out in subdirectories. >> Yes, I have to make sure that everybody agree on our side... > > The difficult point with this prefix... well it is difficult to tell... > our product will never be called "at91" again! That's a marketing issue, not a technical kernel one. If we create subdirectory it makes sense to name it 'atmel' instead of 'at91' though, I'm sure. > So, yes, our Linux identity is still "at91" and we are pretty attached > to it but our newer products are named "sam" + "core" + "product family" > which results in our newer family: "sama5d3" (note the at91 is missing)... > => anyway, we think that the at91 prefix is still vivid in Linux > community and we consider it as a good choice for now. > So, I may rename the newly introduced "sama5d3*.dts[i]" files with > "at91-sama5d3*.dts[i]" (while .c/.h files will remain the same). Sounds reasonable, or stick to the same format as you already have with at91sam9 families. When we move to subdirectories it might make sense to stick them under 'atmel' instead of 'at91' though and drop the prefix. -Olof
On 10:19 Thu 04 Apr , Olof Johansson wrote: > On Thu, Apr 4, 2013 at 2:37 AM, Nicolas Ferre <nicolas.ferre@atmel.com> wrote: > > On 04/03/2013 09:45 AM, Nicolas Ferre : > >> On 04/02/2013 08:49 PM, Olof Johansson : > >>> On Fri, Mar 29, 2013 at 03:59:39PM +0100, Nicolas Ferre wrote: > >>>> Arnd, Olof, > >>>> > >>>> Here is a pull-request for AT91 that is dedicated to Device Tree > >>>> modifications. It is stacked on the material that you already have > >>>> for 3.10 in your arm-soc/at91/dt branch. > >>>> Following our discussion with Arnd, I added the non-urgent patches that I > >>>> already proposed too late for 3.9. I also included the moving of macb node > >>>> and kept the original patch. > >>>> > >>>> Thanks, best regards, > >>>> > >>>> The following changes since commit 6901d947be5ba1245a0f63271355b95f9056a362: > >>>> > >>>> ARM: at91/at91sam9x5cm: add 1-wire chip on CM board (2013-03-21 16:07:15 +0100) > >>>> > >>>> are available in the git repository at: > >>>> > >>>> git://github.com/at91linux/linux-at91.git tags/at91-dt > >>>> > >>>> for you to fetch changes up to cc2e191b0ccc5a987fdb29261ab9c264c608924d: > >>>> > >>>> ARM: at91/dt: fix macb node declaration (2013-03-29 10:02:04 +0100) > >>>> > >>>> ---------------------------------------------------------------- > >>>> One macb DT node move for 9x5 family: 9g15 doesn't > >>>> have an Ethernet interface. > >>>> Little fixes mainly related to at91sam9x5 DT and the > >>>> RTC addition. > >>>> Addition of the Acme Systems Aria G25 board. > >>>> > >>>> ---------------------------------------------------------------- > >>>> Douglas Gilbert (1): > >>>> ARM: at91: add Acme Systems Aria G25 board > >>> > >>> Hi, > >>> > >>> I just replied to the above patch -- please prefix the dts files with the > >>> platform so it's easier to navigate the directory. > > > > I do not want to spark a debate here, but moving to directories per > > "mach" earlier would have made things easier. If I recall well, > > Jean-Christophe has proposed it a long time ago... > > Yeah, we're at a size where it's starting to be warranted (powerpc > does so already). It does cut down on the cross-exposure and review > though and puts everyone in their own little sandbox, so there's some > benefit in keeping it flat. > > I think that benefit is losing its appeal though. But let's hold off > for another couple of releases with the churn of moving things out in > subdirectories. > > >> Yes, I have to make sure that everybody agree on our side... > > > > The difficult point with this prefix... well it is difficult to tell... > > our product will never be called "at91" again! > > That's a marketing issue, not a technical kernel one. If we create > subdirectory it makes sense to name it 'atmel' instead of 'at91' > though, I'm sure. > > > So, yes, our Linux identity is still "at91" and we are pretty attached > > to it but our newer products are named "sam" + "core" + "product family" > > which results in our newer family: "sama5d3" (note the at91 is missing)... > > => anyway, we think that the at91 prefix is still vivid in Linux > > community and we consider it as a good choice for now. > > So, I may rename the newly introduced "sama5d3*.dts[i]" files with > > "at91-sama5d3*.dts[i]" (while .c/.h files will remain the same). > > Sounds reasonable, or stick to the same format as you already have > with at91sam9 families. When we move to subdirectories it might make > sense to stick them under 'atmel' instead of 'at91' though and drop > the prefix. I've a rfc for this as I do no lihe idea of prefix and it make the grep search mo complex I send a patch to clean the '\\' stuff in this Makefile can you take I send the dir split on the top of this > > > > -Olof
On 04/04/2013 07:03 PM, Douglas Gilbert : > On 13-04-04 11:42 AM, Nicolas Ferre wrote: >> From: Douglas Gilbert <dgilbert@interlog.com> >> >> Signed-off-by: Douglas Gilbert <dgilbert@interlog.com> >> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> >> --- >> Hi all, >> >> Here is the third revision of this patch. I plan to include it in a >> pull-request real-soon-now! >> >> v3: - move to "at91-" prefix for .dts[i] files >> - remove the rtc activation code because of the ongoing discussions >> about this IP and its DT binding. >> > > Nicolas, > It's a pity that the rtc activation code is removed. > At worst: > rtc@fffffeb0 { > status = "okay"; > }; I try to re-enalbe it when the at91sam9x5.dtsi exposes a compatibility sting != at91rm9200-rtc will soon appear on mailing-list. > does nothing. Also it is unlikely to be changed by any > movement on the rtc-at91rm9200 front. > > > The lack of use of uart1 is for my own, private reasons. > I think it would be more generally useful to show uart1's > definition and disable it as shown in the attached patch > fragment. Well, if uart1 is available on Aria board, I should enable it! If you do not want it on your own design, you must modify the .dts yourself. So I plan to have an "okay" status on it (and move the definition itself to the generic .dtsi). > I also note that my date line was removed. I like dates, > so when I add comments like "the i2c-at91 driver is broken > for the SAM9G20 ** and use the i2c-gpio driver instead" then > this is not taken as an eternal truth. Yep, I see, but I try to cleanup the patch as much as I can. If you want it untouched, provide me a standard formated patch. > It worked in the > past and hopefully it will work again in the future. > > While on the subject of I2C, I'm getting tired of seeing > this oft-copied line: > i2c-gpio,delay-us = <2>; /* ~100 kHz */ > > It is the clock half period in microseconds and for the 100 kHz > (standard) I2C clock speed, it should be 5. Due to rounding > (up) that gives a measured clock speed of around 88 kHz on > my equipment. Crappy I2C devices *** seem to cope better > with 12% below the standard clock frequency than 80% above > it. Makes sense: I keep it in mind. In parallel, it can be interesting if you can send me a patch with all these mistakes corrected ;-) Bye,
On 04/18/2013 11:01 AM, Nicolas Ferre : > On 04/04/2013 07:03 PM, Douglas Gilbert : [..] >> The lack of use of uart1 is for my own, private reasons. >> I think it would be more generally useful to show uart1's >> definition and disable it as shown in the attached patch >> fragment. > > Well, if uart1 is available on Aria board, I should enable it! If you do > not want it on your own design, you must modify the .dts yourself. So I > plan to have an "okay" status on it (and move the definition itself to > the generic .dtsi). Update: I have just checked the ACME website and both UART0 and UART1 pins are expected to be used as GPIOs. So maybe we should mark them as "disabled": + /* + * UART1 pins are marked as GPIO on Aria + * documentation: change to "okay" if you need + * an additional serial port + */ + uart0: serial@f8040000 { + status = "disabled"; + }; + + uart1: serial@f8044000 { + status = "disabled"; + }; (uart0 definition moved to at91sam9x5.dtsi) What do you think? [..] Bye,