All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christophe Kerello <christophe.kerello@st.com>
To: Rob Herring <robh@kernel.org>
Cc: <miquel.raynal@bootlin.com>, <richard@nod.at>, <vigneshr@ti.com>,
	<mark.rutland@arm.com>, <gregkh@linuxfoundation.org>,
	<boris.brezillon@collabora.com>, <linux-mtd@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>,
	<linux-stm32@st-md-mailman.stormreply.com>,
	<devicetree@vger.kernel.org>, <marex@denx.de>
Subject: Re: [PATCH v4 06/10] dt-bindings: mtd: update STM32 FMC2 NAND controller documentation
Date: Thu, 14 May 2020 18:34:46 +0200	[thread overview]
Message-ID: <9ffc04cf-137f-5ee5-57ff-39a876abfb34@st.com> (raw)
In-Reply-To: <20200514150028.GB28489@bogus>

Hi Rob,

On 5/14/20 5:00 PM, Rob Herring wrote:
> On Wed, May 06, 2020 at 11:11:15AM +0200, Christophe Kerello wrote:
>> These bindings can be used on SOCs where the FMC2 NAND controller is
>> in standalone. In case that the FMC2 embeds 2 controllers (an external
>> bus controller and a raw NAND controller), the register base and the
>> clock will be defined in the parent node. It is the reason why the
>> register base address and the clock are now optional.
>>
>> Signed-off-by: Christophe Kerello <christophe.kerello@st.com>
>> ---
>>   .../devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml   | 19 ++++++++++---------
>>   1 file changed, 10 insertions(+), 9 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml b/Documentation/devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml
>> index b059267..68fac1a 100644
>> --- a/Documentation/devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml
>> +++ b/Documentation/devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml
>> @@ -18,13 +18,15 @@ properties:
>>   
>>     reg:
>>       items:
>> -      - description: Registers
>> +      - description: Registers (optional)
> 
> The only thing that can be optional are the last entries. You have to do
> a 'oneOf' with 6 entries and 7 entries.

Ok, so the way to describe the reg property in my case should be:
        reg:
          oneOf:
            - description: FMC2 embeds the NFC controller in standalone.
              items:
                - description: Registers
                - description: Chip select 0 data
                - description: Chip select 0 command
                - description: Chip select 0 address space
                - description: Chip select 1 data
                - description: Chip select 1 command
                - description: Chip select 1 address space

            - description: FMC2 embeds the NFC controller and the EBI
                controller.
              items:
                - description: Chip select 0 data
                - description: Chip select 0 command
                - description: Chip select 0 address space
                - description: Chip select 1 data
                - description: Chip select 1 command
                - description: Chip select 1 address space

> 
> And where's your new compatible string for this different h/w?

 From NFC controller point of view, it is the same HW.
In the case that we have 2 controllers embedded, the register base is 
shared.
The NFC driver will check at probe time the compatible string of its 
parent node.
In case that it is "st,stm32mp1-fmc2-ebi", then the driver will find the 
register base in the parent node (EBI node), otherwise it will find it 
in the NFC node.
Is it better to have 2 compatible strings (one for each reg description) 
than checking the parent's compatible string and have only one 
compatible string?

Regards,
Christophe Kerello.

> 
>>         - description: Chip select 0 data
>>         - description: Chip select 0 command
>>         - description: Chip select 0 address space
>>         - description: Chip select 1 data
>>         - description: Chip select 1 command
>>         - description: Chip select 1 address space
>> +    minItems: 6
>> +    maxItems: 7
>>   
>>     interrupts:
>>       maxItems: 1
>> @@ -61,7 +63,6 @@ required:
>>     - compatible
>>     - reg
>>     - interrupts
>> -  - clocks
>>   
>>   examples:
>>     - |
>> @@ -77,13 +78,13 @@ examples:
>>               <0x81000000 0x1000>,
>>               <0x89010000 0x1000>,
>>               <0x89020000 0x1000>;
>> -            interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
>> -            dmas = <&mdma1 20 0x10 0x12000a02 0x0 0x0>,
>> -                   <&mdma1 20 0x10 0x12000a08 0x0 0x0>,
>> -                   <&mdma1 21 0x10 0x12000a0a 0x0 0x0>;
>> -            dma-names = "tx", "rx", "ecc";
>> -            clocks = <&rcc FMC_K>;
>> -            resets = <&rcc FMC_R>;
>> +      interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
>> +      dmas = <&mdma1 20 0x2 0x12000a02 0x0 0x0>,
>> +             <&mdma1 20 0x2 0x12000a08 0x0 0x0>,
>> +             <&mdma1 21 0x2 0x12000a0a 0x0 0x0>;
>> +      dma-names = "tx", "rx", "ecc";
>> +      clocks = <&rcc FMC_K>;
>> +      resets = <&rcc FMC_R>;
>>         #address-cells = <1>;
>>         #size-cells = <0>;
>>   
>> -- 
>> 1.9.1
>>

