All of lore.kernel.org
 help / color / mirror / Atom feed
From: b.brezillon@overkiz.com (boris brezillon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: at91/dt: split sam9x5 peripheral definitions
Date: Wed, 07 Aug 2013 19:28:29 +0200	[thread overview]
Message-ID: <520283BD.9060002@overkiz.com> (raw)
In-Reply-To: <20130807180854.41b4bedb@skate>

Hello Thomas,

Sorry for the noise, this mail was filtered by LKML and LAKML beacause 
thunderbird
added HTML contents.

On 07/08/2013 18:08, Thomas Petazzoni wrote:
> Dear Boris BREZILLON,
>
> On Wed,  7 Aug 2013 12:14:26 +0200, Boris BREZILLON wrote:
>> This patch splits the sam9x5 peripheral definitions into:
>> - a common base for all sam9x5 SoCs (at91sam9x5.dtsi)
>> - several optional peripheral definitions which will be included by specific
>>    sam9x5 SoCs (at91sam9x5_'periph name'.dtsi)
>>
>> This provides a better representation of the real hardware (drop unneeded
>> dt nodes) and avoids future peripheral id conflict (lcdc and isi both use
>> peripheral id 25).
>>
>> Signed-off-by: Boris BREZILLON<b.brezillon@overkiz.com>
>> ---
>>   arch/arm/boot/dts/at91sam9g25.dtsi       |    2 +
>>   arch/arm/boot/dts/at91sam9g35.dtsi       |    1 +
>>   arch/arm/boot/dts/at91sam9x25.dtsi       |   24 ++---------
>>   arch/arm/boot/dts/at91sam9x35.dtsi       |    1 +
>>   arch/arm/boot/dts/at91sam9x5.dtsi        |   67 ------------------------------
>>   arch/arm/boot/dts/at91sam9x5_macb0.dtsi  |   56 +++++++++++++++++++++++++
>>   arch/arm/boot/dts/at91sam9x5_macb1.dtsi  |   44 ++++++++++++++++++++
>>   arch/arm/boot/dts/at91sam9x5_usart3.dtsi |   51 +++++++++++++++++++++++
>>   8 files changed, 158 insertions(+), 88 deletions(-)
>>   create mode 100644 arch/arm/boot/dts/at91sam9x5_macb0.dtsi
>>   create mode 100644 arch/arm/boot/dts/at91sam9x5_macb1.dtsi
>>   create mode 100644 arch/arm/boot/dts/at91sam9x5_usart3.dtsi
> Hum, do we really want to have .dtsi files per peripheral? I might have
> overlooked this, but I think it's the first time we would have this in
> arch/arm/boot/dts.
It's not one .dtsi file for each available peripheral but for each 
**optional**
peripheral (those which are not available for all sam9x5 SoCs).

For example:

macb0 is available in this SoCs:
- 9g25
- 9g35
- 9x25
- 9x35
and not available in 9g15 SoC.

And we have different combinatory for each of the optional devices.

IMHO, defining the unneeded dt nodes in the common sam9x5.dtsi is a bad 
idea, because
the dtb footprint will be bigger for SoC which does not have the 
optional peripherals
and the dt hardware representation will be false.

I see two options to solve this issue:
  1) define a .dtsi file describing the optional peripherals and include 
these .dtsi in the SoC.dtsi file
      (as I proposed, but maybe the names  are not appropriate)
  2) copy the peripheral definitions in each SoC .dtsi file

I prefer option 1) as it's safer than copying the definition (update of 
dtsi is easier and there is no
risk to introduce a new bug when copying definitions).

Please, tell me if you see other options, or if you think this "issue" 
should not be solved.

Best Regards,

Boris
> Thomas

WARNING: multiple messages have this Message-ID (diff)
From: boris brezillon <b.brezillon@overkiz.com>
To: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Russell King <linux@arm.linux.org.uk>,
	Nicolas Ferre <nicolas.ferre@atmel.com>,
	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Ludovic Desroches <ludovic.desroches@atmel.com>,
	Richard Genoud <richard.genoud@gmail.com>,
	Mark Brown <broonie@kernel.org>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] ARM: at91/dt: split sam9x5 peripheral definitions
Date: Wed, 07 Aug 2013 19:28:29 +0200	[thread overview]
Message-ID: <520283BD.9060002@overkiz.com> (raw)
In-Reply-To: <20130807180854.41b4bedb@skate>

Hello Thomas,

Sorry for the noise, this mail was filtered by LKML and LAKML beacause 
thunderbird
added HTML contents.

