On 6/25/24 10:50 PM, Dmitry Torokhov wrote:
On Sun, Jun 23, 2024 at 08:21:00PM +0200, Marek Vasut wrote:
On 3/20/24 8:23 AM, Marek Vasut wrote:
On STM32MP135F with XPT2046 touch controller attached to SPI bus, it has
been observed that the touch controller locks up after Linux kernel has
finished booting. Adding a dummy cycle on the SPI bus seems to mitigate
the lock up.
The XPTEK XPT2046 controller seems to be an identical clone of TI TSC2046,
the datasheet seems to be a clone of the TI part as well, text seem to be
word to word identical, except all the pictures have been drawn again.
This touch controller is present e.g. on WaveShare 3.2inch RPi LCD (B)
panel, the DTO provided by WaveShare uses 50 kHz SPI clock for this
touch controller, which is unusually low and possibly might have been
used as some sort of workaround for an issue. The SPI LCD on the same
bus uses 16 MHz clock.
SPI bus DT properties spi-cs-setup-delay-ns, spi-cs-hold-delay-ns,
spi-cs-inactive-delay-ns, spi-rx-delay-us, spi-tx-delay-us set to
range of 500ns..5us seem to have no impact on the behavior of the
touch controller, the lock up always occurs. The STM32MP13xx SPI
controller users GPIO control for the nCS pins.
Since the dummy cycle happens after the controller has been put into
power down mode and both ADC and REF regulators have been disabled,
the cycle should have no impact on the configuration of the controller,
i.e. it should be a NOP.
It is unclear whether this problem is specific to this cloned XPT2046
controller, or whether this is also present on TSC2046. A test on
either TSC2046 or ADS7846 would be very welcome.
Hi,
Are there still any open topics with this patch ?
I am concerned that we are putting workaroud for a single controller
into common function. Can we quirk it based on compatible?
We can, but there is a slight problem. I came across DTs which describe
this XPT2046 using TSC2046 or ADS7846 compatible string in those DTs, so
if those get used, this driver won't work correctly. On the other hand,
those are random downstream DTs, they are not upstream, so maybe those
are irrelevant.
If not then I
would like someone to run tests on other controllers. Unfortunately I do
not have such hardware.
I did dig through my pile and I don't have one such controller either.
Linus, do you have devices with ads7846 or tsc2046 by chance? Spitz?
I would much rather see this tested on at least one of the old
controllers than add a quirk via DT compatible, because I believe this
won't have adverse effects on those controllers, and it would help cover
the odd DTs which consider this to be a drop-in compatible replacement
for TSC2046 transparently (even if it really is not quite compatible).
