From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915/ddi: set has_infoframe flag on DDI too v2
Date: Thu, 20 Nov 2014 11:54:02 -0800 [thread overview]
Message-ID: <20141120115402.0bf3a591@jbarnes-hsw> (raw)
In-Reply-To: <20141120154942.GH25711@phenom.ffwll.local>
On Thu, 20 Nov 2014 16:49:42 +0100
Daniel Vetter <daniel@ffwll.ch> wrote:
> On Tue, Nov 18, 2014 at 09:45:52AM -0800, Jesse Barnes wrote:
> > Just like we do in the HDMI code, set the infoframe flag if we detect
> > that infoframes are enabled.
> >
> > v2: check for actual infoframe status as in hdmi code (Daniel)
> >
> > Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
> > ---
> > drivers/gpu/drm/i915/intel_ddi.c | 8 ++++++++
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
> > index 07c5625..24110c9 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -2075,6 +2075,14 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
> > break;
> > }
> >
> > + if (encoder->type == INTEL_OUTPUT_HDMI) {
>
> Hm I dind't look too closely apparently at this. You again rely upon sw
> state here, just encoder->type this time around. Which means you can't
> upcast the intel_hdmi struct, and you also can't really rely upon the
> encoder->crtc link (that's all just about to get reconstructed). Imo the
> code should have stayed in the TRANS_DDI_MODE_SELECT_HDMI case.
Hm, we look at the encoder->type later and check for eDP, so I figured
it must be valid at this point. It's easy enough to move though if
not...
> The later depency upon encoder->crtc is an issue for everything !g4x, but
> on hsw there's the additional issue that you have to look at the cpu
> transcoder and I guess that part blows up.
I'll check out Paulo's trace; haven't looked yet.
> g4x infoframe readout is probably broken too because it doesn't check that
> the port selected is the one actually queried for.
Yeah that looks like a separate bug from the infoframe_enabled
additions.
>
> Overall I think we need to:
> - Inline the g4x readout into the hdmi get_config function and check the
> port.
> - Inline the ibx/cpt readout code into the relevant get_pipe_config
> functions (well pch config) since that state is per-pipe. We should
> probably double-check the port, too.
> - Same inline for vlv and hsw, with the addition that we need to make sure
> on hsw to not try to read this for the edp transcoder.
I'll check, we may not need to inline since we should be able to get
the port info easily enough.
--
Jesse Barnes, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2014-11-20 19:53 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-17 21:08 [PATCH 1/2] drm/i915/ddi: set has_infoframe flag on DDI too Jesse Barnes
2014-11-17 21:08 ` [PATCH 2/2] drm/i915/ddi: add break in DDI mode select switch Jesse Barnes
2014-11-18 3:27 ` [PATCH 2/2] drm/i915/ddi: add break in DDI mode select shuang.he
2014-11-18 8:14 ` [PATCH 2/2] drm/i915/ddi: add break in DDI mode select switch Daniel Vetter
2014-11-18 8:14 ` [PATCH 1/2] drm/i915/ddi: set has_infoframe flag on DDI too Daniel Vetter
2014-11-18 16:16 ` Jesse Barnes
2014-11-18 17:45 ` [PATCH] drm/i915/ddi: set has_infoframe flag on DDI too v2 Jesse Barnes
2014-11-19 0:00 ` [PATCH] drm/i915/ddi: set has_infoframe flag on DDI too shuang.he
2014-11-19 13:53 ` Daniel Vetter
2014-11-19 13:55 ` [PATCH] drm/i915/ddi: set has_infoframe flag on DDI too v2 Daniel Vetter
2014-11-20 15:49 ` Daniel Vetter
2014-11-20 19:54 ` Jesse Barnes [this message]
2014-11-20 21:40 ` Daniel Vetter
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=20141120115402.0bf3a591@jbarnes-hsw \
--to=jbarnes@virtuousgeek.org \
--cc=daniel@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.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