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

[Chris Packham <Chris.Packham@xxxxxxxxxxxxxxxxxxx>]

Hi Jan, Geert,

On 25/01/18 04:03, Jan Kundrát wrote:
> On středa 24. ledna 2018 14:41:27 CET, Geert Uytterhoeven wrote:
>> Can't you just deduce an unused HW CS from the cs-gpios property?
> 
> Thanks for a review. Yes, I probably can. I just noticed that my local use
> of spi-orion's "direct mode" is probably the root cause of some weirdness
> that I'm seeing (such as the CS GPIO pin going up in the middle of a
> two-byte transaction, and other nasty issues that just go away once one
> adds a dev_info call...).
> 
>> Renesas MSIOF also requires driving a native chip select, cfr. commit
>> b8761434bdec32fa ("spi: sh-msiof: Implement cs-gpios configuration").
> 
> I'll take a look. It could be a candidate for some shared code, I suppose.

How would this work? If I understand the sh-msiof driver it picks an 
unused native CS. In the case of b28b9149b37f the gpios supplement the 
native CS they do not replace it (the hardware I was using has a GPIO 
which controls a gate attached to CS0).

My specific board isn't upstream but here's the snippet from its dts

&spi0 {
         status = "okay";
         cs-gpios = <0
                     &gpio0 17 GPIO_ACTIVE_LOW>;

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