On Tue, Oct 16, 2018 at 07:29:21PM +0000, Trent Piepho wrote: > On Tue, 2018-10-16 at 10:03 +0100, Mark Brown wrote: > > On Mon, Oct 15, 2018 at 06:34:18PM +0000, Trent Piepho wrote: > > > I imagine it depends on what set_cs needs to do, which might not be > > > solely related to changing the CS line. > > It should be. If something is hanging other work on set_cs() then it's > > going to break. > IIRC, for spi-dw setting CS is the only way to trigger the master to do > anything. I think orion is the same way. Even if you don't want a CS > line the driver still needs to assert one. Which CS to use as the > dummy CS is a challenge that has come up before. > bcm2835_spi_set_cs() does check SPI_NO_CS, but it still does a lot of > other stuff even if that is set, likely because of the above issue. For hardware that's that broken I'd recommend deferring the actual CS setting operation to the transfer operation instead; that way we can guarantee it happens for any pattern of access to the chip select (or error out if we can't represent it properly, though obviously a lot of such systems use a GPIO for the chip select to work around the broken hardware).
Attachment:
signature.asc
Description: PGP signature
