All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolas Ferre <nicolas.ferre@microchip.com>
To: Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Radu Pirea <radu.pirea@microchip.com>
Cc: <broonie@kernel.org>, <robh+dt@kernel.org>,
	<mark.rutland@arm.com>, <linux-kernel@vger.kernel.org>,
	<linux-spi@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<devicetree@vger.kernel.org>
Subject: Re: [PATCH 2/3] dt-bindings: add binding for at91-usart in spi mode
Date: Fri, 13 Apr 2018 19:12:54 +0200	[thread overview]
Message-ID: <8e6c447d-dce5-f9af-e5b2-8d1d863159d6@microchip.com> (raw)
In-Reply-To: <20180413162327.GE22187@piout.net>

On 13/04/2018 at 18:23, Alexandre Belloni wrote:
> On 13/04/2018 19:11:16+0300, Radu Pirea wrote:
>> These are bindings for at91-usart IP in spi spi mode. There is no support for
>> internal chip select. Only kind of chip selects available are gpio chip
>> selects.
>>
>> Signed-off-by: Radu Pirea <radu.pirea@microchip.com>
>> ---
>>   .../bindings/spi/microchip,at91-usart-spi.txt | 24 +++++++++++++++++++
>>   1 file changed, 24 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/spi/microchip,at91-usart-spi.txt
>>
>> diff --git a/Documentation/devicetree/bindings/spi/microchip,at91-usart-spi.txt b/Documentation/devicetree/bindings/spi/microchip,at91-usart-spi.txt
>> new file mode 100644
>> index 000000000000..92d33ccdffae
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/spi/microchip,at91-usart-spi.txt
>> @@ -0,0 +1,24 @@
>> +* Universal Synchronous Asynchronous Receiver/Transmitter (USART) in SPI mode
>> +
>> +Required properties:
>> +- #size-cells      : Must be <0>
>> +- #address-cells   : Must be <1>
>> +- compatible: Should be "microchip,at91sam9g45-usart-spi" or "microchip,sama5d2-usart-spi"
>> +- reg: Should contain registers location and length
>> +- interrupts: Should contain interrupt
>> +- clocks: phandles to input clocks.
>> +- clock-names: tuple listing input clock names.
>> +	Required elements: "usart"
>> +- cs-gpios: chipselects (internal cs not supported)
>> +
>> +Example:
>> +	spi0: spi@f001c000 {
>> +		#address-cells = <1>;
>> +		#size-cells = <0>;
>> +		compatible = "microchip,sama5d2-usart-spi", "microchip,at91sam9g45-usart-spi";
> 
> I'm pretty sure this will be considered configuration rather than
> hardware description. Why don't you do something like the flexcom mode
> selection?

Because we are not in the same situation as having a glue layer that 
would select one of the already existing peripherals with associated 
drivers above.
This layout of the hardware is completely different from the USART one 
and it seems to makes sense to address it with a different hardware 
description and so a different compatible string.

Regards,
   Nicolas

>> +		reg = <0xf001c000 0x100>;
>> +		interrupts = <12 IRQ_TYPE_LEVEL_HIGH>;
>> +		clocks = <&usart0_clk>;
>> +		clock-names = "usart";
>> +		cs-gpios = <&pioB 3 0>;
>> +	};
>> -- 
>> 2.17.0
>>
> 


-- 
Nicolas Ferre

WARNING: multiple messages have this Message-ID (diff)
From: Nicolas Ferre <nicolas.ferre@microchip.com>
To: Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Radu Pirea <radu.pirea@microchip.com>
Cc: broonie@kernel.org, robh+dt@kernel.org, mark.rutland@arm.com,
	linux-kernel@vger.kernel.org, linux-spi@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org
Subject: Re: [PATCH 2/3] dt-bindings: add binding for at91-usart in spi mode
Date: Fri, 13 Apr 2018 19:12:54 +0200	[thread overview]
Message-ID: <8e6c447d-dce5-f9af-e5b2-8d1d863159d6@microchip.com> (raw)
In-Reply-To: <20180413162327.GE22187@piout.net>

