Message-ID: <779069a1-7389-ab70-9f03-81090d0600ba@microchip.com>
Date:   Thu, 24 Feb 2022 06:37:21 +0000
From:   <Tudor.Ambarus@...rochip.com>
To:     <p.yadav@...com>
CC:     <michael@...le.cc>, <broonie@...nel.org>,
        <miquel.raynal@...tlin.com>, <richard@....at>, <vigneshr@...com>,
        <linux-mtd@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
        <linux-spi@...r.kernel.org>, <Nicolas.Ferre@...rochip.com>,
        <zhengxunli@...c.com.tw>, <jaimeliao@...c.com.tw>
Subject: Re: [PATCH 0/4] spi-mem: Allow specifying the byte order in DTR mode

On 2/24/22 08:08, Tudor.Ambarus@...rochip.com wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On 2/23/22 20:38, Pratyush Yadav wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>
>> Hi Tudor,
>>
>> On 22/02/22 02:43PM, Tudor.Ambarus@...rochip.com wrote:
>>> On 2/22/22 16:27, Michael Walle wrote:
>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>>>
>>>> Am 2022-02-22 15:23, schrieb Tudor.Ambarus@...rochip.com:
>>>>> On 2/22/22 16:13, Michael Walle wrote:
>>>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know
>>>>>> the content is safe
>>>>>>
>>>>>> Am 2022-02-22 14:54, schrieb Tudor.Ambarus@...rochip.com:
>>>>>>> On 2/21/22 09:44, Michael Walle wrote:
>>>>>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you
>>>>>>>> know
>>>>>>>> the content is safe
>>>>>>>>
>>>>>>>> Am 2022-02-18 15:58, schrieb Tudor Ambarus:
>>>>>>>>> Fortunately there are controllers
>>>>>>>>> that can swap back the bytes at runtime, fixing the endiannesses.
>>>>>>>>> Provide
>>>>>>>>> a way for the upper layers to specify the byte order in DTR mode.
>>>>>>>>
>>>>>>>> Are there any patches for the atmel-quadspi yet? What happens if
>>>>>>>
>>>>>>> not public, but will publish them these days.
>>>>>>>
>>>>>>>> the controller doesn't support it? Will there be a software
>>>>>>>> fallback?
>>>>>>>
>>>>>>> no need for a fallback, the controller can ignore
>>>>>>> op->data.dtr_bswap16
>>>>>>> if
>>>>>>> it can't swap bytes.
>>>>>>
>>>>>> I don't understand. If the controller doesn't swap the 16bit values,
>>>>>> you will read the wrong content, no?
>>>>>>
>>>>>
>>>>> In linux no, because macronix swaps bytes on a 2 byte boundary both on
>>>>> reads and on page program. The problem is when you mix 8D-8D-8D mode
>>>>> and
>>>>> 1-1-1 mode along the boot stages. Let's assume you write all boot
>>>>> binaries
>>>>> in 1-1-1 mode. When reaching u-boot if you enable 8D-8D-8D mode, when
>>>>> u-boot
>>>>> will try to get the kernel it will fail, as the flash swaps the bytes
>>>>> compared
>>>>> to what was written with 1-1-1 mode. You write D0 D1 D2 D3 in 1-1-1
>>>>> mode and
>>>>> when reaching u-boot you will read D1 D0 D3 D2 and it will mess the
>>>>> kernel image.
>>>>
>>>> But you have to consider also 3rd parties, like an external programmer
>>>> or
>>>
>>> Why? If you use the same mode when reading and writing, everything is fine.
>>> I'm not sure what's your suggestion here.
>>
>> So our stance here is that we don't care about external programs?>
>> If that is the case then why bother with all this anyway? Since the swap
>> happens at both page program and read, what you write is what you read
>> back. Who cares the order stored in the actual flash memory as long as
>> the data read is correct?
>>
>> If we do care about external programs, then what would happen if the
>> external program writes data in 8D-8D-8D mode _without_ swapping the
>> bytes? This would also cause data corruption. You can't control what
>> they mode they use, and you can't detect it later either.
>>
>> I think there is no winning here. You just have to say that external
>> programs should write in 8D-8D-8D mode or it won't boot.
>>
> 
> How about swapping the bytes just at user request? Maybe with a Kconfig
> option.

Michael has suggested on #irc to always swap the bytes: if the SPI controller
can't do it, to do it in software at SPI NOR level. I don't know what to say
about this, because JEDEC216 just informs the reader I guess:
"Byte order of 16-bit words is swapped when read in 8D-8D-8D mode compared to
1-1-1 mode.", this doesn't look like a hard request. The downside to doing
the swapping in software is performance penalty which will make macronix
users have second thoughts. I don't have a strong opinion, but I lean towards
doing the swap just at user request, regardless if I do it via the SPI controller
or in software.

I would love to hear Macronix's opinion.

Cheers,
ta

> 
>>>
>>>> another OS. So, there has to be *one correct* way of writing/reading
>>>> these
>>>> bytes.
>>>>
>>>
>>>
>>
>> --
>> Regards,
>> Pratyush Yadav
>> Texas Instruments Inc.
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

Powered by blists - more mailing lists