On Thu, Nov 18, 2021 at 10:30 AM Dave Stevenson <dave.stevenson@xxxxxxxxxxxxxxx> wrote: > > On Thu, 18 Nov 2021 at 17:36, Tim Harvey <tharvey@xxxxxxxxxxxxx> wrote: > > > > 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. > > No, we've reverted away from that driver as it exposes no regulator > framework either, so again the touch element loses power. > > > > 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). > > No I haven't as it's been crazy trying to get this lot to work under > KMS at all over the last couple of months. > > > 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. > > I hadn't seen Nicolas' patches, hence implementing it myself. > > If you've implemented the requested changes, could you check that the > polling rate is as expected? We were seeing that the input framework > wasn't delivering the requested poll rate when CONFIG_HZ=100 is > defined in the config. I must confess that I haven't checked it on my > current patch, but it was on my list of things to do. > There was a report that "bd88ce25335d Input: raspberrypi-ts - switch > to using polled mode of input devices" dropped the polling rate from > the desired 60Hz in switching to that framework. Ok, I'll make a note to test that and submit it. > > > > > > > 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?). > > The touchscreen I2C does NOT go through the STM. > The TS interrupt line does feed into the STM, but it's not actually used. > The TC358762 I2C does go through the STM, but it isn't used other than > a kick to bring the bridge out of reset. Ok, I've determined the DFROBOT Rpi displays do differ from the official Rpi 7in display. Official 7in RPI display: - I can't find a schematic anywhere for the official display but I an ohmmeter confirms your claim that the touch controller I2C is connected to the 15pin display I2C. - I do not see the ft5406@0x38 on the i2c bus until I send a command a REG_POWERON cmdto the ATTINY@0x45 'i2c dev 2 && i2c mw 0x45 0x85 1 1' in u-boot - I must disable the rpi-panel-attiny-regulator.c driver as its probe disables REG_POWERON and the linux driver won't see the FT5406 - The linux edt-ft5x06.c driver with polling added works fine and gives me expected touch events With the DFROBOT 5in and 7in displays: - the touch interface I2C does not connect directly to the 15pin connector's I2C (shown in the schematic at schematic: https://github.com/DFRobot/Wiki/raw/master/DFR0550_Schematics.pdf and also verified with an ohmeter) - I see the ft5406@0x38 on the i2c bus regardless of setting or clearing REG_POWERON on the ATTINY@0x45 - The linux edt-ft5x06.c driver with polling added gives me data that does not make sense for touch events So I can only assume the DFROBOT displays are doing something strange but I'm not clear how what they are doing is compatible with the RPI. I guess I have to get an RPI, hook it up and see if the touch screen works with the rpi 5.10.y kernel. > > > 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? > > If the power goes down then all the registers written during probe [1] > are reset. I don't recall exactly what the data then contained, but I > did get a load of I2C transactions fail with -EREMOTEIO as the > messages weren't ACKed. > > [1] https://elixir.bootlin.com/linux/latest/source/drivers/input/touchscreen/edt-ft5x06.c#L1207 > > > Silly question likely but how do I power down the DRM portion to test > > to see if it affects the touch controller? > > xrandr --output DSI-1 --off > There must be a libdrm call to do the equivalent, but I'll admit that > I can't think of an existing tool that implements it. do you know of a sysfs way to do this or something that doesn't require xrandr? > > > > 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. > > I'm not that familiar with the DFRobot displays. > I have tried an Osoyoo 3.5" panel [2] that pretends to be the Pi > panel, and it looks similar. Reality is that it uses a Lattice FPGA to > convert from DSI to DPI. All the LP configuration commands sent to it > are ignored. Startup requirements of that compared to the Toshiba are > unknown. > > [2] https://www.amazon.co.uk/OSOYOO-Capacitive-Connector-Resolution-Raspberry/dp/B087WVC1J2 > > > > 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. > > I have one of our panels working in front of me using my patched > version of edt-ft5x06 as the driver for the touch element. > > > 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? > > As above, I'm not aware of DFRobot. > With the Osoyoo I can't recall exactly what it was doing with I2C. I > think it only really responded to the ID command and PWM for the > backlight. The reset and power control that is required on our boards > isn't really relevant to them. > I was doing i2cset -y -f <bus> 0x45 0x85 [1|0] to turn power on/off, > and I seem to recall it did nothing. Right... this is also the same with the DFROBOT touchscreen displays. I do really like the build quality, availability, and pricing of the DFROBOT displays but also a huge advantage is that they derive power from the 15pin connector 3.3V pins so there are no other connections. Their backlight doesn't appear to be controllable via PWM however and instead they have a manual brightness thumbwheel on them. The other advantage for me at the moment is that I still haven't gotten the official RPI 7in display to work with the IMX8MM (no pixels displayed) where as the DFROBOT one is working for me. > ... > Just for you I fired it up. It ACKs all I2C addresses just for a > laugh, and indeed it takes no action on 0x85, only 0x86 (for PWM), and > reading 0x80 (ID). > Thanks, Tim