On 13/04/2018 at 18:23, Alexandre Belloni wrote:
> On 13/04/2018 19:11:16+0300, Radu Pirea wrote:
>> These are bindings for at91-usart IP in spi spi mode. There is no support for
>> internal chip select. Only kind of chip selects available are gpio chip
>> selects.
>>
>> Signed-off-by: Radu Pirea <radu.pirea@microchip.com>
>> ---
>>   .../bindings/spi/microchip,at91-usart-spi.txt | 24 +++++++++++++++++++
>>   1 file changed, 24 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/spi/microchip,at91-usart-spi.txt
>>
>> diff --git a/Documentation/devicetree/bindings/spi/microchip,at91-usart-spi.txt b/Documentation/devicetree/bindings/spi/microchip,at91-usart-spi.txt
>> new file mode 100644
>> index 000000000000..92d33ccdffae
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/spi/microchip,at91-usart-spi.txt
>> @@ -0,0 +1,24 @@
>> +* Universal Synchronous Asynchronous Receiver/Transmitter (USART) in SPI mode
>> +
>> +Required properties:
>> +- #size-cells      : Must be <0>
>> +- #address-cells   : Must be <1>
>> +- compatible: Should be "microchip,at91sam9g45-usart-spi" or "microchip,sama5d2-usart-spi"
>> +- reg: Should contain registers location and length
>> +- interrupts: Should contain interrupt
>> +- clocks: phandles to input clocks.
>> +- clock-names: tuple listing input clock names.
>> +	Required elements: "usart"
>> +- cs-gpios: chipselects (internal cs not supported)
>> +
>> +Example:
>> +	spi0: spi@f001c000 {
>> +		#address-cells = <1>;
>> +		#size-cells = <0>;
>> +		compatible = "microchip,sama5d2-usart-spi", "microchip,at91sam9g45-usart-spi";
> 
> I'm pretty sure this will be considered configuration rather than
> hardware description. Why don't you do something like the flexcom mode
> selection?

Because we are not in the same situation as having a glue layer that 
would select one of the already existing peripherals with associated 
drivers above.
This layout of the hardware is completely different from the USART one 
and it seems to makes sense to address it with a different hardware 
description and so a different compatible string.

Regards,
   Nicolas

>> +		reg = <0xf001c000 0x100>;
>> +		interrupts = <12 IRQ_TYPE_LEVEL_HIGH>;
>> +		clocks = <&usart0_clk>;
>> +		clock-names = "usart";
>> +		cs-gpios = <&pioB 3 0>;
>> +	};
>> -- 
>> 2.17.0
>>
> 


-- 
Nicolas Ferre

WARNING: multiple messages have this Message-ID (diff)
From: nicolas.ferre@microchip.com (Nicolas Ferre)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/3] dt-bindings: add binding for at91-usart in spi mode
Date: Fri, 13 Apr 2018 19:12:54 +0200	[thread overview]
Message-ID: <8e6c447d-dce5-f9af-e5b2-8d1d863159d6@microchip.com> (raw)
In-Reply-To: <20180413162327.GE22187@piout.net>

