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.
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
