On 17/09/13 12:38, Mike Turquette wrote: > Quoting Archit Taneja (2013-09-17 00:06:28) >> 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 <archit@xxxxxx> > > 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. Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
