Re: [PATCH] Input: synaptics-rmi4: Add device tree support for RMI4 I2C devices
On Tue, Aug 11, 2015 at 12:10:26PM -0700, Andrew Duggan wrote: > Hi Dmitry, > > On 08/09/2015 12:40 AM, Dmitry Torokhov wrote: > >Hi Andrew, > > > >On Fri, Aug 07, 2015 at 05:37:49PM -0700, Andrew Duggan wrote: > >>+Optional Properties: > >>+- syna,sensor-name: The string containing the name of the sensor. > >>+- syna,attn-gpio: The GPIO number used to assert attention. > >>+- syna,attn-polarity: The polarity of the attention GPIO. > >>+- syna,level-triggered: Set to 1 if attention GPIO is level triggered, 0 if > >>+ edge triggered. > >We already have generic bindings for i2c devices interrupt line, along > >with trigger type. We also have standard bindings for gpios, with the > >polarity. Interrupts are also parsed by the I2C core. There is no need > >to invent your own bindings. > > In the current implementation rmi_driver expects an attention GPIO > from the platform data and manages it internally. I just added those > parameters to device tree. But, that essentially duplicates the > generic I2C and device tree interrupt handling. I agree that > rmi_driver should just use the irq provided in the I2C client and > then we don't have to duplicate the GPIO handling and we can use the > generic bindings. > > One option is to check to see if there is an irq in the I2C client > and skip the GPIO initialization if there is. I can provide a patch > which does that and a v2 of this patch to use the generic bindings. > But, this also brings up the question on whether or not we should > still have the code for handling the GPIO in rmi_driver at all. The > last time the GPIO code was discussed, Chris said it allowed for > releasing the irq for certain diagnostic modes. But, there are cases > when rmi_driver won't have access to the GPIO or when the device is > directly connected to the IO_APIC (ie HID or SMBus devices) so the > diagnostic mode won't be available for those devices. Also, I'm also > not convinced that the diagnostic capabilities justify duplicating > the GPIO handling. If most platforms are using device tree at this > point I think it might be time to remove the GPIO code from > rmi_driver and let the lower levels handle interrupts. Or, if there > are major objections I can work around it and leave it as an option > in the platform data for devices which still use board files. > > http://marc.info/?l=linux-input=139155532321252=2 I am always happy with making things simpler so you would not hear me objecting to dropping gpio handling and relying on interrupts set up for I2C or SPI client. That said if you absolutely want to also support GPIO you can make it optional and alter the behavior depending whether the platform presents you with GPIO or not. In any case we also have standard GPIO bindings that allow setting the polarity, etc. Just use gpiod API and it should work for devicetree, acpi and can be even plugged into static board code. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Input: synaptics-rmi4: Add device tree support for RMI4 I2C devices
Hi Dmitry, On 08/09/2015 12:40 AM, Dmitry Torokhov wrote: Hi Andrew, On Fri, Aug 07, 2015 at 05:37:49PM -0700, Andrew Duggan wrote: +Optional Properties: +- syna,sensor-name: The string containing the name of the sensor. +- syna,attn-gpio: The GPIO number used to assert attention. +- syna,attn-polarity: The polarity of the attention GPIO. +- syna,level-triggered: Set to 1 if attention GPIO is level triggered, 0 if + edge triggered. We already have generic bindings for i2c devices interrupt line, along with trigger type. We also have standard bindings for gpios, with the polarity. Interrupts are also parsed by the I2C core. There is no need to invent your own bindings. In the current implementation rmi_driver expects an attention GPIO from the platform data and manages it internally. I just added those parameters to device tree. But, that essentially duplicates the generic I2C and device tree interrupt handling. I agree that rmi_driver should just use the irq provided in the I2C client and then we don't have to duplicate the GPIO handling and we can use the generic bindings. One option is to check to see if there is an irq in the I2C client and skip the GPIO initialization if there is. I can provide a patch which does that and a v2 of this patch to use the generic bindings. But, this also brings up the question on whether or not we should still have the code for handling the GPIO in rmi_driver at all. The last time the GPIO code was discussed, Chris said it allowed for releasing the irq for certain diagnostic modes. But, there are cases when rmi_driver won't have access to the GPIO or when the device is directly connected to the IO_APIC (ie HID or SMBus devices) so the diagnostic mode won't be available for those devices. Also, I'm also not convinced that the diagnostic capabilities justify duplicating the GPIO handling. If most platforms are using device tree at this point I think it might be time to remove the GPIO code from rmi_driver and let the lower levels handle interrupts. Or, if there are major objections I can work around it and leave it as an option in the platform data for devices which still use board files. http://marc.info/?l=linux-input=139155532321252=2 +- syna,poll-interval-ms: The interval in milliseconds to wait between reading + interrupts when the driver is polling. +- syna,reset-delay-ms: The number of milliseconds to wait after resetting the + device. +- syna,f01-*: Additional parameters specific to RMI4 function 1 + see Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt. +- syna,f11-*: Additional parameters specific to RMI4 function 11 + see Documentation/devicetree/bindings/input/rmi4/rmi_f11.txt. For function parameters I wonder if they should not be modelled as subnodes with "reg" representing function number. I'll look in to doing this. Putting the function parameters into subnodes makes sense to me. Thanks. Thanks, Andrew -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Input: synaptics-rmi4: Add device tree support for RMI4 I2C devices
Hi Dmitry, On 08/09/2015 12:40 AM, Dmitry Torokhov wrote: Hi Andrew, On Fri, Aug 07, 2015 at 05:37:49PM -0700, Andrew Duggan wrote: +Optional Properties: +- syna,sensor-name: The string containing the name of the sensor. +- syna,attn-gpio: The GPIO number used to assert attention. +- syna,attn-polarity: The polarity of the attention GPIO. +- syna,level-triggered: Set to 1 if attention GPIO is level triggered, 0 if + edge triggered. We already have generic bindings for i2c devices interrupt line, along with trigger type. We also have standard bindings for gpios, with the polarity. Interrupts are also parsed by the I2C core. There is no need to invent your own bindings. In the current implementation rmi_driver expects an attention GPIO from the platform data and manages it internally. I just added those parameters to device tree. But, that essentially duplicates the generic I2C and device tree interrupt handling. I agree that rmi_driver should just use the irq provided in the I2C client and then we don't have to duplicate the GPIO handling and we can use the generic bindings. One option is to check to see if there is an irq in the I2C client and skip the GPIO initialization if there is. I can provide a patch which does that and a v2 of this patch to use the generic bindings. But, this also brings up the question on whether or not we should still have the code for handling the GPIO in rmi_driver at all. The last time the GPIO code was discussed, Chris said it allowed for releasing the irq for certain diagnostic modes. But, there are cases when rmi_driver won't have access to the GPIO or when the device is directly connected to the IO_APIC (ie HID or SMBus devices) so the diagnostic mode won't be available for those devices. Also, I'm also not convinced that the diagnostic capabilities justify duplicating the GPIO handling. If most platforms are using device tree at this point I think it might be time to remove the GPIO code from rmi_driver and let the lower levels handle interrupts. Or, if there are major objections I can work around it and leave it as an option in the platform data for devices which still use board files. http://marc.info/?l=linux-inputm=139155532321252w=2 +- syna,poll-interval-ms: The interval in milliseconds to wait between reading + interrupts when the driver is polling. +- syna,reset-delay-ms: The number of milliseconds to wait after resetting the + device. +- syna,f01-*: Additional parameters specific to RMI4 function 1 + see Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt. +- syna,f11-*: Additional parameters specific to RMI4 function 11 + see Documentation/devicetree/bindings/input/rmi4/rmi_f11.txt. For function parameters I wonder if they should not be modelled as subnodes with reg representing function number. I'll look in to doing this. Putting the function parameters into subnodes makes sense to me. Thanks. Thanks, Andrew -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Input: synaptics-rmi4: Add device tree support for RMI4 I2C devices
On Tue, Aug 11, 2015 at 12:10:26PM -0700, Andrew Duggan wrote: Hi Dmitry, On 08/09/2015 12:40 AM, Dmitry Torokhov wrote: Hi Andrew, On Fri, Aug 07, 2015 at 05:37:49PM -0700, Andrew Duggan wrote: +Optional Properties: +- syna,sensor-name: The string containing the name of the sensor. +- syna,attn-gpio: The GPIO number used to assert attention. +- syna,attn-polarity: The polarity of the attention GPIO. +- syna,level-triggered: Set to 1 if attention GPIO is level triggered, 0 if + edge triggered. We already have generic bindings for i2c devices interrupt line, along with trigger type. We also have standard bindings for gpios, with the polarity. Interrupts are also parsed by the I2C core. There is no need to invent your own bindings. In the current implementation rmi_driver expects an attention GPIO from the platform data and manages it internally. I just added those parameters to device tree. But, that essentially duplicates the generic I2C and device tree interrupt handling. I agree that rmi_driver should just use the irq provided in the I2C client and then we don't have to duplicate the GPIO handling and we can use the generic bindings. One option is to check to see if there is an irq in the I2C client and skip the GPIO initialization if there is. I can provide a patch which does that and a v2 of this patch to use the generic bindings. But, this also brings up the question on whether or not we should still have the code for handling the GPIO in rmi_driver at all. The last time the GPIO code was discussed, Chris said it allowed for releasing the irq for certain diagnostic modes. But, there are cases when rmi_driver won't have access to the GPIO or when the device is directly connected to the IO_APIC (ie HID or SMBus devices) so the diagnostic mode won't be available for those devices. Also, I'm also not convinced that the diagnostic capabilities justify duplicating the GPIO handling. If most platforms are using device tree at this point I think it might be time to remove the GPIO code from rmi_driver and let the lower levels handle interrupts. Or, if there are major objections I can work around it and leave it as an option in the platform data for devices which still use board files. http://marc.info/?l=linux-inputm=139155532321252w=2 I am always happy with making things simpler so you would not hear me objecting to dropping gpio handling and relying on interrupts set up for I2C or SPI client. That said if you absolutely want to also support GPIO you can make it optional and alter the behavior depending whether the platform presents you with GPIO or not. In any case we also have standard GPIO bindings that allow setting the polarity, etc. Just use gpiod API and it should work for devicetree, acpi and can be even plugged into static board code. Thanks. -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Input: synaptics-rmi4: Add device tree support for RMI4 I2C devices
Hi Andrew, On Fri, Aug 07, 2015 at 05:37:49PM -0700, Andrew Duggan wrote: > +Optional Properties: > +- syna,sensor-name: The string containing the name of the sensor. > +- syna,attn-gpio: The GPIO number used to assert attention. > +- syna,attn-polarity: The polarity of the attention GPIO. > +- syna,level-triggered: Set to 1 if attention GPIO is level triggered, 0 if > + edge triggered. We already have generic bindings for i2c devices interrupt line, along with trigger type. We also have standard bindings for gpios, with the polarity. Interrupts are also parsed by the I2C core. There is no need to invent your own bindings. > +- syna,poll-interval-ms: The interval in milliseconds to wait between reading > + interrupts when the driver is polling. > +- syna,reset-delay-ms: The number of milliseconds to wait after resetting the > + device. > +- syna,f01-*: Additional parameters specific to RMI4 function 1 > + see Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt. > +- syna,f11-*: Additional parameters specific to RMI4 function 11 > + see Documentation/devicetree/bindings/input/rmi4/rmi_f11.txt. For function parameters I wonder if they should not be modelled as subnodes with "reg" representing function number. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Input: synaptics-rmi4: Add device tree support for RMI4 I2C devices
Hi Andrew, On Fri, Aug 07, 2015 at 05:37:49PM -0700, Andrew Duggan wrote: +Optional Properties: +- syna,sensor-name: The string containing the name of the sensor. +- syna,attn-gpio: The GPIO number used to assert attention. +- syna,attn-polarity: The polarity of the attention GPIO. +- syna,level-triggered: Set to 1 if attention GPIO is level triggered, 0 if + edge triggered. We already have generic bindings for i2c devices interrupt line, along with trigger type. We also have standard bindings for gpios, with the polarity. Interrupts are also parsed by the I2C core. There is no need to invent your own bindings. +- syna,poll-interval-ms: The interval in milliseconds to wait between reading + interrupts when the driver is polling. +- syna,reset-delay-ms: The number of milliseconds to wait after resetting the + device. +- syna,f01-*: Additional parameters specific to RMI4 function 1 + see Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt. +- syna,f11-*: Additional parameters specific to RMI4 function 11 + see Documentation/devicetree/bindings/input/rmi4/rmi_f11.txt. For function parameters I wonder if they should not be modelled as subnodes with reg representing function number. Thanks. -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Input: synaptics-rmi4: Add device tree support for RMI4 I2C devices
Add devicetree binding for I2C devices and add bindings for optional
parameters in the function drivers.
Signed-off-by: Andrew Duggan
---
I saw Benjamin Tissoires's email about the lack of a devicetree implementation
for rmi_i2c.c. I decided to clean up and add documentation to the implementaion
which I have been using and submit it for review.
This patch applies to the current implementation of Dmitry's synaptics-rmi4
branch in the input repository. If Benjamin's patchset gets applied before
this I can rebase this patch.
Thanks,
Andrew
.../devicetree/bindings/input/rmi4/rmi_f01.txt | 34 ++
.../devicetree/bindings/input/rmi4/rmi_f11.txt | 51
.../devicetree/bindings/input/rmi4/rmi_i2c.txt | 40 +++
.../devicetree/bindings/vendor-prefixes.txt| 1 +
drivers/input/rmi4/rmi_bus.c | 49
drivers/input/rmi4/rmi_bus.h | 8 +-
drivers/input/rmi4/rmi_driver.c| 46 ++-
drivers/input/rmi4/rmi_f01.c | 50 +++-
drivers/input/rmi4/rmi_f11.c | 133 -
drivers/input/rmi4/rmi_i2c.c | 60 +-
include/linux/rmi.h| 2 +-
11 files changed, 465 insertions(+), 9 deletions(-)
create mode 100644 Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt
create mode 100644 Documentation/devicetree/bindings/input/rmi4/rmi_f11.txt
create mode 100644 Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt
diff --git a/Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt
b/Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt
new file mode 100644
index 000..53846e2
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt
@@ -0,0 +1,34 @@
+Synaptics RMI4 F01 Device Binding
+
+The Synaptics RMI4 core is able to support RMI4 devices using differnet
+transports and differnet functions. This file describes the device tree
+bindings for devices which contain Function 1. Complete documentation
+for transports and other functions can be found in:
+Documentation/devicetree/bindings/input/rmi4.
+
+Additional documentation for F01 can be found at:
+http://www.synaptics.com/sites/default/files/511-000136-01-Rev-E-RMI4-Interfacing-Guide.pdf
+
+Optional Properties:
+- syna,f01-nosleep: If set the device will run at full power without sleeping.
+- syna,f01-wakeup-threshold: Defines the amplitude of the disturbance to the
+ background capacitance that will cause the
+ device to wake from dozing.
+- syna,f01-doze-holdoff: The delay to wait after the last finger lift and the
+ first doze cycle (in 0.1 second units).
+- syna,f01-doze-interval: The time period that the device sleeps between finger
+ activity (in 10 ms units).
+
+
+Example of a RMI4 I2C device with F01:
+{
+ rmi-i2c-dev@2c {
+ compatible = "syna,rmi-i2c";
+ reg = <0x2c>;
+ syna,sensor-name="TM1949";
+ syna,attn-gpio = <4 2>;
+ syna,attn-polarity = <0>;
+ syna,level-triggered = <1>;
+ syna,f01-nosleep = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/input/rmi4/rmi_f11.txt
b/Documentation/devicetree/bindings/input/rmi4/rmi_f11.txt
new file mode 100644
index 000..2405523
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/rmi4/rmi_f11.txt
@@ -0,0 +1,51 @@
+Synaptics RMI4 F11 Device Binding
+
+The Synaptics RMI4 core is able to support RMI4 devices using differnet
+transports and differnet functions. This file describes the device tree
+bindings for devices which contain Function 11. Complete documentation
+for transports and other functions can be found in:
+Documentation/devicetree/bindings/input/rmi4.
+
+RMI4 Function 11 is for 2D touch position sensing. Additional documentation for
+F11 can be found at:
+http://www.synaptics.com/sites/default/files/511-000136-01-Rev-E-RMI4-Interfacing-Guide.pdf
+
+Optional Properties:
+- syna,f11-swap-axes: Swap X and Y positions when reporting.
+- syna,f11-flip-x: Reverse the direction of X.
+- syna,f11-flip-y: Reverse the direction of Y.
+- syna,f11-clip-x-low: Sets a minimum value for X.
+- syna,f11-clip-y-low: Sets a minimum value for Y.
+- syna,f11-clip-x-high: Sets a maximum value for X.
+- syna,f11-clip-y-high: Sets a maximum value for Y.
+- syna,f11-offset-x: Add an offset to X.
+- syna,f11-offset_y: Add an offset to Y.
+- syna,f11-delta-x-threshold: Set the minimum distance on the X axis required
+ to generate an interrupt in reduced reporting
+ mode.
+- syna,f11-delta-y-threshold: Set the minimum distance on the Y axis required
+
[PATCH] Input: synaptics-rmi4: Add device tree support for RMI4 I2C devices
Add devicetree binding for I2C devices and add bindings for optional
parameters in the function drivers.
Signed-off-by: Andrew Duggan adug...@synaptics.com
---
I saw Benjamin Tissoires's email about the lack of a devicetree implementation
for rmi_i2c.c. I decided to clean up and add documentation to the implementaion
which I have been using and submit it for review.
This patch applies to the current implementation of Dmitry's synaptics-rmi4
branch in the input repository. If Benjamin's patchset gets applied before
this I can rebase this patch.
Thanks,
Andrew
.../devicetree/bindings/input/rmi4/rmi_f01.txt | 34 ++
.../devicetree/bindings/input/rmi4/rmi_f11.txt | 51
.../devicetree/bindings/input/rmi4/rmi_i2c.txt | 40 +++
.../devicetree/bindings/vendor-prefixes.txt| 1 +
drivers/input/rmi4/rmi_bus.c | 49
drivers/input/rmi4/rmi_bus.h | 8 +-
drivers/input/rmi4/rmi_driver.c| 46 ++-
drivers/input/rmi4/rmi_f01.c | 50 +++-
drivers/input/rmi4/rmi_f11.c | 133 -
drivers/input/rmi4/rmi_i2c.c | 60 +-
include/linux/rmi.h| 2 +-
11 files changed, 465 insertions(+), 9 deletions(-)
create mode 100644 Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt
create mode 100644 Documentation/devicetree/bindings/input/rmi4/rmi_f11.txt
create mode 100644 Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt
diff --git a/Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt
b/Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt
new file mode 100644
index 000..53846e2
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt
@@ -0,0 +1,34 @@
+Synaptics RMI4 F01 Device Binding
+
+The Synaptics RMI4 core is able to support RMI4 devices using differnet
+transports and differnet functions. This file describes the device tree
+bindings for devices which contain Function 1. Complete documentation
+for transports and other functions can be found in:
+Documentation/devicetree/bindings/input/rmi4.
+
+Additional documentation for F01 can be found at:
+http://www.synaptics.com/sites/default/files/511-000136-01-Rev-E-RMI4-Interfacing-Guide.pdf
+
+Optional Properties:
+- syna,f01-nosleep: If set the device will run at full power without sleeping.
+- syna,f01-wakeup-threshold: Defines the amplitude of the disturbance to the
+ background capacitance that will cause the
+ device to wake from dozing.
+- syna,f01-doze-holdoff: The delay to wait after the last finger lift and the
+ first doze cycle (in 0.1 second units).
+- syna,f01-doze-interval: The time period that the device sleeps between finger
+ activity (in 10 ms units).
+
+
+Example of a RMI4 I2C device with F01:
+ i2c1 {
+ rmi-i2c-dev@2c {
+ compatible = syna,rmi-i2c;
+ reg = 0x2c;
+ syna,sensor-name=TM1949;
+ syna,attn-gpio = 4 2;
+ syna,attn-polarity = 0;
+ syna,level-triggered = 1;
+ syna,f01-nosleep = 1;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/input/rmi4/rmi_f11.txt
b/Documentation/devicetree/bindings/input/rmi4/rmi_f11.txt
new file mode 100644
index 000..2405523
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/rmi4/rmi_f11.txt
@@ -0,0 +1,51 @@
+Synaptics RMI4 F11 Device Binding
+
+The Synaptics RMI4 core is able to support RMI4 devices using differnet
+transports and differnet functions. This file describes the device tree
+bindings for devices which contain Function 11. Complete documentation
+for transports and other functions can be found in:
+Documentation/devicetree/bindings/input/rmi4.
+
+RMI4 Function 11 is for 2D touch position sensing. Additional documentation for
+F11 can be found at:
+http://www.synaptics.com/sites/default/files/511-000136-01-Rev-E-RMI4-Interfacing-Guide.pdf
+
+Optional Properties:
+- syna,f11-swap-axes: Swap X and Y positions when reporting.
+- syna,f11-flip-x: Reverse the direction of X.
+- syna,f11-flip-y: Reverse the direction of Y.
+- syna,f11-clip-x-low: Sets a minimum value for X.
+- syna,f11-clip-y-low: Sets a minimum value for Y.
+- syna,f11-clip-x-high: Sets a maximum value for X.
+- syna,f11-clip-y-high: Sets a maximum value for Y.
+- syna,f11-offset-x: Add an offset to X.
+- syna,f11-offset_y: Add an offset to Y.
+- syna,f11-delta-x-threshold: Set the minimum distance on the X axis required
+ to generate an interrupt in reduced reporting
+ mode.
+- syna,f11-delta-y-threshold: Set the minimum distance on the Y axis required
+
