Hi Tomi,
On Mon, 4 Apr 2011, Tomi Valkeinen wrote:
> On Fri, 2011-04-01 at 20:12 -0600, Paul Walmsley wrote:
>
> > 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()?
>
> Hmm, right. I guess no other HW module has clock setups like this?
I think McBSP can have an optional main functional clock. So something
like that should be usable for that case too. (In the McBSP case, the
optional clock isn't controlled by the PRCM, it's controlled by the SCM,
but that doesn't really matter to the hwmod code.)
> Currently DSS can use clk_enable/disable() for the system fclk when its
> using DSI PLL for the fclk. So omap_hwmod_{release,require}_system_fclk
> sounds like a simple solution to this.
OK. The only problem with those functions (actually
omap_device_{release,require}_system_fclk()) is that they will need to be
called through platform_data function pointers for now. Maybe it is
possible to handle something like this simply with the clock framework
also.
> Not directly related, but something I've been wondering about is how to
> abstract the DSI/HDMI PLLs in DSS. What do you think, would it be
> possible/worth it to create struct clks for the clocks coming out of
> those PLLs? These would, of course, be DSS internal clks. I'm not very
> familiar with the clock framework, so I don't really have any idea what
> this would require and what would be the pros and cons.
Yes, I think it would be good to try to implement the entire DSS clock
tree in the clock framework. One change to the clock code that we know
we'll need is to put a hwmod pointer in the struct clk which tells the
clock code that the hwmod needs to be enabled in order to access the
clock's registers. Right now, the clock code assumes that all of the
clock registers are accessible, all of the time.
- Paul
--
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
