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

[Geert Uytterhoeven <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>]

Hi Chris,

On Thu, Jan 25, 2018 at 10:18 PM, Chris Packham
<Chris.Packham-6g8wRflRTwXFdCa3tKVlE6U/zSkkHjvu@public.gmane.org> wrote:
> 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.

(Un)fortunately a mux driver is WIP, as Mark mentioned above.
See https://lkml.org/lkml/2018/1/22/859

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html