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: <20210511144139.GB4413@qmqm.qmqm.pl>
Date:   Tue, 11 May 2021 16:41:39 +0200
From:   Michał Mirosław <mirq-linux@...e.qmqm.pl>
To:     Dmitry Osipenko <digetx@...il.com>
Cc:     Thierry Reding <thierry.reding@...il.com>,
        Jonathan Hunter <jonathanh@...dia.com>,
        Peter De Schrijver <pdeschrijver@...dia.com>,
        Prashant Gaikwad <pgaikwad@...dia.com>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Rob Herring <robh+dt@...nel.org>, linux-tegra@...r.kernel.org,
        linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org
Subject: Re: [PATCH v7 6/8] clk: tegra: cclk: Handle thermal DIV2 CPU
 frequency throttling

On Tue, May 11, 2021 at 02:17:35AM +0300, Dmitry Osipenko wrote:
> Check whether thermal DIV2 throttle is active in order to report
> the CPU frequency properly. This very useful for userspace tools
> like cpufreq-info which show actual frequency asserted from hardware.
> 
> Signed-off-by: Dmitry Osipenko <digetx@...il.com>
> ---
>  drivers/clk/tegra/clk-tegra-super-cclk.c | 16 ++++++++++++++--
>  drivers/clk/tegra/clk-tegra30.c          |  2 +-
>  2 files changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/clk/tegra/clk-tegra-super-cclk.c b/drivers/clk/tegra/clk-tegra-super-cclk.c
> index a03119c30456..f75822b71d0e 100644
> --- a/drivers/clk/tegra/clk-tegra-super-cclk.c
> +++ b/drivers/clk/tegra/clk-tegra-super-cclk.c
> @@ -25,6 +25,8 @@
>  
>  #define SUPER_CDIV_ENB		BIT(31)
>  
> +#define TSENSOR_SLOWDOWN	BIT(23)
> +
>  static struct tegra_clk_super_mux *cclk_super;
>  static bool cclk_on_pllx;
>  
> @@ -47,10 +49,20 @@ static int cclk_super_set_rate(struct clk_hw *hw, unsigned long rate,
>  static unsigned long cclk_super_recalc_rate(struct clk_hw *hw,
>  					    unsigned long parent_rate)
>  {
> +	struct tegra_clk_super_mux *super = to_clk_super_mux(hw);
> +	u32 val = readl_relaxed(super->reg);
> +	unsigned int div2;
> +
> +	/* check whether thermal throttling is active */
> +	if (val & TSENSOR_SLOWDOWN)
> +		div2 = 2;
> +	else
> +		div2 = 1;
> +
>  	if (cclk_super_get_parent(hw) == PLLX_INDEX)
> -		return parent_rate;
> +		return parent_rate / div2;
>  
> -	return tegra_clk_super_ops.recalc_rate(hw, parent_rate);
> +	return tegra_clk_super_ops.recalc_rate(hw, parent_rate) / div2;
>  }

Could you check if the compiler can optimize out the division? I know this
is a slow path, but nevertheless the 'shr' version would be the same amount
of source code.

Best Regrads
Michał Mirosław

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