From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Fix RGB color range property for PCH platforms
Date: Thu, 10 Jan 2013 13:10:37 +0200 [thread overview]
Message-ID: <20130110111037.GA3867@intel.com> (raw)
In-Reply-To: <CAKMK7uGN2QtyaJhrVj4mZbViio5q69ii+KQ8OGUZb57sknsjfQ@mail.gmail.com>
On Wed, Jan 09, 2013 at 07:49:07PM +0100, Daniel Vetter wrote:
> On Wed, Jan 9, 2013 at 7:36 PM, <ville.syrjala@linux.intel.com> wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > The RGB color range select bit on the DP/SDVO/HDMI registers
> > disappeared when PCH was introduced, and instead a new PIPECONF bit
> > was added that performs the same function.
> >
> > Add a new intel_encoder function pointer to query the encoder whether
> > limited or full range should be selected, and set the PIPECONF bit 13
> > accordingly.
> >
> > Experimentation showed that simply toggling the bit while the pipe is
> > active doesn't work. We need to restart the pipe, which luckily already
> > happens.
> >
> > The DP/SDVO/HDMI bit 8 is marked MBZ in the docs, so avoid setting it,
> > although it doesn't seem to do any harm in practice.
> >
> > TODO:
> > - the PIPECONF bit too seems to have disappeared from HSW. Need a
> > volunteer to test if it's just a documentation issue or if it's really
> > gone. If the bit is gone and no easy replacement is found, then I suppose
> > we may need to use the pipe CSC unit to perform the range compression.
> > - move color_range to intel_encoder to avoid the silly func pointer?
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46800
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Can't we just add another flag to mod->private_flags like we do for
> 6bpc dithering? I know that that's ugly, and we need to extend this
> into a more generic pipe configuration struct, but we have way to many
> bits&pieces where encoders want to control/influence pipe state like
> that, so adding new virtual functions like this wont scale.
Right. private_flags seems like a decent way to handle this.
v2 coming up soon.
--
Ville Syrjälä
Intel OTC
prev parent reply other threads:[~2013-01-10 11:10 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-09 18:36 [PATCH] drm/i915: Fix RGB color range property for PCH platforms ville.syrjala
2013-01-09 18:49 ` Daniel Vetter
2013-01-10 11:10 ` Ville Syrjälä [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=20130110111037.GA3867@intel.com \
--to=ville.syrjala@linux.intel.com \
--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 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.