Re: Multiplex SPI Chip Selects

[Anthony DeRosa <anthony.derosa@xxxxxxxxxxxx>]

Hi Chris,

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.

Best,

Anthony

Anthony V. DeRosa
Principal
Ph. 410-671-5389
anthony.derosa@xxxxxxxxxxxx


10015 Old Columbia Rd. Suite B215
Columbia, MD 21046


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.
>
> Regards,
> Chris
>
> --
> [1] -
> https://lwn.net/ml/devicetree/20190412050213.17698-1-chris.packham@xxxxxxxxxxxxxxxxxxx/