On 13/04/2018 at 18:23, Alexandre Belloni wrote:
> On 13/04/2018 19:11:16+0300, Radu Pirea wrote:
>> These are bindings for at91-usart IP in spi spi mode. There is no support for
>> internal chip select. Only kind of chip selects available are gpio chip
>> selects.
>>
>> Signed-off-by: Radu Pirea <radu.pirea@microchip.com>
>> ---
>>   .../bindings/spi/microchip,at91-usart-spi.txt | 24 +++++++++++++++++++
>>   1 file changed, 24 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/spi/microchip,at91-usart-spi.txt
>>
>> diff --git a/Documentation/devicetree/bindings/spi/microchip,at91-usart-spi.txt b/Documentation/devicetree/bindings/spi/microchip,at91-usart-spi.txt
>> new file mode 100644
>> index 000000000000..92d33ccdffae
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/spi/microchip,at91-usart-spi.txt
>> @@ -0,0 +1,24 @@
>> +* Universal Synchronous Asynchronous Receiver/Transmitter (USART) in SPI mode
>> +
>> +Required properties:
>> +- #size-cells      : Must be <0>
>> +- #address-cells   : Must be <1>
>> +- compatible: Should be "microchip,at91sam9g45-usart-spi" or "microchip,sama5d2-usart-spi"
>> +- reg: Should contain registers location and length
>> +- interrupts: Should contain interrupt
>> +- clocks: phandles to input clocks.
>> +- clock-names: tuple listing input clock names.
>> +	Required elements: "usart"
>> +- cs-gpios: chipselects (internal cs not supported)
>> +
>> +Example:
>> +	spi0: spi at f001c000 {
>> +		#address-cells = <1>;
>> +		#size-cells = <0>;
>> +		compatible = "microchip,sama5d2-usart-spi", "microchip,at91sam9g45-usart-spi";
> 
> I'm pretty sure this will be considered configuration rather than
> hardware description. Why don't you do something like the flexcom mode
> selection?

Because we are not in the same situation as having a glue layer that 
would select one of the already existing peripherals with associated 
drivers above.
This layout of the hardware is completely different from the USART one 
and it seems to makes sense to address it with a different hardware 
description and so a different compatible string.

Regards,
   Nicolas

>> +		reg = <0xf001c000 0x100>;
>> +		interrupts = <12 IRQ_TYPE_LEVEL_HIGH>;
>> +		clocks = <&usart0_clk>;
>> +		clock-names = "usart";
>> +		cs-gpios = <&pioB 3 0>;
>> +	};
>> -- 
>> 2.17.0
>>
> 


-- 
Nicolas Ferre

  reply	other threads:[~2018-04-13 17:13 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-13 16:11 [PATCH 0/3] Driver for AT91 USART in SPI mode Radu Pirea
2018-04-13 16:11 ` Radu Pirea
2018-04-13 16:11 ` Radu Pirea
2018-04-13 16:11 ` [PATCH 1/3] MAINTAINERS: add usart spi driver Radu Pirea
2018-04-13 16:11   ` Radu Pirea
2018-04-13 16:11   ` Radu Pirea
2018-04-13 16:11 ` [PATCH 2/3] dt-bindings: add binding for at91-usart in spi mode Radu Pirea
2018-04-13 16:11   ` Radu Pirea
2018-04-13 16:11   ` Radu Pirea
2018-04-13 16:23   ` Alexandre Belloni
2018-04-13 16:23     ` Alexandre Belloni
2018-04-13 17:12     ` Nicolas Ferre [this message]
2018-04-13 17:12       ` Nicolas Ferre
2018-04-13 17:12       ` Nicolas Ferre
2018-04-13 18:12       ` Alexandre Belloni
2018-04-13 18:12         ` Alexandre Belloni
2018-04-17 11:03         ` Mark Brown
2018-04-17 11:03           ` Mark Brown
2018-04-19 10:04           ` Radu Pirea
2018-04-19 10:04             ` Radu Pirea
2018-04-19 10:04             ` Radu Pirea
2018-04-19 14:55             ` Mark Brown
2018-04-19 14:55               ` Mark Brown
2018-04-19 13:32           ` Alexandre Belloni
2018-04-19 13:32             ` Alexandre Belloni
2018-04-19 14:07             ` Mark Brown
2018-04-19 14:07               ` Mark Brown
2018-04-13 16:11 ` [PATCH 3/3] spi: at91-usart: add driver for at91-usart as spi Radu Pirea
2018-04-13 16:11   ` Radu Pirea
2018-04-13 16:11   ` Radu Pirea

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=8e6c447d-dce5-f9af-e5b2-8d1d863159d6@microchip.com \
    --to=nicolas.ferre@microchip.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=radu.pirea@microchip.com \
    --cc=robh+dt@kernel.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.