mbox

[GIT,PULL] at91: DT changes for 3.10 #2

Message ID 1364569179-24773-1-git-send-email-nicolas.ferre@atmel.com
State New
Headers show

Pull-request

git://github.com/at91linux/linux-at91.git tags/at91-dt

Message

Nicolas Ferre March 29, 2013, 2:59 p.m. UTC
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

Nicolas Ferre (5):
      ARM: at91/at91sam9x5: add RTC node
      ARM: at91/trivial: typos in compatible property
      ARM: at91/trivial: fix model name for SAM9G15-EK
      ARM: at91: remove partial parameter in bootargs for at91sam9x5ek.dtsi
      ARM: at91/dt: fix macb node declaration

 arch/arm/boot/dts/ariag25.dts       | 175 +++++++++++++++++++++++++++++++++++
 arch/arm/boot/dts/at91sam9g15.dtsi  |   2 +-
 arch/arm/boot/dts/at91sam9g15ek.dts |   2 +-
 arch/arm/boot/dts/at91sam9g25.dtsi  |   2 +-
 arch/arm/boot/dts/at91sam9g25ek.dts |   9 ++
 arch/arm/boot/dts/at91sam9g35.dtsi  |   2 +-
 arch/arm/boot/dts/at91sam9g35ek.dts |   9 ++
 arch/arm/boot/dts/at91sam9x25.dtsi  |   2 +-
 arch/arm/boot/dts/at91sam9x25ek.dts |  14 +++
 arch/arm/boot/dts/at91sam9x35.dtsi  |   2 +-
 arch/arm/boot/dts/at91sam9x35ek.dts |   9 ++
 arch/arm/boot/dts/at91sam9x5.dtsi   |   7 ++
 arch/arm/boot/dts/at91sam9x5ek.dtsi |   7 +-
 13 files changed, 230 insertions(+), 12 deletions(-)
 create mode 100644 arch/arm/boot/dts/ariag25.dts

Comments

Olof Johansson April 2, 2013, 6:49 p.m. UTC | #1
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
Nicolas Ferre April 3, 2013, 7:45 a.m. UTC | #2
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,
Nicolas Ferre April 4, 2013, 9:37 a.m. UTC | #3
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,
>
Olof Johansson April 4, 2013, 5:19 p.m. UTC | #4
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
Jean-Christophe PLAGNIOL-VILLARD April 8, 2013, 11:52 a.m. UTC | #5
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
Nicolas Ferre April 18, 2013, 9:01 a.m. UTC | #6
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,
Nicolas Ferre April 18, 2013, 10:13 a.m. UTC | #7
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,