Messages in this thread | | | Date | Thu, 14 May 2020 15:35:37 +0100 | From | Mark Brown <> | Subject | Re: [PATCH 11/17] spi: dw: Fix native CS being unset |
| |
On Thu, May 14, 2020 at 02:55:58PM +0300, Serge Semin wrote: > On Thu, May 14, 2020 at 10:31:13AM +0200, Linus Walleij wrote:
> > We had some related discussion what to do with this case > > when a controller can support active high CS if and only if > > it is using a GPIO instead of the native CS. We didn't really > > figure it out, I suppose ideally we should use two flags in the > > master but that exercise is for another day.
> Even though it might be painful, but as I see it the best way to generically fix > this problem would be to change the controller->set_cs() callback > semantics. SPI core should pass a CS activation flag to the set_cs() > callback instead of the CS pin logical level (just propagate the enable argument > passed to the spi_set_cs() SPI core method). So if an SPI controller supports > the Active-high native CS, during the set_cs() callback invocation it would > analyze the spi_device flags state to figure out whether the slave needs the
The idea with set_cs() is to support controllers that allow the chip select to be directly managed. If the controller is interpreting or automatically managing chip select at all then set_cs() is not likely to be a good fit, if the controller does support unfiltered management then anything else is going to result in there being a bunch of duplicate code between drivers. [unhandled content-type:application/pgp-signature] | |