On Mon, Dec 16, 2019 at 05:23:23PM +0300, Dmitry Osipenko wrote: > >> Could you please clarify what do you mean by the "existing users"? > >> AFAIK, nothing in kernel uses mux clocks. > > > > The DT clk bindings allow for parent initialization, so it's certainly > > possible there are some DTs which rely on this. We promised to never > > break the bindings, which changing to 1 clock would do. > > What about this variant: > > 1. Keep the old CaR code in place. > > 2. Make CaR driver to scan whole device-tree for the legacy PMC clocks. > > 3. If legacy clock is found, then register PMC clocks from CaR. > > 4. If legacy clocks are not found, then don't register PMC clocks from > CaR. > > 5. Add clocks support to the PMC driver and only register them if > legacy clocks are not registered by CaR. > > Now both old and new DTBs can co-exist and work, everyone happy. That seems even more work.. Today the only upstream user is audio. Currently these clocks are setup by the CAR clock driver. However as they will move to the PMC driver, this mechanism cannot be used. Hence the plan is to modify the audio driver to check for the PMC clocks in DT and if they are not available use the CAR clocks as fallback. The whole reason the clocks move to the PMC driver, is that when PMC becomes secure, all accesses have to go via an SMC. Given that we don't want SMCs all over the Tegra drivers, it's a good opportunity to move the PMC clock handling into the PMC driver. PMC can be secure with both 'new' and old DTs, so just registering the PMC clocks in the CAR driver if legacy clocks are found in the DT, won't always work. Peter. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
