[PATCH 1/2] memory: samsung: exynos5422-dmc: Adjust polling interval and uptreshold

[Lukasz Luba]

On 7/10/20 2:19 PM, Krzysztof Kozlowski wrote:
> On Fri, Jul 10, 2020 at 03:13:18PM +0200, Marek Szyprowski wrote:
>> Hi Lukasz,
>>
>> On 10.07.2020 10:34, Lukasz Luba wrote:
>>> Hi Chanwoo,
>>>
>>> On 7/9/20 5:08 AM, Chanwoo Choi wrote:
>>>> Hi Lukasz,
>>>>
>>>> On 7/9/20 12:34 AM, Lukasz Luba wrote:
>>>>> In order to react faster and make better decisions under some
>>>>> workloads,
>>>>> benchmarking the memory subsystem behavior, adjust the polling interval
>>>>> and upthreshold value used by the simple_ondemand governor.
>>>>>
>>>>> Reported-by: Willy Wolff <willy.mh.wolff.ml at gmail.com>
>>>>> Signed-off-by: Lukasz Luba <lukasz.luba at arm.com>
>>>>> ---
>>>>>    drivers/memory/samsung/exynos5422-dmc.c | 4 ++--
>>>>>    1 file changed, 2 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/drivers/memory/samsung/exynos5422-dmc.c
>>>>> b/drivers/memory/samsung/exynos5422-dmc.c
>>>>> index 93e9c2429c0d..e03ee35f0ab5 100644
>>>>> --- a/drivers/memory/samsung/exynos5422-dmc.c
>>>>> +++ b/drivers/memory/samsung/exynos5422-dmc.c
>>>>> @@ -1466,10 +1466,10 @@ static int exynos5_dmc_probe(struct
>>>>> platform_device *pdev)
>>>>>             * Setup default thresholds for the devfreq governor.
>>>>>             * The values are chosen based on experiments.
>>>>>             */
>>>>> -        dmc->gov_data.upthreshold = 30;
>>>>> +        dmc->gov_data.upthreshold = 10;
>>>>>            dmc->gov_data.downdifferential = 5;
>>>>>    -        exynos5_dmc_df_profile.polling_ms = 500;
>>>>> +        exynos5_dmc_df_profile.polling_ms = 100;
>>>>>        }
>>>>>
>>>>
>>>> Reviewed-by: Chanwoo Choi <cw00.choi at samsung.com>
>>>>
>>>
>>> Thank you for the review. Do you think this patch could go through
>>> your tree together with your patches?
>>>
>>> I don't know Krzysztof's opinion about the patch 2/2, but
>>> I would expect, assuming the patch itself is correct, he would
>>> like to take it into his next/dt branch.
>>
>> Is there really a need to remove the interrupts property? imho they are
>> correct hw description, it just a matter of the driver to use or not to
>> use them.

Marek, I agree with you, they are correct hw description. Unfortunately,
I don't have TRM to experiment and maybe fix the interrupt mode code.

> 
> That's actually very good point. I would also prefer to leave them.
> However I understood that driver chooses mode depending on the property.

Correct

> 
> In such case, maybe as you said, let's switch to polling mode
> unconditionally?

I can make happen that the polling mode will be unconditionally
set as default.

Do you think that the interrupt mode code can still stay in the
driver, because maybe in future could be fixed?


> 
> Best regards,
> Krzysztof
>