All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "Manna, Animesh" <animesh.manna@intel.com>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH 11/13] drm/i915/dsb: Write each legacy LUT entry twice with DSB
Date: Fri, 3 Feb 2023 12:50:33 +0200	[thread overview]
Message-ID: <Y9zm+TP/SHgsRJBt@intel.com> (raw)
In-Reply-To: <PH7PR11MB5981B0FDF6E03F7849A19858F9D69@PH7PR11MB5981.namprd11.prod.outlook.com>

On Thu, Feb 02, 2023 at 07:05:27PM +0000, Manna, Animesh wrote:
> 
> 
> > -----Original Message-----
> > From: Intel-gfx <intel-gfx-bounces@lists.freedesktop.org> On Behalf Of Ville
> > Syrjala
> > Sent: Wednesday, January 18, 2023 10:01 PM
> > To: intel-gfx@lists.freedesktop.org
> > Subject: [Intel-gfx] [PATCH 11/13] drm/i915/dsb: Write each legacy LUT entry
> > twice with DSB
> > 
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > 
> > The DSB has problems loading the legacy LUT. Looks like simply writing each
> > LUT entry twice back-to-back is sufficient workaround for this.
> > 
> > Curiously it doesn't even matter what data we provide for the first write, the
> > second write always seems to work 100%. So this doesn't seem to be some
> > kind of simple race where the data gets latched before it's actually available
> > on some bus (which was my first hunch).
> > 
> > TODO: need to figure out what is the actual hw issue here
> > 
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> >  drivers/gpu/drm/i915/display/intel_color.c | 11 ++++++++++-
> >  1 file changed, 10 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> > b/drivers/gpu/drm/i915/display/intel_color.c
> > index 4c3344ee473e..8de2dc4b7904 100644
> > --- a/drivers/gpu/drm/i915/display/intel_color.c
> > +++ b/drivers/gpu/drm/i915/display/intel_color.c
> > @@ -860,9 +860,18 @@ static void ilk_load_lut_8(const struct
> > intel_crtc_state *crtc_state,
> > 
> >  	lut = blob->data;
> > 
> > -	for (i = 0; i < 256; i++)
> > +	for (i = 0; i < 256; i++) {
> > +		/*
> > +		 * DSB fails to correctly load the legacy
> > +		 * LUT unless we write each entry twice.
> > +		 * It doesn't actually matter what data we
> > +		 * provide for the first write.
> > +		 */
> 
> Is it confirmed by hardware team?

Haven't filed the hsd yet on account of being busy debugging
other DSB issues. But I should do that soon.

> Is there any difference with indexed register write and single register write.

It doesn't matter what kind of write you use. I also tried all
various other tricks (eg. the non-posted write stuff, and just
slowing things down with other registers writes, etc.).

-- 
Ville Syrjälä
Intel

  reply	other threads:[~2023-02-03 10:50 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-18 16:30 [Intel-gfx] [PATCH 00/13] drm/i915: Load LUTs with DSB Ville Syrjala
2023-01-18 16:30 ` [Intel-gfx] [PATCH 01/13] drm/i915/dsb: Define more DSB registers Ville Syrjala
2023-02-03  9:49   ` Manna, Animesh
2023-01-18 16:30 ` [Intel-gfx] [PATCH 02/13] drm/i915/dsb: Pimp debug/error prints Ville Syrjala
2023-02-03  9:49   ` Manna, Animesh
2023-01-18 16:30 ` [Intel-gfx] [PATCH 03/13] drm/i915/dsb: Split intel_dsb_wait() from intel_dsb_commit() Ville Syrjala
2023-02-02 15:22   ` Manna, Animesh
2023-01-18 16:30 ` [Intel-gfx] [PATCH 04/13] drm/i915/dsb: Introduce intel_dsb_finish() Ville Syrjala
2023-02-02 15:26   ` Manna, Animesh
2023-01-18 16:30 ` [Intel-gfx] [PATCH 05/13] drm/i915/dsb: Dump the DSB command buffer when DSB fails Ville Syrjala
2023-02-02 17:09   ` Manna, Animesh
2023-02-03 11:51     ` Ville Syrjälä
2023-01-18 16:30 ` [Intel-gfx] [PATCH 06/13] drm/i915/dsb: Allow vblank synchronized DSB execution Ville Syrjala
2023-02-02 17:17   ` Manna, Animesh
2023-01-18 16:30 ` [Intel-gfx] [PATCH 07/13] drm/i915/dsb: Nuke the DSB debug Ville Syrjala
2023-02-02 17:19   ` Manna, Animesh
2023-01-18 16:30 ` [Intel-gfx] [PATCH 08/13] drm/i915/dsb: Skip DSB command buffer setup if we have no LUTs Ville Syrjala
2023-02-03 10:01   ` Manna, Animesh
2023-01-18 16:30 ` [Intel-gfx] [PATCH 09/13] drm/i915/dsb: Don't use DSB to load the LUTs during full modeset Ville Syrjala
2023-02-03 10:04   ` Manna, Animesh
2023-02-03 10:46     ` Ville Syrjälä
2023-01-18 16:30 ` [Intel-gfx] [PATCH 10/13] drm/i915/dsb: Load LUTs using the DSB during vblank Ville Syrjala
2023-01-18 16:30 ` [Intel-gfx] [PATCH 11/13] drm/i915/dsb: Write each legacy LUT entry twice with DSB Ville Syrjala
2023-02-02 19:05   ` Manna, Animesh
2023-02-03 10:50     ` Ville Syrjälä [this message]
2023-01-18 16:30 ` [Intel-gfx] [PATCH 12/13] drm/i915/dsb: Load LUTs with the DSB Ville Syrjala
2023-01-18 16:30 ` [Intel-gfx] [PATCH 13/13] drm/i915: Do state check for color management changes Ville Syrjala
2023-01-19  0:07 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Load LUTs with DSB Patchwork
2023-01-19  0:35 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-01-19 22:29 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork

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=Y9zm+TP/SHgsRJBt@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=animesh.manna@intel.com \
    --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.