All of lore.kernel.org
 help / color / mirror / Atom feed
From: Doug Anderson <dianders@chromium.org>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Philipp Zabel <p.zabel@pengutronix.de>,
	Thierry Reding <treding@nvidia.com>,
	Heiko Stuebner <heiko@sntech.de>, David Airlie <airlied@linux.ie>,
	Andy Yan <andy.yan@rock-chips.com>,
	Yakir Yang <ykk@rock-chips.com>,
	Fabio Estevam <fabio.estevam@freescale.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] drm: bridge/dw_hdmi: Filter modes > 165MHz for DVI
Date: Wed, 17 Jun 2015 19:52:14 -0700	[thread overview]
Message-ID: <CAD=FV=W92nP8Ch_1rbXnZaE2XAwdjFV8M8k+hQ+ZnAvhmMOAMQ@mail.gmail.com> (raw)
In-Reply-To: <20150617233040.GE7557@n2100.arm.linux.org.uk>

Russell,

On Wed, Jun 17, 2015 at 4:30 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Wed, Jun 17, 2015 at 04:14:07PM -0700, Doug Anderson wrote:
>> If you plug in a DVI monitor to your HDMI port, you need to filter out
>> clocks > 165MHz.  That's because 165MHz is the maximum clock rate that
>> we can run single-link DVI at.
>>
>> If you want to run high resolutions to DVI, you'd need some type of an
>> active adapter that pretended that it was HDMI, interpreted the
>> signal, and produced a new dual link DVI signal at a lower clock rate.
>>
>> Signed-off-by: Doug Anderson <dianders@chromium.org>
>> ---
>> Note: this patch was tested against a 3.14 kernel with backports.  It
>> was only compile tested against linuxnext, but the code is
>> sufficiently similar that I'm convinced it will work there.
>
> Really?  I have to wonder what your testing was...
>
>         hdmi->vic = drm_match_cea_mode(mode);
>
>         if (!hdmi->vic) {
>                 dev_dbg(hdmi->dev, "Non-CEA mode used in HDMI\n");
>                 hdmi->hdmi_data.video_mode.mdvi = true;
>         } else {
>                 dev_dbg(hdmi->dev, "CEA mode used vic=%d\n", hdmi->vic);
>                 hdmi->hdmi_data.video_mode.mdvi = false;
>         }
>
> mdvi indicates whether the _currently set mode_ is a CEA mode or not (imho,
> it's mis-named).  It doesn't indicate whether we have a HDMI display device
> or a DVI display device connected, which seems to be what you want to use
> it for below.
>
> To sort that, what you need to do is detect a HDMI display device using
> drm_detect_hdmi_monitor() on the EDID received from the device before
> parsing the modes, and save that value in a dw_hdmi struct member, and
> I'd suggest that it's a top-level struct member, not buried in 'hdmi_data'
> or 'video_mode'.

OK, so clearly my patch won't work against mainline.  I guess it's a
good thing that I pointed out that it was only tested locally (would
have been better to test against mainline, but I don't think that's so
easy since there are several unlanded patches in mainline for
Rockchip).

As pointed out by others at <http://crosreview.com/278255>, locally
our kernel has a slightly older version of
<https://lkml.org/lkml/2015/2/28/291>, which would change mdvi to be
as needed.

...so I guess my change is blocked on someone reviewing/landing that
series.  If that series is rejected (or is changed sufficiently so
that mdvi no longer is set via drm_detect_hdmi_monitor() then my patch
will need to be re-spun.

-Doug

  reply	other threads:[~2015-06-18  2:52 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-17 23:14 [PATCH] drm: bridge/dw_hdmi: Filter modes > 165MHz for DVI Doug Anderson
2015-06-17 23:30 ` Russell King - ARM Linux
2015-06-17 23:30   ` Russell King - ARM Linux
2015-06-18  2:52   ` Doug Anderson [this message]
2015-06-18  8:53     ` Russell King - ARM Linux
2015-06-18  8:53       ` Russell King - ARM Linux
2015-06-18 15:26       ` Doug Anderson
2015-06-18 15:55         ` Russell King - ARM Linux
2015-06-18 15:55           ` Russell King - ARM Linux
2015-06-18 16:09           ` Russell King - ARM Linux
2015-06-18 16:22             ` Doug Anderson
2015-06-18 16:10           ` Doug Anderson
2015-06-19  1:31             ` Yakir Yang
2015-06-19  1:31               ` Yakir Yang

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='CAD=FV=W92nP8Ch_1rbXnZaE2XAwdjFV8M8k+hQ+ZnAvhmMOAMQ@mail.gmail.com' \
    --to=dianders@chromium.org \
    --cc=airlied@linux.ie \
    --cc=andy.yan@rock-chips.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=fabio.estevam@freescale.com \
    --cc=heiko@sntech.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=p.zabel@pengutronix.de \
    --cc=treding@nvidia.com \
    --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 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.