Hi Murthy,
On 2/16/2011 9:57 AM, Murthy, Raghuveer wrote:
On Monday 14 February 2011 09:32 PM, Valkeinen, Tomi wrote:
Hi,
On Thu, 2011-02-03 at 07:56 -0600, Murthy, Raghuveer wrote:
- Adding dss_feature for DPLL fclk
- Enabling pixel clock generation for DPI interface
A bit more description what the patch set is about would be nice. Also,
one line patch descriptions are a bit too short for anything else than
the most trivial patches.
Now to the actual patch contents:
DPLL is not a feature of the DSS, and I don't think we should have
dss_features for that. In fact, I think the whole DPLL code should be
moved from DSS to somewhere under arch/arm.
In a perfect world DSS could just set the dss_fck to whatever rate it
requires, but as the clock rate can only be set to certain rates, and we
need a precise control for the rate, some other method has to be in
place.
I am not sure what this method should be. Perhaps there is something in
the clock framework that could help us here, or perhaps we just need a
bunch of function pointers in the DSS's platform data which can be used
to configure the clock.
Tomi
Hi Paul, Benoit,
DPLL_PER post divider output for DSS core functional clock can be
changed in OMAP3xxx and OMAP4430, based on the requested pixel clock for
a given display resolution.
Additionally, the number of dividers available for DPLL_PER post
dividors for DSS has increased from 16 to 32, from OMAP3630 onwards.
Both these are added as dss_features.
Given the above comments from Tomi, can the same be included as part of
the clock framework?
Yes, I do agree with Tomi, this code has nothing to do in the DSS driver.
We do have similar issue with clock rate that can be changed by 2
successive clock nodes (DPLL and HS divider for example).
But it might be tricky to handle in a generic manner. We need to tie
these two clock nodes and thus ensuring that there is no other
descendant for the parent node and then force a parent rate change if
the clock rate cannot be achieve by the descendant.
Maybe Paul has some idea about that.
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
