On Tue, 2011-06-28 at 10:14 +0200, Cousson, Benoit wrote:
> On 6/28/2011 8:56 AM, Valkeinen, Tomi wrote:
> > On Mon, 2011-06-27 at 18:33 +0200, Benoit Cousson wrote:
> >> Hi Paul,
> >>
> >> Here is the second part of the modulemode series.
> >> The goal here is to do the cleanup on the clock nodes and PRCM macros
> >> that are not needed anymore by the hwmod data.
> >> Some macros are still needed because of clock data. It should be removed
> >> once the clock data will be cleaned.
> >>
> >> Moreover, in order to get rid of static clkdev, omap_device is trying to
> >> create dynamically an "fck" alias if a main_clk is defined in hwmod data.
> >>
> >> As usual, because of drivers non-adapted to pm_runtime, some temp hacks
> >> are needed for both MMC and timer1.
> >> If the drivers are fixes before these series, these temp patches could be
> >> dropped.
> >>
> >> The series is based on for_3.0.1/5_hwmod_clkdm_fixes and tested
> >> on OMAP4430 ES2.1 + SDP. It should not affect OMAP2&  3, but some testing
> >> are definitively needed.
> >>
> >> The patches are available here:
> >> git://gitorious.org/omap-pm/linux.git for_3.0.1/6_hwmod_modulemode
> >
> > I tested the branch on Blaze, but DSS doesn't work as the clock aliases
> > have changed, leading to crash. And as only OMAP4 clocks/hwmods were
> > changed, this makes me believe OMAP2/3 DSS would still work.
> 
> Mmm, so what alias are you using today? The one from the opt_clock role?
> In theory, that main_clock should be named "fck" and the secondary or 
> optional clocks will have the name from the role.

You can see the clocks from drivers/video/dss/dss.c:dss_get_clocks(). It
currently gets these via the clkdev aliases:

- ick
- fck
- sys_clk
- tv_clk
- video_clk

> > I think the OMAP2/3/4 changes need to be done in sync, and at the same
> > time keeping the peripherals working.
> 
> Sure, but first we need to figure out what will be the proper clock alias.

My current pm_runtime patch set removes the omapdss clock aliases from
arch/arm/mach-omap2/clock44xx_data.c, as the driver uses the opt-clock
names. Isn't that correct way?

The opt-clocks that my patch set gets are:

- dss_clk
- sys_clk
- hdmi_clk
- rfbi_iclk
- tv_clk
- tv_dac_clk

Additionally these are used to configure the clk rates:
- dpll4_m4_ck
- dpll_per_m5x2_ck

The "dss_clk" opt-clock is a bit of an odd-ball. The same clock is used
as a main-clk and an opt-clock. The driver uses the clock to change the
clock rates. If the driver can get the main-clock with some built-in
alias, like "fck", then this opt-clock is not needed. But I wasn't aware
of such a method.

You can see how the are setup in the following patches:

  OMAP4: HWMOD: Modify DSS opt clocks
  OMAP3: HWMOD: Add DSS opt clocks
  OMAP2420: HWMOD: Add DSS opt clocks
  OMAP2430: HWMOD: Add DSS opt clocks

Then, after the main runtime PM patch, there's a small cleanup:

  OMAP4: HWMOD: Remove unneeded DSS opt clocks
  OMAP4: CLKDEV: Remove omapdss clock aliases

 Tomi


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to