devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: "Heiko Stübner" <heiko@sntech.de>
Cc: Mark Rutland <mark.rutland@arm.com>,
	devicetree@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
	Pawel Moll <pawel.moll@arm.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	dianders@chromium.org, linux-rockchip@lists.infradead.org,
	dri-devel@lists.freedesktop.org, Yakir Yang <ykk@rock-chips.com>,
	Andy Yan <andy.yan@rock-chips.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 1/2] drm/bridge: dw-hdmi: support optional supply regulators
Date: Sat, 6 Jun 2015 00:10:58 +0100	[thread overview]
Message-ID: <20150605231058.GQ7557@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <23123577.mOoqGCAPdL@diego>

On Fri, Jun 05, 2015 at 02:16:40PM +0200, Heiko Stübner wrote:
> Hi Thierry
> 
> Am Freitag, 5. Juni 2015, 13:02:01 schrieb Thierry Reding:
> > If this is specific to the Rockchip implementation, shouldn't this go
> > into Documentation/devicetree/bindings/video/dw_hdmi-rockchip.txt? It
> > could then simply go into the Rockchip DRM tree.
> 
> actually, we determined that the supply names are universal to the IP
> (both in imx and rockchip and probably more if there are more users
> out there). Just Russell requested that we don't pollute the generic
> code until necessary, as it looks like the supply of those is somehow
> handled internally on the imx.

Why do you think it's universal?

Let's start from the beginning, before we create something that's not
representative of the hardware.

dw_hdmi actually drives two pieces of hardware - the HDMI transmitter,
and a separate hardware block, the HDMI phy.

There are at least two possible HDMI phys referenced in the iMX
documentation - there is one called HEAC which doesn't appear in iMX
devices afaik, and the one which does, which is a 3D phy.

The 3D phy top level IO diagram does have VPH and VP power supplies,
but it also has VP_FILT0, VP_FILT1, VP_FILT2, VP_FILT3 and GD labelled
up as "Power supply signals".  Where they connect to in the rest of the
system - or whether they are connected - is undocumented.

The HDMI transmitter itself is not documented what it's supplies
actually are.

So, what we currently have in DT for dw_hdmi is something which doesn't
_quite_ reflect the hardware right now, and to go adding VP and VPH
supplies to the generic binding is wrong - it doesn't follow the
hardware structure detailed in the iMX documentation I have.

As the Rockchip documentation is not available, I can't comment whether
it would be current proposal is appropriate for Rockchip or not, which
is why I haven't commented on this other than saying that it's not
appropriate to be a generic dw_hdmi binding.

If we wanted to model this correctly, then for iMX, I would suggest
that the HDMI phy should be modelled in DT, and _all_ the six VP*
supplies are modelled - and we should assume that "GD" is a "power
good" signal, though we don't know that for certain.

What we also don't know on iMX6 is what voltages any of these are
supplied with.

So, as we don't have much certainty here, and we know that adding it
to what is the HDMI transmitter would be wrong, I'd suggest not
modelling it in a generic way at present.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2015-06-05 23:10 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-12 20:45 [PATCH v3 1/2] drm/bridge: dw-hdmi: support optional supply regulators Heiko Stuebner
2015-03-12 20:46 ` [PATCH v3 2/2] ARM: dts: rockchip: add hdmi analog power supplies to rk3288 boards Heiko Stuebner
2015-03-23 18:17 ` [PATCH v3 1/2] drm/bridge: dw-hdmi: support optional supply regulators Heiko Stuebner
2015-03-25 16:51   ` Philipp Zabel
2015-06-05 11:02   ` Thierry Reding
2015-06-05 12:16     ` Heiko Stübner
2015-06-05 12:23       ` Thierry Reding
     [not found]         ` <20150605122311.GA759-AwZRO8vwLAwmlAP/+Wk3EA@public.gmane.org>
2015-06-05 23:03           ` Heiko Stübner
2015-06-05 23:10       ` Russell King - ARM Linux [this message]
2015-06-08 14:02         ` Thierry Reding
2015-06-08 14:29           ` Russell King - ARM Linux
2015-06-08 15:44             ` Thierry Reding
2015-06-08 16:34               ` Russell King - ARM Linux
2015-06-09  7:53                 ` Thierry Reding
2015-06-09 23:29                   ` Heiko Stübner
2015-06-09 23:36                     ` Russell King - ARM Linux
2015-06-12  7:27                       ` Heiko Stübner

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=20150605231058.GQ7557@n2100.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --cc=andy.yan@rock-chips.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dianders@chromium.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=heiko@sntech.de \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=pawel.moll@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=ykk@rock-chips.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).