Re: Multiplex SPI Chip Selects

Re: Multiplex SPI Chip Selects

[Chris Packham]

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@alliedtelesis.co.nz> 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@alliedtelesis.co.nz/

Re: Multiplex SPI Chip Selects

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1401 bytes --]

On Mon, Jan 06, 2020 at 10:44:15PM +0000, Chris Packham wrote:
> On Mon, 2020-01-06 at 08:27 -0500, Anthony DeRosa wrote:

As documented in submitting-patches.rst please send patches to the 
maintainers for the code you would like to change.  The normal kernel
workflow is that people apply patches from their inboxes, if they aren't
copied they are likely to not see the patch at all and it is much more
difficult to apply patches.

> > 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.

> 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.

If you want me to review something you'l need to submit it; that patch
was from 2013 so predates me maintaining the subsystem so I've never
seen a copy.

My general instinct with this stuff is that it's likely to be more
sensible to describe this with GPIO chip selects, the state of
controller chip selects is such that a lot of devices use them anyway
even when the controller supports native chip selects as the controller
chip selects often suffer from unfortunate limitations that mean they're
not actually useful.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]