On 12/04/19 8:29 PM, Mark Brown wrote:
> On Fri, Apr 12, 2019 at 05:02:10PM +1200, Chris Packham wrote:
>
>> Unfortunately recent changes have stopped my hacks from working. I've
>> tried adapting cs-gpios to work with my particular hardware but I came
>> to the realisation that the current cs-gpios support assumes a 1:1
>> mapping of gpio to SPI device whereas my hardware used the state of the
>> gpio selecting the device i.e. a 1:2 mapping.
>
>> This is my attempt to implement a driver to deal with this. One nice
>> property is that it is pretty much self contained. The only change to
>> the core SPI infrastructure is exposing a function I needed to lookup
>> the spi_controller instance.
>
> Why not implement the device that demuxes the GPIOs you're using for
> chip select as a GPIO controller? Presumably it might get used for
> things other than chip selects.
>
Hmm a gpio-gpio driver. Interesting.
One other problem that I encounter is the interaction between cs-gpio
and SPI_MASTER_GPIO_SS. Having cs-gpio automatically sets SPI_CS_HIGH
which has the undesired side-effect that now my real chip select is
inverted. I actually wonder if this change breaks commit 8eee6b9dd30d
("spi: Add Flag to Enable Slave Select with GPIO Chip Select.") since
now there is an extra inversion on the CS enable.
