")
Fcc: +sent-mail
On Thu, Jan 25, 2018 at 09:51:06AM +0100, Geert Uytterhoeven wrote:
> On Wed, Jan 24, 2018 at 10:29 PM, Chris Packham
> However, Jan wrote:
> > semi-public datahseet, it seems that the SPI hardware really insists on
> > driving *some* HW CS signal whenever a SPI transaction is in progress.
> If that is correct, it behaves like MSIOF, so you must leave one native chip
> select unused. If all native chip selects are in use, one of them must be
> replaced by a GPIO chip select (which could be the same physical pin,
> depending on pinmux capabilities).
Using the same pin is the ideal thing obviously, or if not then
something that we know isn't routed out of the SoC (which may or may not
be possible with a given chip design).
> > spi-flash@0 {
> > /* This is on CS0 when GPIO 17 is high */
> > };
> >
> > spi-sram@1 {
> > /* This is on CS0 when GPIO 17 is low */
> > };
> > };
> > I'm not sure what else I could do. I can't claim the GPIO twice. If I
> > could I could probably use spi-cs-high to handle the high/low toggle.
> So this uses GPIO17 to drive a mux to connect CS0 to either the first or
> second device?
Interesting, coincidentally there was someone else sending a patch for
muxing the other day which looked like having some support for chip
select muxing would be the most sensible implementation. I've copied in
Ben who had initially approached this with a mux for the full bus which
I'm not so convincd about.
> But you describe this as @0 being driven by CS0, and @1 by GPIO17, and you
> rely on CS0 still being driven when @1 is selected, right?
> That indeed won't work when an unused native chip select is driven when
> using cs-gpio.
> IMHO, this needs the mux to be described properly in DT.
Yes.
Attachment:
signature.asc
Description: PGP signature
