Hi
On Thu, 22 Sep 2011, Cousson, Benoit wrote:
ADDR_TYPE_RT is mainly use for sysconfig access inside hwmod core today, so
why should we use it in this case?
Just for consistency, since the flag isn't defined to be
SYSCONFIG-specific.
That way, if there's another need -- other than SYSCONFIG access -- to
identify the chunk of address space that's used for register access, we
won't have to dig through and possibly repatch the hwmod data, just
because some people didn't want to follow the rule.
If the flag was simply defined to be SYSCONFIG-specific, then you're
right, it wouldn't be needed.
To be honest, I've been confused with that flag for some time :-)
* ADDR_TYPE_RT: Address space contains module register target data.
Maybe that's my English, but what does "register target data" mean exactly?
The name comes from the L3 section of the 34xx TRM - see for example
section 9.1.1 "Terminology" of the rev ZR TRM. The L3 has several address
space sections, and whoever wrote that text -- Sonics? -- called the one
with the L3's own internal registers the "register target." And I was
looking for a name that I did not have to make up, so I personally
wouldn't have to defend the name ;-)
What was the intent? Providing a way to identify some register vs memory
space?
As you suggest, the original impetus for the flag was to identify which
chunk of address space needs to be mapped by the hwmod code for SYSCONFIG
accesses to work. On current OMAPs, this seems to be the same thing as
identifying the IP block's primary register area for every module with
SYS* and REVISION registers. And I probably thought at the time that
specifying the IP block's main register mapping seemed more useful and
generally applicable than designating where the SYSCONFIG register was.
Hence the current definition.
Regarding main_clk, I do not think that some internal IPs like ohci/ehci
should have a main_clk, since this is not visible at that level.
Do you not agree that every IP block that contains sequential logic on
current and foreseeable future SoCs must have some clock signal to drive
that logic?
The idea of the main_clk was not intended to be PRCM or OCP or even
OMAP-specific. It's just intended to represent a clock that is used to
drive the register logic inside the IP block. Therefore it must be
enabled before any register access may occur. Even if clock gating is
handled by some higher-level interface (e.g., at the IP block level), the
main_clk has a rate, so it also implies an upper limit on how quickly
register operations can occur. I suppose that all of the IP block's
clocks could be "optional clocks," but we know that every IP block with
registers requires at least one clock to work, and that should be the
main_clk.