Hi Tomi, Benoît, et al,
On Wed, 30 Mar 2011, Tomi Valkeinen wrote:
> Currently we have these aliases for OMAP4:
>
> "dss_clk" -> dss_dss_clk
> "fck" -> dss_fck
> "ick" -> dummy_ck
>
> If that would be changed to:
>
> "fck" -> dss_dss_clk
> "ick -> dss_fck
>
> The driver would work the same way for all OMAPs.
This looks reasonable to me, and seems to match the TRM's Figure 10-4 "DSS
Clock Tree".
The current OMAP4 clock data name "dss_fck" is just kind of a fake name
for that clock in the OMAP4 context.
> Anyway. To get things working for rc2 (DSS currently crashes due to not
> enabling dss_clk) we need to either:
> 1) Change the clock aliases as above
> 2) Add something like Sumit's patch (attached) to handle dss_clk. While
> the patch is not that complex, it feels rather hacky.
Yeah, that patch looks like a hack to me, especially something like
this:
+ if (pdata->opt_clock_available("dss_clk")) {
Based on the E-mail thread so far, I'd say that changing the clock aliases
is the way to go for right now. The clock aliases are not hardware data;
they just control how the clock hardware is mapped to the drivers.
Of course, at some point soon, those clock aliases are going to go away.
But hopefully you all will have converted the driver over to PM runtime at
that point.
Once that happens, there's another problem: omap_hwmod_enable() is defined
that the hardware registers should be accessible by the MPU after it
completes. So by that definition, the hwmod code should be
enabling/disabling that dss_clk clock too when it enables/idles/shuts down
the hwmod. Probably we'd need to mark that struct omap_hwmod_opt_clk with
some flag. Then we'd need some kind of way for the DSS to tell the hwmod
code whether it is or isn't reliant on the PRCM-provided functional clock
for its internal functional clock. Maybe something like
omap_hwmod_{release,require}_system_fclk()?
- Paul
