[PATCH 3/3] mtd: spi-nand: add devicetree binding

[PATCH 3/3] mtd: spi-nand: add devicetree binding

[Peter Pan 潘栋 (peterpandong)]

This commit adds the devicetree binding document that specifies the
spi nand devices support.

Signed-off-by: Peter Pan <peterpandong@micron.com>
---
 Documentation/devicetree/bindings/mtd/spi-nand.txt | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/spi-nand.txt

diff --git a/Documentation/devicetree/bindings/mtd/spi-nand.txt b/Documentation/devicetree/bindings/mtd/spi-nand.txt
new file mode 100644
index 0000000..9dd3efd
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/spi-nand.txt
@@ -0,0 +1,22 @@
+* NAND driver for MT29F, GD5F and similar SPI NAND flash chips
+
+Required properties:
+- #address-cells, #size-cells : Must be present if the device has sub-nodes
+  representing partitions.
+- compatible : Should be the manufacturer and the name of the chip. Bear in mind
+               the DT binding is not Linux-only, but in case of Linux, see the
+               "spi_nand_id_table" array in drivers/mtd/spi-nand/spi-nand-device.c
+               for the list of supported chips.
+- reg : Chip-Select number
+- spi-max-frequency : Maximum frequency of the SPI bus the chip can operate at
+
+Example:
+
+	flash: flash@0 {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "micron,mt29f";
+		reg = <0>;
+		spi-max-frequency = <50000000>;
+	};
+
-- 
1.9.1

Re: [PATCH 3/3] mtd: spi-nand: add devicetree binding

[Ezequiel Garcia]

On 01/07/2015 09:52 PM, Peter Pan 潘栋 (peterpandong) wrote:
> This commit adds the devicetree binding document that specifies the
> spi nand devices support.
> 
> Signed-off-by: Peter Pan <peterpandong@micron.com>
> ---
>  Documentation/devicetree/bindings/mtd/spi-nand.txt | 22 ++++++++++++++++++++++
>  1 file changed, 22 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mtd/spi-nand.txt
> 
> diff --git a/Documentation/devicetree/bindings/mtd/spi-nand.txt b/Documentation/devicetree/bindings/mtd/spi-nand.txt
> new file mode 100644
> index 0000000..9dd3efd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/spi-nand.txt
> @@ -0,0 +1,22 @@
> +* NAND driver for MT29F, GD5F and similar SPI NAND flash chips
> +
> +Required properties:
> +- #address-cells, #size-cells : Must be present if the device has sub-nodes
> +  representing partitions.
> +- compatible : Should be the manufacturer and the name of the chip. Bear in mind
> 

Unless I'm mistaken, we don't need the chip ID here, as SPI NAND allows
to autodetect the device. Any reason why we can't just use a generic
compatible "spi-nand" here?
-- 
Ezequiel

RE: [PATCH 3/3] mtd: spi-nand: add devicetree binding

[Peter Pan 潘栋 (peterpandong)]

> > This commit adds the devicetree binding document that specifies the
> > spi nand devices support.
> >
> > Signed-off-by: Peter Pan <peterpandong@micron.com>
> > ---
> >  Documentation/devicetree/bindings/mtd/spi-nand.txt | 22
> ++++++++++++++++++++++
> >  1 file changed, 22 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/mtd/spi-
> nand.txt
> >
> > diff --git a/Documentation/devicetree/bindings/mtd/spi-nand.txt
> b/Documentation/devicetree/bindings/mtd/spi-nand.txt
> > new file mode 100644
> > index 0000000..9dd3efd
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mtd/spi-nand.txt
> > @@ -0,0 +1,22 @@
> > +* NAND driver for MT29F, GD5F and similar SPI NAND flash chips
> > +
> > +Required properties:
> > +- #address-cells, #size-cells : Must be present if the device has
> sub-nodes
> > +  representing partitions.
> > +- compatible : Should be the manufacturer and the name of the chip.
> Bear in mind
> >
> 
> Unless I'm mistaken, we don't need the chip ID here, as SPI NAND allows
> to autodetect the device. Any reason why we can't just use a generic
> compatible "spi-nand" here?
> --
> Ezequiel

In fact, I don't know how to autodetect the SPI NAND device. Micron device and
Gigadevice device have different read ID functions. The Chip ID here is used to
determine which function to use.


Peter Pan

Re: [PATCH 3/3] mtd: spi-nand: add devicetree binding

[Mark Rutland]

