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
