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

[Eric Anholt]

Lubomir Rintel <lkundrak at v3.sk> 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 <swarren at wwwdotorg.org>
> Cc: Eric Anholt <eric at anholt.net>
> Cc: Gordon Hollingworth <gordon at raspberrypi.org>
> Signed-off-by: Lubomir Rintel <lkundrak at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-rpi-kernel/attachments/20160226/8daa74cb/attachment.sig>