linux-spi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: <Tudor.Ambarus@microchip.com>
To: <p.yadav@ti.com>
Cc: <michael@walle.cc>, <broonie@kernel.org>,
	<miquel.raynal@bootlin.com>, <richard@nod.at>, <vigneshr@ti.com>,
	<linux-mtd@lists.infradead.org>, <linux-kernel@vger.kernel.org>,
	<linux-spi@vger.kernel.org>, <Nicolas.Ferre@microchip.com>,
	<zhengxunli@mxic.com.tw>, <jaimeliao@mxic.com.tw>
Subject: Re: [PATCH 1/4] spi: spi-mem: Allow specifying the byte order in DTR mode
Date: Thu, 10 Mar 2022 05:31:19 +0000	[thread overview]
Message-ID: <f0501c29-ae70-185d-8f40-4a249e49575e@microchip.com> (raw)
In-Reply-To: <20220302100255.gseqjbdyxrgmt3zf@ti.com>

On 3/2/22 12:02, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> Hi Tudor,

Hi, Pratyush,

> 
> I'm reviewing the code here. I still have not thought through the
> discussion about Kconfig option yet.
> 
> On 18/02/22 04:58PM, Tudor Ambarus wrote:
>> There are NOR flashes (Macronix) that swap the bytes on a 16-bit boundary
>> when configured in DTR mode. The byte order of 16-bit words is swapped
> 
> s/DTR mode/ Octal DTR mode/
> 
> I don't think this would apply to a 4D-4D-4D flash since it would only
> transmit one byte per clock cycle.

From what I see, flashes that claim "QPI DTR support" they actually support
4S-4D-4D. JESD251-1 talks about 4S-4D-4D too. So data is latched on both rising
and falling edges of the clock. But I'm ok with your proposal because we don't
have any proof if there are any QPI DTR flashes that swap bytes in DTR.

> 
>> when read or written in Double Transfer Rate (DTR) mode compared to
>> Single Transfer Rate (STR) mode. If one writes D0 D1 D2 D3 bytes using
>> 1-1-1 mode, and uses 8D-8D-8D SPI mode for reading, it will read back
>> D1 D0 D3 D2. Swapping the bytes is a bad design decision because this may
>> introduce some endianness problems. It can affect the boot sequence if the
>> entire boot sequence is not handled in either 8D-8D-8D mode or 1-1-1 mode.
>> 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.
>>
>> Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
>> ---
>>  include/linux/spi/spi-mem.h | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/include/linux/spi/spi-mem.h b/include/linux/spi/spi-mem.h
>> index 85e2ff7b840d..e1878417420c 100644
>> --- a/include/linux/spi/spi-mem.h
>> +++ b/include/linux/spi/spi-mem.h
>> @@ -89,6 +89,8 @@ enum spi_mem_data_dir {
>>   * @dummy.dtr: whether the dummy bytes should be sent in DTR mode or not
>>   * @data.buswidth: number of IO lanes used to send/receive the data
>>   * @data.dtr: whether the data should be sent in DTR mode or not
>> + * @data.dtr_bswap16: whether the byte order of 16-bit words is swapped when
>> + *                 read or written in DTR mode compared to STR mode.
>>   * @data.dir: direction of the transfer
>>   * @data.nbytes: number of data bytes to send/receive. Can be zero if the
>>   *            operation does not involve transferring data
>> @@ -119,6 +121,7 @@ struct spi_mem_op {
>>       struct {
>>               u8 buswidth;
>>               u8 dtr : 1;
>> +             u8 dtr_bswap16 : 1;

but I would keep this name here as it is, without prepending octal.

> 
> You also need to add this capability to spi_controller_mem_caps and
> update spi_mem_default_supports_op() to check for it.

sure, will do.

Thanks!
ta
> 
>>               enum spi_mem_data_dir dir;
>>               unsigned int nbytes;
>>               union {
>> --
>> 2.25.1
>>
> 
> --
> Regards,
> Pratyush Yadav
> Texas Instruments Inc.


  reply	other threads:[~2022-03-10  5:31 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-18 14:58 [PATCH 0/4] spi-mem: Allow specifying the byte order in DTR mode Tudor Ambarus
2022-02-18 14:58 ` [PATCH 1/4] spi: " Tudor Ambarus
2022-03-02 10:02   ` Pratyush Yadav
2022-03-10  5:31     ` Tudor.Ambarus [this message]
2022-03-11 17:47       ` Pratyush Yadav
2022-02-18 14:58 ` [PATCH 2/4] mtd: spi-nor: core: " Tudor Ambarus
2022-02-21  7:36   ` Michael Walle
2022-02-22 14:02     ` Tudor.Ambarus
2022-02-22 14:23       ` Michael Walle
2022-03-02 11:34   ` Pratyush Yadav
2022-03-10  8:54     ` Tudor.Ambarus
2022-02-18 14:58 ` [PATCH 3/4] mtd: spi-nor: sfdp: Get the 8D-8D-8D byte order from BFPT Tudor Ambarus
2022-02-21  7:40   ` Michael Walle
2022-03-02 12:28   ` Pratyush Yadav
2022-02-18 14:59 ` [PATCH 4/4] mtd: spi-nor: core: Introduce SPI_NOR_DTR_BSWAP16 no_sfdp_flag Tudor Ambarus
2022-02-21  7:41   ` Michael Walle
2022-03-02 12:30   ` Pratyush Yadav
2022-03-10  4:42     ` Tudor.Ambarus
2022-02-21  7:44 ` [PATCH 0/4] spi-mem: Allow specifying the byte order in DTR mode Michael Walle
2022-02-22 13:54   ` Tudor.Ambarus
2022-02-22 14:13     ` Michael Walle
2022-02-22 14:23       ` Tudor.Ambarus
2022-02-22 14:27         ` Michael Walle
2022-02-22 14:43           ` Tudor.Ambarus
2022-02-23 18:38             ` Pratyush Yadav
2022-02-24  6:08               ` Tudor.Ambarus
2022-02-24  6:37                 ` Tudor.Ambarus
2022-02-24  9:37                   ` Michael Walle
2022-02-24 10:27                     ` Tudor.Ambarus
2022-02-25  7:35                       ` zhengxunli
2022-02-24 13:24                     ` Pratyush Yadav
2022-02-24 14:02                       ` Michael Walle
2022-02-24 14:33                         ` Tudor.Ambarus

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=f0501c29-ae70-185d-8f40-4a249e49575e@microchip.com \
    --to=tudor.ambarus@microchip.com \
    --cc=Nicolas.Ferre@microchip.com \
    --cc=broonie@kernel.org \
    --cc=jaimeliao@mxic.com.tw \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=michael@walle.cc \
    --cc=miquel.raynal@bootlin.com \
    --cc=p.yadav@ti.com \
    --cc=richard@nod.at \
    --cc=vigneshr@ti.com \
    --cc=zhengxunli@mxic.com.tw \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).