| Message ID | CAOMZO5BZ8Z8dfwsfuiunNQ_q39_k4QJg7jLPQfaxn+YBsmz2jw@mail.gmail.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On Friday, April 21, 2017 01:11:52 PM Fabio Estevam wrote: > Hi, > > Running 4.11-rc7 on a imx6q-sabresd board I notice that egalax > touchscreen stops generating evtest events after a random period of > time. > > This problem can be avoided if I unselect CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND: > > --- a/arch/arm/configs/imx_v6_v7_defconfig > +++ b/arch/arm/configs/imx_v6_v7_defconfig > @@ -54,7 +54,6 @@ CONFIG_CMA=y > CONFIG_CMDLINE="noinitrd console=ttymxc0,115200" > CONFIG_KEXEC=y > CONFIG_CPU_FREQ=y > -CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y > CONFIG_ARM_IMX6Q_CPUFREQ=y > CONFIG_CPU_IDLE=y > CONFIG_VFP=y > > With this change evtest always capture all touchscreen events. No > single failure is seen. > > I could see the same behavior with all mainline kernels I tested (4.9 and 4.10). > > Any ideas as to how fix this bug when CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y? And which governor is the default otherwise? Thanks, Rafael
On Friday, April 21, 2017 06:37:31 PM Fabio Estevam wrote: > On Fri, Apr 21, 2017 at 6:28 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote: > > On Friday, April 21, 2017 01:11:52 PM Fabio Estevam wrote: > >> Hi, > >> > >> Running 4.11-rc7 on a imx6q-sabresd board I notice that egalax > >> touchscreen stops generating evtest events after a random period of > >> time. > >> > >> This problem can be avoided if I unselect CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND: > >> > >> --- a/arch/arm/configs/imx_v6_v7_defconfig > >> +++ b/arch/arm/configs/imx_v6_v7_defconfig > >> @@ -54,7 +54,6 @@ CONFIG_CMA=y > >> CONFIG_CMDLINE="noinitrd console=ttymxc0,115200" > >> CONFIG_KEXEC=y > >> CONFIG_CPU_FREQ=y > >> -CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y > >> CONFIG_ARM_IMX6Q_CPUFREQ=y > >> CONFIG_CPU_IDLE=y > >> CONFIG_VFP=y > >> > >> With this change evtest always capture all touchscreen events. No > >> single failure is seen. > >> > >> I could see the same behavior with all mainline kernels I tested (4.9 and 4.10). > >> > >> Any ideas as to how fix this bug when CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y? > > > > And which governor is the default otherwise? > > When CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y is removed then the > 'performance' governor is the default. There you go. Apparently, using frequencies below the max causes problems to happen in the SoC. Thanks, Rafael
On Fri, Apr 21, 2017 at 6:28 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote: > On Friday, April 21, 2017 01:11:52 PM Fabio Estevam wrote: >> Hi, >> >> Running 4.11-rc7 on a imx6q-sabresd board I notice that egalax >> touchscreen stops generating evtest events after a random period of >> time. >> >> This problem can be avoided if I unselect CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND: >> >> --- a/arch/arm/configs/imx_v6_v7_defconfig >> +++ b/arch/arm/configs/imx_v6_v7_defconfig >> @@ -54,7 +54,6 @@ CONFIG_CMA=y >> CONFIG_CMDLINE="noinitrd console=ttymxc0,115200" >> CONFIG_KEXEC=y >> CONFIG_CPU_FREQ=y >> -CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y >> CONFIG_ARM_IMX6Q_CPUFREQ=y >> CONFIG_CPU_IDLE=y >> CONFIG_VFP=y >> >> With this change evtest always capture all touchscreen events. No >> single failure is seen. >> >> I could see the same behavior with all mainline kernels I tested (4.9 and 4.10). >> >> Any ideas as to how fix this bug when CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y? > > And which governor is the default otherwise? When CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y is removed then the 'performance' governor is the default. Thanks
On 21-04-17, 13:11, Fabio Estevam wrote: > Hi, > > Running 4.11-rc7 on a imx6q-sabresd board I notice that egalax > touchscreen stops generating evtest events after a random period of > time. > > This problem can be avoided if I unselect CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND: > > --- a/arch/arm/configs/imx_v6_v7_defconfig > +++ b/arch/arm/configs/imx_v6_v7_defconfig > @@ -54,7 +54,6 @@ CONFIG_CMA=y > CONFIG_CMDLINE="noinitrd console=ttymxc0,115200" > CONFIG_KEXEC=y > CONFIG_CPU_FREQ=y > -CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y > CONFIG_ARM_IMX6Q_CPUFREQ=y > CONFIG_CPU_IDLE=y > CONFIG_VFP=y > > With this change evtest always capture all touchscreen events. No > single failure is seen. > > I could see the same behavior with all mainline kernels I tested (4.9 and 4.10). > > Any ideas as to how fix this bug when CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y? So as Rafael pointed out the problem doesn't happen if you stay at the max frequencies, but otherwise. You need to investigate on why that is the case. You can go to the cpufreq sysfs directory and see what frequencies are getting selected, etc.. Give me output of this for now: grep . /sys/devices/system/cpu/cpufreq/policy0/* grep . /sys/devices/system/cpu/cpufreq/policy0/stats/*
Hi Viresh, On Mon, Apr 24, 2017 at 1:07 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote: > So as Rafael pointed out the problem doesn't happen if you stay at the max > frequencies, but otherwise. > > You need to investigate on why that is the case. You can go to the cpufreq sysfs > directory and see what frequencies are getting selected, etc.. Yes, when the CPU frequency stays at 996 MHz I do not see the touchscreen failure. When it goes to 396MHz I do see see touchscreeen events getting lost. > Give me output of this for now: > > grep . /sys/devices/system/cpu/cpufreq/policy0/* > grep . /sys/devices/system/cpu/cpufreq/policy0/stats/* Here it goes, thanks. # grep . /sys/devices/system/cpu/cpufreq/policy0/* /sys/devices/system/cpu/cpufreq/policy0/affected_cpus:0 1 2 3 /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_cur_freq:396000 /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_max_freq:996000 /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_min_freq:396000 /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_transition_latency:109036 /sys/devices/system/cpu/cpufreq/policy0/related_cpus:0 1 2 3 /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies:396000 792000 996000 /sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors:ondemand performance /sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq:396000 /sys/devices/system/cpu/cpufreq/policy0/scaling_driver:imx6q-cpufreq /sys/devices/system/cpu/cpufreq/policy0/scaling_governor:ondemand /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq:996000 /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq:396000 /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed:<unsupported> # grep . /sys/devices/system/cpu/cpufreq/policy0/stats/* grep: /sys/devices/system/cpu/cpufreq/policy0/stats/reset: Permission denied /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:396000 2869 /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:792000 76 /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:996000 33 /sys/devices/system/cpu/cpufreq/policy0/stats/total_trans:8 /sys/devices/system/cpu/cpufreq/policy0/stats/trans_table: From : To /sys/devices/system/cpu/cpufreq/policy0/stats/trans_table: : 396000 792000 996000 /sys/devices/system/cpu/cpufreq/policy0/stats/trans_table: 396000: 0 2 0 /sys/devices/system/cpu/cpufreq/policy0/stats/trans_table: 792000: 2 0 2 /sys/devices/system/cpu/cpufreq/policy0/stats/trans_table: 996000: 1 1 0
On 24-04-17, 08:20, Fabio Estevam wrote: > Here it goes, thanks. > > # grep . /sys/devices/system/cpu/cpufreq/policy0/* > /sys/devices/system/cpu/cpufreq/policy0/affected_cpus:0 1 2 3 > /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_cur_freq:396000 > /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_max_freq:996000 > /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_min_freq:396000 > /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_transition_latency:109036 > /sys/devices/system/cpu/cpufreq/policy0/related_cpus:0 1 2 3 > /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies:396000 > 792000 996000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors:ondemand > performance > /sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq:396000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_driver:imx6q-cpufreq > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor:ondemand > /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq:996000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq:396000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed:<unsupported> > > # grep . /sys/devices/system/cpu/cpufreq/policy0/stats/* > grep: /sys/devices/system/cpu/cpufreq/policy0/stats/reset: Permission denied > /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:396000 2869 > /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:792000 76 > /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:996000 33 > /sys/devices/system/cpu/cpufreq/policy0/stats/total_trans:8 So clearly the system isn't changing the frequency a lot here and you stayed at the min freq for ever. Please give output of this as well: grep . /sys/devices/system/cpu/cpufreq/ondemand/* I am also worried if the interrupts from the touchscreen will be enough to boost the frequency of the CPU ?
On Mon, Apr 24, 2017 at 8:29 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote: > So clearly the system isn't changing the frequency a lot here and you stayed at > the min freq for ever. Please give output of this as well: > > grep . /sys/devices/system/cpu/cpufreq/ondemand/* # grep . /sys/devices/system/cpu/cpufreq/ondemand/* /sys/devices/system/cpu/cpufreq/ondemand/ignore_nice_load:0 /sys/devices/system/cpu/cpufreq/ondemand/io_is_busy:0 /sys/devices/system/cpu/cpufreq/ondemand/min_sampling_rate:10000 /sys/devices/system/cpu/cpufreq/ondemand/powersave_bias:0 /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor:1 /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate:109000 /sys/devices/system/cpu/cpufreq/ondemand/up_threshold:95 > I am also worried if the interrupts from the touchscreen will be enough to boost > the frequency of the CPU ? It does not seem that the interrupts from the touchscreen boost the frequency of the CPU. When I keep touching the panel, the CPU frequency stays at 396 MHz. Thanks
On 24-04-17, 08:37, Fabio Estevam wrote: > On Mon, Apr 24, 2017 at 8:29 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote: > > > So clearly the system isn't changing the frequency a lot here and you stayed at > > the min freq for ever. Please give output of this as well: > > > > grep . /sys/devices/system/cpu/cpufreq/ondemand/* > > # grep . /sys/devices/system/cpu/cpufreq/ondemand/* > /sys/devices/system/cpu/cpufreq/ondemand/ignore_nice_load:0 > /sys/devices/system/cpu/cpufreq/ondemand/io_is_busy:0 > /sys/devices/system/cpu/cpufreq/ondemand/min_sampling_rate:10000 > /sys/devices/system/cpu/cpufreq/ondemand/powersave_bias:0 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor:1 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate:109000 110 ms is your sampling rate right now. Looks too high. Try doing this: echo 10000 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate and retry your tests. > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold:95 > > > I am also worried if the interrupts from the touchscreen will be enough to boost > > the frequency of the CPU ? > > It does not seem that the interrupts from the touchscreen boost the > frequency of the CPU. > > When I keep touching the panel, the CPU frequency stays at 396 MHz. > > Thanks
On Mon, Apr 24, 2017 at 8:43 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote: > 110 ms is your sampling rate right now. Looks too high. > > Try doing this: > > echo 10000 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate > > and retry your tests. Tried 10ms and also 1ms, but touchscreen also failed in both cases.
On 24-04-17, 08:51, Fabio Estevam wrote: > On Mon, Apr 24, 2017 at 8:43 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote: > > > 110 ms is your sampling rate right now. Looks too high. > > > > Try doing this: > > > > echo 10000 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate > > > > and retry your tests. > > Tried 10ms and also 1ms, but touchscreen also failed in both cases. Honestly, I don't have a clue on how can we fix it for you now :) @Rafael: Any idea apart from running at max all the time? what touchscreen driver are you using btw? Just curious to see if there is any bug in there. Handling touchscreen events shouldn't require us to run at max freq. @shawn: Saw something similar ever ?
Hi Viresh, On Tue, Apr 25, 2017 at 2:06 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote: > Honestly, I don't have a clue on how can we fix it for you now :) > > @Rafael: Any idea apart from running at max all the time? > > what touchscreen driver are you using btw? Just curious to see if there is any > bug in there. Handling touchscreen events shouldn't require us to run at max > freq. imx6q-sabresd board uses a drivers/input/touchscreen/egalax_ts.c touchscreen. > > @shawn: Saw something similar ever ? I do not see the problem with the NXP kernel, but was not able to identify what makes the touchscreen not to fail at 396MHz in their kernel. Thanks
On 25-04-17, 08:09, Fabio Estevam wrote: > Hi Viresh, > > On Tue, Apr 25, 2017 at 2:06 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote: > > > Honestly, I don't have a clue on how can we fix it for you now :) > > > > @Rafael: Any idea apart from running at max all the time? > > > > what touchscreen driver are you using btw? Just curious to see if there is any > > bug in there. Handling touchscreen events shouldn't require us to run at max > > freq. > > imx6q-sabresd board uses a drivers/input/touchscreen/egalax_ts.c touchscreen. > > > > > @shawn: Saw something similar ever ? > > I do not see the problem with the NXP kernel, but was not able to > identify what makes the touchscreen not to fail at 396MHz in their > kernel. @Shawn/Sascha: Can you guys help here? This looks to be some imx specific stuff now.
Hi Adam, On Tue, Apr 25, 2017 at 9:41 AM, Adam Ford <aford173@gmail.com> wrote: > I don't have that board, so I can't test, but I have seen other issues on my > imx6 board where operating at 'performance' instead of on-demand worked > better for me as well in different areas. I was assuming it was something What are the issues you observed with 'on-demand' on your mx6 board? > regarding the voltage levels of various regulators for my board, and I am > going to run tests on my board by playing with regulators on my device tree > to make sure they are properly regulating to the right voltages. Since > 'performance' runs the processor at both a higher speed and higher voltage, > it's conceivable to me that something is just below some limit/level and > needs some minor adjustment. At least that is my theory with my board > issues. Have you looked considered that possibility? One test I have already tried was to run all other cpufreq operating points with the same ARM and SOC-PU voltages as the 996MHz. Still in this case I do see touchscreen failure.
On Tue, Apr 25, 2017 at 8:43 AM, Fabio Estevam <festevam@gmail.com> wrote: > Hi Adam, > > On Tue, Apr 25, 2017 at 9:41 AM, Adam Ford <aford173@gmail.com> wrote: > >> I don't have that board, so I can't test, but I have seen other issues on my >> imx6 board where operating at 'performance' instead of on-demand worked >> better for me as well in different areas. I was assuming it was something > > What are the issues you observed with 'on-demand' on your mx6 board? > My board does not always wake from sleep, and I was having some issues on reboot unless I ran at 'performance' and that is what made me think my board was having voltage dips too low. >> regarding the voltage levels of various regulators for my board, and I am >> going to run tests on my board by playing with regulators on my device tree >> to make sure they are properly regulating to the right voltages. Since >> 'performance' runs the processor at both a higher speed and higher voltage, >> it's conceivable to me that something is just below some limit/level and >> needs some minor adjustment. At least that is my theory with my board >> issues. Have you looked considered that possibility? > > One test I have already tried was to run all other cpufreq operating > points with the same ARM and SOC-PU voltages as the 996MHz. > > Still in this case I do see touchscreen failure. I have a touch screen (using tsc2004 touch controller) on my board. I can run some tests if you tell me how you're able to reproduce your issue. I can at least confirm whether or not I see it too. I won't be able to do it until later tonight or tomorrow however. adam
On Tue, Apr 25, 2017 at 11:35 AM, Adam Ford <aford173@gmail.com> wrote: > I have a touch screen (using tsc2004 touch controller) on my board. I > can run some tests if you tell me how you're able to reproduce your > issue. I can at least confirm whether or not I see it too. I won't > be able to do it until later tonight or tomorrow however. Just run: evtest /dev/input/eventX to capture the touchscreen events and keep touching the screen. After some random time (1-2 minutes) evtest will stop capturing the events. Thanks
On 25-04-17, 12:24, Fabio Estevam wrote: > On Tue, Apr 25, 2017 at 11:35 AM, Adam Ford <aford173@gmail.com> wrote: > > > I have a touch screen (using tsc2004 touch controller) on my board. I > > can run some tests if you tell me how you're able to reproduce your > > issue. I can at least confirm whether or not I see it too. I won't > > be able to do it until later tonight or tomorrow however. > > Just run: > > evtest /dev/input/eventX to capture the touchscreen events and keep > touching the screen. > > After some random time (1-2 minutes) evtest will stop capturing the events. And set the governor to Powersave to make sure we are running on lowest OPP.
On Tue, Apr 25, 2017 at 10:24 AM, Fabio Estevam <festevam@gmail.com> wrote: > On Tue, Apr 25, 2017 at 11:35 AM, Adam Ford <aford173@gmail.com> wrote: > >> I have a touch screen (using tsc2004 touch controller) on my board. I >> can run some tests if you tell me how you're able to reproduce your >> issue. I can at least confirm whether or not I see it too. I won't >> be able to do it until later tonight or tomorrow however. > > Just run: > > evtest /dev/input/eventX to capture the touchscreen events and keep > touching the screen. > Using my board set to ondemand (and I verified frequency) # cat /sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq 396000 I ran it for 3 hours and it and continued to show results. Event: time 71379.065289, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1 Event: time 71379.065289, -------------- SYN_REPORT ------------ Event: time 71379.117399, type 3 (EV_ABS), code 24 (ABS_PRESSURE), value 0 Event: time 71379.117399, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 0 Event: time 71379.117399, -------------- SYN_REPORT ------------ Event: time 83122.438637, type 3 (EV_ABS), code 0 (ABS_X), value 2144 Event: time 83122.438637, type 3 (EV_ABS), code 1 (ABS_Y), value 1186 Event: time 83122.438637, type 3 (EV_ABS), code 24 (ABS_PRESSURE), value 567 Event: time 83122.438637, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1 Event: time 83122.438637, -------------- SYN_REPORT ------------ adam > After some random time (1-2 minutes) evtest will stop capturing the events. > > Thanks
On Wed, Apr 26, 2017 at 9:57 PM, Adam Ford <aford173@gmail.com> wrote: > Using my board set to ondemand (and I verified frequency) > # cat /sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq > 396000 > > I ran it for 3 hours and it and continued to show results. Thanks for testing. Does evtest still work if you keep constantly touching the screen after one or two minutes?
On Wed, Apr 26, 2017 at 8:50 PM, Fabio Estevam <festevam@gmail.com> wrote: > On Wed, Apr 26, 2017 at 9:57 PM, Adam Ford <aford173@gmail.com> wrote: > >> Using my board set to ondemand (and I verified frequency) >> # cat /sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq >> 396000 >> >> I ran it for 3 hours and it and continued to show results. > > Thanks for testing. > > Does evtest still work if you keep constantly touching the screen > after one or two minutes? I held it for nearly six minutes while checking out facebook (I am not sure why I did that part). After 6 minutes it was still operational. I should note that I am running 4.9.23 # evtest /dev/input/event0 Input driver version is 1.0.1 Input device ID: bus 0x18 vendor 0x0 product 0x7d4 version 0x0 Input device name: "TSC200X touchscreen" Supported events: Event type 0 (EV_SYN) Event type 1 (EV_KEY) Event code 330 (BTN_TOUCH) Event type 3 (EV_ABS) Event code 0 (ABS_X) Value 2331 Min 0 Max 4095 Fuzz 4 Event code 1 (ABS_Y) Value 1540 Min 0 Max 4095 Fuzz 7 Event code 24 (ABS_PRESSURE) Value 0 Min 0 Max 2048 Fuzz 2
On Wed, Apr 26, 2017 at 11:01 PM, Adam Ford <aford173@gmail.com> wrote: > I held it for nearly six minutes while checking out facebook (I am not > sure why I did that part). After 6 minutes it was still operational. > > I should note that I am running 4.9.23 Thanks for testing. I will keep investigating.
--- a/arch/arm/configs/imx_v6_v7_defconfig +++ b/arch/arm/configs/imx_v6_v7_defconfig @@ -54,7 +54,6 @@ CONFIG_CMA=y CONFIG_CMDLINE="noinitrd console=ttymxc0,115200" CONFIG_KEXEC=y CONFIG_CPU_FREQ=y -CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y CONFIG_ARM_IMX6Q_CPUFREQ=y CONFIG_CPU_IDLE=y CONFIG_VFP=y