Re: [RFC PATCH 00/11] input: Synaptics RMI4 Touchscreen Driver
On Mon, Aug 27, 2012 at 4:20 PM, Christopher Heiny wrote: > EARLY_SUSPEND/LATE_RESUME and other power management stuff. We're caught in > a bind here. Most of our customers are using some flavor of Android. They > have the expectation that our driver will (a) support the Android power > management model, and (b) be contributed into the mainline kernel without > change. Yes, I know these are contradictory requirements, given that > Android specific features are not in the mainline. > > With the upcoming rebase of the code to more modern kernels, we'll be able > to eliminate a bunch of those dependencies. But the only way to eliminate > them entirely would be to maintain mainline and Android versions of the > driver, which would drain resources from developing core features and fixing > bugs. So for now we've got a single code base. When we finally submit a > patch and the only response is "everything is fine but that Android stuff", > we'll probably change that policy within 48 hours (to include time needed > for celebration and subsequent hangover recovery :-) ). I'd suggest you rebase and test them with Android and the android hooks all over the place, but when you send it out to community, remove these #ifdef sections. This way the delta between what's in the mainline kernel and what you're maintaining internally will ideally be reduced to a few Android-enablement patches. But it's all up to the subsystem maintainer, so I'd ask Dmitry about this. By the way, this patch set has come a long way, and I would suggest to try merging core support and touch to begin with, so you have the core in place, then you can work on individual function drivers one at a time. This would make the patch bombs a bit smaller. Yours, Linus Walleij -- 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: [RFC PATCH 00/11] input: Synaptics RMI4 Touchscreen Driver
On 08/22/2012 05:50 AM, Linus Walleij wrote: On Sat, Aug 18, 2012 at 12:17 AM, Christopher Heiny wrote: >This patch implements a driver supporting Synaptics ClearPad and other >touchscreen sensors that use the RMI4 protocol, as defined here: Nice! >This patch is against the v2.6.38 tag of Linus' kernel tree, commit >521cb40b0c44418a4fd36dc633f575813d59a43d. This will be our last patch against >such an old kernel version, future patches will be against 3.x kernels. Please use the head of the subsystem tree to do this work. In this case, use Dmitry's git. Currently I just cannot test this because we have no such old codebase around. But I will attempt to review the patch set! Thanks for all the feedback so far - it has been quite valuable. I'm not going to try to respond to every comment, especially since most of it will be of a "Yeah - good idea" nature. A couple of general things: The "phys" debugfs interface is intended to tell you about the physical interface a particular RMI4 sensor is using (either SPI or I2C or whatever), including the name of the interface, the number of reads/writes done, number of bytes that have been read/written, number of errors, and so on. We chose to to call name it phys so that the debug tools would be able to find this interface no matter what the physical connection was, even when new physical layer support (for example, SMbus) is introduced. EARLY_SUSPEND/LATE_RESUME and other power management stuff. We're caught in a bind here. Most of our customers are using some flavor of Android. They have the expectation that our driver will (a) support the Android power management model, and (b) be contributed into the mainline kernel without change. Yes, I know these are contradictory requirements, given that Android specific features are not in the mainline. With the upcoming rebase of the code to more modern kernels, we'll be able to eliminate a bunch of those dependencies. But the only way to eliminate them entirely would be to maintain mainline and Android versions of the driver, which would drain resources from developing core features and fixing bugs. So for now we've got a single code base. When we finally submit a patch and the only response is "everything is fine but that Android stuff", we'll probably change that policy within 48 hours (to include time needed for celebration and subsequent hangover recovery :-) ). Cheers, Chris -- 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: [RFC PATCH 00/11] input: Synaptics RMI4 Touchscreen Driver
On Fri, Aug 17, 2012 at 3:17 PM, Christopher Heiny wrote: > This patch implements a driver supporting Synaptics ClearPad and other > touchscreen sensors that use the RMI4 protocol, as defined here: OK I looked over the parts I understood, to my surprise there is a custom GPIO, LED and ADC driver in there, and none of them use the proper kernel subsystems. You may want to expose the bus in or so, and put the drivers for these into e.g. drivers/gpio/gpio-rmi4.c drivers/leds/leds-rmi4.c drivers/iio/adc/rmi4.c Which would be nice. (Kconfig can make sure they're only available when enabling the bus.) As for the input stuff I mainly looked at the stuff I understand... Yours, Linus Walleij -- 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: [RFC PATCH 00/11] input: Synaptics RMI4 Touchscreen Driver
On Fri, Aug 17, 2012 at 3:17 PM, Christopher Heiny che...@synaptics.com wrote: This patch implements a driver supporting Synaptics ClearPad and other touchscreen sensors that use the RMI4 protocol, as defined here: OK I looked over the parts I understood, to my surprise there is a custom GPIO, LED and ADC driver in there, and none of them use the proper kernel subsystems. You may want to expose the bus in linux/input/rmi4.h or so, and put the drivers for these into e.g. drivers/gpio/gpio-rmi4.c drivers/leds/leds-rmi4.c drivers/iio/adc/rmi4.c Which would be nice. (Kconfig can make sure they're only available when enabling the bus.) As for the input stuff I mainly looked at the stuff I understand... Yours, Linus Walleij -- 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: [RFC PATCH 00/11] input: Synaptics RMI4 Touchscreen Driver
On 08/22/2012 05:50 AM, Linus Walleij wrote: On Sat, Aug 18, 2012 at 12:17 AM, Christopher Heiny che...@synaptics.com wrote: This patch implements a driver supporting Synaptics ClearPad and other touchscreen sensors that use the RMI4 protocol, as defined here: Nice! This patch is against the v2.6.38 tag of Linus' kernel tree, commit 521cb40b0c44418a4fd36dc633f575813d59a43d. This will be our last patch against such an old kernel version, future patches will be against 3.x kernels. Please use the head of the subsystem tree to do this work. In this case, use Dmitry's git. Currently I just cannot test this because we have no such old codebase around. But I will attempt to review the patch set! Thanks for all the feedback so far - it has been quite valuable. I'm not going to try to respond to every comment, especially since most of it will be of a Yeah - good idea nature. A couple of general things: The phys debugfs interface is intended to tell you about the physical interface a particular RMI4 sensor is using (either SPI or I2C or whatever), including the name of the interface, the number of reads/writes done, number of bytes that have been read/written, number of errors, and so on. We chose to to call name it phys so that the debug tools would be able to find this interface no matter what the physical connection was, even when new physical layer support (for example, SMbus) is introduced. EARLY_SUSPEND/LATE_RESUME and other power management stuff. We're caught in a bind here. Most of our customers are using some flavor of Android. They have the expectation that our driver will (a) support the Android power management model, and (b) be contributed into the mainline kernel without change. Yes, I know these are contradictory requirements, given that Android specific features are not in the mainline. With the upcoming rebase of the code to more modern kernels, we'll be able to eliminate a bunch of those dependencies. But the only way to eliminate them entirely would be to maintain mainline and Android versions of the driver, which would drain resources from developing core features and fixing bugs. So for now we've got a single code base. When we finally submit a patch and the only response is everything is fine but that Android stuff, we'll probably change that policy within 48 hours (to include time needed for celebration and subsequent hangover recovery :-) ). Cheers, Chris -- 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: [RFC PATCH 00/11] input: Synaptics RMI4 Touchscreen Driver
On Mon, Aug 27, 2012 at 4:20 PM, Christopher Heiny che...@synaptics.com wrote: EARLY_SUSPEND/LATE_RESUME and other power management stuff. We're caught in a bind here. Most of our customers are using some flavor of Android. They have the expectation that our driver will (a) support the Android power management model, and (b) be contributed into the mainline kernel without change. Yes, I know these are contradictory requirements, given that Android specific features are not in the mainline. With the upcoming rebase of the code to more modern kernels, we'll be able to eliminate a bunch of those dependencies. But the only way to eliminate them entirely would be to maintain mainline and Android versions of the driver, which would drain resources from developing core features and fixing bugs. So for now we've got a single code base. When we finally submit a patch and the only response is everything is fine but that Android stuff, we'll probably change that policy within 48 hours (to include time needed for celebration and subsequent hangover recovery :-) ). I'd suggest you rebase and test them with Android and the android hooks all over the place, but when you send it out to community, remove these #ifdef sections. This way the delta between what's in the mainline kernel and what you're maintaining internally will ideally be reduced to a few Android-enablement patches. But it's all up to the subsystem maintainer, so I'd ask Dmitry about this. By the way, this patch set has come a long way, and I would suggest to try merging core support and touch to begin with, so you have the core in place, then you can work on individual function drivers one at a time. This would make the patch bombs a bit smaller. Yours, Linus Walleij -- 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: [RFC PATCH 00/11] input: Synaptics RMI4 Touchscreen Driver
On 08/22/2012 05:50 AM, Linus Walleij wrote: On Sat, Aug 18, 2012 at 12:17 AM, Christopher Heiny wrote: This patch implements a driver supporting Synaptics ClearPad and other touchscreen sensors that use the RMI4 protocol, as defined here: Nice! This patch is against the v2.6.38 tag of Linus' kernel tree, commit 521cb40b0c44418a4fd36dc633f575813d59a43d. This will be our last patch against such an old kernel version, future patches will be against 3.x kernels. Please use the head of the subsystem tree to do this work. In this case, use Dmitry's git. Currently I just cannot test this because we have no such old codebase around. Yeah, we've been in a bind in that regard, mostly due to customer requirements to support Android Gingerbread. At least we were able to drop Froyo support this time around. :-P Going forward, though, we'll be tracking much newer kernels for our development, and hopefully getting patches out more frequently as well. But I will attempt to review the patch set! Thanks! We look forward to your input. Chris -- 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: [RFC PATCH 00/11] input: Synaptics RMI4 Touchscreen Driver
On Sat, Aug 18, 2012 at 12:17 AM, Christopher Heiny wrote: > This patch implements a driver supporting Synaptics ClearPad and other > touchscreen sensors that use the RMI4 protocol, as defined here: Nice! > This patch is against the v2.6.38 tag of Linus' kernel tree, commit > 521cb40b0c44418a4fd36dc633f575813d59a43d. This will be our last patch against > such an old kernel version, future patches will be against 3.x kernels. Please use the head of the subsystem tree to do this work. In this case, use Dmitry's git. Currently I just cannot test this because we have no such old codebase around. But I will attempt to review the patch set! Yours, Linus Walleij -- 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: [RFC PATCH 00/11] input: Synaptics RMI4 Touchscreen Driver
On Sat, Aug 18, 2012 at 12:17 AM, Christopher Heiny che...@synaptics.com wrote: This patch implements a driver supporting Synaptics ClearPad and other touchscreen sensors that use the RMI4 protocol, as defined here: Nice! This patch is against the v2.6.38 tag of Linus' kernel tree, commit 521cb40b0c44418a4fd36dc633f575813d59a43d. This will be our last patch against such an old kernel version, future patches will be against 3.x kernels. Please use the head of the subsystem tree to do this work. In this case, use Dmitry's git. Currently I just cannot test this because we have no such old codebase around. But I will attempt to review the patch set! Yours, Linus Walleij -- 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: [RFC PATCH 00/11] input: Synaptics RMI4 Touchscreen Driver
On 08/22/2012 05:50 AM, Linus Walleij wrote: On Sat, Aug 18, 2012 at 12:17 AM, Christopher Heiny che...@synaptics.com wrote: This patch implements a driver supporting Synaptics ClearPad and other touchscreen sensors that use the RMI4 protocol, as defined here: Nice! This patch is against the v2.6.38 tag of Linus' kernel tree, commit 521cb40b0c44418a4fd36dc633f575813d59a43d. This will be our last patch against such an old kernel version, future patches will be against 3.x kernels. Please use the head of the subsystem tree to do this work. In this case, use Dmitry's git. Currently I just cannot test this because we have no such old codebase around. Yeah, we've been in a bind in that regard, mostly due to customer requirements to support Android Gingerbread. At least we were able to drop Froyo support this time around. :-P Going forward, though, we'll be tracking much newer kernels for our development, and hopefully getting patches out more frequently as well. But I will attempt to review the patch set! Thanks! We look forward to your input. Chris -- 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/
[RFC PATCH 00/11] input: Synaptics RMI4 Touchscreen Driver
This patch implements a driver supporting Synaptics ClearPad and other touchscreen sensors that use the RMI4 protocol, as defined here: http://www.synaptics.com/sites/default/files/511-000136-01-Rev-E-RMI4%20Intrfacing%20Guide.pdf as well as successor documents that haven't made their way through to publication yet. This code supersedes the patch submitted on 2011-12-21. We believe that all outstanding issues arising from the previous submissions have been addressed, except certain issues relating to the use of device_type and the binding of the individual function drivers (see below). This patch is against the v2.6.38 tag of Linus' kernel tree, commit 521cb40b0c44418a4fd36dc633f575813d59a43d. This will be our last patch against such an old kernel version, future patches will be against 3.x kernels. Included in this patch are: - full support for an RMI virtual bus as a standard kernel bus - physical layer implementations for I2C and SPI - function implementations for the following RMI4 functions: * F01 device control * F09 self test (aka BIST) * F11 multifinger pointing * F17 pointing sticks * F19 capacitive buttons * F1A simple capacitive buttons * F21 force sensing * F30 GPIO and LED controls * F34 device reflash * F41 active pen pointing * F54 analog data reporting - character device access to the RMI4 register map via rmidev - firmware reflash using the request_firmware mechanism The driver supports a system having one or more RMI sensors attached to it. Most devices have just a single touch sensor, but some have more than one. An example is the Fuse concept phone, which has 4 RMI sensors in it. Each sensor is presented as a device on the RMI logical bus (/sys/bus/rmi). Devices are named/numbered in the order they are discovered on the bus, starting with /sys/bus/rmi/devices/sensor00 for the first once, .../sensor01 for the second one, and so on. Individual RMI functions are presented as child devices of the sensor device. For example, sensor00/fn01, sensor00/fn11, and so on. Control of an RMI function's operating parameters is implemented via sysfs. For diagnostic purposes, the rmidev interface is provided. This implements a character device (/dev/rmi0, and so on) that provides flat file access to the RMI4 register map. For more information, see the file Documentation/input/rmidev.txt. Note regarding device_type and functional driver matching. Feedback on our patch submission from 2011-12 requested that we use device_type to help match drivers that worked directly with the sensor (such as rmi_dev.c) and drivers that work with individual functions (such as rmi_f11.c). We spent some effort on this request, but in the meantime the original customer requirements that led to the differentiation between the two types of driver no longer exist. As a result, we have rolled back that work, and plan to merge the rmi_dev functionality into the core of the driver, eliminating the need to support two device_types and their drivers. This will be included in our next patch submission, along with changes to how function drivers are matched functions. We considered postponing this patch until that was done, but it's been a very long time since the last one, and we wanted to make the other work available. Due to the large amount of code, we've broken this patch into 17 parts, as follows: 01 - public header files and documentation 02 - core sensor and bus implementation 03 - physical layer drivers 04 - Kconfigs and Makefiles 05 - rmidev 06 - firmware update 07..17 - drivers for individual RMI functions Comments and other feedback on this driver are welcomed. Christopher Heiny and the Synaptics RMI4 driver team Signed-off-by: Christopher Heiny Cc: Jean Delvare Cc: Linus Walleij Cc: Naveen Kumar Gaddipati Cc: Joeri de Gram --- -- 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/
[RFC PATCH 00/11] input: Synaptics RMI4 Touchscreen Driver
This patch implements a driver supporting Synaptics ClearPad and other touchscreen sensors that use the RMI4 protocol, as defined here: http://www.synaptics.com/sites/default/files/511-000136-01-Rev-E-RMI4%20Intrfacing%20Guide.pdf as well as successor documents that haven't made their way through to publication yet. This code supersedes the patch submitted on 2011-12-21. We believe that all outstanding issues arising from the previous submissions have been addressed, except certain issues relating to the use of device_type and the binding of the individual function drivers (see below). This patch is against the v2.6.38 tag of Linus' kernel tree, commit 521cb40b0c44418a4fd36dc633f575813d59a43d. This will be our last patch against such an old kernel version, future patches will be against 3.x kernels. Included in this patch are: - full support for an RMI virtual bus as a standard kernel bus - physical layer implementations for I2C and SPI - function implementations for the following RMI4 functions: * F01 device control * F09 self test (aka BIST) * F11 multifinger pointing * F17 pointing sticks * F19 capacitive buttons * F1A simple capacitive buttons * F21 force sensing * F30 GPIO and LED controls * F34 device reflash * F41 active pen pointing * F54 analog data reporting - character device access to the RMI4 register map via rmidev - firmware reflash using the request_firmware mechanism The driver supports a system having one or more RMI sensors attached to it. Most devices have just a single touch sensor, but some have more than one. An example is the Fuse concept phone, which has 4 RMI sensors in it. Each sensor is presented as a device on the RMI logical bus (/sys/bus/rmi). Devices are named/numbered in the order they are discovered on the bus, starting with /sys/bus/rmi/devices/sensor00 for the first once, .../sensor01 for the second one, and so on. Individual RMI functions are presented as child devices of the sensor device. For example, sensor00/fn01, sensor00/fn11, and so on. Control of an RMI function's operating parameters is implemented via sysfs. For diagnostic purposes, the rmidev interface is provided. This implements a character device (/dev/rmi0, and so on) that provides flat file access to the RMI4 register map. For more information, see the file Documentation/input/rmidev.txt. Note regarding device_type and functional driver matching. Feedback on our patch submission from 2011-12 requested that we use device_type to help match drivers that worked directly with the sensor (such as rmi_dev.c) and drivers that work with individual functions (such as rmi_f11.c). We spent some effort on this request, but in the meantime the original customer requirements that led to the differentiation between the two types of driver no longer exist. As a result, we have rolled back that work, and plan to merge the rmi_dev functionality into the core of the driver, eliminating the need to support two device_types and their drivers. This will be included in our next patch submission, along with changes to how function drivers are matched functions. We considered postponing this patch until that was done, but it's been a very long time since the last one, and we wanted to make the other work available. Due to the large amount of code, we've broken this patch into 17 parts, as follows: 01 - public header files and documentation 02 - core sensor and bus implementation 03 - physical layer drivers 04 - Kconfigs and Makefiles 05 - rmidev 06 - firmware update 07..17 - drivers for individual RMI functions Comments and other feedback on this driver are welcomed. Christopher Heiny and the Synaptics RMI4 driver team Signed-off-by: Christopher Heiny che...@synaptics.com Cc: Jean Delvare kh...@linux-fr.org Cc: Linus Walleij linus.wall...@stericsson.com Cc: Naveen Kumar Gaddipati naveen.gaddip...@stericsson.com Cc: Joeri de Gram j.de.g...@gmail.com --- -- 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/
