On Thu, Nov 18, 2021 at 6:28 AM Dave Stevenson <dave.stevenson@xxxxxxxxxxxxxxx> wrote: > > Hi Tim > > On Thu, 18 Nov 2021 at 01:26, Tim Harvey <tharvey@xxxxxxxxxxxxx> wrote: > > > > Greetings, > > > > I'm trying to get a RPI 7" touchscreen display working on an IMX8MM > > board and while I've been able to get the MIPI DSI display and > > backlight working I still can't seem to figure out the touch > > controller. > > > > It's supposed to have an FT5406 controller on it without an interrupt > > so I added polling support drivers/input/touchscreen/edt-ft5x06.c > > which I was able to verify using another touchscreen with that > > controller but when reading data from the FT5406 on the RPI controller > > the data does not make sense. > > > > These panels appear to route the I2C from the FT5406 to a STM32F103 > > MPU that then provides a different I2C slave interface to the 15pin > > connector that I'm connected to. On that I2C interface I see an i2c > > slave at 0x45 which is managed by the regulator driver Marek wrote > > (drivers/regulator/rpi-panel-attiny-regulator.c) and there is also an > > i2c slave at 0x38 which I assumed was the FT5406 but I believe the MPU > > is perhaps obfuscating that touch data. > > > > Anyone have any ideas on how to make that touch controller useful? > > There should be nothing unusual. 0x38 is the EDT touch controller. > Starting with the Raspberry Pi OS Bullseye release, we're now using > the panel directly from DRM rather than through the firmware. That's > based on the branch at > https://github.com/raspberrypi/linux/tree/rpi-5.10.y/ > Dave, That sounds like the driver that made it into mainline with Eric's commit 2f733d6194bd ("drm/panel: Add support for the Raspberry Pi 7" Touchscreen."). I looked there but that driver just deals with the DSI and not with touch. > I also added polling support to edt-ft5x04.c. > For DT, it uses a combination of the overlays vc4-kms-v3d, > vc4-kms-dsi-7inch, and that includes edt-ft5406.dtsi, all of which are > in /arch/arm/boot/dts/overlays It doesn't look like you ever submitted your edt-ft5x04 polling mode support upstream. I saw another series to add polling support submitted by Nicolas back in 2019 but was never followed up on (https://patchwork.kernel.org/project/linux-input/list/?series=112187&archive=both). I have updated Nicolas' patch with the changes requested and am happy to submit it upstream. The benefit of his patch is that it uses a dt binding for the polling interval. I'm happy to submit this upstream. > > The main issue I had was configuring the regulator framework > appropriately to allow the touch controller power to be separate from > the bridge power. Without that if DRM powered down the panel it killed > the touch controller too, and the touch driver never reinitialised > itself. I'm using the same drivers/regulator/rpi-panel-attiny-regulator.c regulator driver from mainline that Marek added as the power-supply for the panel as well as the backlight controller. It looks like the version in the rpi-5.10.y has several patches on top of it so I'll take a look at those differences to see if it may be affecting the touchscreen controller. It's really strange to me that the touch controller's I2C goes through the STM32F103 MPU (as in the MPU's I2C master connects to the touchscreen controller and a different MPU I2C bus presents the touch controller like they are translating something?). I wonder if I'm hitting that reinitialization issue. Do you recall any details about that? Was it that the driver returned seemingly invalid touch data like I'm getting or did it just not respond? Silly question likely but how do I power down the DRM portion to test to see if it affects the touch controller? > On our branch rpi-panel-attiny-regulator.c has been updated to control > those functions independently as GPIOs, which then get used via > regulator-fixed, or as reset-gpios. > Telling both bridge and touch that they shared a regulator didn't work > as the DSI bridge seems mildly fussy about the DSI state when it is > powered up. Hmm... I wonder if this is the problem I had with the 'official' rpi 7in display that I never got working. I did get the DFROBOT rpi 5in and 7in displays working. > > Hope that helps. > The fact you tell me that the rpi-5.10.y branch goes away from the strange 'firmware' driver I found at https://github.com/raspberrypi/linux/blob/rpi-4.2.y/drivers/input/touchscreen/rpi-ft5406.c and uses the standard ft5406.c driver (with polling mode added) is very helpful in that I feel I have a hope of getting this working. Does the rpi-5.10.y kernel work for the official rpi 7in display as well as the DFROBOT displays as far as you know? Best regards, Tim
