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

[Trent Piepho <tpiepho@xxxxxxxxxx>]

On Tue, 2018-01-30 at 09:03 +0100, Jan Kundrát wrote:
> On úterý 30. ledna 2018 2:13:37 CET, Trent Piepho wrote:
> > Another way to fix it, besides default to 0 or to select an unused
> > chipselect, is to use the cs number of the slave modulus the number of
> > native chip selects.  They are or were some other drivers that do this.
> > The idea is that CS numbers don't need to be sequential and there isn't
> > much of a cost of an unused chip select (one word in device tree
> > property).
> 
> Hi Trent, are you talking about an integer modulo here? I don't think that 
> modulo is a correct approach. If my HW has two CS and I use the following 
> DT:
> 
> 	cs-gpios = <0>, <&gpio0 1>, <&gpio0 2>, <0>;
> 
> ...then the logical CS2 (at gpio0 pin 2) conflicts with the native CS0.

What you'd do is use this:

    cs-gpios = <0>, <&gpio0 1>, <0>, <&gpio0 2>;
Put the slaves on cs 0, 1, and 3.  The slaves on 1 and 3 use native CS1
with their gpios.

> Also, the spi-orion driver currently hard-codes that each and every model 
> is supposed to have exactly eight HW CS pins. That's not true for my SoC 
> (Marvell Armada 388, the Solidrun Clearfog Base board); the 88F6828 CPU 
> only has four SPI CS signals.

Yes, you need to know how many CS the driver will consider the device
to have.  That is an additional difficulty.

> 
> What my patch does is simply picking the *first* unused CS and going with 
> that one because that looks like the easiest and also safest option.

Yes, I agree the easiest to use.  Don't need to know how many HW CS the
driver will think there are.  Don't need to manually place your gpios
cs in the list to avoid native cs conflicts.

But you do lose some flexibility.  What if you don't want the first
unused CS?  Probably rather obscure to have that issue.��.n��������+%������w��{.n�����{����)��jg��������ݢj����G�������j:+v���w�m������w�������h�����٥