Re: [PATCH 1/5 v11] arm: omap: usb: ehci and ohci hwmod structuresfor omap4

[Paul Walmsley]

Hello Ming,

On Wed, 28 Sep 2011, Ming Lei wrote:

> On Fri, Sep 23, 2011 at 7:31 AM, Paul Walmsley <paul@xxxxxxxxx> wrote:
> 
> > 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.
> 
> I am a bit confused about you comment on "main_clk".
> 
> >From hwmod related source code, main_clk is the function clock
> of one module(hwmod), such as: on omap4, for uart3, main_clk is
> uart3_fck.
> 
> But from[1] and [2] of omap4 PRM, we can find that interface clock
> is required to provide register access instead of function clock.

As far as I know, the two cases that you cite are basically documentation 
bugs in the TRM.  In my experience, for IP blocks on OMAPs, a functional 
clock has to be enabled in order for register accesses to succeed.  It's 
possible there may be a few odd IP blocks that behave differently, but I 
can't think of any off the top of my head.

There are three cases that I've come across that might be interesting to 
you.

The first involves IP blocks that use their interface clock as their 
functional clock, such as the MAILBOXES IP block.  In this case, there is 
no separate functional clock that is needed for register accesses to 
complete, and therefore the main_clk should be the interface clock.

The second case involves IP blocks that can receive functional clocks from 
an off-chip source (i.e., not via a PRCM-controlled clock), such as the 
McBSP IP block.  For these IP blocks, it could be that register accesses 
might still succeed even if the module's PRCM-provided functional clock is 
off.  I haven't tested this personally.

The third case involves IP blocks with multiple functional clocks, such as 
the OMAP3 USBHOST subsystem.  What we found on OMAP3 was that only one of 
these two clocks needs to be enabled for register accesses to succeed.  
Some functional clocks might control parts of an IP block that have 
nothing to do with register access.

> This is a bit conflictive with what you description, so could you
> give a further comments about main_clk, function clock and interface
> clock?

I don't know why there are these documentation discrepancies.  I can 
guess, but probably I'd better not :-)  Hope the above helped.

> [1], 23.3.4.2 Clock Configuration
> 	Each UART uses a 48-MHz functional clock for its logic
> 	and to generate external interface signals. Each UART
> 	uses an interface clock for register accesses.
> 
> [2], 3.1.1.1.1 Module Interface and Functional Clocks
> 	The interface clocks have the following characteristics:
> 	• They ensure proper communication between any module/subsystem
> 	and the interconnect.
> 	• In most cases, they supply the system interconnect interface
> 	and registers of the module.

regards,

- Paul