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
