linux-kernel - Re: [PATCH v2 0/3] clk: Implement a clock request API

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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 12 Jan 2022 16:28:41 +0300
From:   Dmitry Osipenko <digetx@...il.com>
To:     Maxime Ripard <maxime@...no.tech>,
        Mike Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        dri-devel@...ts.freedesktop.org,
        Daniel Vetter <daniel.vetter@...el.com>,
        David Airlie <airlied@...ux.ie>,
        Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        Thierry Reding <thierry.reding@...il.com>
Cc:     Maxime Ripard <mripard@...nel.org>, linux-clk@...r.kernel.org,
        Dave Stevenson <dave.stevenson@...pberrypi.com>,
        Phil Elwell <phil@...pberrypi.com>,
        Tim Gover <tim.gover@...pberrypi.com>,
        Dom Cobley <dom@...pberrypi.com>,
        Emma Anholt <emma@...olt.net>, linux-kernel@...r.kernel.org,
        Russell King <linux@...linux.org.uk>
Subject: Re: [PATCH v2 0/3] clk: Implement a clock request API

14.09.2021 12:35, Maxime Ripard пишет:
> Hi,
> 
> This is a follow-up of the discussion here:
> https://lore.kernel.org/linux-clk/20210319150355.xzw7ikwdaga2dwhv@gilmour/
> 
> This implements a mechanism to raise and lower clock rates based on consumer
> workloads, with an example of such an implementation for the RaspberryPi4 HDMI
> controller.
> 
> There's a couple of things worth discussing:
> 
>   - The name is in conflict with clk_request_rate, and even though it feels
>     like the right name to me, we should probably avoid any confusion
> 
>   - The code so far implements a policy of always going for the lowest rate
>     possible. While we don't have an use-case for something else, this should
>     maybe be made more flexible?

Hello Maxime,

On NVIDIA Tegra we use interconnect framework for converting of
workload-based memory bandwidth requirement to the memory clock rate
[1]. All Tegra SoCs have two display controllers and other memory
clients, ICC takes care of summing and updating memory bandwidth for us,
which in the end results in a freq change of the shared memory controller.

[1] https://git.kernel.org/linus/04d5d5df9

Not so long time ago me and Thierry Reding were looking at yours v1 and
back then Thierry suggested that the same ICC approach might work for
yours case. I'm now looking at the v2 and yours discussion with Stephen
Boyd, and it appears that ICC is indeed what you really need. Have you
considered to use ICC?