Re: [PATCH 4/7] OMAP2+: powerdomain: add voltage domain lookup during register

["Cousson, Benoit" <b-cousson@ti.com>]

I knew you will answer that one :-)

On 3/22/2011 11:08 PM, Paul Walmsley wrote:
> Hi Benoît,
>
> On Tue, 22 Mar 2011, Cousson, Benoit wrote:
>
>> On the other hand not every clock belong to a clockdomain, that's why we
>> have clock without clockdomain on OMAP. A clockdomain is a just group of
>> IPs that share the same interface clock.
>
> PRCM clockdomains also include functional clocks.  See for example the
> OMAP4 Public TRM Rev. O Section 3.1.1.1.3 "Clock Domain" ('The clockdomain
> of CM_B is composed of two clocks: a functional clock (FCLK2) and an
> interface clock (ICLK1)', and also later, 'The PRCM module lets software
> check the status of the clock domain functional clocks').

True, but that does not change the definition of the clock domain (same 
paragraph):
"A clock domain is a group of modules fed by clock signals controlled by 
the same clock manager in the PRCM module (see Figure 3-2)."

My point was that a clock domain is related to modules that share some 
clocks.
So yes, a clock domain will contains modules and their related iclk and 
fclk. But that does not means that every clocks will belong to a 
clockdomain.
All the non leaf clocks will not have any clock domain since they will 
not be attached to any module directly.

> Both the TRM and the OMAP4 functional specification clearly link PRCM
> clockdomain idle management to the state of the clockdomain's functional
> clocks.  See for example OMAP4 Public TRM Rev. O Table 3-11 "Clock Domain
> Clock States" ('INACTIVE: ... Every optional functional clock in the clock
> domain is gated.')

That just means that each clock that supplies a module must be idled in 
order to allow the clock domain to transition.
The clock domain FSM is using both iclk and fclk state to trigger the 
domain transition, but that same clock could be used in another clock 
domain too.

> Beyond the PRCM, the Linux-OMAP clockdomain code is not only concerned
> with PRCM-controllable clockdomains.  It is intended to be a generically
> useful way to connect clocks to the powerdomain and voltagedomain that the
> clock exists in, even if there are no explicit PRCM registers associated
> with the clockdomain.  These "powerdomains" and "voltagedomains" also may
> not be directly PRCM controllable.

In that case, you cannot call that clockdomain anymore since this is not 
the proper definition used by the PRCM. If you do not have a module, you 
cannot have a clockdomain.

OMAP4 partitioning is following this hierarchy: module < clockdomain < 
powerdomain < voltagedomain < device.
The clocks are not part of the hierarchy and for a good reason, the can 
be shared across the whole device.

> Every clock that is in the Linux-OMAP clock tree should have a clockdomain
> associated with it.

Mmm... What domain will you use for sys_clk or 32k_clk? or for any DPLL 
or HS divider?
And what for?

I know that the clockdomain name is confusing, but why do you want to 
change its definition?

Benoit

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