RE: [PATCH 1/3] clk: introduce omap_clk_associate

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> >> Wasn't that one of the main features of the clock FW, when it was
> >> designed?
> >
> > Yes. But we adding separate ick and fck during omap2420 confused
> > that.
>
> Why this was originally done? I mean we have possibility to autogate
> interface clocks. AFAIK those could be just fine be enabled on boot and
> let
> the hw to take care of them.

Autogating only happens when you get all preconditions met.  For much of OMAP2 time this was not the case.  For l-o I’m not sure today if it is yet the case.  For OMAP3 this has been a target.

You do need selective control for some modules.

The ideal should be to just control F and let I be auto handled.  In retrospect something like v-clock's which handle the set for a module, but also have explicit access when its needed to individual ones.  Perhaps a v clock with separate id's for individual clocks...  Some of this may be good for next gen omaps.

Regards,
Richard W.
��.n��������+%������w��{.n�����{�������ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux