lkml.org 
[lkml]   [2020]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Multiplex SPI Chip Selects
Date
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/
\
 
 \ /
  Last update: 2020-01-06 23:45    [W:0.048 / U:0.212 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site