On Thu, Jan 08, 2015 at 12:52:26AM +0000, Peter Pan 潘栋 (peterpandong) wrote:
> This commit adds the devicetree binding document that specifies the
> spi nand devices support.
> 
> Signed-off-by: Peter Pan <peterpandong-AL4WhLSQfzjQT0dZR+AlfA@public.gmane.org>
> ---
>  Documentation/devicetree/bindings/mtd/spi-nand.txt | 22 ++++++++++++++++++++++
>  1 file changed, 22 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mtd/spi-nand.txt
> 
> diff --git a/Documentation/devicetree/bindings/mtd/spi-nand.txt b/Documentation/devicetree/bindings/mtd/spi-nand.txt
> new file mode 100644
> index 0000000..9dd3efd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/spi-nand.txt
> @@ -0,0 +1,22 @@
> +* NAND driver for MT29F, GD5F and similar SPI NAND flash chips
> +
> +Required properties:
> +- #address-cells, #size-cells : Must be present if the device has sub-nodes
> +  representing partitions.

Can we refer to the binding document for that?

> +- compatible : Should be the manufacturer and the name of the chip. Bear in mind
> +               the DT binding is not Linux-only, but in case of Linux, see the
> +               "spi_nand_id_table" array in drivers/mtd/spi-nand/spi-nand-device.c
> +               for the list of supported chips.

NAK for referring to Linux internals from a binding document.

The list of compatible string should be defined in this binding
document.

> +- reg : Chip-Select number
> +- spi-max-frequency : Maximum frequency of the SPI bus the chip can operate at
> +
> +Example:
> +
> +	flash: flash@0 {
> +		#address-cells = <1>;
> +		#size-cells = <1>;

These aren't necessary as no partitions are defined here.

Otherwise, this looks ok.

Thanks,
Mark.

> +		compatible = "micron,mt29f";
> +		reg = <0>;
> +		spi-max-frequency = <50000000>;
> +	};
> +
> -- 
> 1.9.1
> N嫥叉靣笡y氊b瞂千v豝?藓{.n?壏漽鴾z谵z)韰骅w*\x1fjg?秹殠娸/侁鋤罐枈?娹櫒璀??摺玜囤\x7f\x1e瓽珴閔?鎗:+v墾妛鑶佶
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] mtd: spi-nand: add devicetree binding

[Ezequiel Garcia]

On 01/08/2015 02:04 AM, Peter Pan 潘栋 (peterpandong) wrote:
>>> This commit adds the devicetree binding document that specifies the
>>> spi nand devices support.
>>>
>>> Signed-off-by: Peter Pan <peterpandong@micron.com>
>>> ---
>>>  Documentation/devicetree/bindings/mtd/spi-nand.txt | 22
>> ++++++++++++++++++++++
>>>  1 file changed, 22 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/mtd/spi-
>> nand.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/mtd/spi-nand.txt
>> b/Documentation/devicetree/bindings/mtd/spi-nand.txt
>>> new file mode 100644
>>> index 0000000..9dd3efd
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/mtd/spi-nand.txt
>>> @@ -0,0 +1,22 @@
>>> +* NAND driver for MT29F, GD5F and similar SPI NAND flash chips
>>> +
>>> +Required properties:
>>> +- #address-cells, #size-cells : Must be present if the device has
>> sub-nodes
>>> +  representing partitions.
>>> +- compatible : Should be the manufacturer and the name of the chip.
>> Bear in mind
>>>
>>
>> Unless I'm mistaken, we don't need the chip ID here, as SPI NAND allows
>> to autodetect the device. Any reason why we can't just use a generic
>> compatible "spi-nand" here?
>> --
>> Ezequiel
> 
> In fact, I don't know how to autodetect the SPI NAND device. Micron device and
> Gigadevice device have different read ID functions. The Chip ID here is used to
> determine which function to use.
> 

Isn't the difference between the Read ID very minor? One of the vendor
needs a 2-byte ID read, and the other one needs a 3-byte ID read.

So you can just try with 2-byte, and if that fails (no vendor ID is
found on the first byte), you can try with the 3-byte command.

It's not the most elegant solution, but it's not super awful either.
-- 
Ezequiel

RE: [PATCH 3/3] mtd: spi-nand: add devicetree binding

[Peter Pan 潘栋 (peterpandong)]

