[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <96f75e90-9c14-5908-e9e9-979c9d28a898@linaro.org>
Date: Fri, 20 Mar 2020 21:17:47 +0100
From: Daniel Lezcano <daniel.lezcano@...aro.org>
To: Willy Wolff <willy.mh.wolff.ml@...il.com>,
Zhang Rui <rui.zhang@...el.com>,
Eduardo Valentin <edubezval@...il.com>,
Amit Kucheria <amit.kucheria@...durent.com>,
linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
"Rafael J. Wysocki" <rjw@...ysocki.net>
Subject: Re: weird cooling_device/cur_state sysfs behaviour
Adding Rafael,
On 20/03/2020 18:43, Daniel Lezcano wrote:
> On 20/03/2020 16:10, Willy Wolff wrote:
>> Hi all,
>> Hope you're doing well with the situation.
>>
>> I fill that my board get a cold too...
>>
>> When I write to a sysfs node, I have a weird behaviour about the function that is called behind.
>> This bug appears on an arm32 odroid-xu3, and only after v5.4, v5.3.18 behave correctly.
>>
>>
>> Here my modification to see what's going on:
>>
>> diff --git a/drivers/thermal/thermal_sysfs.c b/drivers/thermal/thermal_sysfs.c
>> index aa99edb4dff7..a437ae3f4b9f 100644
>> --- a/drivers/thermal/thermal_sysfs.c
>> +++ b/drivers/thermal/thermal_sysfs.c
>> @@ -706,11 +706,22 @@ cur_state_store(struct device *dev, struct device_attribute *attr,
>
> [ ... ]
>
>> return result ? result : count;
>> }
>>
>> +
>
> [ ... ]
>
>>
>> As you can see, the function is recalled with one character less, until the "buffer is empty".
>> I don't understand why. Can anybody help me for this thing?
>> Many thanks in advance.
>
> [ ... ]
>
> Very likely the problem is coming from:
>
> result = cdev->ops->set_cur_state(cdev, state);
>
> which returns '1' as showed by the traces:
>
> drivers/thermal/thermal_sysfs.c:735:cur_state_store result = 1, count = 3
>
> And because of the return condition above:
>
> return result ? result : count;
>
> the function is returning result, so '1', which is interpreted by the
> sysfs as "I wrote one character', so it recalls the function with the
> two remaining characters, etc ...
>
> The problem is from the governor AFAICT, which governor is it?
I went through the code and I believe the problem is coming from:
cpufreq_set_cur_state
-> freq_qos_update_request
-> freq_qos_apply
-> pm_qos_update_target =>
" * This function returns 1 if the aggregated constraint value has changed,"
freq_qos_apply() does:
ret = pm_qos_update_target()
...
return ret;
At the first glance, it is related to commit 77751a466ebd1 (Nov 2019).
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
Powered by blists - more mailing lists