在 2022-07-12星期二的 19:57 +0800，Icenowy Zheng写道： > 在 2022-04-23星期六的 21:12 -0500，Samuel Holland写道： > > On 4/22/22 10:41 AM, icenowy@xxxxxxxxxxx wrote: > > > From: Icenowy Zheng <icenowy@xxxxxxx> > > > > > > Allwinner R329 has two CCUs, one in CPUX and another in PRCM. > > > > > > Add support for them. > > > > > > Signed-off-by: Icenowy Zheng <icenowy@xxxxxxx> > > > > There is a typo in your commit title. = should be -. > > > > Thanks for updating the driver to use .fw_name and be loadable as a > > module. All > > of those changes look good. > > > > There are still some missing clocks here compared to the BSP, and a > > couple of > > other minor issues. Please see my earlier review: > > > > https://lore.kernel.org/linux-sunxi/99a74950-fdc0-ecfe-e5f0-ba4a7d8751f0@xxxxxxxxxxxx/ > > > > So far it's been consistent that any settable bits in the CCU > > registers actually > > do something. So I would expect all of those bits to have an index > > reserved in > > the binding, even if we do not model them. I want to avoid having > > to > > Sorry but I don't think it proper to reserve unclear bits, because > we're just allocating the numbers as a random sequence (in fact it's > the sequence that it gets implemented). > > Or consider a structural number scheme, in which a value can be > uniquely predicted by its name? Well by thinking a little further, I realized our current CCU DT binding is just based on implementation details of sunxi-ng drivers (for example, some intermediate clocks get a number too, just not exposed to the DT binding header). This continues to prove that reserving numbers is just needed at all, and the current way to make CCU DT bindings might be totally wrong. Maybe we should start to use reasonable slice numbers in the next CCU driver? > > > go back and > > add gates to the binding out-of-order later, like we are doing for > > H6. > > > > Regards, > > Samuel > > >
