Re: [PATCH 02/11] omapdss: HDMI: create a HDMI PLL library

[Tomi Valkeinen <tomi.valkeinen@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 1656 bytes --]

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@ti.com>
> 
> 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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]