From: Priit Laes <plaes@plaes.org>
To: Maxime Ripard <maxime.ripard@bootlin.com>
Cc: Russell King - ARM Linux <linux@armlinux.org.uk>,
dri-devel@lists.freedesktop.org, Chen-Yu Tsai <wens@csie.org>,
Mats Lundberg <mats.lundberg@paf.com>,
Priit Laes <priit.laes@paf.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] drm/sun4i: hdmi: Improve compatibility with non-hotplug capable connectors
Date: Wed, 5 Dec 2018 13:18:02 +0000 [thread overview]
Message-ID: <20181205131801.h2ki7xj2fbegv5b2@plaes.org> (raw)
In-Reply-To: <20181120085841.bxgdoj7lncbu6ygz@flea>
On Tue, Nov 20, 2018 at 09:58:41AM +0100, Maxime Ripard wrote:
> On Mon, Nov 19, 2018 at 10:26:38AM +0000, Russell King - ARM Linux wrote:
> > On Mon, Nov 19, 2018 at 09:19:34AM +0100, Maxime Ripard wrote:
> > > Hi,
> > >
> > > On Fri, Nov 16, 2018 at 07:18:29PM +0200, Priit Laes wrote:
> > > > From: Priit Laes <priit.laes@paf.com>
> > > >
> > > > Even though HDMI connector features hotplug detect pin (HPD), there are
> > > > devices that which do not support it.
> > >
> > > Which devices?
> > >
> > > > For these devices fall back to additional check on I2C bus. Of
> > > > course, there might be also devices that do not wire DDC pins too,
> > > > so we don't really know whether cable has been connected.
> > >
> > > Again, which devices?
> > >
> > > >
> > > > Signed-off-by: Priit Laes <plaes@plaes.org>
> > > > Signed-off-by: Priit Laes <priit.laes@paf.com>
> > >
> > > You only need one :)
> > >
> > > > ---
> > >
> > > You're doing basically two things in that patch, first adding the
> > > fallback to the DDC probe if the hotplug mechanism couldn't detect the
> > > display, and then returning a status unknown if both fail.
> > >
> > > While I don't really have an opinion on the first one, it's mandatory
> > > for every HDMI device to be able to retrieve the EDID through the
> > > DDC. If a device was to disallow that, it would violate the HDMI, and
> > > I'm not sure we want to start supporting those devices.
> >
> > There is also the problem that HDMI uses the HPD signal to indicate
> > that the source should re-read the EDID due to the EDID changing.
> > In HDMI, you don't necessarily have a fixed-for-all-time EDID, but
> > one which can change depending on what devices are in the HDMI path.
> >
> > Consider, for example, an AV amplifier which needs to subsitute the
> > audio capabilities when it is turned on, but when in standby needs
> > to pass through the TVs audio capabilities. It informs the source
> > by momentarily deasserting the HDMI HPD signal, which is the HDMI
> > way to inform the source that the EDID should be re-read.
> >
> > If you're going to use "read EDID" as the hotplug method, I think
> > you need to keep track of when it changes so that EDID updates are
> > correctly handled.
>
> I didn't think about that, thanks for bringing it up!
Well, currently this is broken anyway, becuse we are doing the polling
due to missing HPD interrupt. You can test by quickly switching between
two different monitors that both have proper HPD pin.
>
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
prev parent reply other threads:[~2018-12-05 13:18 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-16 17:18 [PATCH] drm/sun4i: hdmi: Improve compatibility with non-hotplug capable connectors Priit Laes
2018-11-19 8:19 ` Maxime Ripard
2018-11-19 8:50 ` Priit Laes
2018-11-19 10:26 ` Russell King - ARM Linux
2018-11-20 8:58 ` Maxime Ripard
2018-12-05 13:18 ` Priit Laes [this message]
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=20181205131801.h2ki7xj2fbegv5b2@plaes.org \
--to=plaes@plaes.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=mats.lundberg@paf.com \
--cc=maxime.ripard@bootlin.com \
--cc=priit.laes@paf.com \
--cc=wens@csie.org \
/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