From: Tudor Ambarus <tudor.ambarus@linaro.org>
To: Michael Walle <michael@walle.cc>
Cc: Serge Semin <fancer.lancer@gmail.com>,
Sergiu.Moga@microchip.com, Mark Brown <broonie@kernel.org>,
Tudor Ambarus <tudor.ambarus@microchip.com>,
Pratyush Yadav <pratyush@kernel.org>,
miquel.raynal@bootlin.com, richard@nod.at, vigneshr@ti.com,
Nicolas.Ferre@microchip.com, alexandre.belloni@bootlin.com,
Claudiu.Beznea@microchip.com, chin-ting_kuo@aspeedtech.com,
clg@kaod.org, joel@jms.id.au, andrew@aj.id.au,
kdasu.kdev@gmail.com, han.xu@nxp.com, john.garry@huawei.com,
matthias.bgg@gmail.com, avifishman70@gmail.com,
tmaimon77@gmail.com, tali.perry1@gmail.com, venture@google.com,
yuenn@google.com, benjaminfair@google.com, haibo.chen@nxp.com,
yogeshgaur.83@gmail.com, heiko@sntech.de,
mcoquelin.stm32@gmail.com, alexandre.torgue@foss.st.com,
michal.simek@xilinx.com, bcm-kernel-feedback-list@broadcom.com,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-spi@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, openbmc@lists.ozlabs.org,
linux-mediatek@lists.infradead.org,
linux-rockchip@lists.infradead.org,
linux-stm32@st-md-mailman.stormreply.com
Subject: Re: [PATCH] spi: Replace `dummy.nbytes` with `dummy.ncycles`
Date: Thu, 9 Mar 2023 15:54:25 +0200 [thread overview]
Message-ID: <b8b61fc0-1e4f-146b-2036-03fda5359585@linaro.org> (raw)
In-Reply-To: <460ef5ff3846b409b322ca53559e2476@walle.cc>
On 09.03.2023 15:33, Michael Walle wrote:
>>>> The controllers that can talk in dummy ncycles don't need the
>>>> dummy.{buswidth, dtr} fields.
>>>>
>>>> The controllers that can't talk in dummy cycles, but only on a "byte"
>>>> boundary need both buswidth and dtr fields. Assume a flash needs 32
>>>> dummy cycles for an op on 8D-8D-8D mode. If the controller does not
>>>> have
>>>> the buswidth and dtr info, it can't convert the dummy ncycles to
>>>> nbytes.
>>>> If he knows only that buswidth is 8, it will convert ncycles to 4
>>>> bytes.
>>>> If dtr is also specified it converts ncycles to 2 bytes.
>>>
>>> No they don't need it. Lets take your semper flash and assume it needs
>>> 12 latency cycles. SPI-NOR will set ncycles to 12 *regardless of the
>>> mode
>>> or dtr setting*. The controller then knows we need 12 clock cycles.
>>> It has
>>> then to figure out how that can be achieved. E.g. if it can only do the
>>> "old" byte programming and is in quad mode, good for it. It will send 6
>>> dummy bytes, which will result in 12 dummy clock cycles, because 1 byte
>>> takes two clock cycles in quad SDR mode. If its in octal mode, send 12
>>> bytes. If its in dual mode, send 3 bytes. Obiously, it cannot be in
>>> single bit mode, because it cannot send 1.5 bytes..
>>>
>>
>> You miss the fact that you can have 1-1-4. What buswidth do you use
>> for dummy, the address buswidth or the data buswidth?
>
> Doesn't matter, does it? The driver is free to chose, 1, 4, or anything
> else. You don't sample any data during the dummy phase.
> To answer your question: single for instruction, single for address,
> whatever you choose for dummy as long as there are ncycles space between
> address and data, and quad for data.
Huh? How does the controller chose, based on what?
>
> Depending on the capabilites of the hardware it will likely be 1 or 4.
>
>> What happens if crazy protocols like 1S-1S-8D appear? What buswidth
>> and transfer mode are you going to use for dummy?
>
> Also doesn't matter. What matters is how many dummy clock cycles you
> do. Again, they don't depent on the mode. You just have to count
> the clock cycles between the address and the data phase (and that is
> what your ncycle parameter will tell the controller).
>
>> And please don't tell me that "we're going to assume that
>> dummy.buswidth = address.buswidth because that's what we currently do
>> in SPI NOR", because I'm not convinced that the assumption is correct.
>
> No, it doesn't matter :)
>
> -michael
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
next prev parent reply other threads:[~2023-03-09 13:56 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-11 17:45 [PATCH] spi: Replace `dummy.nbytes` with `dummy.ncycles` Sergiu Moga
2022-09-12 9:44 ` Patrice CHOTARD
2022-09-12 10:58 ` Tudor.Ambarus
2022-09-12 11:52 ` Mark Brown
2022-09-25 22:03 ` Serge Semin
2022-09-26 9:05 ` Sergiu.Moga
2022-09-26 17:24 ` Serge Semin
2022-09-27 8:21 ` Sergiu.Moga
2023-03-08 9:04 ` Tudor Ambarus
2023-03-09 8:38 ` Michael Walle
2023-03-09 10:42 ` Tudor Ambarus
2023-03-09 10:56 ` Michael Walle
2023-03-09 12:09 ` Tudor Ambarus
2023-03-09 12:35 ` Michael Walle
2023-03-09 13:23 ` Tudor Ambarus
2023-03-09 13:33 ` Michael Walle
2023-03-09 13:54 ` Tudor Ambarus [this message]
2023-03-09 14:01 ` Michael Walle
2023-03-09 14:19 ` Chuanhong Guo
2023-03-09 15:41 ` Michael Walle
2023-03-09 15:41 ` Tudor Ambarus
2023-03-04 5:59 ` 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=b8b61fc0-1e4f-146b-2036-03fda5359585@linaro.org \
--to=tudor.ambarus@linaro.org \
--cc=Claudiu.Beznea@microchip.com \
--cc=Nicolas.Ferre@microchip.com \
--cc=Sergiu.Moga@microchip.com \
--cc=alexandre.belloni@bootlin.com \
--cc=alexandre.torgue@foss.st.com \
--cc=andrew@aj.id.au \
--cc=avifishman70@gmail.com \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=benjaminfair@google.com \
--cc=broonie@kernel.org \
--cc=chin-ting_kuo@aspeedtech.com \
--cc=clg@kaod.org \
--cc=fancer.lancer@gmail.com \
--cc=haibo.chen@nxp.com \
--cc=han.xu@nxp.com \
--cc=heiko@sntech.de \
--cc=joel@jms.id.au \
--cc=john.garry@huawei.com \
--cc=kdasu.kdev@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-aspeed@lists.ozlabs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux-spi@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=matthias.bgg@gmail.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=michael@walle.cc \
--cc=michal.simek@xilinx.com \
--cc=miquel.raynal@bootlin.com \
--cc=openbmc@lists.ozlabs.org \
--cc=pratyush@kernel.org \
--cc=richard@nod.at \
--cc=tali.perry1@gmail.com \
--cc=tmaimon77@gmail.com \
--cc=tudor.ambarus@microchip.com \
--cc=venture@google.com \
--cc=vigneshr@ti.com \
--cc=yogeshgaur.83@gmail.com \
--cc=yuenn@google.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