Re: Multiplex SPI Chip Selects

[Chris Packham <Chris.Packham@xxxxxxxxxxxxxxxxxxx>]

On Mon, 2020-01-06 at 08:27 -0500, Anthony DeRosa wrote:
> Hi Chris,
> 
> On Sun, Jan 5, 2020 at 3:47 PM Chris Packham
> <Chris.Packham@xxxxxxxxxxxxxxxxxxx> wrote:
> > 
> > Hi Anthony,
> > 
> > > On Wed, 2020-01-01 at 09:21 -0500, Anthony DeRosa wrote:
> > > Hi Chris,
> > > 
> > > I saw your thread[1] about multiplexing chip selects on the SPI bus
> > > and wondered what solution you settled on in the end. Looks like your
> > > patch was not integrated into the kernel, is that right? I have a
> > > similar problem where I need to use GPIOs to multiplex the CS0 pin on
> > > a raspberry pi. Any insights would be appreciated.
> > > 
> > 
> > For the simple case the existing cs-gpios support works well. So using
> > that if you can is my recommendation.
> > 
> > Unfortunately for me it's not that simple because I have 2 platforms
> > which need both the gpio CS and the native CS0. This is where things
> > get a bit tricky.
> > 
> > The existing code will invert the native CS0 (because SPI_CS_HIGH is
> > set) I think this is a straight corner-case bug and we should either
> > not invert the native CS0 or have a separate flag to indicate when the
> > native CS0 needs inverting.
> > 
> > For the 2 platforms I'm dealing with I have a complication in the HW
> > design where the gpio is used to steer the native CS0 (as opposed to
> > replacing it) which is what my original series attempted to deal with.
> > I ended up implementing a gpio-over-gpio controller that presented 2
> > virtual gpios which reflected the high-low state of a single physical
> > gpio (basically implemented Mark's suggestion from the thread). I
> > haven't attempted to upstream the driver because I consider it a SW fix
> > for quirk of our HW designs, but if there is interest I could at least
> > send it out.
>
> Thanks for your response. The cs-gpios are not sufficient for me,
> because the cs-gpios provide N more chip selects, but we need 2^N more
> chip selects. We are using a 4:16 address decoder that is controlled
> by GPIOs to extend the number of chip selects available like this
> (requires fixed-width font to view):
> 
> +      MOSI /--------------------------------+--------+--------+--------\
> +      MISO |/------------------------------+|-------+|-------+|-------\|
> +       SCL ||/----------------------------+||------+||------+||------\||
> +           |||                            |||      |||      |||      |||
> +    +------------+                        |||      |||      |||      |||
> +    | SoC  |||   |                      +-+++-+  +-+++-+  +-+++-+  +-+++-+
> +    |      |||   |                      | dev |  | dev |  | dev |  | dev |
> +    |   +--+++-+ | CS-X  +------+\      +--+--+  +--+--+  +--+--+  +--+--+
> +    |   | SPI  +-|-------+ Mux  |\\   CS-0 |        |        |        |
> +    |   +------+ |       +--++--+\\\-------/   CS-1 |        |        |
> +    |            |          ||   \\\----------------/   CS-2 |        |
> +    |   +------+ |          ||    \\-------------------------/   CS-3 |
> +    |   | GPIO +-|----------/|     \----------------------------------/
> +    |   |      +-|-----------/
> +    |   +------+ |
> +    +------------+
> 
> This proposed patch does exactly what I need to do:
> https://patchwork.kernel.org/patch/2706151/, but I was wondering why
> nothing like this already exists or why that patch had not been
> included in the mainline kernel.

Yeah that's the kind of thing I had in mind in the thread I started.
Now that mux-controls is a thing it'd probably be even easier to do
something like this.

I don't know why Dries' patch series didn't land. The reason my one
didn't land was due to some implementation details and the ability to
do something simpler with a fake gpio.

I probably won't get to anything for the next couple of weeks but after
that I can have a try at resurrecting the code from the old thread. I
have a hardware platform suitable for testing.

> 
> > 
> > Regards,
> > Chris
> > 
> > --
> > [1] -
> > https://lwn.net/ml/devicetree/20190412050213.17698-1-chris.packham@xxxxxxxxxxxxxxxxxxx/