ccf: where to put constraints?

[Sören Brinkmann]

On Mon, 2014-02-24 at 03:05PM -0800, Mike Turquette wrote:
> Quoting Sören Brinkmann (2014-02-24 13:21:58)
> > Hi Wolfram,
> > 
> > On Mon, 2014-02-24 at 09:10PM +0100, Wolfram Sang wrote:
> > > Hi,
> > > 
> > > Where do I put constraints when using the CCF? I have a CPU and GPU
> > > clock derived from the same PLL. Both clocks have their own divider.
> > > Now, there is the additional constraint that the CPU clock must not be
> > > lower than the GPU clock. Do I add checks in the set_rate functions?
> > > Feels like the wrong layer, but not checking it and blindly relying on
> > > somebody else does not feel correct, too. How to do it best?
> > 
> > I don't know if it's the best or only way, but so far, I did things like
> > that with clock notifiers.
> > 
> > I.e. when a clock consumer needs to be notified about its input clock
> > being changed it registers a clock notifier. In that notifier callback
> > it then can react to the rate change. E.g. adjust dividers to stay
> > within legal limits or reject the change completely.
> 
> Yes, this is why the notifiers were created. A nice side effect of this
> is that the code can live outside your clock driver. Often times the
> clocks are quite capable of running at these speeds, but the problem is
> the IP blocks (CPU & GPU in Wolfram's case) would be out of spec. It is
> arguable that this logic does not belong in the clock driver but instead
> in some cpufreq driver or something like it.
> 
> The clock notifiers make it easy to put this logic wherever you like and
> you can even veto clock rate changes.

Right, that's how I have it. If a device driver needs to enforce some
policy on its clock, it implements a clock notifier callback.

The drawback though, as I see it, it makes interactions hard to
understand. With such a scheme, rate changes may fail and the cause is
not always obvious - often hidden really well. Usually all you get is a
message from the CCF that the rate change for clock <name> failed, but
if your notifier callback isn't verbose, you can search forever for the
cause of that failure.

On our internal repo I had it a few times that "bugs" get assigned to the
wrong piece. E.g. cpufreq, even though that works perfectly well and
correct on its own, but some other device enforced some policy through a
notifier.

	Sören