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

[Trent Piepho <tpiepho@xxxxxxxxxx>]

On Tue, 2018-01-23 at 20:56 +0100, Jan Kundrát wrote:
> Commit b28b9149b37f added support for using an additional GPIO pin for
> Chip Select. According to that commit and to my understanding of a
> semi-public datahseet, it seems that the SPI hardware really insists on
> driving *some* HW CS signal whenever a SPI transaction is in progress.

It's pretty common for SPI hardware to have this limitation.

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

So say you want two GPIO CS devices and they should make use of native
CS 1, because that pin has no conflicts for this usage, and you also
want a device on native chip select 0 that's not using a GPIO CS.  The
spi master has four native chip selects.  Set up the DT like this:

cs-gpios = <0>, <&gpio 42>, <0>, <0>, <0>, <&gpio 43>;
flash@0 { reg = <0>; } /* on native CS 0 */
slave@1 { reg = <1>; } /* on GPIO 42, also native CS 1 */
slave@5 { reg = <5>; } /* on GPIO 43, also native CS 1 */

This allows assigning which native CS to use.  It could pix muxing
limitations don't allow just any CS to be chosen.  If there's no reason
to care, then selecting automatically is easier to use.
��.n��������+%������w��{.n�����{����)��jg��������ݢj����G�������j:+v���w�m������w�������h�����٥