16.12.2019 18:24, Peter De Schrijver пишет: > On Mon, Dec 16, 2019 at 05:11:32PM +0200, Peter De Schrijver wrote: >> External email: Use caution opening links or attachments >> >> >> 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. >> > > Given the audio driver needs to change anyway, we can indeed use 1 clock > per PMC clk_out_ rather than 2 as we have today. As this models the hw > slightly better, I think we should do that as you suggested. > > Peter. > Okay, let's try and see how it will go. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
