Re: [PATCH v4 2/2] spi: rockchip: skip the unused FIFO direction on a one-wire device
Quentin Schulz <[email protected]>
| Newsgroups | gmane.comp.boot-loaders.u-boot |
|---|---|
| Message-ID | <ea79f87e-48d0-4f96-95bb-9a04fc82faf8__48301.733638958$1787338198$gmane$org@cherry.de> |
Hi Cole,
On 8/21/26 1:55 PM, Cole Munz 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]>
> Tested-by: Alexey Charkov <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
I'm planning to take both patches for 2027.01 (next branch; end of next
week) as this is not fixing a recent regression or a security issue.
Thanks!
Quentin