[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c221873f-f230-0cce-e120-7e3cc732cf00@i2se.com>
Date: Wed, 14 Sep 2022 20:09:04 +0200
From: Stefan Wahren <stefan.wahren@...e.com>
To: Stephen Boyd <sboyd@...nel.org>,
Broadcom internal kernel review list
<bcm-kernel-feedback-list@...adcom.com>,
Daniel Vetter <daniel@...ll.ch>,
David Airlie <airlied@...ux.ie>, Emma Anholt <emma@...olt.net>,
Florian Fainelli <f.fainelli@...il.com>,
Maxime Ripard <maxime@...no.tech>,
Maxime Ripard <mripard@...nel.org>,
Michael Turquette <mturquette@...libre.com>,
Ray Jui <rjui@...adcom.com>,
Scott Branden <sbranden@...adcom.com>
Cc: linux-arm-kernel@...ts.infradead.org,
linux-rpi-kernel@...ts.infradead.org,
dri-devel@...ts.freedesktop.org, Dom Cobley <popcornmix@...il.com>,
linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 2/7] clk: bcm: rpi: Add a function to retrieve the
maximum
Am 14.09.22 um 20:05 schrieb Stephen Boyd:
> Quoting Stefan Wahren (2022-09-14 10:45:48)
>> Am 14.09.22 um 17:50 schrieb Stephen Boyd:
>>> Furthermore, I wonder if even that part needs to be implemented. Why
>>> not make a direct call to rpi_firmware_property() and get the max rate?
>>> All of that can live in the drm driver. Making it a generic API that
>>> takes a 'struct clk' means that it looks like any clk can be passed,
>>> when that isn't true. It would be better to restrict it to the one use
>>> case so that the scope of the problem doesn't grow. I understand that it
>>> duplicates a few lines of code, but that looks like a fair tradeoff vs.
>>> exposing an API that can be used for other clks in the future.
>> it would be nice to keep all the Rpi specific stuff out of the DRM
>> driver, since there more users of it.
> Instead of 'all' did you mean 'any'?
yes
Powered by blists - more mailing lists