WARNING: multiple messages have this Message-ID (diff)
From: Christophe Kerello <christophe.kerello@st.com>
To: Rob Herring <robh@kernel.org>
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, marex@denx.de,
	vigneshr@ti.com, richard@nod.at, miquel.raynal@bootlin.com,
	linux-kernel@vger.kernel.org, boris.brezillon@collabora.com,
	linux-mtd@lists.infradead.org, gregkh@linuxfoundation.org,
	linux-stm32@st-md-mailman.stormreply.com
Subject: Re: [PATCH v4 06/10] dt-bindings: mtd: update STM32 FMC2 NAND controller documentation
Date: Thu, 14 May 2020 18:34:46 +0200	[thread overview]
Message-ID: <9ffc04cf-137f-5ee5-57ff-39a876abfb34@st.com> (raw)
In-Reply-To: <20200514150028.GB28489@bogus>

Hi Rob,

On 5/14/20 5:00 PM, Rob Herring wrote:
> On Wed, May 06, 2020 at 11:11:15AM +0200, Christophe Kerello wrote:
>> These bindings can be used on SOCs where the FMC2 NAND controller is
>> in standalone. In case that the FMC2 embeds 2 controllers (an external
>> bus controller and a raw NAND controller), the register base and the
>> clock will be defined in the parent node. It is the reason why the
>> register base address and the clock are now optional.
>>
>> Signed-off-by: Christophe Kerello <christophe.kerello@st.com>
>> ---
>>   .../devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml   | 19 ++++++++++---------
>>   1 file changed, 10 insertions(+), 9 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml b/Documentation/devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml
>> index b059267..68fac1a 100644
>> --- a/Documentation/devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml
>> +++ b/Documentation/devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml
>> @@ -18,13 +18,15 @@ properties:
>>   
>>     reg:
>>       items:
>> -      - description: Registers
>> +      - description: Registers (optional)
> 
> The only thing that can be optional are the last entries. You have to do
> a 'oneOf' with 6 entries and 7 entries.

Ok, so the way to describe the reg property in my case should be:
        reg:
          oneOf:
            - description: FMC2 embeds the NFC controller in standalone.
              items:
                - description: Registers
                - description: Chip select 0 data
                - description: Chip select 0 command
                - description: Chip select 0 address space
                - description: Chip select 1 data
                - description: Chip select 1 command
                - description: Chip select 1 address space

            - description: FMC2 embeds the NFC controller and the EBI
                controller.
              items:
                - description: Chip select 0 data
                - description: Chip select 0 command
                - description: Chip select 0 address space
                - description: Chip select 1 data
                - description: Chip select 1 command
                - description: Chip select 1 address space

> 
> And where's your new compatible string for this different h/w?

 From NFC controller point of view, it is the same HW.
In the case that we have 2 controllers embedded, the register base is 
shared.
The NFC driver will check at probe time the compatible string of its 
parent node.
In case that it is "st,stm32mp1-fmc2-ebi", then the driver will find the 
register base in the parent node (EBI node), otherwise it will find it 
in the NFC node.
Is it better to have 2 compatible strings (one for each reg description) 
than checking the parent's compatible string and have only one 
compatible string?

Regards,
Christophe Kerello.

> 
>>         - description: Chip select 0 data
>>         - description: Chip select 0 command
>>         - description: Chip select 0 address space
>>         - description: Chip select 1 data
>>         - description: Chip select 1 command
>>         - description: Chip select 1 address space
>> +    minItems: 6
>> +    maxItems: 7
>>   
>>     interrupts:
>>       maxItems: 1
>> @@ -61,7 +63,6 @@ required:
>>     - compatible
>>     - reg
>>     - interrupts
>> -  - clocks
>>   
>>   examples:
>>     - |
>> @@ -77,13 +78,13 @@ examples:
>>               <0x81000000 0x1000>,
>>               <0x89010000 0x1000>,
>>               <0x89020000 0x1000>;
>> -            interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
>> -            dmas = <&mdma1 20 0x10 0x12000a02 0x0 0x0>,
>> -                   <&mdma1 20 0x10 0x12000a08 0x0 0x0>,
>> -                   <&mdma1 21 0x10 0x12000a0a 0x0 0x0>;
>> -            dma-names = "tx", "rx", "ecc";
>> -            clocks = <&rcc FMC_K>;
>> -            resets = <&rcc FMC_R>;
>> +      interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
>> +      dmas = <&mdma1 20 0x2 0x12000a02 0x0 0x0>,
>> +             <&mdma1 20 0x2 0x12000a08 0x0 0x0>,
>> +             <&mdma1 21 0x2 0x12000a0a 0x0 0x0>;
>> +      dma-names = "tx", "rx", "ecc";
>> +      clocks = <&rcc FMC_K>;
>> +      resets = <&rcc FMC_R>;
>>         #address-cells = <1>;
>>         #size-cells = <0>;
>>   
>> -- 
>> 1.9.1
>>

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2020-05-14 16:35 UTC|newest]

