Re: [PATCH v1 2/7] clk: bcm: rpi: Add a function to retrieve the maximum

[Stefan Wahren]

Hi Stephen,

Am 14.09.22 um 20:20 schrieb Stephen Boyd:
> Quoting Stefan Wahren (2022-09-14 11:09:04)
> > 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
> Another idea is to populate an OPP table in the rpi firmware driver for
> this platform device with the adjusted max frequency. That would be an
> SoC/firmware agnostic interface that expresses the constraints.
Do you mean in the source code of this driver or in the DT?
> I'm
> almost certain we talked about this before.
I'm not sure about the context. Do you mean the CPU frequency handling? 
I remember it was a hard decision. In the end it was little benefit but 
a lot of disadvantages (hard to maintain all theses OPP tables for all 
Raspberry Pi boards, doesn't work with already deployed DT). So yes, i'm 
part of the problem i mentioned before ;-)