On Mon 13 May 2024 at 21:30, Dmitry Rokosov <ddrokosov@xxxxxxxxxxxxxxxxx> wrote: > On Mon, May 13, 2024 at 04:48:33PM +0100, Conor Dooley wrote: >> On Mon, May 13, 2024 at 12:18:02PM +0300, Dmitry Rokosov wrote: >> > Hello Conor, >> > >> > Thank you for quick review! >> > >> > On Sat, May 11, 2024 at 02:08:03PM +0100, Conor Dooley wrote: >> > > On Fri, May 10, 2024 at 12:08:54PM +0300, Dmitry Rokosov wrote: >> > > > The 'syspll' PLL is a general-purpose PLL designed specifically for the >> > > > CPU clock. It is capable of producing output frequencies within the >> > > > range of 768MHz to 1536MHz. >> > > > >> > > > The clock source sys_pll_div16, being one of the GEN clock parents, >> > > > plays a crucial role and cannot be tagged as "optional". Unfortunately, >> > > > it was not implemented earlier due to the cpu clock ctrl driver's >> > > > pending status on the TODO list. >> > > >> > > It's fine to not mark it optional in the binding, but it should be >> > > optional in the driver as otherwise backwards compatibility will be >> > > broken. Given this is an integral clock driver, sounds like it would >> > > quite likely break booting on these devices if the driver doesn't treat >> > > syspll_in as optional. >> > > A lesson perhaps in describing the hardware entirely, even if the >> > > drivers don't make use of all the information yet? >> > >> > Yes, it's definitely the right lesson for me. However, without syspll or >> > syspll_in, we cannot utilize CPU power management at all. >> >> That's the status-quo, right? The incorrect dts would continue to not >> support CPU power management and the new one with the correct description >> would? > > Hmmm, correct. Okay, I see, I will support sys_pll as optional > connection :) Again, the way controller is written, all inputs are actually optional. The controller does not error out if an input is missing, it behave as if the input is disconnected -- Jerome
