Re: [PATCH] spi: orion: Allow specifying which HW CS to use with a GPIO CS

[Chris Packham <Chris.Packham@xxxxxxxxxxxxxxxxxxx>]

Hi Mark, Geert,

On 26/01/18 00:57, Mark Brown wrote:
> ")
> 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?

Correct. GPIO17 directs CS0 with the addition of a logic gate.

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

Yes that's my problem.

> 
>> IMHO, this needs the mux to be described properly in DT.
> 
> Yes.

I'm more than happy to update the DT on this product. But I've no idea 
what that update would look like.

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html