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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux