On 06/18/2014 05:14 PM, Thierry Reding wrote:
On Wed, Jun 18, 2014 at 04:09:06PM -0600, Stephen Warren wrote:
On 06/18/2014 04:03 PM, Thierry Reding wrote:
...
From what I remember, Mike was fairly strongly opposing the idea of virtual clocks, but what you're proposing here sounds like it would assume the existence of virtual clocks. clk_set_rate() per client doesn't work with the current API as I understand it.
Or perhaps what you're proposing isn't about the individual clocks at all but rather about a mechanism to express constraints for a set of clocks?
This doesn't have anything to do with virtual clocks. As you mention, it's just about constraints.
One user of clock "cpu" wants min rate 216MHz. Another wants max rate 1GHz. cpufreq will request some rate between the 2, or be capped to those limits. These set of imposed constraints would need to be stored per client of the clock, not per HW clock, since many clients could set different max rates (e.g. thermal throttle 1.5GHz due to temperature, CPU policy 1GHz due to the user selecting low CPU power, etc.)
Similarly for audio, of there are N clients of 1 clock/PLL, and they each want the PLL to run at a different rate, something needs to detect that and deny it.
I'm wondering how this should work with the current API. Could the clock core be modified to return a per-client struct clk * that references the hardware clock internally? Or do we need to add a new API?
I would assume the we can just change struct clk and hide the details from any driver. Hopefully only clock-core and clock-drivers would need any changes.