Re: [RFC PATCH 3/3] clk: tegra: Implement Tegra124 shared/cbus clks

[Thierry Reding]

On Tue, May 13, 2014 at 12:09:49PM -0600, Stephen Warren wrote:
> On 05/13/2014 08:06 AM, Peter De Schrijver wrote:
> > Add shared and cbus clocks to the Tegra124 clock implementation.
> 
> > diff --git a/include/dt-bindings/clock/tegra124-car.h b/include/dt-bindings/clock/tegra124-car.h
> 
> > +#define TEGRA124_CLK_C2BUS 401
> > +#define TEGRA124_CLK_C3BUS 402
> > +#define TEGRA124_CLK_GR3D_CBUS 403
> > +#define TEGRA124_CLK_GR2D_CBUS 404
> ...
> 
> I worry about this a bit. IIUC, these clocks don't actually exist in HW,
> but are more a way of SW applying policy to the clock that do exist in
> HW. As such, I'm not convinced it's a good idea to expose these clock
> IDS to DT, since DT is supposed to represent the HW, and not be
> influenced by internal SW implementation details.
> 
> Do any DTs actually need to used these new clock IDs? I don't think we
> could actually use these value in e.g. tegra124.dtsi's clocks
> properties, since these clocks don't exist in HW. Was it your intent to
> do that? If not, can't we just define these SW-internal clock IDs in the
> header inside the Tegra clock driver, so the values are invisible to DT?

I'm beginning to wonder if abusing clocks in this way is really the best
solution. From what I understand there are two problems here that are
mostly orthogonal though they're implemented using similar techniques.

The reason for introducing cbus clocks are still unclear to me. From the
cover letter of this patch series it seems like these should be
completely hidden from drivers and as such they don't belong in device
tree. Also if they are an implementation detail, why are they even
implemented as clocks? Perhaps an example use-case would help illustrate
the need for this.

As for shared clocks I'm only aware of one use-case, namely EMC scaling.
Using clocks for that doesn't seem like the best option to me. While it
can probably fix the immediate issue of choosing an appropriate
frequency for the EMC clock it isn't a complete solution for the problem
that we're trying to solve. From what I understand EMC scaling is one
part of ensuring quality of service. The current implementations of that
seems to abuse clocks (essentially one X.emc clock per X clock) to
signal the amount of memory bandwidth required by any given device. But
there are other parts to the puzzle. Latency allowance is one. The value
programmed to the latency allowance registers for example depends on the
EMC frequency.

Has anyone ever looked into using a different framework to model all of
these requirements? PM QoS looks like it might fit, but if none of the
existing frameworks have what we need, perhaps something new can be
created.

Thierry

Attachment: pgpVK5Nn85bqK.pgp
Description: PGP signature