Re: [PATCH 0/4] Touchscreen performance related fixes
Hi, On Thursday 13 November 2014 05:53 PM, Vignesh R wrote: Hi, On Wednesday 12 November 2014 06:30 PM, Johannes Pointner wrote: Hello Vignesh, I tried your patch version 3 on a customized board and had some behavior I couldn't explain. If I only use the touchscreen it works fine but if I also read values from the ADCs then I get a lot of pen_up events even if I am still touching the screen. For the test I read via # cat /sys/bus/iio/devices/iio\:device0/in_voltage5_raw values from the ADC in an busy loop as you explained in an email before. Did you also experience such behavior or do you know what causes it? Thanks for testing. I was able to fix this issue. Will post version 4 shortly. Were you able to test the v4 patch series on your board? Is the issue fixed? Regards Vignesh Without the patches the touchscreen works fine during the iio test. Thanks, Hannes 2014-11-06 8:42 GMT+01:00 Vignesh R vigne...@ti.com: On Monday 03 November 2014 11:39 PM, Richard Cochran wrote: On Mon, Oct 27, 2014 at 04:38:27PM +0530, Vignesh R wrote: This series of patches fix TSC defects related to lag in touchscreen performance and cursor jump at touch release. The lag was result of udelay in TSC interrupt handler. Cursor jump due to false pen-up event. The patches implement Advisory 1.0.31 in silicon errata of am335x-evm to avoid false pen-up events and remove udelay. That advisory has two workarounds. You have chosen the second one? Work around one. Hence 5 wire design is not broken. The text of the second workaround says it only works on 4 wire setups, so I wonder how 5 wire designs will be affected. The advisory says to use steps 1 to 4 for ADC and 5 to 16 for TSC (assuming 4 wire TSC and 4 channel ADC). No, it doesn't say that. (sprz360f.pdf) The pen up event detection happens immediately after charge step. Hence, interchanging ADC and TSC steps makes sure that sampling of touch co-ordinates and pen events are done one after the other. This workaround was suggested by internal hardware folks. Earlier ADC steps intervened between sampling of co-ordinates and pen event detection which is not desirable. Further the X co-ordinate must be the last one to be sampled just before charge step. The first two patches implement the required changes. FWIW, I implemented the first workaround and removed the udelay not too long ago. Like Sebastian, I saw the TSC unit hang after about 5 interrupts when running with the workaround. Did you test you patch for very long? Yes, I tested for about 20 interrupts and I didn't see any hang. This patch series does not just implement workaround but also does some minor changes, such as interchanging ADC and TSC steps etc, which makes TSC driver more robust. Let me know if you encounter any issues with my patch series. Regards Vignesh Thanks, Richard -- To unsubscribe from this list: send the line unsubscribe linux-iio in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Touchscreen performance related fixes
On Tuesday 04 November 2014 06:07 PM, Sebastian Andrzej Siewior wrote: On 11/04/2014 12:44 PM, Vignesh R wrote: I ran following commands $ evtest /dev/input/touchscreen0 (with heavy item on touchscreen) and $ cat /sys/bus/iio/devices/iio\:device0/scan_elements/in_voltage4_en (in a busy loop) I tried above experiment on my board but I didn't hit any problem even after running for close to 30 minutes. I was unable to reproduce failure Just to make sure: You had the touchscreen and iio command running in parallel and you saw evtest output while there was iio operation? The problem may be in configuring correct charge-delay value. Please run: $ ts_test /dev/null and let me know if pen events are being detected properly. Well I get the touch events but not while busy loop on iio interface is running (I get maybe one event every 5 seconds or so). After all, it is the same HW you have. Were you able to test the latest version (v4) of this patch series? Please let me know if the performance is satisfactory. Regards Vignesh Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Touchscreen performance related fixes
Hi, On Wednesday 12 November 2014 06:30 PM, Johannes Pointner wrote: Hello Vignesh, I tried your patch version 3 on a customized board and had some behavior I couldn't explain. If I only use the touchscreen it works fine but if I also read values from the ADCs then I get a lot of pen_up events even if I am still touching the screen. For the test I read via # cat /sys/bus/iio/devices/iio\:device0/in_voltage5_raw values from the ADC in an busy loop as you explained in an email before. Did you also experience such behavior or do you know what causes it? Thanks for testing. I was able to fix this issue. Will post version 4 shortly. Regards Vignesh Without the patches the touchscreen works fine during the iio test. Thanks, Hannes 2014-11-06 8:42 GMT+01:00 Vignesh R vigne...@ti.com: On Monday 03 November 2014 11:39 PM, Richard Cochran wrote: On Mon, Oct 27, 2014 at 04:38:27PM +0530, Vignesh R wrote: This series of patches fix TSC defects related to lag in touchscreen performance and cursor jump at touch release. The lag was result of udelay in TSC interrupt handler. Cursor jump due to false pen-up event. The patches implement Advisory 1.0.31 in silicon errata of am335x-evm to avoid false pen-up events and remove udelay. That advisory has two workarounds. You have chosen the second one? Work around one. Hence 5 wire design is not broken. The text of the second workaround says it only works on 4 wire setups, so I wonder how 5 wire designs will be affected. The advisory says to use steps 1 to 4 for ADC and 5 to 16 for TSC (assuming 4 wire TSC and 4 channel ADC). No, it doesn't say that. (sprz360f.pdf) The pen up event detection happens immediately after charge step. Hence, interchanging ADC and TSC steps makes sure that sampling of touch co-ordinates and pen events are done one after the other. This workaround was suggested by internal hardware folks. Earlier ADC steps intervened between sampling of co-ordinates and pen event detection which is not desirable. Further the X co-ordinate must be the last one to be sampled just before charge step. The first two patches implement the required changes. FWIW, I implemented the first workaround and removed the udelay not too long ago. Like Sebastian, I saw the TSC unit hang after about 5 interrupts when running with the workaround. Did you test you patch for very long? Yes, I tested for about 20 interrupts and I didn't see any hang. This patch series does not just implement workaround but also does some minor changes, such as interchanging ADC and TSC steps etc, which makes TSC driver more robust. Let me know if you encounter any issues with my patch series. Regards Vignesh Thanks, Richard -- To unsubscribe from this list: send the line unsubscribe linux-iio in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Touchscreen performance related fixes
Hello Vignesh, I tried your patch version 3 on a customized board and had some behavior I couldn't explain. If I only use the touchscreen it works fine but if I also read values from the ADCs then I get a lot of pen_up events even if I am still touching the screen. For the test I read via # cat /sys/bus/iio/devices/iio\:device0/in_voltage5_raw values from the ADC in an busy loop as you explained in an email before. Did you also experience such behavior or do you know what causes it? Without the patches the touchscreen works fine during the iio test. Thanks, Hannes 2014-11-06 8:42 GMT+01:00 Vignesh R vigne...@ti.com: On Monday 03 November 2014 11:39 PM, Richard Cochran wrote: On Mon, Oct 27, 2014 at 04:38:27PM +0530, Vignesh R wrote: This series of patches fix TSC defects related to lag in touchscreen performance and cursor jump at touch release. The lag was result of udelay in TSC interrupt handler. Cursor jump due to false pen-up event. The patches implement Advisory 1.0.31 in silicon errata of am335x-evm to avoid false pen-up events and remove udelay. That advisory has two workarounds. You have chosen the second one? Work around one. Hence 5 wire design is not broken. The text of the second workaround says it only works on 4 wire setups, so I wonder how 5 wire designs will be affected. The advisory says to use steps 1 to 4 for ADC and 5 to 16 for TSC (assuming 4 wire TSC and 4 channel ADC). No, it doesn't say that. (sprz360f.pdf) The pen up event detection happens immediately after charge step. Hence, interchanging ADC and TSC steps makes sure that sampling of touch co-ordinates and pen events are done one after the other. This workaround was suggested by internal hardware folks. Earlier ADC steps intervened between sampling of co-ordinates and pen event detection which is not desirable. Further the X co-ordinate must be the last one to be sampled just before charge step. The first two patches implement the required changes. FWIW, I implemented the first workaround and removed the udelay not too long ago. Like Sebastian, I saw the TSC unit hang after about 5 interrupts when running with the workaround. Did you test you patch for very long? Yes, I tested for about 20 interrupts and I didn't see any hang. This patch series does not just implement workaround but also does some minor changes, such as interchanging ADC and TSC steps etc, which makes TSC driver more robust. Let me know if you encounter any issues with my patch series. Regards Vignesh Thanks, Richard -- To unsubscribe from this list: send the line unsubscribe linux-iio in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Touchscreen performance related fixes
On Tuesday 04 November 2014 06:07 PM, Sebastian Andrzej Siewior wrote: On 11/04/2014 12:44 PM, Vignesh R wrote: I ran following commands $ evtest /dev/input/touchscreen0 (with heavy item on touchscreen) and $ cat /sys/bus/iio/devices/iio\:device0/scan_elements/in_voltage4_en (in a busy loop) I tried above experiment on my board but I didn't hit any problem even after running for close to 30 minutes. I was unable to reproduce failure Just to make sure: You had the touchscreen and iio command running in parallel and you saw evtest output while there was iio operation? Yeah.. I see both evtest and IIO outputs. Touch events are received consistently (decent samples per second) and atleast one IIO output per second. Here is a part from console log --- 928 Event: time 1413204484.240114, type 3 (Absolute), code 0 (X), value 1746 Event: time 1413204484.240114, type 3 (Absolute), code 1 (Y), value 1720 Event: time 1413204484.240114, type 3 (Absolute), code 24 (Pressure), value 99 Event: time 1413204484.240114, -- Report Sync Event: time 1413204484.255318, type 1 (Key), code 330 (Touch), value 0 Event: time 1413204484.255318, type 3 (Absolute), code 24 (Pressure), value 0 Event: time 1413204484.255318, -- Report Sync 933 Event: time 1413204484.273599, type 3 (Absolute), code 1 (Y), value 1718 Event: time 1413204484.273599, type 3 (Absolute), code 24 (Pressure), value 99 Event: time 1413204484.273599, type 1 (Key), code 330 (Touch), value 1 Event: time 1413204484.273599, -- Report Sync Event: time 1413204484.290195, type 3 (Absolute), code 24 (Pressure), value 98 Event: time 1413204484.290195, -- Report Sync Event: time 1413204484.306783, type 3 (Absolute), code 1 (Y), value 1719 Event: time 1413204484.306783, -- Report Sync 946 Event: time 1413204484.322164, type 1 (Key), code 330 (Touch), value 0 Event: time 1413204484.322164, type 3 (Absolute), code 24 (Pressure), value 0 Event: time 1413204484.322164, -- Report Sync Event: time 1413204484.340435, type 3 (Absolute), code 1 (Y), value 1721 Event: time 1413204484.340435, type 3 (Absolute), code 24 (Pressure), value 98 Event: time 1413204484.340435, type 1 (Key), code 330 (Touch), value 1 Event: time 1413204484.340435, -- Report Sync Event: time 1413204484.357025, type 3 (Absolute), code 0 (X), value 1745 Event: time 1413204484.357025, type 3 (Absolute), code 24 (Pressure), value 97 Event: time 1413204484.357025, -- Report Sync Event: time 1413204484.373621, type 3 (Absolute), code 0 (X), value 1746 Event: time 1413204484.373621, type 3 (Absolute), code 1 (Y), value 1720 Event: time 1413204484.373621, -- Report Sync 942 --- The numbers 928, 933 etc are from oneshot ADC read. The above output is pretty consistent over time. The problem may be in configuring correct charge-delay value. Please run: $ ts_test /dev/null and let me know if pen events are being detected properly. Well I get the touch events but not while busy loop on iio interface is running (I get maybe one event every 5 seconds or so). After all, it is the same HW you have. Yeah.. I believe HW is same. I am using rev 1.5B with omap2plus_defconfig (+ TSC/ADC enabled) Regards Vignesh Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Touchscreen performance related fixes
On Monday 03 November 2014 11:39 PM, Richard Cochran wrote: On Mon, Oct 27, 2014 at 04:38:27PM +0530, Vignesh R wrote: This series of patches fix TSC defects related to lag in touchscreen performance and cursor jump at touch release. The lag was result of udelay in TSC interrupt handler. Cursor jump due to false pen-up event. The patches implement Advisory 1.0.31 in silicon errata of am335x-evm to avoid false pen-up events and remove udelay. That advisory has two workarounds. You have chosen the second one? Work around one. Hence 5 wire design is not broken. The text of the second workaround says it only works on 4 wire setups, so I wonder how 5 wire designs will be affected. The advisory says to use steps 1 to 4 for ADC and 5 to 16 for TSC (assuming 4 wire TSC and 4 channel ADC). No, it doesn't say that. (sprz360f.pdf) The pen up event detection happens immediately after charge step. Hence, interchanging ADC and TSC steps makes sure that sampling of touch co-ordinates and pen events are done one after the other. This workaround was suggested by internal hardware folks. Earlier ADC steps intervened between sampling of co-ordinates and pen event detection which is not desirable. Further the X co-ordinate must be the last one to be sampled just before charge step. The first two patches implement the required changes. FWIW, I implemented the first workaround and removed the udelay not too long ago. Like Sebastian, I saw the TSC unit hang after about 5 interrupts when running with the workaround. Did you test you patch for very long? Yes, I tested for about 20 interrupts and I didn't see any hang. This patch series does not just implement workaround but also does some minor changes, such as interchanging ADC and TSC steps etc, which makes TSC driver more robust. Let me know if you encounter any issues with my patch series. Regards Vignesh Thanks, Richard -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Touchscreen performance related fixes
On Monday 03 November 2014 05:47 PM, Sebastian Andrzej Siewior wrote: On 10/27/2014 08:02 PM, Griffis, Brad wrote: On 10/27/2014 12:34 PM, Sebastian Andrzej Siewior wrote: Do we really need #3 (and then #4)? Given the complexity we have already, is there any benefit by decreasing this value? I specifically requested we add ti,charge-delay to the device tree because it is THE critical value to tune for a given design. Although I think the current value of 0xB000 will be suitable for a great many designs, I expect that many users will need to adjust this value for their hardware. Details such as which touchscreen vendor is being used and how the touchscreen is connected (header vs cable) have an effect on what's appropriate here. Oh. That is one knob I hoped we could avoid since I haven't seen it before on other TSCs. But okay. Please make sure that there is a message printed if the default value is used. And lets hope the user will do something about his. Would someone want to increase it? Can we safely determine a value which works for everyone? This value represents a hardware delay before checking for the pen-up event. So in the scenario where someone is seeing excessive false pen-up events they will want to increase this parameter. The downsize of making this larger is that it decreases the overall sampling speed of both the touchscreen as well as the standalone ADC samples. At one point I tried making it huge, but that made the touchscreen overly sluggish because the sampling became too slow. So there is a definite trade-off that if you make it too large the touchscreen becomes sluggish, and if you make it too small then you may see false pen-up events. The optimal value will need to be tuned for a given design. I applied the patches from this series and did the following test on my am335x-evm: A mug on the touchscreen (to make sure the events are coming), evtest on the event node to see that the events and loop of cat /sys/bus/iio/devices/iio\:device0/in_voltage4_raw In the past I was able lock up the TSC/ADC HW that way (see commit 7ca6740cd1 (mfd: input: iio: ti_amm335x: Rework TSC/ADC synchronization)) for details. With this patches applied I don't seen any TSC events once the IIO interface is (heavily) used. Can this be fixed? I ran following commands $ evtest /dev/input/touchscreen0 (with heavy item on touchscreen) and $ cat /sys/bus/iio/devices/iio\:device0/scan_elements/in_voltage4_en (in a busy loop) I tried above experiment on my board but I didn't hit any problem even after running for close to 30 minutes. I was unable to reproduce failure The problem may be in configuring correct charge-delay value. Please run: $ ts_test /dev/null and let me know if pen events are being detected properly. Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Touchscreen performance related fixes
On 11/04/2014 12:44 PM, Vignesh R wrote: I ran following commands $ evtest /dev/input/touchscreen0 (with heavy item on touchscreen) and $ cat /sys/bus/iio/devices/iio\:device0/scan_elements/in_voltage4_en (in a busy loop) I tried above experiment on my board but I didn't hit any problem even after running for close to 30 minutes. I was unable to reproduce failure Just to make sure: You had the touchscreen and iio command running in parallel and you saw evtest output while there was iio operation? The problem may be in configuring correct charge-delay value. Please run: $ ts_test /dev/null and let me know if pen events are being detected properly. Well I get the touch events but not while busy loop on iio interface is running (I get maybe one event every 5 seconds or so). After all, it is the same HW you have. Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Touchscreen performance related fixes
On 10/27/2014 08:02 PM, Griffis, Brad wrote: On 10/27/2014 12:34 PM, Sebastian Andrzej Siewior wrote: Do we really need #3 (and then #4)? Given the complexity we have already, is there any benefit by decreasing this value? I specifically requested we add ti,charge-delay to the device tree because it is THE critical value to tune for a given design. Although I think the current value of 0xB000 will be suitable for a great many designs, I expect that many users will need to adjust this value for their hardware. Details such as which touchscreen vendor is being used and how the touchscreen is connected (header vs cable) have an effect on what's appropriate here. Oh. That is one knob I hoped we could avoid since I haven't seen it before on other TSCs. But okay. Please make sure that there is a message printed if the default value is used. And lets hope the user will do something about his. Would someone want to increase it? Can we safely determine a value which works for everyone? This value represents a hardware delay before checking for the pen-up event. So in the scenario where someone is seeing excessive false pen-up events they will want to increase this parameter. The downsize of making this larger is that it decreases the overall sampling speed of both the touchscreen as well as the standalone ADC samples. At one point I tried making it huge, but that made the touchscreen overly sluggish because the sampling became too slow. So there is a definite trade-off that if you make it too large the touchscreen becomes sluggish, and if you make it too small then you may see false pen-up events. The optimal value will need to be tuned for a given design. I applied the patches from this series and did the following test on my am335x-evm: A mug on the touchscreen (to make sure the events are coming), evtest on the event node to see that the events and loop of cat /sys/bus/iio/devices/iio\:device0/in_voltage4_raw In the past I was able lock up the TSC/ADC HW that way (see commit 7ca6740cd1 (mfd: input: iio: ti_amm335x: Rework TSC/ADC synchronization)) for details. With this patches applied I don't seen any TSC events once the IIO interface is (heavily) used. Can this be fixed? Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Touchscreen performance related fixes
On Mon, Oct 27, 2014 at 04:38:27PM +0530, Vignesh R wrote: This series of patches fix TSC defects related to lag in touchscreen performance and cursor jump at touch release. The lag was result of udelay in TSC interrupt handler. Cursor jump due to false pen-up event. The patches implement Advisory 1.0.31 in silicon errata of am335x-evm to avoid false pen-up events and remove udelay. That advisory has two workarounds. You have chosen the second one? The text of the second workaround says it only works on 4 wire setups, so I wonder how 5 wire designs will be affected. The advisory says to use steps 1 to 4 for ADC and 5 to 16 for TSC (assuming 4 wire TSC and 4 channel ADC). No, it doesn't say that. (sprz360f.pdf) Further the X co-ordinate must be the last one to be sampled just before charge step. The first two patches implement the required changes. FWIW, I implemented the first workaround and removed the udelay not too long ago. Like Sebastian, I saw the TSC unit hang after about 5 interrupts when running with the workaround. Did you test you patch for very long? Thanks, Richard -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] Touchscreen performance related fixes
This series of patches fix TSC defects related to lag in touchscreen performance and cursor jump at touch release. The lag was result of udelay in TSC interrupt handler. Cursor jump due to false pen-up event. The patches implement Advisory 1.0.31 in silicon errata of am335x-evm to avoid false pen-up events and remove udelay. The advisory says to use steps 1 to 4 for ADC and 5 to 16 for TSC (assuming 4 wire TSC and 4 channel ADC). Further the X co-ordinate must be the last one to be sampled just before charge step. The first two patches implement the required changes. A DT parameter to configure the duration of tsc charge step. It represents number of ADC clock cycles to wait between applying the step configuration registers and going back to the IDLE state. The charge delay value can vary across boards. Configuring correct value of charge delay is important to avoid false pen-up events. Hence it is necessary to expose charge-delay value as DT parameter. The pen-up detection happens immediately after the charge step so this does in fact function as a hardware knob for adjusting the amount of settling time. After applying these changes false pen-up events have not be observed and smooth circles can be drawn on touch screen. The performance is much better in recognizing quick movement across the screen. No lag or cursor jump is observed. Brad Griffis (2): input: touchscreen: ti_am335x_tsc Interchange touchscreen and ADC steps input: touchscreen: ti_am335x_tsc: Remove udelay in interrupt handler Vignesh R (2): arm: boot: dts: am335x-evm: Make charge delay a DT parameter for tsc input: touchscreen: ti_am335x_tsc: Use charge delay DT parameter .../bindings/input/touchscreen/ti-tsc-adc.txt | 13 +++ arch/arm/boot/dts/am335x-evm.dts | 1 + drivers/iio/adc/ti_am335x_adc.c| 2 +- drivers/input/touchscreen/ti_am335x_tsc.c | 106 ++--- drivers/mfd/ti_am335x_tscadc.c | 7 +- include/linux/mfd/ti_am335x_tscadc.h | 4 +- 6 files changed, 76 insertions(+), 57 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Touchscreen performance related fixes
On 10/27/2014 12:08 PM, Vignesh R wrote: This series of patches fix TSC defects related to lag in touchscreen I will try to look this in the next few days. Do we really need #3 (and then #4)? Given the complexity we have already, is there any benefit by decreasing this value? Would someone want to increase it? Can we safely determine a value which works for everyone? Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/4] Touchscreen performance related fixes
On 10/27/2014 12:34 PM, Sebastian Andrzej Siewior wrote: Do we really need #3 (and then #4)? Given the complexity we have already, is there any benefit by decreasing this value? I specifically requested we add ti,charge-delay to the device tree because it is THE critical value to tune for a given design. Although I think the current value of 0xB000 will be suitable for a great many designs, I expect that many users will need to adjust this value for their hardware. Details such as which touchscreen vendor is being used and how the touchscreen is connected (header vs cable) have an effect on what's appropriate here. Would someone want to increase it? Can we safely determine a value which works for everyone? This value represents a hardware delay before checking for the pen-up event. So in the scenario where someone is seeing excessive false pen-up events they will want to increase this parameter. The downsize of making this larger is that it decreases the overall sampling speed of both the touchscreen as well as the standalone ADC samples. At one point I tried making it huge, but that made the touchscreen overly sluggish because the sampling became too slow. So there is a definite trade-off that if you make it too large the touchscreen becomes sluggish, and if you make it too small then you may see false pen-up events. The optimal value will need to be tuned for a given design. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
