On Tue, Oct 16, 2012 at 11:28:27AM +0300, Peter De Schrijver wrote:
> >
> > There are two ways this could work:
> >
> > 1)
> >
> > All clocks needed could be represented in the node of that device (or
> > perhaps in the DC node?) For example, perhaps hdmi might contain:
> >
> > clocks = <&car TEGRA_CLK_PLL_D>
> > <&car TEGRA_CLK_PLL_D_OUT_0>
> > <&car TEGRA_CLK_HDMI>
> > ...;
> > clock-names = "pll_d", "pll_d_out_0", "hdmi", ...;
> >
> > That should work (I think) with pretty much no modification to the
> > current code, other than calling clk_get(dev, "hdmi") rather than
> > clk_get_sys(NULL, "hdmi").
> >
> > However, I'm not sure this is the best way or not; this still requires
> > the HDMI driver to implement all the clocking policy (e.g. is the HDMI
> > clock a child of PLL_D, PLL_C, PLL_P, ... and what rate should the
> > parent PLL be set to, etc.)
> >
> > For example, what if the clock frequency HDMI needs can be generated
> > by PLL_C, so we make PLL_C the parent of HDMI (so as to save power by
> > not running PLL_D, or to use PLL_D for a second display head), then
> > something else comes along and /has/ to use PLL_C. If the two childs'
> > frequency requirements are the same, everything is fine. If the two
> > child's frequency requirements are not compatible, we might need to
> > spin up PLL_D and reparent HDMI onto it. More complex scenarios are
> > possible where PLL_C needs to be reprogrammed, yet can be in a way
> > that supports both HDMI and some other requirement, so we only need to
> > temporarily move HDMI onto PLL_D, then reprogram PLL_C, then move HDMI
> > back to it and spin PLL_D down. All these decisions should be made
> > centrally in the Tegra clock driver, or at least some kind of
> > centralized policy management point, and not by the HDMI driver:
> >
>
> This assumes we can glitch free provide a new parent clock to eg. HDMI, I
> doubt the hardware can do that.
I think for starters it would be enough if the clock code was smart
enough to choose an appropriate parent. We could start thinking about
power optimizations later. I took a brief look at the current code and
it seems like all the information is already there, so we just need an
algorithm that figures out the proper parent that can provide the right
frequency and select it as parent in clk_set_rate() automatically. Such
an algorithm could be as simple as this:
if (current parent supports frequency) {
set parent frequency
} else {
foreach (parent clock) {
if (clock supports frequency)
select as new parent
}
if (no parent found)
abort
}
Checking for frequency support of a new parent would also involve
checking for conflicts with other children of that clock. For some
rudimentary power saving it should be enough to prefer already enabled
clocks when looking for a new parent, so that if a compatible match is
found no new clocks need to be enabled.
Does that sound reasonable?
Thierry
Attachment:
pgpXdU9wWLtIc.pgp
Description: PGP signature
