linux-kernel - Re: [PATCH v7 36/47] memory: tegra20-emc: Add devfreq support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <05fbab83-517f-a0e3-24db-358bfc367d5b@gmail.com>
Date:   Thu, 5 Nov 2020 16:50:54 +0300
From:   Dmitry Osipenko <digetx@...il.com>
To:     Chanwoo Choi <cw00.choi@...sung.com>,
        Thierry Reding <thierry.reding@...il.com>,
        Jonathan Hunter <jonathanh@...dia.com>,
        Georgi Djakov <georgi.djakov@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Peter De Schrijver <pdeschrijver@...dia.com>,
        MyungJoo Ham <myungjoo.ham@...sung.com>,
        Kyungmin Park <kyungmin.park@...sung.com>,
        Mikko Perttunen <cyndis@...si.fi>,
        Viresh Kumar <vireshk@...nel.org>,
        Peter Geis <pgwipeout@...il.com>,
        Nicolas Chauvet <kwizart@...il.com>,
        Krzysztof Kozlowski <krzk@...nel.org>
Cc:     linux-tegra@...r.kernel.org, linux-pm@...r.kernel.org,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        devicetree@...r.kernel.org
Subject: Re: [PATCH v7 36/47] memory: tegra20-emc: Add devfreq support

05.11.2020 05:30, Chanwoo Choi пишет:
> On 11/5/20 1:49 AM, Dmitry Osipenko wrote:
>> Add devfreq support to the Tegra20 EMC driver. Memory utilization
>> statistics will be periodically polled from the memory controller and
>> appropriate minimum clock rate will be selected by the devfreq governor.
>>
>> Signed-off-by: Dmitry Osipenko <digetx@...il.com>
>> ---
>>  drivers/memory/tegra/Kconfig       |  2 +
>>  drivers/memory/tegra/tegra20-emc.c | 92 ++++++++++++++++++++++++++++++
>>  2 files changed, 94 insertions(+)
>>
>> diff --git a/drivers/memory/tegra/Kconfig b/drivers/memory/tegra/Kconfig
>> index ac3dfe155505..76e9a3b10839 100644
>> --- a/drivers/memory/tegra/Kconfig
>> +++ b/drivers/memory/tegra/Kconfig
>> @@ -12,6 +12,8 @@ config TEGRA20_EMC
>>  	tristate "NVIDIA Tegra20 External Memory Controller driver"
>>  	default y
>>  	depends on TEGRA_MC && ARCH_TEGRA_2x_SOC
>> +	select DEVFREQ_GOV_SIMPLE_ONDEMAND
>> +	select PM_DEVFREQ
>>  	select PM_OPP
> 
> nitpick. If you select PM_DEVFREQ, don't need to select 'PM_OPP'
> bacause PM_DEVFREQ use OPP as mandatory with 'select PM_OPP' in Kconfig.

Ok

...
>> +static int tegra_emc_devfreq_init(struct tegra_emc *emc)
>> +{
>> +	int err;
>> +
>> +	/*
>> +	 * PWR_COUNT is 1/2 of PWR_CLOCKS at max, and thus, the up-threshold
>> +	 * should be less than 50.  Secondly, multiple active memory clients
>> +	 * may cause over 20% of lost clock cycles due to stalls caused by
>> +	 * competing memory accesses.  This means that threshold should be
>> +	 * set to a less than 30 in order to have a properly working governor.
>> +	 */
>> +	emc->ondemand_data.upthreshold = 20;
>> +
>> +	/*
>> +	 * Reset statistic gathers state, select global bandwidth for the
>> +	 * statistics collection mode and set clocks counter saturation
>> +	 * limit to maximum.
>> +	 */
>> +	writel_relaxed(0x00000000, emc->regs + EMC_STAT_CONTROL);
>> +	writel_relaxed(0x00000000, emc->regs + EMC_STAT_LLMC_CONTROL);
>> +	writel_relaxed(0xffffffff, emc->regs + EMC_STAT_PWR_CLOCK_LIMIT);
>> +
>> +	emc->devfreq = devfreq_add_device(emc->dev, &tegra_emc_devfreq_profile,
>> +					  DEVFREQ_GOV_SIMPLE_ONDEMAND,
>> +					  &emc->ondemand_data);
> 
> Do you want to use 'devfreq_add_device' instead of
> 'devm_devfreq_add_device()'? If you have to use 'devfreq_add_device'
> due to some reason, you need to call 'devfreq_remove_device' on exit.

The reason I didn't use the devm here is because the EMC-clk callback
should be unregistered *after* devfreq is removed.

Thinking a bit more about it, I guess the best variant will be to add
devm support to the clk callback registration and then it should be
possible to use devm for the devfreq. I'll try to implement it in v8,
thanks.