From: David Laight <David.Laight@ACULAB.COM>
To: 'Michael Walle' <michael@walle.cc>
Cc: 'Vignesh Raghavendra' <vigneshr@ti.com>,
Tudor Ambarus <tudor.ambarus@microchip.com>,
"p.yadav@ti.com" <p.yadav@ti.com>,
"broonie@kernel.org" <broonie@kernel.org>,
"miquel.raynal@bootlin.com" <miquel.raynal@bootlin.com>,
"richard@nod.at" <richard@nod.at>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-spi@vger.kernel.org" <linux-spi@vger.kernel.org>,
"nicolas.ferre@microchip.com" <nicolas.ferre@microchip.com>
Subject: RE: [PATCH v2 0/6] spi-mem: Allow specifying the byte order in DTR mode
Date: Thu, 17 Mar 2022 10:14:08 +0000 [thread overview]
Message-ID: <8b765d24cb9a422bb383aad07251b65f@AcuMS.aculab.com> (raw)
In-Reply-To: <bc2083a8903fdabc65083f7e5232ca2d@walle.cc>
From: Michael Walle
> Sent: 17 March 2022 09:40
>
> Am 2022-03-16 14:55, schrieb David Laight:
> > Thought...
>
> Thank you for your proposal.
>
> > Can you read the device in STR mode until you get a suitable
> > non-palindromic value, then read it in DTR mode and dynamically
> > determine the byte order?
> >
> > Clearly this won't work if the device is erased to all 0xff.
> > But a check could be done on/after the first write.
> >
> > I suspect write times are actually dominated by the time spent
> > waiting for the write to complete?
> > (Never mind the earlier block erase time.)
> > So always writing in STR mode probably makes little difference?
> > Writes really ought to be uncommon as well.
> >
> > Speeding up reads is a different matter - and probably useful.
> >
> > Of course, if you've got hardware reading the spi memory in DTR
> > mode for config data you might need to byteswap it (compared
> > to the STR writes) - but that is probably a 2nd order problem.
> >
> > I've got some bespoke logic on an PCIe fpga for accessing spi memory.
> > Uses address bits for the control signals and converts a 32bit
> > read/write into 8 nibble transfers to the chip.
> > (uses byte enables - don't an odd number of clocks.)
> > mmapp()ed to userspace for updating the 6MB fpga image.
>
> Our problem is not how to detect that we have to swap it, but
> rather what we do when we have to do it.
>
> If we have a controller which can swap the bytes for us on the
> fly, we are lucky and can enable swapping if we need it. We are
> also lucky when we don't have to swap the flash contents, obviously.
>
> But what do we do when we need to swap it and the controller
> doesn't support it. We could do it in software which will slow
> things down. So depending on the use case this might or might not
> work. We can degrade it to a speed which doesn't have this issue;
> which might be 1-1-1 in the worst case. We could also do just
> nothing special; but this will lead to inconsistencies between
> reading in 1-1-1 and 8d-8d-8d.
I really doubt you'll notice the effects of a software byteswap
compared to the actual time taken to do an spi read.
What's the maximum clock rate for spi memory?
Something like 50MHz ?
If the spi controller isn't doing dma then the cpu pio reads
to get the data are very likely to be even slower than that.
(Especially if they are PCIe reads.)
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
next prev parent reply other threads:[~2022-03-17 10:14 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-11 8:01 [PATCH v2 0/6] spi-mem: Allow specifying the byte order in DTR mode Tudor Ambarus
2022-03-11 8:01 ` [PATCH v2 1/6] spi: " Tudor Ambarus
2022-03-11 8:01 ` [PATCH v2 2/6] mtd: spi-nor: core: " Tudor Ambarus
2022-03-11 8:01 ` [PATCH v2 3/6] mtd: spi-nor: sfdp: Get the 8D-8D-8D byte order from BFPT Tudor Ambarus
2022-03-11 8:01 ` [PATCH v2 4/6] mtd: spi-nor: core: Introduce SPI_NOR_DTR_BSWAP16 no_sfdp_flag Tudor Ambarus
2022-03-11 8:01 ` [PATCH v2 5/6] mtd: spi-nor: core: Introduce SPI_NOR_SOFT_RESET flash_info fixup_flag Tudor Ambarus
2022-03-11 8:01 ` [PATCH v2 6/6] mtd: spi-nor: macronix: Add support for mx66lm1g45g Tudor Ambarus
2022-03-15 6:08 ` [PATCH v2 0/6] spi-mem: Allow specifying the byte order in DTR mode Vignesh Raghavendra
2022-03-15 6:58 ` Tudor.Ambarus
2022-03-16 7:08 ` Vignesh Raghavendra
2022-03-16 8:39 ` Michael Walle
2022-03-15 7:19 ` Michael Walle
2022-03-16 7:05 ` Vignesh Raghavendra
2022-03-16 7:57 ` Tudor.Ambarus
2022-03-16 13:55 ` David Laight
2022-03-17 9:40 ` Michael Walle
2022-03-17 10:14 ` David Laight [this message]
2022-03-17 10:23 ` Vignesh Raghavendra
2022-03-17 11:10 ` David Laight
2022-03-17 16:49 ` Vignesh Raghavendra
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=8b765d24cb9a422bb383aad07251b65f@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=broonie@kernel.org \
--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=nicolas.ferre@microchip.com \
--cc=p.yadav@ti.com \
--cc=richard@nod.at \
--cc=tudor.ambarus@microchip.com \
--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 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).