Thread overview: 70+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-06  9:11 [PATCH v4 00/10] add STM32 FMC2 EBI controller driver Christophe Kerello
2020-05-06  9:11 ` Christophe Kerello
2020-05-06  9:11 ` [PATCH v4 01/10] mtd: rawnand: stm32_fmc2: manage all errors cases at probe time Christophe Kerello
2020-05-06  9:11   ` Christophe Kerello
2020-05-11 20:29   ` Miquel Raynal
2020-05-11 20:29     ` Miquel Raynal
2020-05-06  9:11 ` [PATCH v4 02/10] mtd: rawnand: stm32_fmc2: remove useless inline comments Christophe Kerello
2020-05-06  9:11   ` Christophe Kerello
2020-05-11 20:29   ` Miquel Raynal
2020-05-11 20:29     ` Miquel Raynal
2020-05-06  9:11 ` [PATCH v4 03/10] mtd: rawnand: stm32_fmc2: use FMC2_TIMEOUT_MS for timeouts Christophe Kerello
2020-05-06  9:11   ` Christophe Kerello
2020-05-11 20:29   ` Miquel Raynal
2020-05-11 20:29     ` Miquel Raynal
2020-05-06  9:11 ` [PATCH v4 04/10] mtd: rawnand: stm32_fmc2: cleanup Christophe Kerello
2020-05-06  9:11   ` Christophe Kerello
2020-05-11 20:39   ` Miquel Raynal
2020-05-11 20:39     ` Miquel Raynal
2020-05-12  6:49     ` Christophe Kerello
2020-05-12  6:49       ` Christophe Kerello
2020-05-12  6:59       ` Miquel Raynal
2020-05-12  6:59         ` Miquel Raynal
2020-05-06  9:11 ` [PATCH v4 05/10] mtd: rawnand: stm32_fmc2: use FIELD_PREP/FIELD_GET macros Christophe Kerello
2020-05-06  9:11   ` Christophe Kerello
2020-05-11 20:29   ` Miquel Raynal
2020-05-11 20:29     ` Miquel Raynal
2020-05-06  9:11 ` [PATCH v4 06/10] dt-bindings: mtd: update STM32 FMC2 NAND controller documentation Christophe Kerello
2020-05-06  9:11   ` Christophe Kerello
2020-05-14 15:00   ` Rob Herring
2020-05-14 15:00     ` Rob Herring
2020-05-14 16:34     ` Christophe Kerello [this message]
2020-05-14 16:34       ` Christophe Kerello
2020-05-14 17:55       ` Rob Herring
2020-05-14 17:55         ` Rob Herring
2020-05-15  9:02         ` Christophe Kerello
2020-05-15  9:02           ` Christophe Kerello
2020-05-06  9:11 ` [PATCH v4 07/10] dt-bindings: memory-controller: add STM32 FMC2 EBI " Christophe Kerello
2020-05-06  9:11   ` Christophe Kerello
2020-05-14 15:07   ` Rob Herring
2020-05-14 15:07     ` Rob Herring
2020-05-14 16:37     ` Christophe Kerello
2020-05-14 16:37       ` Christophe Kerello
2020-05-06  9:11 ` [PATCH v4 08/10] memory: stm32-fmc2-ebi: add STM32 FMC2 EBI controller driver Christophe Kerello
2020-05-06  9:11   ` Christophe Kerello
2020-05-06  9:11 ` [PATCH v4 09/10] mtd: rawnand: stm32_fmc2: use regmap APIs Christophe Kerello
2020-05-06  9:11   ` Christophe Kerello
2020-05-06  9:11 ` [PATCH v4 10/10] mtd: rawnand: stm32_fmc2: get resources from parent node Christophe Kerello
2020-05-06  9:11   ` Christophe Kerello
2020-05-11  9:18   ` Miquel Raynal
2020-05-11  9:18     ` Miquel Raynal
2020-05-11 10:21     ` Christophe Kerello
2020-05-11 10:21       ` Christophe Kerello
2020-05-11 11:59       ` Miquel Raynal
2020-05-11 11:59         ` Miquel Raynal
2020-05-11 12:47         ` Christophe Kerello
2020-05-11 12:47           ` Christophe Kerello
2020-05-11 12:58           ` Miquel Raynal
2020-05-11 12:58             ` Miquel Raynal
2020-05-11 14:19             ` Christophe Kerello
2020-05-11 14:19               ` Christophe Kerello
2020-05-11 14:45               ` Miquel Raynal
2020-05-11 14:45                 ` Miquel Raynal
2020-05-11 17:02                 ` Christophe Kerello
2020-05-11 17:02                   ` Christophe Kerello
2020-05-11 20:28                   ` Miquel Raynal
2020-05-11 20:28                     ` Miquel Raynal
2020-05-11  9:22 ` [PATCH v4 00/10] add STM32 FMC2 EBI controller driver Miquel Raynal
2020-05-11  9:22   ` Miquel Raynal
2020-05-11 10:26   ` Christophe Kerello
2020-05-11 10:26     ` Christophe Kerello

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=9ffc04cf-137f-5ee5-57ff-39a876abfb34@st.com \
    --to=christophe.kerello@st.com \
    --cc=boris.brezillon@collabora.com \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=marex@denx.de \
    --cc=mark.rutland@arm.com \
    --cc=miquel.raynal@bootlin.com \
    --cc=richard@nod.at \
    --cc=robh@kernel.org \
    --cc=vigneshr@ti.com \
    /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.