Hi Dmitry,
On 08/13/2015 09:38 AM, Dmitry Torokhov wrote:
Hi Andrew,
On Fri, Aug 07, 2015 at 05:36:51PM -0700, Andrew Duggan wrote:
Hi Dmitry,
With the renewed interest in supporting SMBus with the Synaptics
RMI4 driver I thought I would look into this again. I'm sorry for
not responding to your comments sooner, especially since you took
the time to read the F30 spec. Now that it has been over a year
later we may need to essentially start over. But, this time I will
make sure to follow up and hopefully not waste your time in the
future.
This is great and I agree that we need to get RMI4 into kernel proper.
Unfortunately it is quite large body of code and I am afraid that I wont
be able to give it enough attention until mid-September.
In the meantime, Benjamin, maybe you could work with Andrew? You have
done a lot of work on input side.
I understand, it is a lot of code. If you have time later this year to
work on it then that would be great! In the meantime, I'll post the
device tree related patches I've been working on the last couple of days
and then we can go from there when you have time.
Thanks,
Andrew
Thanks.
On 07/27/2014 12:26 AM, Dmitry Torokhov wrote:
Hi Andrew,
On Thu, Jul 24, 2014 at 04:47:21PM -0700, Andrew Duggan wrote:
RMI4 Function 0x30 provides support for GPIOs, LEDs and mechanical
buttons. In particular, the mechanical button support is used in
an increasing number of touchpads.
I was reading the spec for F30 and it looks to me that instead instead of basic
keymap it should actually implement a gpio chip plus LED devices (probably
later). Then, if GPIOs are indeed attached to buttons one can use standard
gpio_keys driver to create input device.
The most common use of F30 is handling input from the tact switch on
clickpads. Since the tact switch is wired up to the touch
controller, it's the touch controller that handles the GPIO. The
touch controller then asserts attention to the host, which then
issues reads to see what interrupted, and then reads the F30 data
register to get the state of the GPIO. Would gpio chip work with
this setup? After looking at gpio chip a little bit I'm not really
seeing how that would work. It looks like to work with gpio_keys
each button would need it's own irq? I couldn't find an example of a
driver doing something similar, but if there is one could you point
me to it?
For touchpad buttons we know based on convention which GPIOs
represent which buttons. In the case of touchpads we can avoid
creating a button map in the platform data. For touchpads we also
want to report the input events for F30 from the same input device
which is reporting finger data. Benjamin's patchset contains a patch
which allows for a unified input device which will allow more then
one function to use the same input device.
The F30 spec is fairly generic so it could be used for things
besides the touchpad buttons and we might want to report events
independently of finger position. However, besides touchpad LEDs I'm
not sure F30 has ever been used for other applications in production
so I'm not sure its worth implementing something more generic at
this time.
OK, fair enough. I'll have to take another look then - the details are
quite hazy ;)
Thanks.
Also, the fact that it took me over a year to reply to these
comments highlights that we at Synaptics have been inconsistent in
our effort to get the synaptics-rmi4 driver upstreamed. I think it's
about time we have a single upstreamed driver which can support all
of our RMI devices so I'm willing do more on behalf of Synaptics to
help get it upstreamed.
Thanks,
Andrew
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
