On Tue, Sep 17, 2013 at 3:02 AM, Tomi Valkeinen [off-list ref] wrote:

On 17/09/13 12:38, Mike Turquette wrote:

quoted

Quoting Archit Taneja (2013-09-17 00:06:28)

quoted

HDMI PLL is a block common to DSS in OMAP4, OMAP5 and DRA7x. Move the
existing PLL functions from ti_hdmi_4xxx_ip.c and hdmi.c to a separate file.
These funcs are called directly from the hdmi driver rather than hdmi_ip_ops
function pointer calls.

Add the PLL library function declarations to ti_hdmi.h. These will be shared
amongst the omap4/5 hdmi platform drivers. Remove the PLL function pointer ops
from the ti_hdmi_ip_ops struct. These will be shared amongst the omap4/5 hdmi
platform drivers and other libraries.

Signed-off-by: Archit Taneja <redacted>

Would be cool to see this convert to the common clock framework
implementation (include/linux/clk-provider.h). It appears that this PLL
only needs to support .enable, .disable and .recalc_rate callbacks at
first glance.

We've got a (very) long term plan to use CCF for DSS. And, if I'm not
mistaken, the PLL used for HDMI and DSI is the same as used elsewhere in
OMAP (I don't remember the PLL type name).

I think the main issue with DSS clocks is that we require as exact
clocks as possible, and there are multiple dividers/multipliers on the
clock path. So we iterate over the divider/multiplier ranges, trying to
find as good freq match as possible.

So if the clock path is composed from "black boxes", and we can only ask
for a certain frequency, and get back probably some other frequency, it
gets quite difficult to find good clock matches. Well, at least I
imagine so, I have not tried to implement that.

I hope that the existing CLK_SET_RATE_PARENT flag could help you get
the frequency you need; it causes a call to clk_set_rate(leaf_clk,
target_rate) to walk up the chain of parents and configure rates as
needed.

However I have been looking at standardizing a way to define clock
rate tables, possibly in DT. In many cases it is a board-specific
issue (e.g. different oscillators or other reference clocks that feed
into the SoC) and specifying rate tables in DT is one way to store
known-good configurations for complex clock subtrees.

Regards,
Mike

 Tomi