On 07/08/2013 18:08, Thomas Petazzoni wrote:
> Dear Boris BREZILLON,
>
> On Wed,  7 Aug 2013 12:14:26 +0200, Boris BREZILLON wrote:
>> This patch splits the sam9x5 peripheral definitions into:
>> - a common base for all sam9x5 SoCs (at91sam9x5.dtsi)
>> - several optional peripheral definitions which will be included by specific
>>    sam9x5 SoCs (at91sam9x5_'periph name'.dtsi)
>>
>> This provides a better representation of the real hardware (drop unneeded
>> dt nodes) and avoids future peripheral id conflict (lcdc and isi both use
>> peripheral id 25).
>>
>> Signed-off-by: Boris BREZILLON<b.brezillon@overkiz.com>
>> ---
>>   arch/arm/boot/dts/at91sam9g25.dtsi       |    2 +
>>   arch/arm/boot/dts/at91sam9g35.dtsi       |    1 +
>>   arch/arm/boot/dts/at91sam9x25.dtsi       |   24 ++---------
>>   arch/arm/boot/dts/at91sam9x35.dtsi       |    1 +
>>   arch/arm/boot/dts/at91sam9x5.dtsi        |   67 ------------------------------
>>   arch/arm/boot/dts/at91sam9x5_macb0.dtsi  |   56 +++++++++++++++++++++++++
>>   arch/arm/boot/dts/at91sam9x5_macb1.dtsi  |   44 ++++++++++++++++++++
>>   arch/arm/boot/dts/at91sam9x5_usart3.dtsi |   51 +++++++++++++++++++++++
>>   8 files changed, 158 insertions(+), 88 deletions(-)
>>   create mode 100644 arch/arm/boot/dts/at91sam9x5_macb0.dtsi
>>   create mode 100644 arch/arm/boot/dts/at91sam9x5_macb1.dtsi
>>   create mode 100644 arch/arm/boot/dts/at91sam9x5_usart3.dtsi
> Hum, do we really want to have .dtsi files per peripheral? I might have
> overlooked this, but I think it's the first time we would have this in
> arch/arm/boot/dts.
It's not one .dtsi file for each available peripheral but for each 
**optional**
peripheral (those which are not available for all sam9x5 SoCs).

For example:

macb0 is available in this SoCs:
- 9g25
- 9g35
- 9x25
- 9x35
and not available in 9g15 SoC.

And we have different combinatory for each of the optional devices.

IMHO, defining the unneeded dt nodes in the common sam9x5.dtsi is a bad 
idea, because
the dtb footprint will be bigger for SoC which does not have the 
optional peripherals
and the dt hardware representation will be false.

I see two options to solve this issue:
  1) define a .dtsi file describing the optional peripherals and include 
these .dtsi in the SoC.dtsi file
      (as I proposed, but maybe the names  are not appropriate)
  2) copy the peripheral definitions in each SoC .dtsi file

I prefer option 1) as it's safer than copying the definition (update of 
dtsi is easier and there is no
risk to introduce a new bug when copying definitions).

Please, tell me if you see other options, or if you think this "issue" 
should not be solved.

Best Regards,

Boris
> Thomas


  reply	other threads:[~2013-08-07 17:28 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-07 10:14 [PATCH] ARM: at91/dt: split sam9x5 peripheral definitions Boris BREZILLON
2013-08-07 10:14 ` Boris BREZILLON
2013-08-07 10:38 ` Richard Genoud
2013-08-07 10:38   ` Richard Genoud
2013-08-07 10:55   ` boris brezillon
2013-08-07 10:55     ` boris brezillon
2013-08-07 10:59     ` Richard Genoud
2013-08-07 10:59       ` Richard Genoud
2013-08-07 16:08 ` Thomas Petazzoni
2013-08-07 16:08   ` Thomas Petazzoni
2013-08-07 17:28   ` boris brezillon [this message]
2013-08-07 17:28     ` boris brezillon
2013-08-08 14:07 ` Jean-Christophe PLAGNIOL-VILLARD
2013-08-08 14:07   ` Jean-Christophe PLAGNIOL-VILLARD
2013-08-08 15:23   ` boris brezillon
2013-08-08 15:23     ` boris brezillon
2013-08-08 15:52     ` boris brezillon
2013-08-08 15:52       ` boris brezillon
2013-08-19 16:23     ` Nicolas Ferre
2013-08-19 16:23       ` Nicolas Ferre
2013-08-19 22:37       ` Mike Turquette
2013-08-19 22:37         ` Mike Turquette
2013-08-20  6:00         ` b.brezillon at overkiz.com
2013-08-20  6:00           ` b.brezillon
2013-08-20 22:36           ` Mike Turquette

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=520283BD.9060002@overkiz.com \
    --to=b.brezillon@overkiz.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.