Date:   Wed, 12 Jan 2022 14:51:47 +0100
From:   Maxime Ripard <maxime@cerno.tech>
To:     Dmitry Osipenko <digetx@gmail.com>
Cc:     Mike Turquette <mturquette@baylibre.com>,
        Stephen Boyd <sboyd@kernel.org>,
        dri-devel@lists.freedesktop.org,
        Daniel Vetter <daniel.vetter@intel.com>,
        David Airlie <airlied@linux.ie>,
        Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
        Thomas Zimmermann <tzimmermann@suse.de>,
        Thierry Reding <thierry.reding@gmail.com>,
        linux-clk@vger.kernel.org,
        Dave Stevenson <dave.stevenson@raspberrypi.com>,
        Phil Elwell <phil@raspberrypi.com>,
        Tim Gover <tim.gover@raspberrypi.com>,
        Dom Cobley <dom@raspberrypi.com>,
        Emma Anholt <emma@anholt.net>, linux-kernel@vger.kernel.org,
        Russell King <linux@armlinux.org.uk>
Subject: Re: [PATCH v2 0/3] clk: Implement a clock request API
Message-ID: <20220112135147.dbkmsnlqyipq7urq@houat>
References: <20210914093515.260031-1-maxime@cerno.tech>
 <a5400ae3-f181-91fc-bc35-db989584c70b@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="t2qv6kke3mwujz2s"
Content-Disposition: inline
In-Reply-To: <a5400ae3-f181-91fc-bc35-db989584c70b@gmail.com>
Precedence: bulk


--t2qv6kke3mwujz2s
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Dmitry,

On Wed, Jan 12, 2022 at 04:28:41PM +0300, Dmitry Osipenko wrote:
> 14.09.2021 12:35, Maxime Ripard =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
> > Hi,
> >=20
> > This is a follow-up of the discussion here:
> > https://lore.kernel.org/linux-clk/20210319150355.xzw7ikwdaga2dwhv@gilmo=
ur/
> >=20
> > This implements a mechanism to raise and lower clock rates based on con=
sumer
> > workloads, with an example of such an implementation for the RaspberryP=
i4 HDMI
> > controller.
> >=20
> > There's a couple of things worth discussing:
> >=20
> >   - The name is in conflict with clk_request_rate, and even though it f=
eels
> >     like the right name to me, we should probably avoid any confusion
> >=20
> >   - 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?
>=20
> Hello Maxime,
>=20
> 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.
>=20
> [1] https://git.kernel.org/linus/04d5d5df9
>=20
> 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?

The goals seem to be similar indeed, but most of these clocks feed some
internal state machine in those devices and are not related to the
memory bandwidth at all. So there's no real interconnect to model there :/

Maxime

--t2qv6kke3mwujz2s
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCYd7c8wAKCRDj7w1vZxhR
xVuPAP9/9WqdgEDuYNDuYiROyAiSVfLJJPhtDldKsoecRjwokgD/ZDi8CesqnZXj
fnIDTx+JuQiyTMzhpUz/iwl0Lx+NSQE=
=mcMz
-----END PGP SIGNATURE-----

--t2qv6kke3mwujz2s--