Hi Tony, On Thu, 29 Feb 2024 09:06:26 +0200 Tony Lindgren <tony@xxxxxxxxxxx> wrote: > * Tony Lindgren <tony@xxxxxxxxxxx> [240214 05:41]: > > * Andreas Kemnade <andreas@xxxxxxxxxxxx> [240213 23:11]: > > > On Tue, 13 Feb 2024 12:56:40 +0200 > > > Tony Lindgren <tony@xxxxxxxxxxx> wrote: > > > > > > > Hi all, > > > > > > > > This series updates the clksel clocks to use the standard reg property > > > > instead of ti,bit-shift. > > > > > > > > I'd like to apply these before we make further use of the clksel clocks > > > > to reduce the dtb check warnings. > > > > > > > > > > hmm, we still have ti,bit-shift if these clocks are not used below a ti,clksel. > > > Just wondering, can we completely deorbit ti,bit-shift if we used #address-cells = <2>; > > > in those cases? I wait a bit with further txt->yaml conversions until > > > this is settled. > > > > No need to wait on the yaml conversion I think :) How about just tag the > > ti,bit-shift property as deprecated? And add a comment saying it is only > > needed for the remaining unconnected clocks. > > > > Eventually we can move all the component clocks under clksel clocks, or the > > related clock such as the dpll clock for the clkdcoldo clocks. > > Oh and yes, using #clock-cells = <2> would be nice eventually :) I think > the clkcel binding already supports that. But that still leaves the issue > of unconnected composite clocks.. I'm pretty sure they all have some real > parent like clksel for dpll though. > > If you had some good idea in mind for the #address-cells = <2> for the > remaining unconnected composite clocks maybe clarify it a bit. > I was just wondering whether we could do reg = <register bit> then. Regards, Andreas
