[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <56F54ED2.3030609@atmel.com>
Date: Fri, 25 Mar 2016 15:44:34 +0100
From: Cyrille Pitchen <cyrille.pitchen@...el.com>
To: Rob Herring <robh+dt@...nel.org>,
Brian Norris <computersforpeace@...il.com>
CC: "linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
"Nicolas Ferre" <nicolas.ferre@...el.com>,
boris brezillon <boris.brezillon@...e-electrons.com>,
Marek Vašut <marex@...x.de>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
Pawel Moll <pawel.moll@....com>,
Mark Rutland <mark.rutland@....com>,
Ian Campbell <ijc+devicetree@...lion.org.uk>,
"Kumar Gala" <galak@...eaurora.org>
Subject: Re: [PATCH v2 2/2] doc: dt: mtd: add a DT property to enable the use
of 4byte-address op codes
Hi all,
Since the framework is named spi-nor, what about spi-nor-4byte-opcodes?
Is it okay for everyone?
It would follow the same pattern as spi-max-frequency which applies to all SPI
devices.
Best regards,
Cyrille
Le 23/03/2016 16:08, Cyrille Pitchen a écrit :
> Hi Rob,
>
> sorry I've sent v3 at the same time as you answered to v2.
> I'll take your comments into account for v4.
>
> Brian, any preference between 4byte-opcodes or m25p-4byte-opcodes?
>
> Best regards,
>
> Cyrille
>
> Le 23/03/2016 13:49, Rob Herring a écrit :
>> On Tue, Mar 22, 2016 at 10:13 AM, Cyrille Pitchen
>> <cyrille.pitchen@...el.com> wrote:
>>> This patch adds a new optional DT property which enables an alternative
>>> way of supporting memory size above 16MiB (128Mib). This new mechanism
>>> translates the regular 3byte-address op codes into their 4byte-address
>>> version whereas the old/default mecanism makes the SPI memory enter its
>>> 4byte-address mode, which has annoying side effects for early bootloaders.
>>>
>>> We cannot discover at run time whether the SPI NOR memory supports the
>>> 4byte-address op codes. For instance both Macronix MX25L25635E and
>>> MX25L25673G share the same JEDEC ID (C22019 without any extension byte).
>>> However the first one doesn't support 4byte-address op codes whereas the
>>> second one does.
>>>
>>> Signed-off-by: Cyrille Pitchen <cyrille.pitchen@...el.com>
>>> ---
>>> Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt | 11 +++++++++++
>>> 1 file changed, 11 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
>>> index 2c91c03e7eb0..8be610482089 100644
>>> --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
>>> +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
>>> @@ -66,6 +66,17 @@ Optional properties:
>>> Refer to your chips' datasheet to check if this is supported
>>> by your chip.
>>>
>>> +- m25p,4byte-opcodes: For memory size above 16MiB (128Mib), use the dedicated
>>
>> m25p is not a vendor. So drop it or m25p-4byte-opcodes.
>>
>>> + 4byte-address opcodes instead of entering the 4byte
>>> + address mode. This mode changes the internal state of the
>>> + chip so may conflict with some early boot loaders, which
>>> + expect to use the regular (Fast) Read opcodes with 3byte
>>> + address.
>>> + However 4byte-address opcodes are not supported by all
>>> + chips and support for them can not be detected at runtime.
>>
>> s/can not/cannot/
>>
>>> + Refer to you chip's datasheet to check if this is
>>> + supported by your chip.
>>> +
>>> Example:
>>>
>>> flash: m25p80@0 {
>>> --
>>> 1.8.2.2
>>>
>
Powered by blists - more mailing lists