Re: [PATCH v2 2/2] spi: rockchip: skip the unused FIFO direction on a one-wire device

Hi Quentin,

On 8/21/26 12:12 PM, Quentin Schulz wrote:
> Are you sure? The controller needs to tell the peripheral which data
> it's interested in. Therefore, the peripheral cannot send data to the
> controller until it knows what it wants?

At the protocol level you're right. The peripheral has nothing useful
to say before it sees a command. At the controller level TMOD_TR still
shifts POCI into the RX FIFO on every frame no matter what the
peripheral drives. The existing loop depends on that: toread counts
down todo bytes even for write-only transfers where in is NULL and
every byte is discarded. If the RX FIFO stayed empty there the loop
would hang today.

> The controller has 64x 16b-wide RX and TX FIFOs, so my reading of the
> TRM means that you can have up to 64 16b data pending in RX and/or TX
> FIFOs. So I'm not sure "pacing" is the correct term here.

Fair, pacing was the wrong word. Writes run ahead into the FIFO and
nothing slows them down. The RX drain gates the loop exit instead. The
last RX byte only lands once the last frame has clocked, so in TMOD_TR
the loop cannot exit before the wire is done. In TMOD_TO that gate is
gone and wait_till_not_busy() is all that remains. Same conclusion as
yours.

> If we agree on this, then I think
> it's more appropriate to reword the comment just before
> rkspi_wait_till_not_busy() to specify we wait till the TX FIFO has been
> sent over the wire before starting a new transfer as disabling the
> controller will clear all FIFOs.

Agreed. v4 shrinks the toread comment to your one sentence and rewords
the one above rkspi_wait_till_not_busy() to say the TX FIFO can still
hold unsent data and disabling the controller clears the FIFOs. Thanks
for digging into the TRM.

Cheers,
Cole