dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
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 17:14:21 +0100	[thread overview]
Message-ID: <20140610161421.GA7287@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <20140610151306.GZ23430@n2100.arm.linux.org.uk>

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.

Not only does this feel horribly unclean from the DT perspective, but
it's also a horrid violation of reasonable layering.  What if we wanted
to fix this by adding control of di0_sel to the HDMI interface too?
We then need to list yet again the IPU DI clock and the desired input
clock there, and make the imx-hdmi code aware of that.

Wouldn't it be better to have the ipuv3-crtc, or even the IPU DI code
be in control of its external clock mux, and request the IPU DI code
to select a particular input clock?  In other words, have one central
place where the IPU DI clock is controlled, rather than ending up with
it spread through lots of different sub-drivers?

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

  reply	other threads:[~2014-06-10 16:14 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 [this message]
2014-06-10 17:04                       ` Russell King - ARM Linux
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=20140610161421.GA7287@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).