[PATCH 0/3] spi: spi-imx: fix use of more than four chip selects

[Mark Brown]

On Wed, Apr 26, 2023 at 02:47:44PM +0200, Rasmus Villemoes wrote:
> On 26/04/2023 14.25, Mark Brown wrote:

> > I'm not sure this is sensible, it'll be a fairly rare situation and we
> > don't want to preclude using the built in chip select functionality for
> > some of the chip selects.  In a situation like this we only need to have
> > a single chip select to be managed as a GPIO rather than all of them,
> > which I'd expect to end up handled in the DT by not allocating that chip
> > select number.

> Sorry, I don't understand what you're saying. What exactly is not
> sensible? And what is "a situation like this"?

Building hardware which uses all the native chip selects and also GPIO
ones and then describing it in DT as using native chip selects.

> I described a problem with what is now 87c614175bbf in linux-next: If
> one has five spi devices, the first four of which use the four native
> chip selects, there is no way to use a gpio for the fifth, because
> whichever "channel" you choose in the CHANNEL_SELECT field will cause
> the ecspi IP block to drive some SSx pin low, while the spi core is also
> driving the gpio low, so two different devices would be selected.

Sure, and therefore I'd not expect anyone to actually describe the
hardware like that but to instead describe the hardware as using three
or fewer of the native chip selects with the remaining chip selects
described as GPIOs.  If the device requires that a native chip select be
controlled the hardware simply won't work without at least one native
chip select being unallocated.

> It's not exactly a regression, because any chip_select >= 4 never
> actually worked, but what I'm saying is that 87c614175bbf also isn't a
> complete fix if one wants to support mixing native and gpio chip
> selects. For that, one really needs the unused_native_cs to be used for
> all gpio chip selects; in particular, one needs some unused native cs to
> exist. IOW, what my series tries to do.

No, we only need one unused chip select to be available.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20230426/9c8fba99/attachment.sig>