From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Fabio Estevam <festevam@gmail.com>
Cc: devel@driverdev.osuosl.org, Sascha Hauer <kernel@pengutronix.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
DRI mailing list <dri-devel@lists.freedesktop.org>,
Shawn Guo <shawn.guo@freescale.com>
Subject: Re: [PATCH] imx-drm: imx-hdmi: fix hdmi hotplug detection initial state
Date: Tue, 10 Jun 2014 18:04:57 +0100 [thread overview]
Message-ID: <20140610170457.GA7877@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <20140610161421.GA7287@n2100.arm.linux.org.uk>
On Tue, Jun 10, 2014 at 05:14:21PM +0100, Russell King - ARM Linux wrote:
> On Tue, Jun 10, 2014 at 04:13:06PM +0100, Russell King - ARM Linux wrote:
> > where 'M' is the IPU DI clock muxer. However, we're currently setting
> > this up as:
> >
> > LM --+---------------- LDB serial
> > `- /7 -+-------- LDB DI clock
> > IPM --- /N ---- IM --- IPU DI clock
> >
> > and hoping that the LDB and IPU DI clocks are appropriately synchronised.
>
> I've just found that we do indeed do this - but there's nothing to
> switch the configuration back when the LDB is no longer using a
> particular DI.
>
> Also, I'm having a hard time working out why we have the LDB being
> given all sorts of clocks...
>
> LM --+----------------- LDB serial (clks 33, aka di0_pll)
> `- /7 -+--------- LDB DI clock (clks 135, aka di0)
> `- IM --- IPU DI clock (clks 39, aka di0_sel)
>
> The LDB is given all of these to play with, including reprogramming
> the IM, and there's nothing which ever programs IM to anything but
> the LDB DI clock once it's set there.
*Sigh*... is the clock tree represented in Linux even correct?
--|\
--| |
--| |------------------+-----------------------------------------
--| | ^ ldb_di0_sel |
--|/ (clks 33) |
`-- /3.5 ---- /2 ------------------ G -+--
^ ^ ldb_di0_podf | ^ ldb_di0
ldb_di0_div_3_5 |
.----------------------'
|
'------|\
(ldb_di1)------------| |
(ipp_di0)------------| |--------- G ----
(ipp_di1)------------| | ^ ^ ipu1_di0
(ipu1_di0_pre)------------|/ ipu1_di0_sel
This diagram is drawn from the code in clk-imx6.c, and it does not
agree with what is in the SoC manuals - this is the representation
redrawn from the manuals:
--|\
--| |
--| |------------------+---------------------------------- G ----
--| | ^ ldb_di0_sel | ^ ldb serial
--|/ (clks 33) |
`-- /3.5 ---- /2 -----------------+-------
^ ^ ldb_di0_podf | ^ ldb di
ldb_di0_div_3_5 |
.-----------------'
|
'------|\
(ldb_di1)------------| |
(ipp_di0)------------| |--------- G ----
(ipp_di1)------------| | ^ ^ ipu1_di0
(ipu1_di0_pre)------------|/ ipu1_di0_sel
The difference is, there is no clock gate between the LDB DI clock and
the /7 divider, but there is a clock gate on the LDB serial clock.
In another location, the iMX6QDL manual suggests that it may be more
like this:
--|\
--| |
--| |----------- cg ---+-----------------------------------------
--| | ^ ldb_di0_sel | ^ ldb serial
--|/ (clks 33) |
`-- /3.5 ---- /2 -----------------+-------
^ ^ ldb_di0_podf | ^ ldb di
ldb_di0_div_3_5 |
.-----------------'
|
'------|\
(ldb_di1)------------| |
(ipp_di0)------------| |----------------
(ipp_di1)------------| | ^ ^ ipu1_di0
(ipu1_di0_pre)-- cg ------|/ ipu1_di0_sel
although "cg" is not defined what it is. Another place seems to
confirm the above diagram, saying that the "ldb_di0_clk_enable"
gating bits controls both "ch_0_serial_clk" (presumably the
ldb serial clock) and "di_0_clk_nc" (presumably the ldb di clock.
If that's correct "cg" refers to the clock gating via the CCM_CCGR
registers, which appear in the CCM clock tree diagram under LPCG.
So... I wonder which one of these three is actually the right one...
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
next prev parent reply other threads:[~2014-06-10 17:05 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-06 13:56 [PATCH] imx-drm: imx-hdmi: fix hdmi hotplug detection initial state Russell King
2014-06-06 14:06 ` Greg Kroah-Hartman
2014-06-09 13:44 ` Fabio Estevam
2014-06-09 14:06 ` Russell King - ARM Linux
2014-06-09 14:29 ` Fabio Estevam
2014-06-09 14:33 ` Shawn Guo
2014-06-09 15:19 ` Fabio Estevam
2014-06-09 17:49 ` Russell King - ARM Linux
2014-06-09 18:15 ` Fabio Estevam
2014-06-09 18:38 ` Fabio Estevam
2014-06-09 18:47 ` Fabio Estevam
2014-06-09 20:09 ` Russell King - ARM Linux
2014-06-09 21:03 ` Fabio Estevam
2014-06-10 12:58 ` Fabio Estevam
2014-06-10 13:32 ` Fabio Estevam
2014-06-11 8:17 ` Russell King - ARM Linux
2014-06-11 15:34 ` Philipp Zabel
2014-06-16 14:13 ` Fabio Estevam
2014-06-16 21:49 ` Russell King - ARM Linux
2014-06-10 15:13 ` Russell King - ARM Linux
2014-06-10 16:14 ` Russell King - ARM Linux
2014-06-10 17:04 ` Russell King - ARM Linux [this message]
2014-06-10 17:36 ` Fabio Estevam
2014-06-09 19:29 ` Russell King - ARM Linux
2014-06-09 19:29 ` Russell King - ARM Linux
2014-06-10 18:54 ` Tim Harvey
2014-06-10 19:03 ` Fabio Estevam
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=20140610170457.GA7877@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=devel@driverdev.osuosl.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=festevam@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=kernel@pengutronix.de \
--cc=shawn.guo@freescale.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).