Re: [PATCH] Input: raspberrypi-ft5406: Add Raspberry Pi Touchscreen driver

Lubomir Rintel [off-list ref] writes:

Raspberry Pi uses a FT5406 attached to the VideoCore's I2C bus. The
firmware runs a thread that periodicaly does a register dump to a shared
memory window.  The interrupt and wake signals seem disconnected.

This driver is based on the driver by Gordon Hollingworth. Notable changes:
 - Changed to use input polldev instead of a dedicated thread
 - Streamlined the probe routing with devm_*() functions
 - Get a memory window from the device tree instead of via firmware call

Cc: Stephen Warren <redacted>
Cc: Eric Anholt <redacted>
Cc: Gordon Hollingworth <redacted>
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
---
A few notes/questions; to the bcm2835 crowd:

- Tested on RPi2 (with some changes, see below) with the touchscreen connected
  only to the DSI connector (the cables to I2C1 not in place).

- This now uses the memory window that needs to be set up by the bootloader. 

  The necessary change to u-boot (not submitted yet) is here:
  https://github.com/lkundrak/u-boot/commit/860614e8.patch

  Is this okay? It makes the driver simpler as if we called firmware directly.

- It would probably be best if we could access the I2C directly.

  According to Gordon Hollingworth it's not possible, since the VideoCore
  uses the bus for its business too (power control).

  Could we perhaps convince Raspberry Pi to include a more generic I2C
  interface via firmware?

- The driver doesn't work now, since when the gpio driver sets the gpios 0 and 1 
  to alt0 the firmware stops updating the buffer.

  This might be a firmware bug? The firmware not being able to access I2C
  might not be a good thing in any case?

  No idea why this doesn't happen with the downstream kernel; their gpio driver
  is mostly the same and they set the 0 and 1 gpios to alt0 too.

Overally, this whole "just have the firmware run all of our device
drivers" is something I'm not a fan of.  I understand that we need to
compromise on a few things (thermal appears to be one), but a generic
i2c driver for a touchscreen doesn't seem like such a case.

My plan had been to write a native driver once I got DSI going.  We
should be able to use pinctrl to steal the pins to an i2c adapter that
we own.  Hopefully someone from the Foundation could clarify which i2c
bus we can definitely own -- I think i've been seeing issues with the
firmware talking to the busses behind my back.