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

Hi Cole,

On Tue, Aug 18, 2026 at 1:34 PM Cole Munz <[email protected]> wrote:
>
> The controller has a transfer-mode field that can run transmit-only or
> receive-only instead of both, which leaves the unused FIFO out of the
> transfer entirely. The driver never used it for that: claim_bus always
> programmed TMOD_TR, and the only other mode came from an opportunistic
> switch to TMOD_RO for read-only transfers.
>
> A device described with spi-{tx,rx}-bus-width = <0> has no wire in that
> direction at all, so now that the width reaches plat->mode as
> SPI_NO_TX/SPI_NO_RX, pick the transfer mode from it. A write-only
> display stops clocking receive bytes nobody reads.
>
> The transmit-only case needs one more change. The 8-bit loop paces
> itself on the receive FIFO and sets toread unconditionally, so with no
> receive path it would wait on a FIFO that stays empty forever. Leave
> toread at zero there and let the existing wait_till_not_busy() at the
> end of the chunk handle completion, which is the same thing that
> already covers a transmit component today.
>
> The restore at the end of a read-only transfer went back to a hardcoded
> TMOD_TR, which would undo the device's own mode. Restore what the mode
> asks for instead.
>
> Signed-off-by: Cole Munz <[email protected]>
> ---
> Alexey, this is the FIFO wiring you asked about. It applies on top of
> "spi: Handle spi-{tx,rx}-bus-width 0 as SPI_NO_TX/SPI_NO_RX", since it
> needs those bits to exist.
>
> You are right that the first patch is a no-op on its own. With this one
> the Flipper One display bus stops running the receive FIFO at all: the
> MISO pin is the end-of-frame GPIO, so every byte the controller clocked
> in was discarded by the loop anyway.
>
> The part that is not just a mode select is the 8-bit loop. It sets
> toread = todo whether or not the caller passed a din, and drains the
> receive FIFO to pace itself. In TMOD_TO that FIFO never fills, so it
> would spin forever. Leaving toread at zero and letting the existing
> rkspi_wait_till_not_busy() close out the chunk keeps the timing the same
> for the transmit case, which already relied on that call.
>
> Verification, and its limits. I have no Rockchip board, so this is
> compile-tested and reasoned from the driver, not run:
>
>  $ make jaguar-rk3588_defconfig
>  $ make CROSS_COMPILE=aarch64-linux-gnu- drivers/spi/rk_spi.o
>  CC      drivers/spi/rk_spi.o     (exit 0)
>
> checkpatch --strict is 0/0/0. A full board build stops in binman for want
> of BL31 and tee.bin, identically with and without this patch, so that one
> is my missing blobs rather than the change.
>
> What I cannot check here is the hardware behaviour: that TMOD_TO really
> does leave the receive FIFO idle on a real part, and that a write-only
> display still clocks out correctly. If you have a board in front of you,
> that is the bit worth a look.
>
>  drivers/spi/rk_spi.c | 25 ++++++++++++++++++++++---
>  1 file changed, 22 insertions(+), 3 deletions(-)

Looks like you've missed running scripts/get_maintainer.pl on this
one, as Quentin is not on the recipients list and he definitely should
be. I've added him now. Please try `b4` for future submissions, as it
does both checkpatch and get_maintainer automatically, and also
records the base for the patch series in easy to parse metadata.

It probably makes sense to send it as a small series with your patch
[1] to the SPI uclass which this one depends on (and which otherwise
has no users without this patch). There is also something fishy going
on with your SMTP headers, which makes the tooling assume this patch
is a v2 of the prerequisite, so please resend.

[1] https://lore.kernel.org/all/10e92a74c8a22cc2cd54f5dcccc31594016d4263.1787015208.git.Munzzyy1@proton.me/

On a positive side: I've just tried it on the Flipper One, and the
warning is gone while the SPI screen still works in U-Boot for the
transmit-only mode, so please feel free to include:

Tested-by: Alexey Charkov <[email protected]>

Best regards,
Alexey