Le mercredi 05 avril 2023 à 16:50 +0200, Maxime Ripard a écrit :
On Wed, Apr 05, 2023 at 02:57:26PM +0200, Paul Cercueil wrote:
Le lundi 27 mars 2023 à 21:24 +0200, Maxime Ripard a écrit :
On Fri, Mar 24, 2023 at 08:58:48PM +0000, Aidan MacDonald wrote:
My suggestion: add a per-clock bitmap to keep track of which parents are allowed. Any operation that would select a parent clock not on the whitelist should fail. Automatic reparenting should only select from clocks on the whitelist. And we need new DT bindings for controlling the whitelist, for example:
clock-parents-0 = <&clk1>, <&pll_c>; clock-parents-1 = <&clk2>, <&pll_a>, <&pll_b>;
This means that clk1 can only have pll_c as a parent, while clk2 can have pll_a or pll_b as parents. By default every clock will be able to use any parent, so a list is only needed if the machine needs a more restrictive policy.
assigned-clock-parents should disable automatic reparenting, but allow explicit clk_set_parent(). This will allow clock drivers to start doing reparenting without breaking old DTs.
I'm generally not a fan of putting all these policies in the device tree. Do you have an example where it wouldn't be possible to do exactly this from the driver itself?
I'm confused. What's implicit in the example is clk1 and clk2 might have *other* possible choices of parent clock and the device tree is limiting what the OS is allowed to choose.
Why would you put such arbitrary limitations into the driver?
Why would we put such arbitrary limitations in the firmware? As this entire thread can attest, people are already using the device tree to work around the limitations of the Linux driver, or reduce the features of Linux because they can rely on the device tree. Either way, it's linked to the state of the Linux driver, and any other OS or Linux version could very well implement something more dynamic.
Probably because if we have to choose between setting policy in the kernel or in the firmware, it is arguably better to set it in the firmware.
I have a very different view on this I guess. Firmware is (most of the time) hard to update, and the policy depend on the state of support of a given OS so it's likely to evolve. The kernel is the best place to me to put that kind of policy. Why do you think differently?
Because the clocks configuration can be board-specific. And you don't really want board-specific stuff in the driver.
If we take the Ingenic JZ4770 SoC as example, on one board we parent everything we can to the PLL1 clock and set it to 432 MHz (the least common multiple). Then the PLL0 (which drives the DDR and CPU clocks) can be updated to overclock/underclock the CPU and RAM.
So should that be hardcoded in the driver? Well, for a different board, for which overclock is not really needed, it's better to parent everything to PLL0 so that PLL1 can be shut down to save power. So what policy should be hardcoded in the driver?
Especially when talking about clocks, as the firmware is already the one programming the boot clocks.
I'm not sure what your point is there. I don't think I ever saw a firmware getting the clocks right for every possible scenario on a given platform. And if it was indeed the case, then we wouldn't even a kernel driver.
My point is that there is already policy in how the firmware sets up the hardware; and most often than not, the kernel driver won't change that (e.g. you're probably not going to touch the DDR clock). It's better to have all policy in the firmware then, instead of having some in the firmware, and some in the kernel driver.
Cheers, -Paul