diff mbox

Touchscreen failure with CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND

Message ID CAOMZO5BZ8Z8dfwsfuiunNQ_q39_k4QJg7jLPQfaxn+YBsmz2jw@mail.gmail.com (mailing list archive)
State Not Applicable, archived
Headers show

Commit Message

Fabio Estevam April 21, 2017, 4:11 p.m. UTC
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:


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?

Thanks

Comments

Rafael J. Wysocki April 21, 2017, 9:28 p.m. UTC | #1
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
Rafael J. Wysocki April 21, 2017, 9:33 p.m. UTC | #2
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
Fabio Estevam April 21, 2017, 9:37 p.m. UTC | #3
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
Viresh Kumar April 24, 2017, 4:07 a.m. UTC | #4
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/*
Fabio Estevam April 24, 2017, 11:20 a.m. UTC | #5
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
Viresh Kumar April 24, 2017, 11:29 a.m. UTC | #6
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 ?
Fabio Estevam April 24, 2017, 11:37 a.m. UTC | #7
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
Viresh Kumar April 24, 2017, 11:43 a.m. UTC | #8
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
Fabio Estevam April 24, 2017, 11:51 a.m. UTC | #9
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.
Viresh Kumar April 25, 2017, 5:06 a.m. UTC | #10
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 ?
Fabio Estevam April 25, 2017, 11:09 a.m. UTC | #11
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
Viresh Kumar April 25, 2017, 11:13 a.m. UTC | #12
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.
Fabio Estevam April 25, 2017, 1:43 p.m. UTC | #13
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.
Adam Ford April 25, 2017, 2:35 p.m. UTC | #14
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
Fabio Estevam April 25, 2017, 3:24 p.m. UTC | #15
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
Viresh Kumar April 26, 2017, 4:18 a.m. UTC | #16
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.
Adam Ford April 27, 2017, 12:57 a.m. UTC | #17
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
Fabio Estevam April 27, 2017, 1:50 a.m. UTC | #18
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?
Adam Ford April 27, 2017, 2:01 a.m. UTC | #19
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
Fabio Estevam April 27, 2017, 2:20 a.m. UTC | #20
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.
diff mbox

Patch

--- 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