Lubomir Rintel <lkundrak@xxxxx> 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@xxxxxxxxxxxxx> > Cc: Eric Anholt <eric@xxxxxxxxxx> > Cc: Gordon Hollingworth <gordon@xxxxxxxxxxxxxxx> > Signed-off-by: Lubomir Rintel <lkundrak@xxxxx> > --- > 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.
Attachment:
signature.asc
Description: PGP signature
