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 ;-)
