Re: SPI driver probe problem during boot

[Martin Townsend <mtownsend1973@xxxxxxxxx>]

On Tue, May 5, 2020 at 9:43 AM Andy Shevchenko
<andy.shevchenko@xxxxxxxxx> wrote:
>
> On Tue, May 5, 2020 at 11:04 AM Martin Townsend <mtownsend1973@xxxxxxxxx> wrote:
>
> > I've just finished debugging a SPI comms problem for a TPM device on a
> > TI Sitara AM4372 SoC.  The SPI bus has 3 devices
> >
> > 1) CAN FD Controller 0 (Using native CS)
> > 2) CAN FD Controller 1 (Using GPIO for CS)
> > 3) TPM Device (Using GPIO for CS)
> >
> > All CS are active low.
> >
> > During boot the TPM would fail it's probe but if I unbind and then
> > rebind the driver after boot the TPM would work fine so I got the
> > logic analyser out to probe the SPI bus and could see that the voltage
> > on the MISO line was half the expected voltage whilst the TPM was
> > being probed and this was due to CS0 being driven low for this period
> > of time.  After the TPM was probed the CS0 went high.  After debugging
> > this I found that the OMAP SPI controller defaults internal CS lines
> > to active high so when the SPI master controller is initialised this
> > is the state of CS0 so it's driven low for inactive.  During the probe
> > of the SPI master controller it calls devm_spi_register_master ->
> > spi_register_master which calls of_register_spi_devices which will add
> > the devices to the SPI master controller via spi_add_device.  This
> > function would call device_add. Due to the way the device tree is
> > parsed the SPI devices above are enumerated from the highest CS to the
> > lowest so the TPM device is setup first.  When device_add is called it
> > triggers it's probe function but the SPI bus hasn't been setup yet and
> > hence the TPM driver tries to communicate with the TPM device whilst
> > CS0 is being driven low causing the CAN FD controller to also respond
> > reducing the voltage on the MISO line.  In spi_device_add it calls
> >
> > status = spi_setup(spi);
> >
> > which would setup the CS lines so I modified the
> > of_register_spi_devices function to make it a 2 phase operation so the
> > CS lines are all setup and then it iterates of the SPI devices a
> > second time to add them to the driver model via device_add and the TPM
> > now probes fine.
>
> ...
>
> > Now this is on a oldish kernel (4.12) and moving the kernel forward
> > isn't trivial.  I was just wondering if this has been fixed already so
> > I could backport it, I couldn't see anything in the latest kernel but
> > maybe it has been solved a different way.  If not is there a better
> > way of fixing this? Or is the OMAP SPI controller driver the problem,
> > should it parse the child nodes first and set itself up accordingly?
>
> Can you confirm the issue on v5.7-rc4?
>

I will try but it's not always possible with these embedded SoC's
without a lot of work.

> --
> With Best Regards,
> Andy Shevchenko