Quoting Maxime Ripard (2019-08-21 05:24:36) > On Tue, Aug 20, 2019 at 08:02:55AM -0500, Samuel Holland wrote: > > On 8/20/19 2:11 AM, Maxime Ripard wrote: > > > So I'm not really sure that we should do it statically this way, and > > > that we should do it at all. > > > > Do you have a better way to model "firmware uses this clock behind the scenes, > > so Linux please don't touch it"? It's unfortunate that we have Linux and > > firmware fighting over the R_CCU, but since we didn't have firmware (e.g. SCPI > > clocks) in the beginning, it's where we are today. > > > > The AR100 clock doesn't actually have a gate, and it generally has dependencies > > like R_INTC in use. So as I mentioned in the commit message, the clock will > > normally be on anyway. The goal was to model the fact that there are users of > > this clock that Linux doesn't/can't know about. > > Like I said, if that's an option, I'd prefer to have protected-clocks > work for everyone / for sunxi. > Yes. Use protected-clocks to indicate what shouldn't be touched by the kernel. It's not super easy to make it "generic" right now, but I suppose we can work the flag into the core framework more so that we still register the clks but otherwise make the 'clk_get()' operation fail on them somehow and the disable unused operation skip them. I just took the easy way out for qcom for the time being and didn't register them from the driver.
