All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Roper <matthew.d.roper@intel.com>
To: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: intel-gfx@lists.freedesktop.org, kausalmalladi@gmail.com,
	dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 2/5] drm/i915: Do not read GAMMA_MODE register
Date: Tue, 23 Feb 2016 10:16:19 -0800	[thread overview]
Message-ID: <20160223181619.GP22387@intel.com> (raw)
In-Reply-To: <56CC3634.2000000@intel.com>

On Tue, Feb 23, 2016 at 10:36:36AM +0000, Lionel Landwerlin wrote:
> On 23/02/16 00:38, Matt Roper wrote:
> >On Mon, Feb 22, 2016 at 02:18:08PM +0000, Lionel Landwerlin wrote:
> >>Implement Daniel Stone's recommendation to not read registers to infer
> >>the hardware's state.
> >>
> >>Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
> >Do we need to ensure that software and hardware state are synchronized
> >at startup?  A boot firmware might have set it to something different
> >before our driver starts up; if we use 'fastboot' then we might not do
> >any modesets and might wind up with 0 (8BIT) in our state variable, but
> >something else actually programmed into the hardware.
> >
> >
> >Matt
> 
> Thanks Matt,
> 
> It makes sense know, I couldn't understand why this would ever be at
> something different that 8bit mode...
> I guess the value should be read from the intel_color_init()
> function upon startup.

We have a hardware state readout where we reconstruct the hardware state
for various things like plane state and such; you could add color
management readout to that.  Alternatively, we could just force
known-good values into the hardware at startup as we do (or will very
soon) for stuff we don't trust the BIOS to get right like watermarks.


Matt

> 
> -
> Lionel

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2016-02-23 18:16 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-22 14:18 [PATCH 0/5] Pipe level color management V6 Lionel Landwerlin
2016-02-22 14:18 ` [PATCH 1/5] drm/i915: Extract out gamma table and CSC to their own file Lionel Landwerlin
2016-02-23  0:00   ` Matt Roper
2016-02-22 14:18 ` [PATCH 2/5] drm/i915: Do not read GAMMA_MODE register Lionel Landwerlin
2016-02-23  0:38   ` [Intel-gfx] " Matt Roper
2016-02-23 10:36     ` Lionel Landwerlin
2016-02-23 18:16       ` Matt Roper [this message]
2016-02-22 14:18 ` [PATCH 3/5] drm: introduce pipe color correction properties Lionel Landwerlin
2016-02-22 14:18 ` [PATCH 4/5] drm/i915: Implement color management on bdw/skl/bxt/kbl Lionel Landwerlin
2016-02-23  0:52   ` Matt Roper
2016-02-23 14:42     ` Lionel Landwerlin
2016-02-22 14:18 ` [PATCH 5/5] drm/i915: Implement color management on chv Lionel Landwerlin
2016-02-22 14:48 ` ✗ Fi.CI.BAT: warning for Pipe level color management (rev6) Patchwork
  -- strict thread matches above, loose matches on Subject: below --
2016-02-26 17:04 [PATCH 0/5] Pipe level color management V10 Lionel Landwerlin
2016-02-26 17:04 ` [PATCH 2/5] drm/i915: Do not read GAMMA_MODE register Lionel Landwerlin
2016-02-25 15:33 [PATCH 0/5] Pipe level color management V9 Lionel Landwerlin
2016-02-25 15:33 ` [PATCH 2/5] drm/i915: Do not read GAMMA_MODE register Lionel Landwerlin
2016-02-25 10:58 [PATCH 0/5] Pipe level color management V8 Lionel Landwerlin
2016-02-25 10:58 ` [PATCH 2/5] drm/i915: Do not read GAMMA_MODE register Lionel Landwerlin
2016-02-25 23:27   ` Matt Roper
2016-02-23 14:39 [PATCH 0/5] Pipe level color management V7 Lionel Landwerlin
2016-02-23 14:39 ` [PATCH 2/5] drm/i915: Do not read GAMMA_MODE register Lionel Landwerlin
2016-02-19 15:39 [PATCH 0/5] Pipe level color management V5 Lionel Landwerlin
2016-02-19 15:39 ` [PATCH 2/5] drm/i915: Do not read GAMMA_MODE register Lionel Landwerlin

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=20160223181619.GP22387@intel.com \
    --to=matthew.d.roper@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=kausalmalladi@gmail.com \
    --cc=lionel.g.landwerlin@intel.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.