On Wed, Dec 08, 2021 at 07:59:00AM +0100, Alexander Stein wrote: > Am Dienstag, dem 07.12.2021 um 12:57 +0000 schrieb Mark Brown: > > Do we need to use the num_cs property or can we just set num_chipselect > > to whatever the maximum value that can be set is? I've never been 100% > > clear on why num-cs is in the binding. > I see two things which needs to be considered when setting > num_chipselect: > 1. > The hardware limitation in the uC. The i.MX8XQP RM says: > > The entire CS field is not fully supported in every LPSPI module > > instance. Refer to the chip-specific information for LPSPI. > This indicates there are some i.MX, not necessarily i.MX8 only, which > have more than 2 hardware chip selects. This might be set depending on > the compatible. Yes, this sounds like it should be figured out from the compatible and not need a separate property - that's usually better in general if there's quirks in the IP configuration in different SoCs. > 2. > The hardware limitation on the SOM and/or mainboard. E.g. even if the > uC supports 2 chip selects, only one may be available on the board > connector. This is something which can only be set in the DT. > This case is what this patch is about: Providing 2 hardware chip > selects, as the default (if unset) is just one. Given that we won't try to enable a chip select unless there's something connected to it this shouldn't be an issue - with a lot of designs you can't avoid doing that anyway since the chip selects are all in a single register. If the pin isn't connected (or the signal not pinmuxed out) that doesn't seem like a problem?
Attachment:
signature.asc
Description: PGP signature
