On 6/28/2011 10:29 AM, Valkeinen, Tomi wrote:
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?
Yes, it is, but we need to take care of the name. The names are local to
the device, so previously I had to prefix with dss_ every clocks
affected to the dss_core. Since now, most of them are connected only to
the relevant hwmod, we can use alias like "fck" if the role of the clock
is the functional one.
The opt-clocks that my patch set gets are:
- dss_clk
So that one was the DSS PRCM modulemode and will not exist anymore.
- sys_clk
That one is OK.
- hdmi_clk
I guess that one should be name "fck", since only the HDMI hwmod will
use it.
- rfbi_iclk
Should be named "ick", but I'm not even sure that one is needed.
- tv_clk
- tv_dac_clk
Why do you have two clocks for the tv? I can only see the dss_tv_fclk in
the spec.
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.
Maybe because I've just introduced it :-)
OMAP: omap_device: Create clkdev entry for hwmod main_clk
It was not done like that before. Only the opt_clk were used, because
the main_clk was not relevant. With that series, the main_clk represents
real clock, and thus can be exposed with "fck" alias.
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
