[PATCH 03/32] spi: dw: Fix driving MOSI low while recieving
Sean Anderson
seanga2 at gmail.com
Mon Nov 9 08:47:10 EST 2020
On 11/9/20 8:29 AM, Mark Brown wrote:
> On Sat, Nov 07, 2020 at 05:13:51PM +0900, Damien Le Moal wrote:
>
>> The resting state of MOSI is high when nothing is driving it. If we
>> drive it low while recieving, it looks like we are transmitting 0x00
>> instead of transmitting nothing. This can confuse slaves (like SD cards)
>> which allow new commands to be sent over MOSI while they are returning
>> data over MISO. The return of MOSI from 0 to 1 at the end of recieving
>> a byte can look like a start bit and a transmission bit to an SD card.
>
> If client devices are interpreting the transmitted data then I would
> expect the drivers for that hardware to be ensuring that whatever we
> transmit matches what the device is expecting. We shouldn't be putting
> a hack in a particular controller driver to paper over things, that will
> mean that the device will break when used with other controllers and if
> different devices have different requirements then obviously we can't
> satisfy them. There is not meaningfully a general specification for SPI
> which says what happens when signals are idle, it's all specific to the
> client device.
>
> In this case it also looks like the controller hardware requires
> transmit data and therefore should be setting SPI_MUST_TX and just
> removing the in driver default anyway, though that will have no effect
> one way or anther on the issue you're seeing.
There is a recieve-only mode, but it is not used by this driver. Perhaps
it should be.
> Please also try to avoid the use of master/slave terminology where
> reasonable, controller and device tend to work for SPI (though MOSI/MISO
> are going to be harder to shift).
Here I use it to draw distinction between the SPI master and the SPI
slave, which are both devices in different contexts.
--Sean
More information about the linux-riscv
mailing list