> On 01/08/2015 02:04 AM, Peter Pan 潘栋 (peterpandong) wrote:
> >>> This commit adds the devicetree binding document that specifies the
> >>> spi nand devices support.
> >>>
> >>> Signed-off-by: Peter Pan <peterpandong@micron.com>
> >>> ---
> >>>  Documentation/devicetree/bindings/mtd/spi-nand.txt | 22
> >> ++++++++++++++++++++++
> >>>  1 file changed, 22 insertions(+)
> >>>  create mode 100644 Documentation/devicetree/bindings/mtd/spi-
> >> nand.txt
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/mtd/spi-nand.txt
> >> b/Documentation/devicetree/bindings/mtd/spi-nand.txt
> >>> new file mode 100644
> >>> index 0000000..9dd3efd
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/mtd/spi-nand.txt
> >>> @@ -0,0 +1,22 @@
> >>> +* NAND driver for MT29F, GD5F and similar SPI NAND flash chips
> >>> +
> >>> +Required properties:
> >>> +- #address-cells, #size-cells : Must be present if the device has
> >> sub-nodes
> >>> +  representing partitions.
> >>> +- compatible : Should be the manufacturer and the name of the chip.
> >> Bear in mind
> >>>
> >>
> >> Unless I'm mistaken, we don't need the chip ID here, as SPI NAND
> allows
> >> to autodetect the device. Any reason why we can't just use a generic
> >> compatible "spi-nand" here?
> >> --
> >> Ezequiel
> >
> > In fact, I don't know how to autodetect the SPI NAND device. Micron
> device and
> > Gigadevice device have different read ID functions. The Chip ID here
> is used to
> > determine which function to use.
> >
> 
> Isn't the difference between the Read ID very minor? One of the vendor
> needs a 2-byte ID read, and the other one needs a 3-byte ID read.
> 
> So you can just try with 2-byte, and if that fails (no vendor ID is
> found on the first byte), you can try with the 3-byte command.
> 
> It's not the most elegant solution, but it's not super awful either.
> --
> Ezequiel

I agree with your idea about try different ways to read ID. It is a better way
to detect the chip if it can work properly.

The difference between the Read ID is that some chips need to send a dummy byte
or address after opcode then read 2 byte, some chips needn't send any data after
opcode but read 3 byte.

I'm concerned maybe chip will get into unknown or vendor specified state if we
send the wrong sequence.

Re: [PATCH 3/3] mtd: spi-nand: add devicetree binding

[Ezequiel Garcia]

On 01/11/2015 10:57 PM, Peter Pan 潘栋 (peterpandong) wrote:
>> On 01/08/2015 02:04 AM, Peter Pan 潘栋 (peterpandong) wrote:
>>>>> This commit adds the devicetree binding document that specifies the
>>>>> spi nand devices support.
>>>>>
>>>>> Signed-off-by: Peter Pan <peterpandong@micron.com>
>>>>> ---
>>>>>  Documentation/devicetree/bindings/mtd/spi-nand.txt | 22
>>>> ++++++++++++++++++++++
>>>>>  1 file changed, 22 insertions(+)
>>>>>  create mode 100644 Documentation/devicetree/bindings/mtd/spi-
>>>> nand.txt
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/mtd/spi-nand.txt
>>>> b/Documentation/devicetree/bindings/mtd/spi-nand.txt
>>>>> new file mode 100644
>>>>> index 0000000..9dd3efd
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/mtd/spi-nand.txt
>>>>> @@ -0,0 +1,22 @@
>>>>> +* NAND driver for MT29F, GD5F and similar SPI NAND flash chips
>>>>> +
>>>>> +Required properties:
>>>>> +- #address-cells, #size-cells : Must be present if the device has
>>>> sub-nodes
>>>>> +  representing partitions.
>>>>> +- compatible : Should be the manufacturer and the name of the chip.
>>>> Bear in mind
>>>>>
>>>>
>>>> Unless I'm mistaken, we don't need the chip ID here, as SPI NAND
>> allows
>>>> to autodetect the device. Any reason why we can't just use a generic
>>>> compatible "spi-nand" here?
>>>> --
>>>> Ezequiel
>>>
>>> In fact, I don't know how to autodetect the SPI NAND device. Micron
>> device and
>>> Gigadevice device have different read ID functions. The Chip ID here
>> is used to
>>> determine which function to use.
>>>
>>
>> Isn't the difference between the Read ID very minor? One of the vendor
>> needs a 2-byte ID read, and the other one needs a 3-byte ID read.
>>
>> So you can just try with 2-byte, and if that fails (no vendor ID is
>> found on the first byte), you can try with the 3-byte command.
>>
>> It's not the most elegant solution, but it's not super awful either.
>> --
>> Ezequiel
> 
> I agree with your idea about try different ways to read ID. It is a better way
> to detect the chip if it can work properly.
> 
> The difference between the Read ID is that some chips need to send a dummy byte
> or address after opcode then read 2 byte, some chips needn't send any data after
> opcode but read 3 byte.
> 
> I'm concerned maybe chip will get into unknown or vendor specified state if we
> send the wrong sequence.
> 

Have you seen this happpening? Or this a potential/future problem?

For the latter, we can always fix it when the issue appears.
-- 
Ezequiel