From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: "Cousson, Benoit" <b-cousson@ti.com>, Paul Walmsley <paul@pwsan.com>
Cc: "Semwal, Sumit" <sumit.semwal@ti.com>,
"Taneja, Archit" <archit@ti.com>,
linux-omap <linux-omap@vger.kernel.org>
Subject: OMAP4 DSS clock setup
Date: Wed, 30 Mar 2011 09:48:53 +0300 [thread overview]
Message-ID: <1301467733.2333.83.camel@deskari> (raw)
Hi Benoit, Paul,
I've been discussing with Sumit and Archit to understand how the DSS
clocks are set up on OMAP4. I think I now have some idea how things
work, but I'm still at loss why things are the way they are.
So, if I look at OMAP4 TRM, Figure 10-4 DSS Clock Tree, there are two
clocks in PRCM block that are relevant to this discussion: DSS_L3_ICLK
and DSS_FCLK. To my understanding DSS_L3_ICLK is not really
controllable, but it is affected by MODULEMODE bit.
Then we have two relevant clocks defined in clock44xx_data.c: dss_fck
and dss_dss_clk. dss_fck controls the MODULEMODE bit, and dss_dss_clk is
the TRM's DSS_FCLK.
Was that correct?
If so, from DSS driver's perspective, the dss_fck sounds very much like
an interface clock (it's always needed when DSS is used) and dss_dss_clk
sounds very much like functional clock (it's always needed, except if
DSI PLL is used for DSS functional clock).
If "dss_fck" would control DSS_FCLK and "dss_ick" would control
MODULEMODE, they would be about the same as the clocks in OMAP2 and 3,
and we wouldn't need any omap4 spesific trickery in the DSS driver.
("dss_dss_clk" wouldn't be needed).
Why are the clocks set up in this strange fashion?
Tomi
next reply other threads:[~2011-03-30 6:48 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-30 6:48 Tomi Valkeinen [this message]
2011-03-30 9:32 ` OMAP4 DSS clock setup Cousson, Benoit
2011-03-30 11:03 ` Tomi Valkeinen
2011-03-30 12:12 ` Cousson, Benoit
2011-03-30 12:58 ` Tomi Valkeinen
2011-03-30 13:21 ` Cousson, Benoit
2011-03-31 6:42 ` Archit Taneja
2011-03-31 9:36 ` Cousson, Benoit
2011-03-31 7:34 ` Tomi Valkeinen
2011-04-02 2:12 ` Paul Walmsley
2011-04-04 6:53 ` Tomi Valkeinen
2011-04-06 9:09 ` Tomi Valkeinen
2011-04-07 19:27 ` Paul Walmsley
2011-04-08 5:51 ` Tomi Valkeinen
2011-04-08 14:55 ` Paul Walmsley
2011-04-11 9:05 ` Tomi Valkeinen
2011-04-11 18:20 ` Paul Walmsley
2011-04-12 7:17 ` Tomi Valkeinen
2011-04-08 15:36 ` Cousson, Benoit
2011-04-08 16:35 ` Tomi Valkeinen
2011-04-08 16:28 ` Paul Walmsley
2011-04-11 8:56 ` Tomi Valkeinen
2011-04-11 16:05 ` Paul Walmsley
2011-04-11 21:06 ` Cousson, Benoit
2011-04-11 21:29 ` Cousson, Benoit
2011-04-12 7:29 ` Tomi Valkeinen
2011-04-08 14:23 ` Cousson, Benoit
2011-04-08 16:50 ` Paul Walmsley
2011-04-11 9:09 ` Tomi Valkeinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1301467733.2333.83.camel@deskari \
--to=tomi.valkeinen@ti.com \
--cc=archit@ti.com \
--cc=b-cousson@ti.com \
--cc=linux-omap@vger.kernel.org \
--cc=paul@pwsan.com \
--cc=sumit.semwal@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.