[U-Boot] [PATCH 1/4 v2] spi: spi-mem: Use 2 SPI messages instead of a single full-duplex one

Stefan Roese sr at denx.de
Thu Aug 9 05:24:14 UTC 2018


Hi Miquel,

On 08.08.2018 10:56, Miquel Raynal wrote:
> Boris Brezillon <boris.brezillon at bootlin.com> wrote on Tue, 7 Aug 2018
> 15:28:02 +0200:
> 
>> On Tue,  7 Aug 2018 14:16:52 +0200
>> Stefan Roese <sr at denx.de> wrote:
>>
>>> Some SPI controller do not support full-duplex SPI transfers. This patch
>>> changes the SPI transfer into 2 separate transfers - or 1, if no data is
>>> to transmitted.
>>>
>>> With this change, no buffers need to be allocated anymore. We use the
>>> TX and RX buffers that are passed to spi_mem_exec_op() directly.
>>>
>>> Signed-off-by: Stefan Roese <sr at denx.de>
>>> Suggested-by: Boris Brezillon <boris.brezillon at bootlin.com>
>>> Cc: Miquel Raynal <miquel.raynal at bootlin.com>
>>> Cc: Boris Brezillon <boris.brezillon at bootlin.com>
>>> Cc: Jagan Teki <jagan at openedev.com>
>>
>> Looks good overall, just a few comments (that you might chose to ignore
>> if you disagree).
>>
>> Reviewed-by: Boris Brezillon <boris.brezillon at bootlin.com>
>>
> 
> Sorry for being a bit late on the discussion, but while I do agree with
> the change, I'm not sure about its implementation : I think SPI
> controllers are supposed to be abstracted by the SPI layer.
> Addressing the controller's limitations in the SPI-mem layer would
> not be appropriate.
> 
> Would it be possible to adapt spi_xfer() to handle such case?

No, I don't think so. Its impossible to guess in the SPI driver layer,
which parts of the message are TX data and which are RX data. So this
message can't be split up into a half-duplex one here. This can only
be done in the driver which constructs the SPI messages.

Or did I miss something here?

Thanks,
Stefan


More information about the U-Boot mailing list