On středa 21. února 2018 19:58:25 CET, Trent Piepho wrote:
On Tue, 2018-02-20 at 20:02 +0100, Jan Kundrát wrote:
I just found out that this patch only takes effect *after* the SPI slaves
have been probed. That's because the HW CS signal selection takes place
after a call to spi_register_master/spi_register_controller
which adds the
SPI clients on its own. I now also understand why MSIOF
discovers the CS in
such a complicated manner. Sorry. I wrote this patch for
spidev where it is
not a problem, so I haven't seen this before.
I see three options now:
1) Add an explicit DT property to let the user select an
appropriate HW CS
signal. This has an advantage of being able to handle DT overlays in
future, as Trent pointed out.
You could also use a modulo scheme to allow specifying the hw cs to use
without adding a new property.
Ah, right, I got your idea now. You're suggesting to simply use a
logical_cs % number_of_hw_cs, and mandating the DT designer to come up with
"proper" CS assignment. So if my device has four native CSes, one of which
is unused and all others takes, and I need to add three more SPI slaves on
a GPIO CS, I could do it like this:
cs_gpios = <0>, <&gpio0 1>, <0>, <0>,
<0>, <gpio0 2>, <0>, <0>,
<0>, <gpio0 3>, <0>, <0>;
To be honest, I find this rather inconvenient for a DT writer. This
behavior would express a driver's implementation detail ("we're using
modulos for finding a fake HW CS") into the DT.
It would also need driver changes because not every driver supports this.
For example, my silicon supports four native CSes, but the spi-orion driver
doesn't know that and instead assumes a default of 8 CSes.
4) Try to determine the HW CS to use at spi_setup() time. This way
the master should know about all _probed_ spi slaves already. It does
not work if the kernel does not know about a device that is attached to
a HW CS.
I don't think that would work. The slaves are probed one-after-another,
they can issue SPI transactions during the probe, and while probing GPIO
CS#1, we have no idea whether HW CS#2 is used or not. A simple algorithm
would therefore end up using a "free HW GPIO" without knowing that it's in
fact used by a device which hasn't been probed yet. At best, we would get
bus clashes, and at worst, a dead HW due to push-pull outputs working
against each other.
Design the hardware so the GPIOs are high impedance out of reset and
put a weak pullup on each chip select line.
"I cannot do that." My platform is very limited in terms of spare GPIOs,
and the designers added a dual-use function to them. Some of the GPIOs are
sampled at power-on-reset to configure the CPU's clock frequencies,
interrupt vector instruction encoding, and boot device selection. I just
*cannot* add pull-ups I would like to add.
I could add physical inverters and use active-high CS pins, that's true.
But that only works because we're still prototyping the expansion boards.
It feels wrong to add extra silicon just because I cannot configure a
generic OS to properly initialize GPIO CS pins.
I would much prefer the Linux SPI drivers to initialize all CS pins prior
to issuing SPI transfers to any device.
With kind regards,
Jan
--
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
