Date:   Wed, 15 Dec 2021 15:08:36 +0100
From:   Maxime Ripard <maxime@cerno.tech>
To:     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>
Cc:     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: <20211215140836.bpxyau4atm74sfkk@houat>
References: <20210914093515.260031-1-maxime@cerno.tech>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="lg2pqwgvtun7kcl5"
Content-Disposition: inline
In-Reply-To: <20210914093515.260031-1-maxime@cerno.tech>
Precedence: bulk


--lg2pqwgvtun7kcl5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Stephen, Mike,

On Tue, Sep 14, 2021 at 11:35:12AM +0200, Maxime Ripard wrote:
> Hi,
>=20
> This is a follow-up of the discussion here:
> https://lore.kernel.org/linux-clk/20210319150355.xzw7ikwdaga2dwhv@gilmour/
>=20
> This implements a mechanism to raise and lower clock rates based on consu=
mer
> workloads, with an example of such an implementation for the RaspberryPi4=
 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 fee=
ls
>     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 ra=
te
>     possible. While we don't have an use-case for something else, this sh=
ould
>     maybe be made more flexible?

This has been posted around 8 monthes ago now:
https://lore.kernel.org/all/20210413101320.321584-1-maxime@cerno.tech/

I haven't had any review on this, and I'm struggling to see how we can
move forward. Given your initial reaction, I'm guessing you were a bit
reluctant at first with the approach, if so, can you share *any*
direction in which I should amend that series to support similar
features?

Maxime

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

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

iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCYbn25AAKCRDj7w1vZxhR
xXPHAQDOqQ4yaKrzcO5kvJncig3EqvvGSCVhhwqr3YlVw4JwogD7B2wtLggYl6h3
hip/UU8FeqCCPB/OZzacWJicCo8cFQo=
=PF1A
-----END PGP SIGNATURE-----

--lg2pqwgvtun7kcl5--