Re: [Intel-gfx] [PATCH 06/10] drm/tegra: Handle 64-bit return from drm_crtc_vblank_count()

[Rodrigo Vivi]

On Wed, Feb 07, 2018 at 09:32:35PM +, Pandiyan, Dhinakaran wrote:
> 
> 
> 
> On Wed, 2018-02-07 at 10:41 +0100, Thierry Reding wrote:
> > On Wed, Feb 07, 2018 at 01:41:18AM +, Pandiyan, Dhinakaran wrote:
> > > On Fri, 2018-02-02 at 21:12 -0800, Dhinakaran Pandiyan wrote:
> > > > 570e86963a51 ("drm: Widen vblank count to 64-bits [v3]") changed the
> > > > return type for drm_crtc_vblank_count() to u64. This could cause
> > > > potential problems if the return value is used in arithmetic operations
> > > > with a 32-bit reference HW vblank count. Explicitly typecasting this
> > > > down to u32 either fixes a potential problem or serves to add clarity in
> > > > case the implicit typecasting was already correct.
> > > > 
> > > > Cc: Keith Packard 
> > > > Cc: Thierry Reding 
> > > 
> > > 
> > > Thierry, 
> > > 
> > > Can I get an Ack on this please? 
> > > 
> > > > Signed-off-by: Dhinakaran Pandiyan 
> > > > ---
> > > >  drivers/gpu/drm/tegra/dc.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> > > > index b8403ed48285..49df2db2ad46 100644
> > > > --- a/drivers/gpu/drm/tegra/dc.c
> > > > +++ b/drivers/gpu/drm/tegra/dc.c
> > > > @@ -1359,7 +1359,7 @@ static u32 tegra_dc_get_vblank_counter(struct 
> > > > drm_crtc *crtc)
> > > > return host1x_syncpt_read(dc->syncpt);
> > > >  
> > > > /* fallback to software emulated VBLANK counter */
> > > > -   return drm_crtc_vblank_count(>base);
> > > > +   return (u32)drm_crtc_vblank_count(>base);
> > 
> > Isn't this the wrong way around? Shouldn't we instead make the
> > ->get_vblank_counter() callback return u64 like drm_crtc_vblank_count()?
> 
> Here's how I understand this - 
> 
> To use the software emulated vblank counter, the driver should set
> max_vblank_count = 0 and the core takes care of calculating elapsed
> vblanks.
> 
> ->get_vblank_counter() is meant to return the hardware counter if
> available, which would be a 32-bit value. Hence the explicit typecast to
> 32-bit for the fallback case too.
> 
> Having said that, I believe drm_crtc_accurate_vblank_count() is the
> appropriate function for fallback.

Hi Thierry,

any further concerns or thoughts here?

I'd like to merge all together on drm-intel since the ones
around us is kind of blocking us.

Thanks,
Rodrigo.

> 
> -DK
> 
> 
> 
> > 
> > Thierry
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] AWOOGA: Revert "ALSA: hda: Make use of core codec functions to sync power state"

[Lofstedt, Marta]

See bug: https://bugs.freedesktop.org/show_bug.cgi?id=105069

> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Saarinen, Jani
> Sent: Tuesday, February 13, 2018 9:35 AM
> To: Kumar, Abhijeet ; Takashi Iwai
> ; Chris Wilson 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] AWOOGA: Revert "ALSA: hda: Make use of
> core codec functions to sync power state"
> 
> Hi,
> > -Original Message-
> > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On
> > Behalf Of Kumar, Abhijeet
> > Sent: tiistai 13. helmikuuta 2018 7.18
> > To: Takashi Iwai ; Chris Wilson
> > 
> > Cc: intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH] AWOOGA: Revert "ALSA: hda: Make use
> > of core codec functions to sync power state"
> >
> >
> >
> > On 2/13/2018 10:41 AM, Takashi Iwai wrote:
> > > On Mon, 12 Feb 2018 18:29:53 +0100,
> > > Chris Wilson wrote:
> > >> This reverts commit 3b5b899ca67db07a4c4825911072221f99e157e2.
> > >>
> > >> Fixes: 3b5b899ca67d ("ALSA: hda: Make use of core codec functions
> > >> to sync power state")
> > >> Cc: Abhijeet Kumar 
> > >> Cc: Takashi Iwai 
> > > Did the patch break anything?
> > Not sure, why it would break anything. As there was literally no
> > functional change.
> You can also doing so by yourself just looking at resutls from revert, but I 
> also
> sent mail to explain.
> 
> >
> > Chris,
> > Can you help us in understanding the issue caused by this patch ?
> >
> > Warm Regards,
> > Abhijeet
> > > I don't understand it without any real context...
> > >
> > >
> > > thanks,
> > >
> > > Takashi
> > >
> > >> ---
> > >>   sound/pci/hda/hda_codec.c | 28 +++-
> > >>   sound/pci/hda/hda_local.h |  6 +-
> > >>   2 files changed, 28 insertions(+), 6 deletions(-)
> > >>
> > >> diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
> > >> index 5bc3a7468e17..e018ecbf78a8 100644
> > >> --- a/sound/pci/hda/hda_codec.c
> > >> +++ b/sound/pci/hda/hda_codec.c
> > >> @@ -2702,6 +2702,32 @@ void
> snd_hda_codec_set_power_to_all(struct
> > hda_codec *codec, hda_nid_t fg,
> > >>   }
> > >>   EXPORT_SYMBOL_GPL(snd_hda_codec_set_power_to_all);
> > >>
> > >> +/*
> > >> + * wait until the state is reached, returns the current state  */
> > >> +static unsigned int hda_sync_power_state(struct hda_codec *codec,
> > >> +
> hda_nid_t fg,
> > >> +
> unsigned int power_state)
> > >> +{
> > >> +unsigned long end_time = jiffies + msecs_to_jiffies(500);
> > >> +unsigned int state, actual_state;
> > >> +
> > >> +for (;;) {
> > >> +state = snd_hda_codec_read(codec, fg, 0,
> > >> +
> AC_VERB_GET_POWER_STATE, 0);
> > >> +if (state & AC_PWRST_ERROR)
> > >> +break;
> > >> +actual_state = (state >> 4) & 0x0f;
> > >> +if (actual_state == power_state)
> > >> +break;
> > >> +if (time_after_eq(jiffies, end_time))
> > >> +break;
> > >> +/* wait until the codec reachs to the target state
> */
> > >> +msleep(1);
> > >> +}
> > >> +return state;
> > >> +}
> > >> +
> > >>   /**
> > >>* snd_hda_codec_eapd_power_filter - A power filter callback for
> EAPD
> > >>* @codec: the HDA codec
> > >> @@ -2764,7 +2790,7 @@ static unsigned int
> > >> hda_set_power_state(struct
> > hda_codec *codec,
> > >>
>  state);
> > >>
>   snd_hda_codec_set_power_to_all(codec, fg,
> > power_state);
> > >>  }
> > >> -state = snd_hda_sync_power_state(codec, fg,
> power_state);
> > >> +state = hda_sync_power_state(codec, fg,
> power_state);
> > >>  if (!(state & AC_PWRST_ERROR))
> > >>  break;
> > >>  }
> > >> diff --git a/sound/pci/hda/hda_local.h b/sound/pci/hda/hda_local.h
> > >> index 321e78baa63c..5b5c324c99b9 100644
> > >> --- a/sound/pci/hda/hda_local.h
> > >> +++ b/sound/pci/hda/hda_local.h
> > >> @@ -622,11 +622,7 @@ snd_hda_check_power_state(struct
> hda_codec
> > *codec, hda_nid_t nid,
> > >>   {
> > >>  return snd_hdac_check_power_state(>core, nid,
> target_state);
> > >>   }
> > >> -static inline bool snd_hda_sync_power_state(struct hda_codec
> *codec,
> > >> -   hda_nid_t nid, unsigned int
> target_state)
> > >> -{
> > >> -return snd_hdac_sync_power_state(>core, nid,
> target_state);
> > >> -}
> > >> +
> > >>   unsigned int snd_hda_codec_eapd_power_filter(struct hda_codec
> *codec,
> > >>
> hda_nid_t nid,
> > >>
> unsigned int power_state);
> > >> --
> > >> 2.16.1
> > >>
> >
> > ___
> > Intel-gfx mailing list
> > 

[Intel-gfx] patches that failed to cherry-pick on drm-intel-fixes for 4.16-rc1

[Rodrigo Vivi]

These patches failed to cherry-pick on drm-intel-fixes

Please provide a backport or advise how to proceed.

fd10e2ce9905 ("drm/i915/breadcrumbs: Ignore unsubmitted signalers")
1fe699e30113 ("drm/i915/pmu: Fix sleep under atomic in RC6 readout")

Thanks,
Rodrigo.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] AWOOGA: Revert "ALSA: hda: Make use of core codec functions to sync power state"

[Saarinen, Jani]

Hi, 
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Kumar, Abhijeet
> Sent: tiistai 13. helmikuuta 2018 7.18
> To: Takashi Iwai ; Chris Wilson 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] AWOOGA: Revert "ALSA: hda: Make use of core
> codec functions to sync power state"
> 
> 
> 
> On 2/13/2018 10:41 AM, Takashi Iwai wrote:
> > On Mon, 12 Feb 2018 18:29:53 +0100,
> > Chris Wilson wrote:
> >> This reverts commit 3b5b899ca67db07a4c4825911072221f99e157e2.
> >>
> >> Fixes: 3b5b899ca67d ("ALSA: hda: Make use of core codec functions to
> >> sync power state")
> >> Cc: Abhijeet Kumar 
> >> Cc: Takashi Iwai 
> > Did the patch break anything?
> Not sure, why it would break anything. As there was literally no functional
> change.
You can also doing so by yourself just looking at resutls from revert, but I 
also sent mail to explain. 

> 
> Chris,
> Can you help us in understanding the issue caused by this patch ?
> 
> Warm Regards,
> Abhijeet
> > I don't understand it without any real context...
> >
> >
> > thanks,
> >
> > Takashi
> >
> >> ---
> >>   sound/pci/hda/hda_codec.c | 28 +++-
> >>   sound/pci/hda/hda_local.h |  6 +-
> >>   2 files changed, 28 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
> >> index 5bc3a7468e17..e018ecbf78a8 100644
> >> --- a/sound/pci/hda/hda_codec.c
> >> +++ b/sound/pci/hda/hda_codec.c
> >> @@ -2702,6 +2702,32 @@ void snd_hda_codec_set_power_to_all(struct
> hda_codec *codec, hda_nid_t fg,
> >>   }
> >>   EXPORT_SYMBOL_GPL(snd_hda_codec_set_power_to_all);
> >>
> >> +/*
> >> + * wait until the state is reached, returns the current state  */
> >> +static unsigned int hda_sync_power_state(struct hda_codec *codec,
> >> +   hda_nid_t fg,
> >> +   unsigned int power_state)
> >> +{
> >> +  unsigned long end_time = jiffies + msecs_to_jiffies(500);
> >> +  unsigned int state, actual_state;
> >> +
> >> +  for (;;) {
> >> +  state = snd_hda_codec_read(codec, fg, 0,
> >> + AC_VERB_GET_POWER_STATE, 0);
> >> +  if (state & AC_PWRST_ERROR)
> >> +  break;
> >> +  actual_state = (state >> 4) & 0x0f;
> >> +  if (actual_state == power_state)
> >> +  break;
> >> +  if (time_after_eq(jiffies, end_time))
> >> +  break;
> >> +  /* wait until the codec reachs to the target state */
> >> +  msleep(1);
> >> +  }
> >> +  return state;
> >> +}
> >> +
> >>   /**
> >>* snd_hda_codec_eapd_power_filter - A power filter callback for EAPD
> >>* @codec: the HDA codec
> >> @@ -2764,7 +2790,7 @@ static unsigned int hda_set_power_state(struct
> hda_codec *codec,
> >>   state);
> >>snd_hda_codec_set_power_to_all(codec, fg,
> power_state);
> >>}
> >> -  state = snd_hda_sync_power_state(codec, fg, power_state);
> >> +  state = hda_sync_power_state(codec, fg, power_state);
> >>if (!(state & AC_PWRST_ERROR))
> >>break;
> >>}
> >> diff --git a/sound/pci/hda/hda_local.h b/sound/pci/hda/hda_local.h
> >> index 321e78baa63c..5b5c324c99b9 100644
> >> --- a/sound/pci/hda/hda_local.h
> >> +++ b/sound/pci/hda/hda_local.h
> >> @@ -622,11 +622,7 @@ snd_hda_check_power_state(struct hda_codec
> *codec, hda_nid_t nid,
> >>   {
> >>return snd_hdac_check_power_state(>core, nid, target_state);
> >>   }
> >> -static inline bool snd_hda_sync_power_state(struct hda_codec *codec,
> >> - hda_nid_t nid, unsigned int target_state)
> >> -{
> >> -  return snd_hdac_sync_power_state(>core, nid, target_state);
> >> -}
> >> +
> >>   unsigned int snd_hda_codec_eapd_power_filter(struct hda_codec *codec,
> >> hda_nid_t nid,
> >> unsigned int power_state);
> >> --
> >> 2.16.1
> >>
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] AWOOGA: Revert "ALSA: hda: Make use of core codec functions to sync power state"

[Saarinen, Jani]

HI, 
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Takashi Iwai
> Sent: tiistai 13. helmikuuta 2018 7.11
> To: Chris Wilson 
> Cc: intel-gfx@lists.freedesktop.org; Kumar, Abhijeet
> 
> Subject: Re: [Intel-gfx] [PATCH] AWOOGA: Revert "ALSA: hda: Make use of core
> codec functions to sync power state"
> 
> On Mon, 12 Feb 2018 18:29:53 +0100,
> Chris Wilson wrote:
> >
> > This reverts commit 3b5b899ca67db07a4c4825911072221f99e157e2.
> >
> > Fixes: 3b5b899ca67d ("ALSA: hda: Make use of core codec functions to
> > sync power state")
> > Cc: Abhijeet Kumar 
> > Cc: Takashi Iwai 
> 
> Did the patch break anything?
> I don't understand it without any real context...
Yes. See resutls from link what is fixed by reverting:
https://patchwork.freedesktop.org/series/38097/
Test pm_rpm:
Subgroup basic-pci-d3-state:
fail   -> PASS   (fi-hsw-4770)
fail   -> PASS   (fi-bdw-5557u)
Subgroup basic-rte:
fail   -> PASS   (fi-hsw-4770)
fail   -> PASS   (fi-bdw-5557u)

See also: 
https://intel-gfx-ci.01.org/tree/drm-tip/igt@pm_...@basic-pci-d3-state.html
https://intel-gfx-ci.01.org/tree/drm-tip/igt@pm_...@basic-rte.html

That build when breakage started had these commits: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3755/commits_short.log


> 
> 
> thanks,
> 
> Takashi
Br,
Jani Saarinen
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
> 
> > ---
> >  sound/pci/hda/hda_codec.c | 28 +++-
> > sound/pci/hda/hda_local.h |  6 +-
> >  2 files changed, 28 insertions(+), 6 deletions(-)
> >
> > diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
> > index 5bc3a7468e17..e018ecbf78a8 100644
> > --- a/sound/pci/hda/hda_codec.c
> > +++ b/sound/pci/hda/hda_codec.c
> > @@ -2702,6 +2702,32 @@ void snd_hda_codec_set_power_to_all(struct
> > hda_codec *codec, hda_nid_t fg,  }
> > EXPORT_SYMBOL_GPL(snd_hda_codec_set_power_to_all);
> >
> > +/*
> > + * wait until the state is reached, returns the current state  */
> > +static unsigned int hda_sync_power_state(struct hda_codec *codec,
> > +hda_nid_t fg,
> > +unsigned int power_state)
> > +{
> > +   unsigned long end_time = jiffies + msecs_to_jiffies(500);
> > +   unsigned int state, actual_state;
> > +
> > +   for (;;) {
> > +   state = snd_hda_codec_read(codec, fg, 0,
> > +  AC_VERB_GET_POWER_STATE, 0);
> > +   if (state & AC_PWRST_ERROR)
> > +   break;
> > +   actual_state = (state >> 4) & 0x0f;
> > +   if (actual_state == power_state)
> > +   break;
> > +   if (time_after_eq(jiffies, end_time))
> > +   break;
> > +   /* wait until the codec reachs to the target state */
> > +   msleep(1);
> > +   }
> > +   return state;
> > +}
> > +
> >  /**
> >   * snd_hda_codec_eapd_power_filter - A power filter callback for EAPD
> >   * @codec: the HDA codec
> > @@ -2764,7 +2790,7 @@ static unsigned int hda_set_power_state(struct
> hda_codec *codec,
> >state);
> > snd_hda_codec_set_power_to_all(codec, fg,
> power_state);
> > }
> > -   state = snd_hda_sync_power_state(codec, fg, power_state);
> > +   state = hda_sync_power_state(codec, fg, power_state);
> > if (!(state & AC_PWRST_ERROR))
> > break;
> > }
> > diff --git a/sound/pci/hda/hda_local.h b/sound/pci/hda/hda_local.h
> > index 321e78baa63c..5b5c324c99b9 100644
> > --- a/sound/pci/hda/hda_local.h
> > +++ b/sound/pci/hda/hda_local.h
> > @@ -622,11 +622,7 @@ snd_hda_check_power_state(struct hda_codec
> > *codec, hda_nid_t nid,  {
> > return snd_hdac_check_power_state(>core, nid, target_state);
> > } -static inline bool snd_hda_sync_power_state(struct hda_codec
> > *codec,
> > -  hda_nid_t nid, unsigned int target_state)
> > -{
> > -   return snd_hdac_sync_power_state(>core, nid, target_state);
> > -}
> > +
> >  unsigned int snd_hda_codec_eapd_power_filter(struct hda_codec *codec,
> >  hda_nid_t nid,
> >  unsigned int power_state);
> > --
> > 2.16.1
> >
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Fix incorrect comment

[Rodrigo Vivi]

On Fri, Feb 09, 2018 at 11:32:59PM +, James Ausmus wrote:
> On Fri, Feb 09, 2018 at 03:07:55PM +0200, David Weinehall wrote:
> > While the comment singles out Port A or B, the code says Port A or *D*.
> > Looking at the history it seems that the comment was added after the code,
> > so it seems likely that the code is correct, not the comment.
> > 
> > CC: Jani Nikula 
> > CC: Rodrigo Vivi 
> > Signed-off-by: David Weinehall 
> 
> Matches my read of BSpec.
> 
> Reviewed-by: James Ausmus 

Thanks for patch and review.

merged to dinq.

> 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index f10a14330e7c..21d526bd4df6 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -258,7 +258,7 @@ static int cnl_max_source_rate(struct intel_dp 
> > *intel_dp)
> > if (IS_CNL_WITH_PORT_F(dev_priv))
> > return 81;
> >  
> > -   /* For other SKUs, max rate on ports A and B is 5.4G */
> > +   /* For other SKUs, max rate on ports A and D is 5.4G */
> > if (port == PORT_A || port == PORT_D)
> > return 54;
> >  
> > -- 
> > 2.16.1
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] AWOOGA: Revert "ALSA: hda: Make use of core codec functions to sync power state"

[Kumar, Abhijeet]

On 2/13/2018 10:41 AM, Takashi Iwai wrote:

On Mon, 12 Feb 2018 18:29:53 +0100,
Chris Wilson wrote:

This reverts commit 3b5b899ca67db07a4c4825911072221f99e157e2.

Fixes: 3b5b899ca67d ("ALSA: hda: Make use of core codec functions to sync power 
state")
Cc: Abhijeet Kumar 
Cc: Takashi Iwai 

Did the patch break anything?
Not sure, why it would break anything. As there was literally no 
functional change.


Chris,
Can you help us in understanding the issue caused by this patch ?

Warm Regards,
Abhijeet

I don't understand it without any real context...


thanks,

Takashi


---
  sound/pci/hda/hda_codec.c | 28 +++-
  sound/pci/hda/hda_local.h |  6 +-
  2 files changed, 28 insertions(+), 6 deletions(-)

diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
index 5bc3a7468e17..e018ecbf78a8 100644
--- a/sound/pci/hda/hda_codec.c
+++ b/sound/pci/hda/hda_codec.c
@@ -2702,6 +2702,32 @@ void snd_hda_codec_set_power_to_all(struct hda_codec 
*codec, hda_nid_t fg,
  }
  EXPORT_SYMBOL_GPL(snd_hda_codec_set_power_to_all);
  
+/*

+ * wait until the state is reached, returns the current state
+ */
+static unsigned int hda_sync_power_state(struct hda_codec *codec,
+hda_nid_t fg,
+unsigned int power_state)
+{
+   unsigned long end_time = jiffies + msecs_to_jiffies(500);
+   unsigned int state, actual_state;
+
+   for (;;) {
+   state = snd_hda_codec_read(codec, fg, 0,
+  AC_VERB_GET_POWER_STATE, 0);
+   if (state & AC_PWRST_ERROR)
+   break;
+   actual_state = (state >> 4) & 0x0f;
+   if (actual_state == power_state)
+   break;
+   if (time_after_eq(jiffies, end_time))
+   break;
+   /* wait until the codec reachs to the target state */
+   msleep(1);
+   }
+   return state;
+}
+
  /**
   * snd_hda_codec_eapd_power_filter - A power filter callback for EAPD
   * @codec: the HDA codec
@@ -2764,7 +2790,7 @@ static unsigned int hda_set_power_state(struct hda_codec 
*codec,
   state);
snd_hda_codec_set_power_to_all(codec, fg, power_state);
}
-   state = snd_hda_sync_power_state(codec, fg, power_state);
+   state = hda_sync_power_state(codec, fg, power_state);
if (!(state & AC_PWRST_ERROR))
break;
}
diff --git a/sound/pci/hda/hda_local.h b/sound/pci/hda/hda_local.h
index 321e78baa63c..5b5c324c99b9 100644
--- a/sound/pci/hda/hda_local.h
+++ b/sound/pci/hda/hda_local.h
@@ -622,11 +622,7 @@ snd_hda_check_power_state(struct hda_codec *codec, 
hda_nid_t nid,
  {
return snd_hdac_check_power_state(>core, nid, target_state);
  }
-static inline bool snd_hda_sync_power_state(struct hda_codec *codec,
-  hda_nid_t nid, unsigned int target_state)
-{
-   return snd_hdac_sync_power_state(>core, nid, target_state);
-}
+
  unsigned int snd_hda_codec_eapd_power_filter(struct hda_codec *codec,
 hda_nid_t nid,
 unsigned int power_state);
--
2.16.1



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] AWOOGA: Revert "ALSA: hda: Make use of core codec functions to sync power state"

[Takashi Iwai]

On Mon, 12 Feb 2018 18:29:53 +0100,
Chris Wilson wrote:
> 
> This reverts commit 3b5b899ca67db07a4c4825911072221f99e157e2.
> 
> Fixes: 3b5b899ca67d ("ALSA: hda: Make use of core codec functions to sync 
> power state")
> Cc: Abhijeet Kumar 
> Cc: Takashi Iwai 

Did the patch break anything?
I don't understand it without any real context...


thanks,

Takashi

> ---
>  sound/pci/hda/hda_codec.c | 28 +++-
>  sound/pci/hda/hda_local.h |  6 +-
>  2 files changed, 28 insertions(+), 6 deletions(-)
> 
> diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
> index 5bc3a7468e17..e018ecbf78a8 100644
> --- a/sound/pci/hda/hda_codec.c
> +++ b/sound/pci/hda/hda_codec.c
> @@ -2702,6 +2702,32 @@ void snd_hda_codec_set_power_to_all(struct hda_codec 
> *codec, hda_nid_t fg,
>  }
>  EXPORT_SYMBOL_GPL(snd_hda_codec_set_power_to_all);
>  
> +/*
> + * wait until the state is reached, returns the current state
> + */
> +static unsigned int hda_sync_power_state(struct hda_codec *codec,
> +  hda_nid_t fg,
> +  unsigned int power_state)
> +{
> + unsigned long end_time = jiffies + msecs_to_jiffies(500);
> + unsigned int state, actual_state;
> +
> + for (;;) {
> + state = snd_hda_codec_read(codec, fg, 0,
> +AC_VERB_GET_POWER_STATE, 0);
> + if (state & AC_PWRST_ERROR)
> + break;
> + actual_state = (state >> 4) & 0x0f;
> + if (actual_state == power_state)
> + break;
> + if (time_after_eq(jiffies, end_time))
> + break;
> + /* wait until the codec reachs to the target state */
> + msleep(1);
> + }
> + return state;
> +}
> +
>  /**
>   * snd_hda_codec_eapd_power_filter - A power filter callback for EAPD
>   * @codec: the HDA codec
> @@ -2764,7 +2790,7 @@ static unsigned int hda_set_power_state(struct 
> hda_codec *codec,
>  state);
>   snd_hda_codec_set_power_to_all(codec, fg, power_state);
>   }
> - state = snd_hda_sync_power_state(codec, fg, power_state);
> + state = hda_sync_power_state(codec, fg, power_state);
>   if (!(state & AC_PWRST_ERROR))
>   break;
>   }
> diff --git a/sound/pci/hda/hda_local.h b/sound/pci/hda/hda_local.h
> index 321e78baa63c..5b5c324c99b9 100644
> --- a/sound/pci/hda/hda_local.h
> +++ b/sound/pci/hda/hda_local.h
> @@ -622,11 +622,7 @@ snd_hda_check_power_state(struct hda_codec *codec, 
> hda_nid_t nid,
>  {
>   return snd_hdac_check_power_state(>core, nid, target_state);
>  }
> -static inline bool snd_hda_sync_power_state(struct hda_codec *codec,
> -hda_nid_t nid, unsigned int target_state)
> -{
> - return snd_hdac_sync_power_state(>core, nid, target_state);
> -}
> +
>  unsigned int snd_hda_codec_eapd_power_filter(struct hda_codec *codec,
>hda_nid_t nid,
>unsigned int power_state);
> -- 
> 2.16.1
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for tests/kms_rotation_crc: Remove hardcoding of platforms in igt_require()

[Patchwork]

== Series Details ==

Series: tests/kms_rotation_crc: Remove hardcoding of platforms in igt_require()
URL   : https://patchwork.freedesktop.org/series/38108/
State : failure

== Summary ==

Test pm_rpm:
Subgroup sysfs-read:
fail   -> PASS   (shard-hsw)
Subgroup gem-mmap-cpu:
skip   -> PASS   (shard-apl)
Subgroup system-suspend-modeset:
skip   -> PASS   (shard-apl)
Subgroup modeset-lpsp:
fail   -> SKIP   (shard-hsw)
Subgroup reg-read-ioctl:
fail   -> PASS   (shard-hsw)
Subgroup modeset-non-lpsp:
fail   -> PASS   (shard-hsw)
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-indfb-draw-render:
skip   -> PASS   (shard-apl) fdo#103167
Test kms_mmio_vs_cs_flip:
Subgroup setcrtc_vs_cs_flip:
skip   -> PASS   (shard-apl)
Test kms_vblank:
Subgroup pipe-b-ts-continuation-suspend:
pass   -> SKIP   (shard-snb)
Subgroup pipe-b-wait-busy:
skip   -> PASS   (shard-apl)
Test kms_rmfb:
Subgroup rmfb-ioctl:
skip   -> PASS   (shard-apl)
Test kms_rotation_crc:
Subgroup primary-rotation-180:
pass   -> SKIP   (shard-snb)
pass   -> SKIP   (shard-hsw)
pass   -> SKIP   (shard-apl) fdo#103925 +1
Subgroup exhaust-fences:
skip   -> PASS   (shard-apl)
Subgroup sprite-rotation-270:
pass   -> SKIP   (shard-apl) fdo#103356 +1
Subgroup primary-rotation-270:
pass   -> SKIP   (shard-apl)
Subgroup cursor-rotation-180:
pass   -> SKIP   (shard-snb)
pass   -> SKIP   (shard-hsw) fdo#102614
pass   -> SKIP   (shard-apl)
Subgroup sprite-rotation-180:
pass   -> SKIP   (shard-snb)
pass   -> SKIP   (shard-hsw)
pass   -> SKIP   (shard-apl)
Test kms_color:
Subgroup pipe-c-ctm-max:
skip   -> PASS   (shard-apl)
Subgroup pipe-c-degamma:
skip   -> PASS   (shard-apl)
Subgroup pipe-b-ctm-green-to-red:
skip   -> PASS   (shard-apl)
Subgroup pipe-a-legacy-gamma:
pass   -> FAIL   (shard-apl)
Test kms_flip:
Subgroup wf_vblank-ts-check-interruptible:
skip   -> PASS   (shard-apl) fdo#100368
Subgroup blocking-absolute-wf_vblank:
skip   -> PASS   (shard-apl)
Test kms_cursor_legacy:
Subgroup flip-vs-cursor-crc-legacy:
skip   -> PASS   (shard-apl)
Subgroup flip-vs-cursor-atomic:
pass   -> FAIL   (shard-apl) fdo#102670
Subgroup cursora-vs-flipa-legacy:
skip   -> PASS   (shard-apl)
Test perf:
Subgroup oa-exponents:
fail   -> PASS   (shard-apl) fdo#102254
Test kms_plane_scaling:
Subgroup pipe-a-scaler-with-rotation:
skip   -> PASS   (shard-apl)
Test kms_chv_cursor_fail:
Subgroup pipe-b-128x128-top-edge:
pass   -> SKIP   (shard-snb)
Test pm_lpsp:
Subgroup screens-disabled:
fail   -> PASS   (shard-hsw) fdo#104941
Test gem_eio:
Subgroup in-flight-contexts:
fail   -> PASS   (shard-hsw) fdo#104676

fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925
fdo#103356 https://bugs.freedesktop.org/show_bug.cgi?id=103356
fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670
fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254
fdo#104941 https://bugs.freedesktop.org/show_bug.cgi?id=104941
fdo#104676 https://bugs.freedesktop.org/show_bug.cgi?id=104676

shard-apltotal:3381 pass:1743 dwarn:1   dfail:0   fail:22  skip:1614 
time:13704s
shard-hswtotal:3427 pass:1718 dwarn:1   dfail:0   fail:49  skip:1658 
time:14689s
shard-snbtotal:3427 pass:1344 dwarn:1   dfail:0   fail:10  skip:2072 
time:7536s
Blacklisted hosts:
shard-kbltotal:3427 pass:1862 dwarn:36  dfail:2   fail:20  skip:1507 
time:11007s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_905/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Release the atomic kmap relocation cache around snb GTT w/a

[Patchwork]

== Series Details ==

Series: drm/i915: Release the atomic kmap relocation cache around snb GTT w/a
URL   : https://patchwork.freedesktop.org/series/38107/
State : failure

== Summary ==

Test kms_mmio_vs_cs_flip:
Subgroup setcrtc_vs_cs_flip:
skip   -> PASS   (shard-apl)
Test kms_cursor_legacy:
Subgroup flip-vs-cursor-crc-legacy:
skip   -> PASS   (shard-apl)
Subgroup cursora-vs-flipa-legacy:
skip   -> PASS   (shard-apl)
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-indfb-draw-render:
skip   -> PASS   (shard-apl) fdo#103167
Test kms_flip:
Subgroup blocking-absolute-wf_vblank:
skip   -> PASS   (shard-apl)
Subgroup wf_vblank-ts-check-interruptible:
skip   -> PASS   (shard-apl) fdo#100368
Test kms_rmfb:
Subgroup rmfb-ioctl:
skip   -> PASS   (shard-apl)
Test kms_color:
Subgroup pipe-b-ctm-green-to-red:
skip   -> PASS   (shard-apl)
Subgroup pipe-c-ctm-max:
skip   -> PASS   (shard-apl)
Subgroup pipe-c-degamma:
skip   -> PASS   (shard-apl)
Test kms_rotation_crc:
Subgroup exhaust-fences:
skip   -> PASS   (shard-apl)
Test perf:
Subgroup oa-exponents:
fail   -> PASS   (shard-apl) fdo#102254
Test pm_rpm:
Subgroup i2c:
pass   -> FAIL   (shard-hsw)
Subgroup gem-mmap-cpu:
skip   -> PASS   (shard-apl)
Subgroup system-suspend-modeset:
skip   -> PASS   (shard-apl)
Test kms_plane_scaling:
Subgroup pipe-a-scaler-with-rotation:
skip   -> PASS   (shard-apl)
Test kms_vblank:
Subgroup pipe-b-wait-busy:
skip   -> PASS   (shard-apl)

fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254

shard-apltotal:3410 pass:1769 dwarn:1   dfail:0   fail:20  skip:1619 
time:13741s
shard-hswtotal:3427 pass:1715 dwarn:1   dfail:0   fail:56  skip:1654 
time:14754s
shard-snbtotal:3427 pass:1349 dwarn:1   dfail:0   fail:10  skip:2067 
time:7655s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7986/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v10,1/7] drm/i915/guc: Move GuC WOPCM related code into separate files

[Patchwork]

== Series Details ==

Series: series starting with [v10,1/7] drm/i915/guc: Move GuC WOPCM related 
code into separate files
URL   : https://patchwork.freedesktop.org/series/38119/
State : failure

== Summary ==

Series 38119v1 series starting with [v10,1/7] drm/i915/guc: Move GuC WOPCM 
related code into separate files
https://patchwork.freedesktop.org/api/1.0/series/38119/revisions/1/mbox/

Test core_auth:
Subgroup basic-auth:
pass   -> SKIP   (fi-skl-gvtdvm)
Test core_prop_blob:
Subgroup basic:
pass   -> SKIP   (fi-skl-gvtdvm)
Test debugfs_test:
Subgroup read_all_entries:
pass   -> SKIP   (fi-skl-gvtdvm)
Test drv_getparams_basic:
Subgroup basic-eu-total:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-subslice-total:
pass   -> SKIP   (fi-skl-gvtdvm)
Test drv_hangman:
Subgroup error-state-basic:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_basic:
Subgroup bad-close:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup create-close:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup create-fd-close:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_busy:
Subgroup basic-busy-default:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-hang-default:
pass   -> SKIP   (fi-skl-gvtdvm) fdo#104108 +2
Test gem_close_race:
Subgroup basic-process:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-threads:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_cpu_reloc:
Subgroup basic:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_cs_tlb:
Subgroup basic-default:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_ctx_create:
Subgroup basic:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-files:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_ctx_exec:
Subgroup basic:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_ctx_param:
Subgroup basic:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-default:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_ctx_switch:
Subgroup basic-default:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-default-heavy:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_exec_basic:
Subgroup basic-blt:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-bsd:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-bsd1:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-bsd2:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-default:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-render:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-vebox:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup gtt-blt:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup gtt-bsd:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup gtt-bsd1:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup gtt-bsd2:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup gtt-default:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup gtt-render:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup gtt-vebox:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup readonly-blt:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup readonly-bsd:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup readonly-bsd1:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup readonly-bsd2:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup readonly-default:
pass   -> SKIP   (fi-skl-gvtdvm)
WARNING: Long output truncated

83878f486e686dd291ef3566a45103962d7617ed drm-tip: 2018y-02m-12d-17h-43m-07s UTC 
integration manifest
4d320eb26ae4 HAX Enable GuC Submission for CI
63d5296b9ac7 drm/i915/guc: Check the locking status of GuC WOPCM registers
64f9829bbae8 drm/i915/guc: Add HuC firmware size related restriction for Gen9 
and CNL A0
1c10532a78e7 drm/i915/guc: Add support to return CNL specific reserved GuC 
WOPCM size
13a1710cf100 drm/i915/guc: Implement dynamic GuC WOPCM offset and size
5c1e07e501d5 drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset
c93b3e317960 drm/i915/guc: Move GuC WOPCM related code into separate files

== Logs ==

For more details see: 

[Intel-gfx] [PATCH v10 2/7] drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset

[Jackie Li]

GuC related exported functions should start with "intel_guc_" prefix and
pass intel_guc as the first parameter since its guc related. Current
guc_ggtt_offset() failed to follow this code convention and this is a
problem for future patches that needs to access intel_guc data to verify
the GGTT offset against the GuC WOPCM top.

This patch renames the guc_ggtt_offset to intel_guc_ggtt_offset and updates
the related code to pass intel_guc pointer to this function call, so that
we can have a unified coding style for GuC code and also enable the future
patches to get GuC related data from intel_guc to do the offset
verification. Meanwhile, this patch also moves the GUC_GGTT_TOP from
intel_guc_regs.h to intel_guc.h since it is not GuC register related
definition.

v8:
 - Fixed coding style issues and moved GUC_GGTT_TOP to intel_guc.h (Sagar)
 - Updated commit message to explain to reason and motivation to add
   intel_guc as the first parameter of intel_guc_ggtt_offset (Chris)

v9:
 - Fixed code alignment issue due to line break (Chris)

v10:
 - Removed unnecessary comments, redundant code and avoided reuse variable
   to avoid potential issues (Joonas)

Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Reviewed-by: Sagar Arun Kamble  (v8)
Reviewed-by: Joonas Lahtinen  (v9)
Signed-off-by: Jackie Li 
---
 drivers/gpu/drm/i915/intel_guc.c| 11 ++-
 drivers/gpu/drm/i915/intel_guc.h| 14 --
 drivers/gpu/drm/i915/intel_guc_ads.c| 27 ++-
 drivers/gpu/drm/i915/intel_guc_ct.c |  5 +++--
 drivers/gpu/drm/i915/intel_guc_fw.c |  2 +-
 drivers/gpu/drm/i915/intel_guc_log.c|  2 +-
 drivers/gpu/drm/i915/intel_guc_reg.h|  3 ---
 drivers/gpu/drm/i915/intel_guc_submission.c | 10 +-
 drivers/gpu/drm/i915/intel_huc.c|  6 --
 9 files changed, 46 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 9f45e6d..fdf8cb3 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -269,8 +269,9 @@ void intel_guc_init_params(struct intel_guc *guc)
 
/* If GuC submission is enabled, set up additional parameters here */
if (USES_GUC_SUBMISSION(dev_priv)) {
-   u32 ads = guc_ggtt_offset(guc->ads_vma) >> PAGE_SHIFT;
-   u32 pgs = guc_ggtt_offset(dev_priv->guc.stage_desc_pool);
+   u32 ads = intel_guc_ggtt_offset(guc,
+   guc->ads_vma) >> PAGE_SHIFT;
+   u32 pgs = intel_guc_ggtt_offset(guc, guc->stage_desc_pool);
u32 ctx_in_16 = GUC_MAX_STAGE_DESCRIPTORS / 16;
 
params[GUC_CTL_DEBUG] |= ads << GUC_ADS_ADDR_SHIFT;
@@ -418,7 +419,7 @@ int intel_guc_suspend(struct drm_i915_private *dev_priv)
data[0] = INTEL_GUC_ACTION_ENTER_S_STATE;
/* any value greater than GUC_POWER_D0 */
data[1] = GUC_POWER_D1;
-   data[2] = guc_ggtt_offset(guc->shared_data);
+   data[2] = intel_guc_ggtt_offset(guc, guc->shared_data);
 
return intel_guc_send(guc, data, ARRAY_SIZE(data));
 }
@@ -441,7 +442,7 @@ int intel_guc_reset_engine(struct intel_guc *guc,
data[3] = 0;
data[4] = 0;
data[5] = guc->execbuf_client->stage_id;
-   data[6] = guc_ggtt_offset(guc->shared_data);
+   data[6] = intel_guc_ggtt_offset(guc, guc->shared_data);
 
return intel_guc_send(guc, data, ARRAY_SIZE(data));
 }
@@ -463,7 +464,7 @@ int intel_guc_resume(struct drm_i915_private *dev_priv)
 
data[0] = INTEL_GUC_ACTION_EXIT_S_STATE;
data[1] = GUC_POWER_D0;
-   data[2] = guc_ggtt_offset(guc->shared_data);
+   data[2] = intel_guc_ggtt_offset(guc, guc->shared_data);
 
return intel_guc_send(guc, data, ARRAY_SIZE(data));
 }
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 9e0a97e..50be6de 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -101,13 +101,23 @@ static inline void intel_guc_notify(struct intel_guc *guc)
guc->notify(guc);
 }
 
-/*
+/* GuC addresses above GUC_GGTT_TOP also don't map through the GTT */
+#define GUC_GGTT_TOP   0xFEE0
+
+/**
+ * intel_guc_ggtt_offset() - Get and validate the GGTT offset of @vma
+ * @guc: intel guc.
+ * @vma: i915 graphics virtual memory area.
+ *
  * GuC does not allow any gfx GGTT address that falls into range [0, 
WOPCM_TOP),
  * which is reserved for Boot ROM, SRAM and WOPCM. Currently this top address 
is
  * 512K. In order to exclude 0-512K address space from GGTT, all gfx objects
  * used by GuC is pinned with PIN_OFFSET_BIAS along with size of WOPCM.
+ *
+ * Return: GGTT offset that meets 

[Intel-gfx] [PATCH v10 6/7] drm/i915/guc: Check the locking status of GuC WOPCM registers

[Jackie Li]

GuC WOPCM registers are write-once registers. Current driver code accesses
these registers without checking the accessibility to these registers which
will lead to unpredictable driver behaviors if these registers were touch
by other components (such as faulty BIOS code).

This patch moves the GuC WOPCM registers updating code into
intel_guc_wopcm.c and adds check before and after the update to GuC WOPCM
registers so that we can make sure the driver is in a known state before
and after writing to these write-once registers.

v6:
 - Made sure module reloading won't bug the kernel while doing
   locking status checking

v7:
 - Fixed patch format issues

v8:
 - Fixed coding style issue on register lock bit macro definition (Sagar)

v9:
 - Avoided to use redundant !! to cast uint to bool (Chris)
 - Return error code instead of GEM_BUG_ON for locked with invalid register
   values case (Sagar)
 - Updated guc_wopcm_hw_init to use guc_wopcm as first parameter (Michal)
 - Added code to set and validate the HuC_LOADING_AGENT_GUC bit in GuC
   WOPCM offset register based on the presence of HuC firmware (Michal)
 - Use bit fields instead of macros for GuC WOPCM flags (Michal)

v10:
 - Refined variable names, removed reduntant comments (Joonas)
 - Introduced lockable_reg to handle the write once register write and
   propagate the write error to caller (Joonas)
 - Used lockable_reg abstraction to avoid locking bit check on generic
   i915_reg_t (Michal)
 - Added log message for error paths (Michal)
 - Removed hw_updated flag and only relies on real hardware status

Cc: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Signed-off-by: Jackie Li 
---
 drivers/gpu/drm/i915/intel_guc_reg.h   |   2 +
 drivers/gpu/drm/i915/intel_guc_wopcm.c | 151 -
 drivers/gpu/drm/i915/intel_guc_wopcm.h |  10 ++-
 drivers/gpu/drm/i915/intel_uc.c|   9 +-
 4 files changed, 162 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_reg.h 
b/drivers/gpu/drm/i915/intel_guc_reg.h
index c482df5..a550078 100644
--- a/drivers/gpu/drm/i915/intel_guc_reg.h
+++ b/drivers/gpu/drm/i915/intel_guc_reg.h
@@ -68,6 +68,8 @@
 #define DMA_GUC_WOPCM_OFFSET   _MMIO(0xc340)
 #define   HUC_LOADING_AGENT_VCR  (0<<1)
 #define   HUC_LOADING_AGENT_GUC  (1<<1)
+#define   GUC_WOPCM_OFFSET_SHIFT   14
+#define   GUC_WOPCM_OFFSET_MASK  (0x3 << 
GUC_WOPCM_OFFSET_SHIFT)
 #define GUC_MAX_IDLE_COUNT _MMIO(0xC3E4)
 
 #define HUC_STATUS2 _MMIO(0xD3B0)
diff --git a/drivers/gpu/drm/i915/intel_guc_wopcm.c 
b/drivers/gpu/drm/i915/intel_guc_wopcm.c
index 0194266..4043798 100644
--- a/drivers/gpu/drm/i915/intel_guc_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_guc_wopcm.c
@@ -83,6 +83,12 @@ void intel_guc_wopcm_init_early(struct intel_guc_wopcm 
*guc_wopcm)
guc_wopcm->top = WOPCM_DEFAULT_SIZE;
 }
 
+static inline
+struct intel_guc *guc_wopcm_to_guc(struct intel_guc_wopcm *guc_wopcm)
+{
+   return container_of(guc_wopcm, struct intel_guc, wopcm);
+}
+
 /**
  * intel_guc_wopcm_init() - Initialize the GuC WOPCM.
  * @guc_wopcm: pointer to intel_guc_wopcm.
@@ -101,13 +107,13 @@ void intel_guc_wopcm_init_early(struct intel_guc_wopcm 
*guc_wopcm)
 int intel_guc_wopcm_init(struct intel_guc_wopcm *guc_wopcm, u32 guc_fw_size,
 u32 huc_fw_size)
 {
-   struct intel_guc *guc =
-   container_of(guc_wopcm, struct intel_guc, wopcm);
+   struct intel_guc *guc = guc_wopcm_to_guc(guc_wopcm);
u32 reserved = context_reserved_size(guc);
u32 offset, size, top;
int err;
 
GEM_BUG_ON(!guc_fw_size);
+   GEM_BUG_ON(guc->wopcm.valid);
 
offset = huc_fw_size + WOPCM_RESERVED_SIZE;
 
@@ -138,6 +144,7 @@ int intel_guc_wopcm_init(struct intel_guc_wopcm *guc_wopcm, 
u32 guc_fw_size,
guc->wopcm.offset = offset;
guc->wopcm.size = size;
guc->wopcm.top = top;
+   guc->wopcm.load_huc_fw = huc_fw_size > 0;
 
err = guc_wopcm_size_check(guc, huc_fw_size);
if (err) {
@@ -152,3 +159,143 @@ int intel_guc_wopcm_init(struct intel_guc_wopcm 
*guc_wopcm, u32 guc_fw_size,
 
return 0;
 }
+
+struct lockable_reg {
+   const char *name;
+   struct intel_guc *guc;
+   i915_reg_t reg;
+   u32 reg_val;
+   u32 lock_bit;
+   bool (*validate)(struct lockable_reg *lreg, u32 reg_val, u32 new_val);
+};
+
+static inline u32 lockable_reg_read(struct lockable_reg *lreg)
+{
+   struct drm_i915_private *dev_priv = guc_to_i915(lreg->guc);
+
+   lreg->reg_val = I915_READ(lreg->reg);
+
+   return lreg->reg_val;
+}
+
+static inline bool lockable_reg_validate(struct lockable_reg *lreg, u32 
new_val)
+{
+   GEM_BUG_ON(!lreg->validate);
+
+   return lreg->validate(lreg, lreg->reg_val, new_val);
+}
+
+static 

[Intel-gfx] [PATCH v10 5/7] drm/i915/guc: Add HuC firmware size related restriction for Gen9 and CNL A0

[Jackie Li]

On CNL A0 and Gen9, there's a hardware restriction that requires the
available GuC WOPCM size to be larger than or equal to HuC firmware size.

This patch adds new verfication code to ensure the available GuC WOPCM size
to be larger than or equal to HuC firmware size on both Gen9 and CNL A0.

v6:
 - Extended HuC FW size check against GuC WOPCM size to all
   Gen9 and CNL A0 platforms

v7:
 - Fixed patch format issues

v8:
 - Renamed variables and functions to avoid ambiguity (Joonas)
 - Updated commit message and comments to be more comprehensive (Sagar)

v9:
 - Moved code that is not related to restriction check into a separate
   patch and updated the commit message accordingly (Sagar/Michal)
 - Avoided to call uc_get_fw_size for better layer isolation (Michal)

v10:
 - Shorten function names and reorganized size_check code to have clear
   isolation (Joonas)
 - Removed unnecessary comments (Joonas)

Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: John Spotswood 
Cc: Jeff McGee 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Reviewed-by: Sagar Arun Kamble  (v8)
Signed-off-by: Jackie Li 
---
 drivers/gpu/drm/i915/intel_guc_wopcm.c | 26 ++
 1 file changed, 22 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_wopcm.c 
b/drivers/gpu/drm/i915/intel_guc_wopcm.c
index 9a276fe..0194266 100644
--- a/drivers/gpu/drm/i915/intel_guc_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_guc_wopcm.c
@@ -19,6 +19,20 @@ static inline u32 context_reserved_size(struct intel_guc 
*guc)
return 0;
 }
 
+static inline int check_huc_fw_fits(struct intel_guc_wopcm *guc_wopcm,
+   u32 huc_fw_size)
+{
+   /*
+* On Gen9 & CNL A0, hardware requires the total available GuC WOPCM
+* size to be larger than or equal to HuC firmware size. Otherwise,
+* firmware uploading would fail.
+*/
+   if (guc_wopcm->size - GUC_WOPCM_RESERVED < huc_fw_size)
+   return -E2BIG;
+
+   return 0;
+}
+
 static inline int gen9_check_dword_gap(struct intel_guc_wopcm *guc_wopcm)
 {
u32 guc_wopcm_start;
@@ -40,15 +54,19 @@ static inline int gen9_check_dword_gap(struct 
intel_guc_wopcm *guc_wopcm)
return 0;
 }
 
-static inline int guc_wopcm_size_check(struct intel_guc *guc)
+static inline int guc_wopcm_size_check(struct intel_guc *guc, u32 huc_fw_size)
 {
struct drm_i915_private *i915 = guc_to_i915(guc);
struct intel_guc_wopcm *guc_wopcm = >wopcm;
+   int err = 0;
 
if (IS_GEN9(i915))
-   return gen9_check_dword_gap(guc_wopcm);
+   err = gen9_check_dword_gap(guc_wopcm);
 
-   return 0;
+   if (IS_GEN9(i915) || IS_CNL_REVID(i915, CNL_REVID_A0, CNL_REVID_A0))
+   err = check_huc_fw_fits(guc_wopcm, huc_fw_size);
+
+   return err;
 }
 
 /**
@@ -121,7 +139,7 @@ int intel_guc_wopcm_init(struct intel_guc_wopcm *guc_wopcm, 
u32 guc_fw_size,
guc->wopcm.size = size;
guc->wopcm.top = top;
 
-   err = guc_wopcm_size_check(guc);
+   err = guc_wopcm_size_check(guc, huc_fw_size);
if (err) {
DRM_DEBUG_DRIVER("GuC WOPCM size check failed.\n");
return err;
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v10 7/7] HAX Enable GuC Submission for CI

[Jackie Li]

Signed-off-by: Jackie Li 
---
 drivers/gpu/drm/i915/i915_params.c | 2 +-
 drivers/gpu/drm/i915/i915_params.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 08108ce..b49ae20 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -152,7 +152,7 @@ i915_param_named_unsafe(edp_vswing, int, 0400,
 i915_param_named_unsafe(enable_guc, int, 0400,
"Enable GuC load for GuC submission and/or HuC load. "
"Required functionality can be selected using bitmask values. "
-   "(-1=auto, 0=disable [default], 1=GuC submission, 2=HuC load)");
+   "(-1=auto [default], 0=disable, 1=GuC submission, 2=HuC load)");
 
 i915_param_named(guc_log_level, int, 0400,
"GuC firmware logging level. Requires GuC to be loaded. "
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 430f5f9..3deae1e 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -47,7 +47,7 @@ struct drm_printer;
param(int, disable_power_well, -1) \
param(int, enable_ips, 1) \
param(int, invert_brightness, 0) \
-   param(int, enable_guc, 0) \
+   param(int, enable_guc, -1) \
param(int, guc_log_level, 0) \
param(char *, guc_firmware_path, NULL) \
param(char *, huc_firmware_path, NULL) \
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v10 3/7] drm/i915/guc: Implement dynamic GuC WOPCM offset and size

[Jackie Li]

Hardware may have specific restrictions on GuC WOPCM offset and size. On
Gen9, the value of the GuC WOPCM size register needs to be larger than the
value of GuC WOPCM offset register + a Gen9 specific offset (144KB) for
reserved GuC WOPCM. Fail to enforce such a restriction on GuC WOPCM size
will lead to GuC firmware execution failures. So we need add code to verify
the GuC WOPCM offset and size to avoid any GuC failures. On the other hand,
with current static GuC WOPCM offset and size values (512KB for both offset
and size), the GuC WOPCM size verification will fail on Gen9 even if it can
be fixed by lowering the GuC WOPCM offset by calculating its value based on
HuC firmware size (which is likely less than 200KB on Gen9), so that we can
have a GuC WOPCM size value which is large enough to pass the GuC WOPCM
size check.

This patch updates the reserved GuC WOPCM size for RC6 context on Gen9 to
24KB to strictly align with the Gen9 GuC WOPCM layout and add support to
return CNL specific hardware reserved GuC WOPCM size. It also adds support
to verify the GuC WOPCM size aganist the Gen9 hardware restrictions.
Meanwhile, it provides a common way to calculate GuC WOPCM offset and size
based on GuC and HuC firmware sizes for all GuC/HuC enabled platforms.
Currently, GuC WOPCM offset is calculated based on HuC firmware size +
reserved WOPCM size while GuC WOPCM size is set to total WOPCM size - GuC
WOPCM offset - hardware reserved GuC WOPCM size. In this case, GuC WOPCM
offset will be updated based on the size of HuC firmware while GuC WOPCM
size will be set to use all the remaining WOPCM space.

v2:
 - Removed intel_wopcm_init (Ville/Sagar/Joonas)
 - Renamed and Moved the intel_wopcm_partition into intel_guc (Sagar)
 - Removed unnecessary function calls (Joonas)
 - Init GuC WOPCM partition as soon as firmware fetching is completed

v3:
 - Fixed indentation issues (Chris)
 - Removed layering violation code (Chris/Michal)
 - Created separat files for GuC wopcm code  (Michal)
 - Used inline function to avoid code duplication (Michal)

v4:
 - Preset the GuC WOPCM top during early GuC init (Chris)
 - Fail intel_uc_init_hw() as soon as GuC WOPCM partitioning failed

v5:
 - Moved GuC DMA WOPCM register updating code into intel_guc_wopcm.c
 - Took care of the locking status before writing to GuC DMA
   Write-Once registers. (Joonas)

v6:
 - Made sure the GuC WOPCM size to be multiple of 4K (4K aligned)

v8:
 - Updated comments and fixed naming issues (Sagar/Joonas)
 - Updated commit message to include more description about the hardware
   restriction on GuC WOPCM size (Sagar)

v9:
 - Minor changes variable names and code comments (Sagar)
 - Added detailed GuC WOPCM layout drawing (Sagar/Michal)
 - Refined macro definitions to be reader friendly (Michal)
 - Removed redundent check to valid flag (Michal)
 - Unified first parameter for exported GuC WOPCM functions (Michal)
 - Refined the name and parameter list of hardware restriction checking
   functions (Michal)

v10:
 - Used shorter function name for internal functions (Joonas)
 - Moved init-ealry function into c file (Joonas)
 - Consolidated and removed redundant size checks (Joonas/Michal)
 - Removed unnecessary unlikely() from code which is only called once
   during boot (Joonas)
 - More fixes to kernel-doc format and content (Michal)
 - Avoided the use of PAGE_MASK for 4K pages (Michal)
 - Added error log messages to error paths (Michal)

Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Sujaritha Sundaresan 
Cc: Daniele Ceraolo Spurio 
Cc: John Spotswood 
Cc: Oscar Mateo 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Reviewed-by: Sagar Arun Kamble  (v8)
Reviewed-by: Joonas Lahtinen  (v9)
Signed-off-by: Jackie Li 
---
 drivers/gpu/drm/i915/i915_gem_context.c |   5 +-
 drivers/gpu/drm/i915/intel_guc.c|   5 +-
 drivers/gpu/drm/i915/intel_guc.h|  12 +--
 drivers/gpu/drm/i915/intel_guc_reg.h|   2 +
 drivers/gpu/drm/i915/intel_guc_wopcm.c  | 128 +---
 drivers/gpu/drm/i915/intel_guc_wopcm.h  |  72 --
 drivers/gpu/drm/i915/intel_huc.c|   2 +-
 drivers/gpu/drm/i915/intel_uc.c |  11 ++-
 drivers/gpu/drm/i915/intel_uc_fw.c  |  11 ++-
 drivers/gpu/drm/i915/intel_uc_fw.h  |  16 
 10 files changed, 231 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 3d75f48..414eab2 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -312,12 +312,13 @@ __create_hw_context(struct drm_i915_private *dev_priv,
ctx->desc_template =

[Intel-gfx] [PATCH v10 1/7] drm/i915/guc: Move GuC WOPCM related code into separate files

[Jackie Li]

intel_guc_reg.h should only include definition for GuC registers and
related register bits. Non-register related GuC WOPCM macro definitions
should not be defined in intel_guc_reg.h.

This patch cleans up intel_guc_reg.h and moves GuC WOPCM related code into
new created separate files as future patches will increase the complexity
of determining the GuC WOPCM offset and size.

v8:
 - Fixed naming, coding style issues and typo in commit message (Sagar)
 - Updated commit message to explain why we need create new file for GuC
   WOPCM related code (Chris)

v9:
 - Corrected kernel-doc format (Sagar)
 - Simplified commit message (Michal)
 - Updated license of new created files to use SPDX (Michal)
 - Updated macros and added more comments to be reader friendly (Michal)

v10:
 - Updated license to just use SPDX (Michal/Michel)

Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Michel Thierry 
Reviewed-by: Sagar Arun Kamble  (v8)
Signed-off-by: Jackie Li 
---
 drivers/gpu/drm/i915/Makefile  |  1 +
 drivers/gpu/drm/i915/intel_guc.c   | 11 ---
 drivers/gpu/drm/i915/intel_guc.h   |  2 +-
 drivers/gpu/drm/i915/intel_guc_reg.h   |  4 
 drivers/gpu/drm/i915/intel_guc_wopcm.c | 28 
 drivers/gpu/drm/i915/intel_guc_wopcm.h | 25 +
 drivers/gpu/drm/i915/intel_uc.c|  2 +-
 drivers/gpu/drm/i915/intel_uc_fw.c |  2 +-
 8 files changed, 57 insertions(+), 18 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_guc_wopcm.c
 create mode 100644 drivers/gpu/drm/i915/intel_guc_wopcm.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index f55cc02..418d96b 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -89,6 +89,7 @@ i915-y += intel_uc.o \
  intel_guc_fw.o \
  intel_guc_log.o \
  intel_guc_submission.o \
+ intel_guc_wopcm.o \
  intel_huc.o
 
 # autogenerated null render state
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 21140cc..9f45e6d 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -509,14 +509,3 @@ struct i915_vma *intel_guc_allocate_vma(struct intel_guc 
*guc, u32 size)
i915_gem_object_put(obj);
return vma;
 }
-
-u32 intel_guc_wopcm_size(struct drm_i915_private *dev_priv)
-{
-   u32 wopcm_size = GUC_WOPCM_TOP;
-
-   /* On BXT, the top of WOPCM is reserved for RC6 context */
-   if (IS_GEN9_LP(dev_priv))
-   wopcm_size -= BXT_GUC_WOPCM_RC6_RESERVED;
-
-   return wopcm_size;
-}
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 52856a9..9e0a97e 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -31,6 +31,7 @@
 #include "intel_guc_ct.h"
 #include "intel_guc_log.h"
 #include "intel_guc_reg.h"
+#include "intel_guc_wopcm.h"
 #include "intel_uc_fw.h"
 #include "i915_vma.h"
 
@@ -130,6 +131,5 @@ int intel_guc_auth_huc(struct intel_guc *guc, u32 
rsa_offset);
 int intel_guc_suspend(struct drm_i915_private *dev_priv);
 int intel_guc_resume(struct drm_i915_private *dev_priv);
 struct i915_vma *intel_guc_allocate_vma(struct intel_guc *guc, u32 size);
-u32 intel_guc_wopcm_size(struct drm_i915_private *dev_priv);
 
 #endif
diff --git a/drivers/gpu/drm/i915/intel_guc_reg.h 
b/drivers/gpu/drm/i915/intel_guc_reg.h
index 19a9247..1f52fb8 100644
--- a/drivers/gpu/drm/i915/intel_guc_reg.h
+++ b/drivers/gpu/drm/i915/intel_guc_reg.h
@@ -68,7 +68,6 @@
 #define DMA_GUC_WOPCM_OFFSET   _MMIO(0xc340)
 #define   HUC_LOADING_AGENT_VCR  (0<<1)
 #define   HUC_LOADING_AGENT_GUC  (1<<1)
-#define   GUC_WOPCM_OFFSET_VALUE 0x8   /* 512KB */
 #define GUC_MAX_IDLE_COUNT _MMIO(0xC3E4)
 
 #define HUC_STATUS2 _MMIO(0xD3B0)
@@ -76,9 +75,6 @@
 
 /* Defines WOPCM space available to GuC firmware */
 #define GUC_WOPCM_SIZE _MMIO(0xc050)
-/* GuC addresses below GUC_WOPCM_TOP don't map through the GTT */
-#define   GUC_WOPCM_TOP  (0x80 << 12)  /* 512KB */
-#define   BXT_GUC_WOPCM_RC6_RESERVED (0x10 << 12)  /* 64KB  */
 
 /* GuC addresses above GUC_GGTT_TOP also don't map through the GTT */
 #define GUC_GGTT_TOP   0xFEE0
diff --git a/drivers/gpu/drm/i915/intel_guc_wopcm.c 
b/drivers/gpu/drm/i915/intel_guc_wopcm.c
new file mode 100644
index 000..3972901
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_guc_wopcm.c
@@ -0,0 +1,28 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2017-2018 Intel Corporation
+ */
+
+#include "intel_guc_wopcm.h"
+#include "i915_drv.h"
+
+/**
+ * intel_guc_wopcm_size() - Get the size of 

[Intel-gfx] [PATCH v10 4/7] drm/i915/guc: Add support to return CNL specific reserved GuC WOPCM size

[Jackie Li]

CNL has its specific reserved GuC WOPCM size for RC6 and other hardware
contexts.

This patch updates the code to return CNL specific reserved GuC WOPCM size
for RC6 and other hardware contexts so that the GuC WOPCM size can be
calculated correctly for CNL.

v9:
 - Created a new patch for these changes originally made in v8 4/6 patch of
   this series (Sagar/Michal)

v10:
 - Used if-else ladder to the returning of context sizes (Joonas)

Cc: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Reviewed-by: Joonas Lahtinen  (v9)
Signed-off-by: Jackie Li 
---
 drivers/gpu/drm/i915/intel_guc_wopcm.c | 6 --
 drivers/gpu/drm/i915/intel_guc_wopcm.h | 2 ++
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_wopcm.c 
b/drivers/gpu/drm/i915/intel_guc_wopcm.c
index cf832b9..9a276fe 100644
--- a/drivers/gpu/drm/i915/intel_guc_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_guc_wopcm.c
@@ -13,8 +13,10 @@ static inline u32 context_reserved_size(struct intel_guc 
*guc)
 
if (IS_GEN9_LP(i915))
return BXT_GUC_WOPCM_RC6_CTX_RESERVED;
-
-   return 0;
+   else if (INTEL_GEN(i915) >= 10)
+   return CNL_GUC_WOPCM_HW_CTX_RESERVED;
+   else
+   return 0;
 }
 
 static inline int gen9_check_dword_gap(struct intel_guc_wopcm *guc_wopcm)
diff --git a/drivers/gpu/drm/i915/intel_guc_wopcm.h 
b/drivers/gpu/drm/i915/intel_guc_wopcm.h
index a632caa..13fcab6 100644
--- a/drivers/gpu/drm/i915/intel_guc_wopcm.h
+++ b/drivers/gpu/drm/i915/intel_guc_wopcm.h
@@ -52,6 +52,8 @@ struct intel_guc;
 #define GUC_WOPCM_STACK_RESERVED   (8 << 10)
 /* 24KB at the end of GuC WOPCM is reserved for RC6 CTX on BXT. */
 #define BXT_GUC_WOPCM_RC6_CTX_RESERVED (24 << 10)
+/* 36KB WOPCM reserved at the end of GuC WOPCM on CNL. */
+#define CNL_GUC_WOPCM_HW_CTX_RESERVED  (36 << 10)
 
 /*
  * GuC WOPCM starts at 144KB (GUC_WOPCM_RESERVED + 128KB reserved for GuC
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for Queued/runnable/running engine stats (rev2)

[Patchwork]

== Series Details ==

Series: Queued/runnable/running engine stats (rev2)
URL   : https://patchwork.freedesktop.org/series/36926/
State : failure

== Summary ==

Test kms_plane_scaling:
Subgroup pipe-a-scaler-with-rotation:
skip   -> PASS   (shard-apl)
Test kms_vblank:
Subgroup pipe-b-wait-busy:
skip   -> PASS   (shard-apl)
Test kms_color:
Subgroup pipe-c-ctm-max:
skip   -> PASS   (shard-apl)
Subgroup pipe-c-degamma:
skip   -> PASS   (shard-apl)
Subgroup pipe-b-ctm-green-to-red:
skip   -> PASS   (shard-apl)
Test pm_rpm:
Subgroup gem-mmap-cpu:
skip   -> PASS   (shard-apl)
Subgroup system-suspend-modeset:
skip   -> PASS   (shard-apl)
Test kms_flip:
Subgroup dpms-vs-vblank-race:
pass   -> FAIL   (shard-hsw) fdo#103060
Subgroup blocking-absolute-wf_vblank:
skip   -> PASS   (shard-apl)
Subgroup wf_vblank-ts-check-interruptible:
skip   -> PASS   (shard-apl) fdo#100368
Test gem_eio:
Subgroup in-flight-internal:
pass   -> INCOMPLETE (shard-snb)
pass   -> INCOMPLETE (shard-apl)
Subgroup in-flight-external:
pass   -> INCOMPLETE (shard-snb)
pass   -> INCOMPLETE (shard-hsw) fdo#104676
pass   -> INCOMPLETE (shard-apl)
Test kms_mmio_vs_cs_flip:
Subgroup setcrtc_vs_cs_flip:
skip   -> PASS   (shard-apl)
Test kms_cursor_legacy:
Subgroup flip-vs-cursor-crc-legacy:
skip   -> PASS   (shard-apl)
Subgroup cursora-vs-flipa-legacy:
skip   -> PASS   (shard-apl)
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-indfb-draw-render:
skip   -> PASS   (shard-apl) fdo#103167 +1
Test kms_rmfb:
Subgroup rmfb-ioctl:
skip   -> PASS   (shard-apl)
Test kms_rotation_crc:
Subgroup exhaust-fences:
skip   -> PASS   (shard-apl)
Subgroup cursor-rotation-180:
pass   -> FAIL   (shard-hsw) fdo#102614

fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#104676 https://bugs.freedesktop.org/show_bug.cgi?id=104676
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614

shard-apltotal:3280 pass:1694 dwarn:1   dfail:0   fail:21  skip:1561 
time:12820s
shard-hswtotal:3356 pass:1674 dwarn:1   dfail:0   fail:55  skip:1624 
time:14315s
shard-snbtotal:3297 pass:1291 dwarn:1   dfail:0   fail:11  skip:1992 
time:7179s
Blacklisted hosts:
shard-kbltotal:3297 pass:1828 dwarn:1   dfail:0   fail:22  skip:1444 
time:10284s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7985/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for RFC drm/i915: Only acquire vblank-irq when waiting for vblank evade (rev2)

[Patchwork]

== Series Details ==

Series: RFC drm/i915: Only acquire vblank-irq when waiting for vblank evade 
(rev2)
URL   : https://patchwork.freedesktop.org/series/38109/
State : failure

== Summary ==

Series 38109v2 RFC drm/i915: Only acquire vblank-irq when waiting for vblank 
evade
https://patchwork.freedesktop.org/api/1.0/series/38109/revisions/2/mbox/

Test prime_vgem:
Subgroup basic-fence-flip:
fail   -> PASS   (fi-ilk-650)
pass   -> FAIL   (fi-ivb-3770)

fi-bdw-5557u total:288  pass:265  dwarn:0   dfail:0   fail:2   skip:21  
time:441s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:424s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:376s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:498s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:289s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:484s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:487s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:475s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:462s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:569s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:580s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:420s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:288s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:514s
fi-hsw-4770  total:288  pass:259  dwarn:0   dfail:0   fail:2   skip:27  
time:413s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:417s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:459s
fi-ivb-3770  total:288  pass:254  dwarn:0   dfail:0   fail:1   skip:33  
time:414s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:458s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:492s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:503s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:589s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:435s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:511s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:529s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:496s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:486s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:415s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:432s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:527s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:398s
Blacklisted hosts:
fi-glk-dsi   total:246  pass:219  dwarn:0   dfail:0   fail:0   skip:26 

83878f486e686dd291ef3566a45103962d7617ed drm-tip: 2018y-02m-12d-17h-43m-07s UTC 
integration manifest
0cdeaaf88e2a RFC drm/i915: Only acquire vblank-irq when waiting for vblank evade

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7988/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for tests/kms_rotation_crc: Remove hardcoding of platforms in igt_require()

[Patchwork]

== Series Details ==

Series: tests/kms_rotation_crc: Remove hardcoding of platforms in igt_require()
URL   : https://patchwork.freedesktop.org/series/38108/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
f8d6fa4fa04103b027430f960f2c55d24c4a9600 igt/gem_exec_capture: MI_STORE_DWORD 
requires EXEC_SECURE + DRM_MASTER on ctg/ilk

with latest DRM-Tip kernel build CI_DRM_3757
83878f486e68 drm-tip: 2018y-02m-12d-17h-43m-07s UTC integration manifest

No testlist changes.

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713
Test prime_vgem:
Subgroup basic-fence-flip:
fail   -> PASS   (fi-ilk-650)

fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713

fi-bdw-5557u total:288  pass:265  dwarn:0   dfail:0   fail:2   skip:21  
time:440s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:434s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:375s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:496s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:290s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:480s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:489s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:475s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:460s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:566s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:584s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:419s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:285s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:513s
fi-hsw-4770  total:288  pass:259  dwarn:0   dfail:0   fail:2   skip:27  
time:411s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:418s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:452s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:416s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:459s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:499s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:502s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:589s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:427s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:513s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:529s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:492s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:477s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:417s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:431s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:398s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:472s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_905/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2] RFC drm/i915: Only acquire vblank-irq when waiting for vblank evade

[Chris Wilson]

Cc: Ville Syrjälä 
Cc: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_sprite.c | 65 ++---
 1 file changed, 38 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index e098e4b2c85c..ad707c97a9d9 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -74,6 +74,14 @@ int intel_usecs_to_scanlines(const struct drm_display_mode 
*adjusted_mode,
 #define VBLANK_EVASION_TIME_US 100
 #endif
 
+static inline bool scanline_in_vblank(struct intel_crtc *crtc,
+ int min, int max,
+ int *scanline)
+{
+   *scanline = intel_get_crtc_scanline(crtc);
+   return *scanline < min || *scanline > max;
+}
+
 /**
  * intel_pipe_update_start() - start update of a set of display registers
  * @new_crtc_state: the new crtc state
@@ -91,12 +99,9 @@ void intel_pipe_update_start(const struct intel_crtc_state 
*new_crtc_state)
struct intel_crtc *crtc = to_intel_crtc(new_crtc_state->base.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
const struct drm_display_mode *adjusted_mode = 
_crtc_state->base.adjusted_mode;
-   long timeout = msecs_to_jiffies_timeout(1);
int scanline, min, max, vblank_start;
-   wait_queue_head_t *wq = drm_crtc_vblank_waitqueue(>base);
bool need_vlv_dsi_wa = (IS_VALLEYVIEW(dev_priv) || 
IS_CHERRYVIEW(dev_priv)) &&
intel_crtc_has_type(new_crtc_state, INTEL_OUTPUT_DSI);
-   DEFINE_WAIT(wait);
 
vblank_start = adjusted_mode->crtc_vblank_start;
if (adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE)
@@ -112,41 +117,46 @@ void intel_pipe_update_start(const struct 
intel_crtc_state *new_crtc_state)
if (min <= 0 || max <= 0)
return;
 
-   if (WARN_ON(drm_crtc_vblank_get(>base)))
-   return;
-
crtc->debug.min_vbl = min;
crtc->debug.max_vbl = max;
trace_i915_pipe_update_start(crtc);
 
-   for (;;) {
-   /*
-* prepare_to_wait() has a memory barrier, which guarantees
-* other CPUs can see the task state update by the time we
-* read the scanline.
-*/
-   prepare_to_wait(wq, , TASK_UNINTERRUPTIBLE);
+   if (!scanline_in_vblank(crtc, min, max, )) {
+   wait_queue_head_t *wq = drm_crtc_vblank_waitqueue(>base);
+   long timeout = msecs_to_jiffies_timeout(1);
+   DEFINE_WAIT(wait);
 
-   scanline = intel_get_crtc_scanline(crtc);
-   if (scanline < min || scanline > max)
-   break;
+   if (WARN_ON(drm_crtc_vblank_get(>base)))
+   goto skip_evade;
 
-   if (timeout <= 0) {
-   DRM_ERROR("Potential atomic update failure on pipe 
%c\n",
- pipe_name(crtc->pipe));
-   break;
-   }
+   for (;;) {
+   /*
+* prepare_to_wait() has a memory barrier, which
+* guarantees other CPUs can see the task state update
+* by the time we read the scanline.
+*/
+   prepare_to_wait(wq, , TASK_UNINTERRUPTIBLE);
 
-   local_irq_enable();
+   if (scanline_in_vblank(crtc, min, max, ))
+   break;
 
-   timeout = schedule_timeout(timeout);
+   if (timeout <= 0) {
+   DRM_ERROR("Potential atomic update failure on 
pipe %c\n",
+ pipe_name(crtc->pipe));
+   break;
+   }
 
-   local_irq_disable();
-   }
+   local_irq_enable();
 
-   finish_wait(wq, );
+   timeout = schedule_timeout(timeout);
 
-   drm_crtc_vblank_put(>base);
+   local_irq_disable();
+   }
+
+   finish_wait(wq, );
+
+   drm_crtc_vblank_put(>base);
+   }
 
/*
 * On VLV/CHV DSI the scanline counter would appear to
@@ -166,6 +176,7 @@ void intel_pipe_update_start(const struct intel_crtc_state 
*new_crtc_state)
while (need_vlv_dsi_wa && scanline == vblank_start)
scanline = intel_get_crtc_scanline(crtc);
 
+skip_evade:
crtc->debug.scanline_start = scanline;
crtc->debug.start_vbl_time = ktime_get();
crtc->debug.start_vbl_count = intel_crtc_get_vblank_counter(crtc);
-- 
2.16.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org

[Intel-gfx] ✓ Fi.CI.IGT: success for AWOOGA: Revert "ALSA: hda: Make use of core codec functions to sync power state"

[Patchwork]

== Series Details ==

Series: AWOOGA: Revert "ALSA: hda: Make use of core codec functions to sync 
power state"
URL   : https://patchwork.freedesktop.org/series/38097/
State : success

== Summary ==

Test pm_rpm:
Subgroup gem-execbuf:
fail   -> PASS   (shard-hsw)
Subgroup debugfs-read:
fail   -> PASS   (shard-hsw)
Subgroup modeset-lpsp:
fail   -> SKIP   (shard-hsw)
Subgroup universal-planes-dpms:
fail   -> PASS   (shard-hsw)
Subgroup universal-planes:
fail   -> PASS   (shard-hsw)
Subgroup gem-pread:
fail   -> PASS   (shard-hsw)
Subgroup modeset-non-lpsp:
fail   -> PASS   (shard-hsw)
Subgroup drm-resources-equal:
fail   -> PASS   (shard-hsw)
Subgroup modeset-non-lpsp-stress:
fail   -> PASS   (shard-hsw)
Subgroup gem-idle:
fail   -> PASS   (shard-hsw)
Subgroup reg-read-ioctl:
fail   -> PASS   (shard-hsw)
Subgroup modeset-lpsp-stress:
fail   -> SKIP   (shard-hsw)
Subgroup legacy-planes-dpms:
fail   -> PASS   (shard-hsw)
Subgroup system-suspend:
fail   -> PASS   (shard-hsw) fdo#103375 +1
Subgroup dpms-non-lpsp:
fail   -> PASS   (shard-hsw)
Subgroup pm-caching:
fail   -> PASS   (shard-hsw)
Subgroup gem-execbuf-stress-extra-wait:
fail   -> PASS   (shard-hsw)
Subgroup fences:
fail   -> PASS   (shard-hsw)
Subgroup gem-execbuf-stress:
fail   -> PASS   (shard-hsw)
Subgroup dpms-mode-unset-non-lpsp:
fail   -> PASS   (shard-hsw)
Subgroup dpms-lpsp:
fail   -> SKIP   (shard-hsw)
Subgroup modeset-stress-extra-wait:
fail   -> PASS   (shard-hsw)
Subgroup cursor-dpms:
fail   -> PASS   (shard-hsw)
Subgroup pm-tiling:
fail   -> PASS   (shard-hsw)
Subgroup gem-mmap-cpu:
fail   -> PASS   (shard-hsw)
skip   -> PASS   (shard-apl)
Subgroup system-suspend-modeset:
fail   -> PASS   (shard-hsw)
skip   -> PASS   (shard-apl)
Subgroup basic-pci-d3-state:
fail   -> PASS   (shard-hsw)
Subgroup gem-evict-pwrite:
fail   -> PASS   (shard-hsw)
Subgroup basic-rte:
fail   -> PASS   (shard-hsw)
Subgroup debugfs-forcewake-user:
fail   -> PASS   (shard-hsw)
Subgroup dpms-mode-unset-lpsp:
fail   -> SKIP   (shard-hsw)
Subgroup gem-mmap-gtt:
fail   -> PASS   (shard-hsw)
Subgroup legacy-planes:
fail   -> PASS   (shard-hsw)
Subgroup sysfs-read:
fail   -> PASS   (shard-hsw)
Subgroup cursor:
fail   -> PASS   (shard-hsw)
Subgroup fences-dpms:
fail   -> PASS   (shard-hsw)
Test kms_vblank:
Subgroup pipe-b-ts-continuation-modeset-rpm:
fail   -> PASS   (shard-hsw)
Subgroup pipe-c-ts-continuation-dpms-rpm:
fail   -> PASS   (shard-hsw)
Subgroup pipe-c-ts-continuation-modeset-rpm:
fail   -> PASS   (shard-hsw)
Subgroup pipe-b-wait-busy:
skip   -> PASS   (shard-apl)
Subgroup pipe-a-ts-continuation-dpms-rpm:
fail   -> PASS   (shard-hsw)
Subgroup pipe-b-ts-continuation-dpms-rpm:
fail   -> PASS   (shard-hsw)
Subgroup pipe-a-ts-continuation-modeset-rpm:
fail   -> PASS   (shard-hsw)
Test kms_plane_scaling:
Subgroup pipe-a-scaler-with-rotation:
skip   -> PASS   (shard-apl)
Test kms_color:
Subgroup pipe-c-ctm-max:
skip   -> PASS   (shard-apl)
Subgroup pipe-c-degamma:
skip   -> PASS   (shard-apl)
Subgroup pipe-b-ctm-green-to-red:
skip   -> PASS   (shard-apl)
Test pm_lpsp:
Subgroup screens-disabled:
fail   -> PASS   (shard-hsw) fdo#104941
Test gem_eio:
Subgroup in-flight-external:
pass   -> FAIL   (shard-hsw) fdo#104676
Test perf_pmu:
Subgroup rc6-runtime-pm:
skip   -> PASS   (shard-hsw) fdo#105010 +1
Test kms_mmio_vs_cs_flip:
Subgroup 

[Intel-gfx] ✗ Fi.CI.BAT: warning for RFC drm/i915: Only acquire vblank-irq when waiting for vblank evade

[Patchwork]

== Series Details ==

Series: RFC drm/i915: Only acquire vblank-irq when waiting for vblank evade
URL   : https://patchwork.freedesktop.org/series/38109/
State : warning

== Summary ==

Series 38109v1 RFC drm/i915: Only acquire vblank-irq when waiting for vblank 
evade
https://patchwork.freedesktop.org/api/1.0/series/38109/revisions/1/mbox/

Test core_auth:
Subgroup basic-auth:
pass   -> DMESG-WARN (fi-gdg-551)
pass   -> DMESG-WARN (fi-blb-e6850)
pass   -> DMESG-WARN (fi-pnv-d510)
pass   -> DMESG-WARN (fi-bwr-2160)
pass   -> DMESG-WARN (fi-elk-e7500)
pass   -> DMESG-WARN (fi-ilk-650)
pass   -> DMESG-WARN (fi-snb-2520m)
pass   -> DMESG-WARN (fi-snb-2600)
pass   -> DMESG-WARN (fi-ivb-3520m)
pass   -> DMESG-WARN (fi-ivb-3770)
pass   -> DMESG-WARN (fi-byt-j1900)
pass   -> DMESG-WARN (fi-byt-n2820)
pass   -> DMESG-WARN (fi-hsw-4770)
pass   -> DMESG-WARN (fi-bdw-5557u)
pass   -> DMESG-WARN (fi-bdw-gvtdvm)
pass   -> DMESG-WARN (fi-bsw-n3050)
pass   -> DMESG-WARN (fi-skl-6260u)
pass   -> DMESG-WARN (fi-skl-6600u)
pass   -> DMESG-WARN (fi-skl-6700hq)
pass   -> DMESG-WARN (fi-skl-6700k2)
pass   -> DMESG-WARN (fi-skl-6770hq)
pass   -> DMESG-WARN (fi-skl-guc)
pass   -> DMESG-WARN (fi-skl-gvtdvm)
pass   -> DMESG-WARN (fi-bxt-j4205)
pass   -> DMESG-WARN (fi-kbl-7500u)
pass   -> DMESG-WARN (fi-kbl-7560u)
pass   -> DMESG-WARN (fi-kbl-r)
pass   -> DMESG-WARN (fi-glk-1)
pass   -> DMESG-WARN (fi-cfl-s2)
pass   -> DMESG-WARN (fi-cnl-y3)
Test core_prop_blob:
Subgroup basic:
pass   -> DMESG-WARN (fi-gdg-551)
pass   -> DMESG-WARN (fi-blb-e6850)
pass   -> DMESG-WARN (fi-pnv-d510)
pass   -> DMESG-WARN (fi-bwr-2160)
pass   -> DMESG-WARN (fi-elk-e7500)
pass   -> DMESG-WARN (fi-ilk-650)
pass   -> DMESG-WARN (fi-snb-2520m)
pass   -> DMESG-WARN (fi-snb-2600)
pass   -> DMESG-WARN (fi-ivb-3520m)
pass   -> DMESG-WARN (fi-ivb-3770)
pass   -> DMESG-WARN (fi-byt-j1900)
pass   -> DMESG-WARN (fi-byt-n2820)
pass   -> DMESG-WARN (fi-hsw-4770)
pass   -> DMESG-WARN (fi-bdw-5557u)
pass   -> DMESG-WARN (fi-bdw-gvtdvm)
pass   -> DMESG-WARN (fi-bsw-n3050)
pass   -> DMESG-WARN (fi-skl-6260u)
pass   -> DMESG-WARN (fi-skl-6600u)
pass   -> DMESG-WARN (fi-skl-6700hq)
pass   -> DMESG-WARN (fi-skl-6700k2)
pass   -> DMESG-WARN (fi-skl-6770hq)
pass   -> DMESG-WARN (fi-skl-guc)
pass   -> DMESG-WARN (fi-skl-gvtdvm)
pass   -> DMESG-WARN (fi-bxt-j4205)
pass   -> DMESG-WARN (fi-kbl-7500u)
pass   -> DMESG-WARN (fi-kbl-7560u)
pass   -> DMESG-WARN (fi-kbl-r)
pass   -> DMESG-WARN (fi-glk-1)
pass   -> DMESG-WARN (fi-cfl-s2)
pass   -> DMESG-WARN (fi-cnl-y3)
Test debugfs_test:
Subgroup read_all_entries:
pass   -> DMESG-WARN (fi-gdg-551)
pass   -> DMESG-WARN (fi-blb-e6850)
pass   -> DMESG-WARN (fi-pnv-d510)
pass   -> DMESG-WARN (fi-bwr-2160)
pass   -> DMESG-WARN (fi-elk-e7500) fdo#103989 +16
pass   -> DMESG-WARN (fi-ilk-650)
pass   -> DMESG-WARN (fi-snb-2520m) fdo#103713 +1
pass   -> DMESG-WARN (fi-snb-2600)
pass   -> DMESG-WARN (fi-ivb-3520m)
pass   -> DMESG-WARN (fi-ivb-3770)
pass   -> DMESG-WARN (fi-byt-j1900)
pass   -> DMESG-WARN (fi-byt-n2820)
pass   -> DMESG-WARN (fi-hsw-4770)
pass   -> DMESG-WARN (fi-bdw-5557u)
pass   -> DMESG-WARN (fi-bdw-gvtdvm)
pass   -> DMESG-WARN (fi-bsw-n3050)
pass   -> DMESG-WARN (fi-skl-6260u)
pass   -> DMESG-WARN (fi-skl-6600u)
pass   -> DMESG-WARN (fi-skl-6700hq)
pass   -> DMESG-WARN (fi-skl-6700k2)
pass   -> DMESG-WARN 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Release the atomic kmap relocation cache around snb GTT w/a

[Patchwork]

== Series Details ==

Series: drm/i915: Release the atomic kmap relocation cache around snb GTT w/a
URL   : https://patchwork.freedesktop.org/series/38107/
State : success

== Summary ==

Series 38107v1 drm/i915: Release the atomic kmap relocation cache around snb 
GTT w/a
https://patchwork.freedesktop.org/api/1.0/series/38107/revisions/1/mbox/

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
fail   -> PASS   (fi-gdg-551) fdo#102575
Test prime_vgem:
Subgroup basic-fence-flip:
fail   -> PASS   (fi-ilk-650)

fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575

fi-bdw-5557u total:288  pass:265  dwarn:0   dfail:0   fail:2   skip:21  
time:447s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:422s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:375s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:489s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:289s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:485s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:490s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:476s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:461s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:567s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:587s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:416s
fi-gdg-551   total:288  pass:180  dwarn:0   dfail:0   fail:0   skip:108 
time:286s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:515s
fi-hsw-4770  total:288  pass:259  dwarn:0   dfail:0   fail:2   skip:27  
time:413s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:413s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:450s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:418s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:458s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:496s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:502s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:590s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:428s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:508s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:529s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:489s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:473s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:413s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:436s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:526s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:399s
Blacklisted hosts:
fi-glk-dsi   total:117  pass:104  dwarn:0   dfail:0   fail:0   skip:12 

83878f486e686dd291ef3566a45103962d7617ed drm-tip: 2018y-02m-12d-17h-43m-07s UTC 
integration manifest
900fa4b282bc drm/i915: Release the atomic kmap relocation cache around snb GTT 
w/a

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7986/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] RFC drm/i915: Only acquire vblank-irq when waiting for vblank evade

[Chris Wilson]

Cc: Ville Syrjälä 
Cc: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_sprite.c | 65 ++---
 1 file changed, 38 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index e098e4b2c85c..dd8c1f24980f 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -74,6 +74,14 @@ int intel_usecs_to_scanlines(const struct drm_display_mode 
*adjusted_mode,
 #define VBLANK_EVASION_TIME_US 100
 #endif
 
+static inline bool scanline_in_vblank(struct intel_crtc *crtc,
+ int min, int max,
+ int *scanline)
+{
+   *scanline = intel_get_crtc_scanline(crtc);
+   return *scanline < min && *scanline > max;
+}
+
 /**
  * intel_pipe_update_start() - start update of a set of display registers
  * @new_crtc_state: the new crtc state
@@ -91,12 +99,9 @@ void intel_pipe_update_start(const struct intel_crtc_state 
*new_crtc_state)
struct intel_crtc *crtc = to_intel_crtc(new_crtc_state->base.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
const struct drm_display_mode *adjusted_mode = 
_crtc_state->base.adjusted_mode;
-   long timeout = msecs_to_jiffies_timeout(1);
int scanline, min, max, vblank_start;
-   wait_queue_head_t *wq = drm_crtc_vblank_waitqueue(>base);
bool need_vlv_dsi_wa = (IS_VALLEYVIEW(dev_priv) || 
IS_CHERRYVIEW(dev_priv)) &&
intel_crtc_has_type(new_crtc_state, INTEL_OUTPUT_DSI);
-   DEFINE_WAIT(wait);
 
vblank_start = adjusted_mode->crtc_vblank_start;
if (adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE)
@@ -112,41 +117,46 @@ void intel_pipe_update_start(const struct 
intel_crtc_state *new_crtc_state)
if (min <= 0 || max <= 0)
return;
 
-   if (WARN_ON(drm_crtc_vblank_get(>base)))
-   return;
-
crtc->debug.min_vbl = min;
crtc->debug.max_vbl = max;
trace_i915_pipe_update_start(crtc);
 
-   for (;;) {
-   /*
-* prepare_to_wait() has a memory barrier, which guarantees
-* other CPUs can see the task state update by the time we
-* read the scanline.
-*/
-   prepare_to_wait(wq, , TASK_UNINTERRUPTIBLE);
+   if (!scanline_in_vblank(crtc, min, max, )) {
+   wait_queue_head_t *wq = drm_crtc_vblank_waitqueue(>base);
+   long timeout = msecs_to_jiffies_timeout(1);
+   DEFINE_WAIT(wait);
 
-   scanline = intel_get_crtc_scanline(crtc);
-   if (scanline < min || scanline > max)
-   break;
+   if (WARN_ON(drm_crtc_vblank_get(>base)))
+   goto skip_evade;
 
-   if (timeout <= 0) {
-   DRM_ERROR("Potential atomic update failure on pipe 
%c\n",
- pipe_name(crtc->pipe));
-   break;
-   }
+   for (;;) {
+   /*
+* prepare_to_wait() has a memory barrier, which
+* guarantees other CPUs can see the task state update
+* by the time we read the scanline.
+*/
+   prepare_to_wait(wq, , TASK_UNINTERRUPTIBLE);
 
-   local_irq_enable();
+   if (scanline_in_vblank(crtc, min, max, ))
+   break;
 
-   timeout = schedule_timeout(timeout);
+   if (timeout <= 0) {
+   DRM_ERROR("Potential atomic update failure on 
pipe %c\n",
+ pipe_name(crtc->pipe));
+   break;
+   }
 
-   local_irq_disable();
-   }
+   local_irq_enable();
 
-   finish_wait(wq, );
+   timeout = schedule_timeout(timeout);
 
-   drm_crtc_vblank_put(>base);
+   local_irq_disable();
+   }
+
+   finish_wait(wq, );
+
+   drm_crtc_vblank_put(>base);
+   }
 
/*
 * On VLV/CHV DSI the scanline counter would appear to
@@ -166,6 +176,7 @@ void intel_pipe_update_start(const struct intel_crtc_state 
*new_crtc_state)
while (need_vlv_dsi_wa && scanline == vblank_start)
scanline = intel_get_crtc_scanline(crtc);
 
+skip_evade:
crtc->debug.scanline_start = scanline;
crtc->debug.start_vbl_time = ktime_get();
crtc->debug.start_vbl_count = intel_crtc_get_vblank_counter(crtc);
-- 
2.16.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org

[Intel-gfx] [i-g-t] tests/kms_rotation_crc: Remove hardcoding of platforms in igt_require()

[Anusha Srivatsa]

Rework the rotate and reflect subtests by checking the
crtc supported properties against the ones that the
test is testing. Remove the hardcoded platform names in
igt_require()

Cc: Daniel Vetter 
Cc: Rodrigo Vivi 
Cc: Maarten Lankhorst 
Cc: Mika Kahola 
Signed-off-by: Anusha Srivatsa 
---
 tests/kms_rotation_crc.c | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/tests/kms_rotation_crc.c b/tests/kms_rotation_crc.c
index 0cd5c6e..49d57a2 100644
--- a/tests/kms_rotation_crc.c
+++ b/tests/kms_rotation_crc.c
@@ -373,9 +373,6 @@ static void test_plane_rotation(data_t *data, int 
plane_type, bool test_bad_form
igt_plane_t *plane;
int i, j;
 
-   if (IS_CHERRYVIEW(data->devid) && pipe != PIPE_B)
-   continue;
-
igt_output_set_pipe(output, pipe);
 
plane = igt_output_get_plane_type(output, plane_type);
@@ -558,9 +555,7 @@ igt_main
igt_subtest_f("%s-rotation-%s",
  plane_test_str(subtest->plane),
  rot_test_str(subtest->rot)) {
-   igt_require(!(subtest->rot &
-   (IGT_ROTATION_90 | IGT_ROTATION_270)) ||
-   gen >= 9);
+   
igt_require(igt_plane_get_prop(data.display.pipes->planes, IGT_PLANE_ROTATION) 
& subtest->rot);
data.rotation = subtest->rot;
test_plane_rotation(, subtest->plane, false);
}
@@ -596,9 +591,8 @@ igt_main
igt_subtest_f("primary-%s-reflect-x-%s",
  tiling_test_str(reflect_x->tiling),
  rot_test_str(reflect_x->rot)) {
-   igt_require(gen >= 10 ||
-   (IS_CHERRYVIEW(data.devid) && 
reflect_x->rot == IGT_ROTATION_0
-&& reflect_x->tiling == 
LOCAL_I915_FORMAT_MOD_X_TILED));
+   
igt_require((igt_plane_get_prop(data.display.pipes->planes, IGT_PLANE_ROTATION) 
& subtest->rot) &&
+   (reflect_x->rot == IGT_ROTATION_0 && 
reflect_x->tiling == LOCAL_I915_FORMAT_MOD_X_TILED));
data.rotation = (IGT_REFLECT_X | reflect_x->rot);
data.override_tiling = reflect_x->tiling;
test_plane_rotation(, DRM_PLANE_TYPE_PRIMARY, 
false);
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [igt-dev] [PATCH igt 1/2] lib: force a reset on an uncooperative i915 device

[Antonio Argenziano]

On 09/02/18 03:46, Chris Wilson wrote:

Try to reset the GPU from within igt_require_gem() if we notice we are
starting with a wedged device. If it remains wedged, the test definitely
cannot run. We leave a warning in place to highlight the potentially
suspect result, which will keep the flip-flops alive in CI!

Signed-off-by: Chris Wilson 
---
  lib/ioctl_wrappers.c | 12 +---
  1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
index 10d958726..5d2c82099 100644
--- a/lib/ioctl_wrappers.c
+++ b/lib/ioctl_wrappers.c
@@ -1428,14 +1428,20 @@ void igt_require_gem(int fd)
 * sequences of batches.
 */
err = igt_debugfs_dir(fd);


I would prefer to use two variables, one for the debugfs fd and one for 
-errno for the IOCTL below.


With or without the new variable,
Reviewed-by: Antonio Argenziano 


-   if (err != -1) {
-   igt_sysfs_printf(err, "i915_next_seqno", "1");
-   close(err);
+   igt_require(err >= 0);
+
+   if (ioctl(fd, DRM_IOCTL_I915_GEM_THROTTLE)) {
+   igt_warn("Found wedged device, trying to reset and continue\n");
+   igt_sysfs_set(err, "i915_wedged", "-1");
}
+   igt_sysfs_set(err, "i915_next_seqno", "1");
+
+   close(err);
  
  	err = 0;

if (ioctl(fd, DRM_IOCTL_I915_GEM_THROTTLE))
err = -errno;
+
close(fd);
  
  	igt_require_f(err == 0, "Unresponsive i915/GEM device\n");



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Release the atomic kmap relocation cache around snb GTT w/a

[Chris Wilson]

When we need to rebind the vma into the global GTT for snb, we need to
drop the current reloc_cache as it will be holding a kmap_atomic() and
we may need to sleep for i915_vma_bind(). In practice, this is not an
issue as we already hold an rpm reference for the execbuffer, but with
tighter error checking around rpm we need to be more careful.

References: 31a39207f04a ("drm/i915: Cache kmap between relocations")
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index b15305f2fb76..8c34b1b5a126 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1315,6 +1315,12 @@ eb_relocate_entry(struct i915_execbuffer *eb,
 */
if (reloc->write_domain == I915_GEM_DOMAIN_INSTRUCTION &&
IS_GEN6(eb->i915)) {
+   /*
+* Release the kmap_atomic cache in order to allow the
+* i915_vma_bind() to sleep (if needs be).
+*/
+   reloc_cache_reset(>reloc_cache);
+
err = i915_vma_bind(target, target->obj->cache_level,
PIN_GLOBAL);
if (WARN_ONCE(err,
-- 
2.16.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Always catch incorrect usage of intel_runtime_pm_get

[Patchwork]

== Series Details ==

Series: drm/i915: Always catch incorrect usage of intel_runtime_pm_get
URL   : https://patchwork.freedesktop.org/series/38074/
State : failure

== Summary ==

Test pm_rpm:
Subgroup i2c:
fail   -> PASS   (shard-hsw)
Test kms_plane:
Subgroup plane-panning-bottom-right-suspend-pipe-b-planes:
pass   -> DMESG-WARN (shard-apl) fdo#104164
Test kms_color:
Subgroup pipe-c-ctm-negative:
pass   -> SKIP   (shard-apl)
Subgroup pipe-c-gamma:
pass   -> SKIP   (shard-apl)
Subgroup pipe-b-ctm-max:
pass   -> SKIP   (shard-apl)
Test kms_flip:
Subgroup flip-vs-panning-vs-hang:
pass   -> SKIP   (shard-apl)
Subgroup 2x-modeset-vs-vblank-race-interruptible:
pass   -> FAIL   (shard-hsw)
Subgroup modeset-vs-vblank-race-interruptible:
fail   -> PASS   (shard-hsw) fdo#103060 +1
Test kms_cursor_crc:
Subgroup cursor-128x128-random:
pass   -> SKIP   (shard-apl)
Test gem_eio:
Subgroup in-flight-external:
fail   -> PASS   (shard-hsw) fdo#104676
Test gem_exec_bad_domains:
Subgroup conflicting-write-domain:
pass   -> DMESG-WARN (shard-snb)
Test gem_exec_store:
Subgroup pages-blt:
pass   -> DMESG-WARN (shard-snb)
Subgroup pages-render:
pass   -> DMESG-WARN (shard-snb)
Subgroup pages-default:
pass   -> DMESG-WARN (shard-snb)

fdo#104164 https://bugs.freedesktop.org/show_bug.cgi?id=104164
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#104676 https://bugs.freedesktop.org/show_bug.cgi?id=104676

shard-apltotal:3410 pass:1763 dwarn:2   dfail:0   fail:20  skip:1624 
time:13624s
shard-hswtotal:3427 pass:1715 dwarn:1   dfail:0   fail:56  skip:1654 
time:14784s
shard-snbtotal:3427 pass:1345 dwarn:5   dfail:0   fail:10  skip:2067 
time:7613s
Blacklisted hosts:
shard-kbltotal:3427 pass:1908 dwarn:1   dfail:0   fail:22  skip:1496 
time:10991s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7983/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Keep vblank irq enabled during vblank evasion.

[Chris Wilson]

Quoting Ville Syrjälä (2018-02-12 18:06:58)
> On Mon, Feb 12, 2018 at 05:24:54PM +, Chris Wilson wrote:
> > Quoting Ville Syrjälä (2018-02-12 16:55:28)
> > > On Mon, Feb 12, 2018 at 04:41:05PM +0100, Maarten Lankhorst wrote:
> > > > Op 12-02-18 om 16:31 schreef Chris Wilson:
> > > > > Quoting Maarten Lankhorst (2018-02-12 15:27:34)
> > > > >> Op 12-02-18 om 16:22 schreef Chris Wilson:
> > > > >>> Quoting Maarten Lankhorst (2018-02-12 15:16:39)
> > > >  Op 12-02-18 om 16:10 schreef Chris Wilson:
> > > > > Quoting Maarten Lankhorst (2018-02-09 09:54:00)
> > > > >> This is a nice preparation for grabbing the uncore lock during 
> > > > >> evasion.
> > > > >> Grabbing the spinlock with the lock held messes up the locking,
> > > > >> so it's easier to handover the reference to the eve
> > > > >>
> > > > >> Signed-off-by: Maarten Lankhorst 
> > > > >> 
> > > > >> ---
> > > > >>  drivers/gpu/drm/i915/intel_sprite.c | 11 ---
> > > > >>  1 file changed, 4 insertions(+), 7 deletions(-)
> > > > >>
> > > > >> diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
> > > > >> b/drivers/gpu/drm/i915/intel_sprite.c
> > > > >> index 3be22c0fcfb5..971a1ea0db45 100644
> > > > >> --- a/drivers/gpu/drm/i915/intel_sprite.c
> > > > >> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > > > >> @@ -109,10 +109,10 @@ void intel_pipe_update_start(const struct 
> > > > >> intel_crtc_state *new_crtc_state)
> > > > >>  
> > > > >> local_irq_disable();
> > > > >>  
> > > > >> -   if (min <= 0 || max <= 0)
> > > > >> +   if (WARN_ON(drm_crtc_vblank_get(>base)))
> > > > >> return;
> > > > >>  
> > > > >> -   if (WARN_ON(drm_crtc_vblank_get(>base)))
> > > > >> +   if (min <= 0 || max <= 0)
> > > > >> return;
> > > > >>  
> > > > > The corresponding vblank_put is the one later in update_start(), 
> > > > > right?
> > > > > I don't think you intended to keep this chunk.
> > > > > -Chris
> > > >  I'm not sure what you mean? The vblank_put is now in 
> > > >  pipe_update_end, except if the
> > > >  event takes over the reference. I think the code is correct. :)
> > > > >>> Then it's unbalanced in the case of error still.
> > > > >>> -Chris
> > > > >> It already would have been for events, hence the WARN_ON there.
> > > > >> I don't think we can do anything about it, this shouldn't ever
> > > > >> happen in practice, could be a BUG_ON for all I care. :)
> > > > > I would much prefer that over intentionally bad code.
> > > > >
> > > > > But do we really need to enable the vblank irq here? If the event
> > > > > requires it, doesn't it already enable the vblank. Here, we only need 
> > > > > it
> > > > > when sleeping, can we not determine we have enough time before the
> > > > > vblank without enabling the interrupt?
> > > > I'm not sure why we get a reference to the vblank counter here. Perhaps 
> > > > Ville does?
> > > 
> > > We need the vblank irq to be enabled before we check the scanline since
> > > otherwise we may end up doing:
> > > 
> > > 1. check scanline
> > > 3. vblank irq fires
> > > 2. enable vblank irq
> > > 3. wait for the next vblank
> > > 
> > > So we'd end up wasting an entire frame.
> > 
> > Step: 2.5, check_scanline?
> > 
> > Something like,
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
> > b/drivers/gpu/drm/i915/intel_sprite.c
> > index 574bd02c5a2e..70c2ee1c7b8c 100644
> > --- a/drivers/gpu/drm/i915/intel_sprite.c
> > +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > @@ -97,6 +97,7 @@ void intel_pipe_update_start(const struct 
> > intel_crtc_state *new_crtc_state)
> > bool need_vlv_dsi_wa = (IS_VALLEYVIEW(dev_priv) || 
> > IS_CHERRYVIEW(dev_priv)) &&
> > intel_crtc_has_type(new_crtc_state, INTEL_OUTPUT_DSI);
> > DEFINE_WAIT(wait);
> > +   bool have_vblank_irq = false;
> >  
> > vblank_start = adjusted_mode->crtc_vblank_start;
> > if (adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE)
> > @@ -112,9 +113,6 @@ void intel_pipe_update_start(const struct 
> > intel_crtc_state *new_crtc_state)
> > if (min <= 0 || max <= 0)
> > return;
> >  
> > -   if (WARN_ON(drm_crtc_vblank_get(>base)))
> > -   return;
> > -
> > crtc->debug.min_vbl = min;
> > crtc->debug.max_vbl = max;
> > trace_i915_pipe_update_start(crtc);
> > @@ -127,6 +125,10 @@ void intel_pipe_update_start(const struct 
> > intel_crtc_state *new_crtc_state)
> >  */
> > prepare_to_wait(wq, , TASK_UNINTERRUPTIBLE);
> >  
> > +   if (!have_vblank_irq)
> > +   have_vblank_irq = !drm_crtc_vblank_get(>base);
> > +
> 
> This doesn't seem to change anything.

Nothing wrt to the existing code :)

The idea is that we have to enable the vblank-irq before doing 

Re: [Intel-gfx] [PATCH igt] igt/gem_exec_schedule: Limit smoketest to the desired engines

[Chris Wilson]

Quoting Belgaumkar, Vinay (2018-02-12 18:20:31)
> 
> 
> On 2/10/2018 1:00 AM, Chris Wilson wrote:
> > We run the per-engine scheduling smoketests across all engines, the
> > opposite of what was intended!
> > 
> > Signed-off-by: Chris Wilson 
> > ---
> >   tests/gem_exec_schedule.c | 12 
> >   1 file changed, 8 insertions(+), 4 deletions(-)
> > 
> > diff --git a/tests/gem_exec_schedule.c b/tests/gem_exec_schedule.c
> > index b45ba1670..ec02d9943 100644
> > --- a/tests/gem_exec_schedule.c
> > +++ b/tests/gem_exec_schedule.c
> > @@ -208,11 +208,15 @@ static void smoketest(int fd, unsigned ring, unsigned 
> > timeout)
> >   uint32_t *ptr;
> >   
> >   nengine = 0;
> > - for_each_engine(fd, engine) {
> > - if (ignore_engine(fd, engine))
> > - continue;
> > + if (ring == -1) {
> > + for_each_engine(fd, engine) {
> > + if (ignore_engine(fd, engine))
> > + continue;
> >   
> > - engines[nengine++] = engine;
> > + engines[nengine++] = engine;
> > + }
> > + } else {
> > + engines[nengine++] = ring;
> >   }
> >   igt_require(nengine);
> 
> LGTM. However, do we need the random number generation(from 0 to 
> nengine) in the following code if a single engine is selected?

It's just a few instructions, if the bottleneck was in userspace then
yes, removing them would be useful. As it is, the test is an exercise in
struct_mutex contention.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 2/3] drm/i915: Free memdup-ed DSI VBT data structures on driver_unload

[Ville Syrjälä]

On Tue, Feb 06, 2018 at 03:12:38PM +0100, Hans de Goede wrote:
> Make intel_bios_cleanup function free the DSI VBT data structures which
> are memdup-ed by parse_mipi_config() and parse_mipi_sequence().
> 
> Signed-off-by: Hans de Goede 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/intel_bios.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_bios.c 
> b/drivers/gpu/drm/i915/intel_bios.c
> index f9550507bb9f..18110bbd9ee2 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1629,6 +1629,12 @@ void intel_bios_cleanup(struct drm_i915_private 
> *dev_priv)
>   dev_priv->vbt.sdvo_lvds_vbt_mode = NULL;
>   kfree(dev_priv->vbt.lfp_lvds_vbt_mode);
>   dev_priv->vbt.lfp_lvds_vbt_mode = NULL;
> + kfree(dev_priv->vbt.dsi.data);
> + dev_priv->vbt.dsi.data = NULL;
> + kfree(dev_priv->vbt.dsi.pps);
> + dev_priv->vbt.dsi.pps = NULL;
> + kfree(dev_priv->vbt.dsi.config);
> + dev_priv->vbt.dsi.config = NULL;
>  }
>  
>  /**
> -- 
> 2.14.3

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 1/3] drm/i915: Add intel_bios_cleanup() function

[Ville Syrjälä]

On Tue, Feb 06, 2018 at 03:12:37PM +0100, Hans de Goede wrote:
> Add an intel_bios_cleanup() function to act as counterpart of
> intel_bios_init() and move the cleanup of vbt related resources there,
> putting it in the same file as the allocation.
> 
> Signed-off-by: Hans de Goede 
> ---
>  drivers/gpu/drm/i915/i915_drv.c   | 14 +-
>  drivers/gpu/drm/i915/i915_drv.h   |  1 +
>  drivers/gpu/drm/i915/intel_bios.c | 21 +
>  3 files changed, 23 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index e9f1daf258fe..7f094bbc2a7f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1446,19 +1446,7 @@ void i915_driver_unload(struct drm_device *dev)
>  
>   intel_modeset_cleanup(dev);
>  
> - /*
> -  * free the memory space allocated for the child device
> -  * config parsed from VBT
> -  */
> - if (dev_priv->vbt.child_dev && dev_priv->vbt.child_dev_num) {
> - kfree(dev_priv->vbt.child_dev);
> - dev_priv->vbt.child_dev = NULL;
> - dev_priv->vbt.child_dev_num = 0;
> - }
> - kfree(dev_priv->vbt.sdvo_lvds_vbt_mode);
> - dev_priv->vbt.sdvo_lvds_vbt_mode = NULL;
> - kfree(dev_priv->vbt.lfp_lvds_vbt_mode);
> - dev_priv->vbt.lfp_lvds_vbt_mode = NULL;
> + intel_bios_cleanup(dev_priv);
>  
>   vga_switcheroo_unregister_client(pdev);
>   vga_client_register(pdev, NULL, NULL, NULL);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index d6b5ac2a563d..1cccea1b87bc 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3675,6 +3675,7 @@ extern void intel_i2c_reset(struct drm_i915_private 
> *dev_priv);
>  
>  /* intel_bios.c */
>  void intel_bios_init(struct drm_i915_private *dev_priv);
> +void intel_bios_cleanup(struct drm_i915_private *dev_priv);
>  bool intel_bios_is_valid_vbt(const void *buf, size_t size);
>  bool intel_bios_is_tv_present(struct drm_i915_private *dev_priv);
>  bool intel_bios_is_lvds_present(struct drm_i915_private *dev_priv, u8 
> *i2c_pin);
> diff --git a/drivers/gpu/drm/i915/intel_bios.c 
> b/drivers/gpu/drm/i915/intel_bios.c
> index 4e74aa2f16bc..f9550507bb9f 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1610,6 +1610,27 @@ void intel_bios_init(struct drm_i915_private *dev_priv)
>   pci_unmap_rom(pdev, bios);
>  }
>  
> +/**
> + * intel_bios_cleanup - Free any resources allocated by intel_bios_init()
> + * @dev_priv: i915 device instance
> + */
> +void intel_bios_cleanup(struct drm_i915_private *dev_priv)
> +{
> + /*
> +  * free the memory space allocated for the child device
> +  * config parsed from VBT
> +  */
> + if (dev_priv->vbt.child_dev && dev_priv->vbt.child_dev_num) {

The comment and if() seem pointless. IMO just drop them.

With that
Reviewed-by: Ville Syrjälä 

> + kfree(dev_priv->vbt.child_dev);
> + dev_priv->vbt.child_dev = NULL;
> + dev_priv->vbt.child_dev_num = 0;
> + }
> + kfree(dev_priv->vbt.sdvo_lvds_vbt_mode);
> + dev_priv->vbt.sdvo_lvds_vbt_mode = NULL;
> + kfree(dev_priv->vbt.lfp_lvds_vbt_mode);
> + dev_priv->vbt.lfp_lvds_vbt_mode = NULL;
> +}
> +
>  /**
>   * intel_bios_is_tv_present - is integrated TV present in VBT
>   * @dev_priv:i915 device instance
> -- 
> 2.14.3

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for Queued/runnable/running engine stats (rev2)

[Patchwork]

== Series Details ==

Series: Queued/runnable/running engine stats (rev2)
URL   : https://patchwork.freedesktop.org/series/36926/
State : success

== Summary ==

Series 36926v2 Queued/runnable/running engine stats
https://patchwork.freedesktop.org/api/1.0/series/36926/revisions/2/mbox/

Test gem_ringfill:
Subgroup basic-default-hang:
dmesg-warn -> INCOMPLETE (fi-blb-e6850) fdo#101600 +1
Test prime_vgem:
Subgroup basic-fence-flip:
fail   -> PASS   (fi-ilk-650)

fdo#101600 https://bugs.freedesktop.org/show_bug.cgi?id=101600

fi-bdw-5557u total:288  pass:265  dwarn:0   dfail:0   fail:2   skip:21  
time:441s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:424s
fi-blb-e6850 total:146  pass:114  dwarn:0   dfail:0   fail:0   skip:31 
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:482s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:288s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:483s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:487s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:468s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:459s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:567s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:578s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:415s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:280s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:512s
fi-hsw-4770  total:288  pass:259  dwarn:0   dfail:0   fail:2   skip:27  
time:411s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:418s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:455s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:413s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:458s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:494s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:501s
fi-pnv-d510  total:146  pass:113  dwarn:0   dfail:0   fail:0   skip:32 
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:426s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:507s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:526s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:488s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:477s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:412s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:430s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:528s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:400s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:222  dwarn:36  dfail:0   fail:0   skip:30  
time:512s

83878f486e686dd291ef3566a45103962d7617ed drm-tip: 2018y-02m-12d-17h-43m-07s UTC 
integration manifest
6a799d3c4de5 drm/i915/pmu: Add running counter
d237f5f9f64a drm/i915/pmu: Add runnable counter
4195f08e5171 drm/i915/pmu: Add queued counter
0b151e057a18 drm/i915: Keep a count of requests submitted from userspace
8b8673e0296c drm/i915: Keep a count of requests waiting for a slot on GPU
a9eb3199938c drm/i915/pmu: Fix enable count array size and bounds checking

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7985/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Alex Deucher]

On Mon, Feb 12, 2018 at 4:45 AM, Lukas Wunner  wrote:
> On Mon, Feb 12, 2018 at 09:03:26AM +, Mike Lothian wrote:
>> On 12 February 2018 at 03:39, Lukas Wunner  wrote:
>> > On Mon, Feb 12, 2018 at 12:35:51AM +, Mike Lothian wrote:
>> > > I've not been able to reproduce the original problem you're trying to
>> > > solve on amdgpu thats with or without your patch set and the above
>> > > "trigger" too
>> > >
>> > > Is anything else required to trigger it, I started multiple DRI_PRIME
>> > > glxgears, in parallel, serial waiting the 12 seconds and serial within
>> > > the 12 seconds and I couldn't reproduce it
>> >
>> > The discrete GPU needs to runtime suspend, that's the trigger,
>> > so no DRI_PRIME executables should be running.  Just let it
>> > autosuspend after boot.  Do you see "waiting 12 sec" messages
>> > in dmesg?  If not it's not autosuspending.
>>
>> Yes I'm seeing those messages, I'm just not seeing the hangs
>>
>> I've attached the dmesg in case you're interested
>
> Okay the reason you're not seeing deadlocks is because the output poll
> worker is not enabled.  And the output poll worker is not enabled
> because your discrete GPU doesn't have any outputs:
>
> [0.265568] [drm:dc_create] *ERROR* DC: Number of connectors is zero!
>
> The outputs are only polled if there are connectors which have the
> DRM_CONNECTOR_POLL_CONNECT or DRM_CONNECTOR_POLL_DISCONNECT flag set.
> And that only ever seems to be the case for VGA and DVI.
>
> We know based on bugzilla reports that hybrid graphics laptops do exist
> which poll outputs with radeon and nouveau.  If there are no laptops
> supported by amdgpu whose discrete GPU has polled connectors, then
> patch [5/5] would be unnecessary.  That is for Alex to decide.

Most hybrid laptops don't have display connectors on the dGPU and we
only use polling on analog connectors, so you are not likely to run
into this on recent laptops.  That said, I don't know if there is some
OEM system out there with a VGA port on the dGPU in a hybrid laptop.
I guess another option is to just disable polling on hybrid laptops.

Alex

>
> However that is very good to know, so thanks a lot for your testing
> efforts, much appreciated!
>
> Kind regards,
>
> Lukas
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/6] drm/i915/pmu: Fix enable count array size and bounds checking

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Enable count array is supposed to have one counter for each possible
engine sampler. As such array sizing and bounds checking is not
correct when more engine samplers are added.

At the same time tidy the assert for readability and robustness.

Signed-off-by: Tvrtko Ursulin 
Fixes: b46a33e271ed ("drm/i915/pmu: Expose a PMU interface for perf queries")
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_pmu.c | 13 +
 drivers/gpu/drm/i915/intel_ringbuffer.h |  2 +-
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 964467b03e4d..a0ae7ca220fd 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -576,7 +576,8 @@ static void i915_pmu_enable(struct perf_event *event)
 * Update the bitmask of enabled events and increment
 * the event reference counter.
 */
-   GEM_BUG_ON(bit >= I915_PMU_MASK_BITS);
+   BUILD_BUG_ON(ARRAY_SIZE(i915->pmu.enable_count) != I915_PMU_MASK_BITS);
+   GEM_BUG_ON(bit >= ARRAY_SIZE(i915->pmu.enable_count));
GEM_BUG_ON(i915->pmu.enable_count[bit] == ~0);
i915->pmu.enable |= BIT_ULL(bit);
i915->pmu.enable_count[bit]++;
@@ -600,7 +601,10 @@ static void i915_pmu_enable(struct perf_event *event)
GEM_BUG_ON(!engine);
engine->pmu.enable |= BIT(sample);
 
-   GEM_BUG_ON(sample >= I915_PMU_SAMPLE_BITS);
+   BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.enable_count) !=
+(1 << I915_PMU_SAMPLE_BITS));
+   GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.enable_count));
+   GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.sample));
GEM_BUG_ON(engine->pmu.enable_count[sample] == ~0);
engine->pmu.enable_count[sample]++;
}
@@ -632,7 +636,8 @@ static void i915_pmu_disable(struct perf_event *event)
  engine_event_class(event),
  engine_event_instance(event));
GEM_BUG_ON(!engine);
-   GEM_BUG_ON(sample >= I915_PMU_SAMPLE_BITS);
+   GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.enable_count));
+   GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.sample));
GEM_BUG_ON(engine->pmu.enable_count[sample] == 0);
/*
 * Decrement the reference count and clear the enabled
@@ -642,7 +647,7 @@ static void i915_pmu_disable(struct perf_event *event)
engine->pmu.enable &= ~BIT(sample);
}
 
-   GEM_BUG_ON(bit >= I915_PMU_MASK_BITS);
+   GEM_BUG_ON(bit >= ARRAY_SIZE(i915->pmu.enable_count));
GEM_BUG_ON(i915->pmu.enable_count[bit] == 0);
/*
 * Decrement the reference count and clear the enabled
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 8f1a4badf812..3e98a589716a 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -363,7 +363,7 @@ struct intel_engine_cs {
 *
 * Index number corresponds to the bit number from @enable.
 */
-   unsigned int enable_count[I915_PMU_SAMPLE_BITS];
+   unsigned int enable_count[1 << I915_PMU_SAMPLE_BITS];
/**
 * @sample: Counter values for sampling events.
 *
-- 
2.14.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 6/6] drm/i915/pmu: Add running counter

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

We add a PMU counter to expose the number of requests currently executing
on the GPU.

This is useful to analyze the overall load of the system.

v2:
 * Rebase.
 * Drop floating point constant. (Chris Wilson)

v3:
 * Change scale to 1024 for faster arithmetics. (Chris Wilson)

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_pmu.c | 18 --
 drivers/gpu/drm/i915/intel_ringbuffer.h |  2 +-
 include/uapi/drm/i915_drm.h |  5 +
 3 files changed, 22 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 7acf5cf96266..710ae4bfd52e 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -38,7 +38,8 @@
 BIT(I915_SAMPLE_WAIT) | \
 BIT(I915_SAMPLE_SEMA) | \
 BIT(I915_SAMPLE_QUEUED) | \
-BIT(I915_SAMPLE_RUNNABLE))
+BIT(I915_SAMPLE_RUNNABLE) | \
+BIT(I915_SAMPLE_RUNNING))
 
 #define ENGINE_SAMPLE_BITS (1 << I915_PMU_SAMPLE_BITS)
 
@@ -232,6 +233,11 @@ static void engines_sample(struct drm_i915_private 
*dev_priv)
update_sample(>pmu.sample[I915_SAMPLE_RUNNABLE],
  I915_SAMPLE_RUNNABLE_DIVISOR,
  engine->request_stats.runnable);
+
+   if (engine->pmu.enable & BIT(I915_SAMPLE_RUNNING))
+   update_sample(>pmu.sample[I915_SAMPLE_RUNNING],
+ I915_SAMPLE_RUNNING_DIVISOR,
+ last_seqno - current_seqno);
}
 
if (fw)
@@ -331,6 +337,7 @@ engine_event_status(struct intel_engine_cs *engine,
case I915_SAMPLE_WAIT:
case I915_SAMPLE_QUEUED:
case I915_SAMPLE_RUNNABLE:
+   case I915_SAMPLE_RUNNING:
break;
case I915_SAMPLE_SEMA:
if (INTEL_GEN(engine->i915) < 6)
@@ -540,7 +547,8 @@ static u64 __i915_pmu_event_read(struct perf_event *event, 
bool locked)
}
 
if (sample == I915_SAMPLE_QUEUED ||
-   sample == I915_SAMPLE_RUNNABLE)
+   sample == I915_SAMPLE_RUNNABLE ||
+   sample == I915_SAMPLE_RUNNING)
val = div_u64(val, FREQUENCY);
} else {
switch (event->attr.config) {
@@ -837,6 +845,7 @@ add_pmu_attr(struct perf_pmu_events_attr *attr, const char 
*name,
 /* No brackets or quotes below please. */
 #define I915_SAMPLE_QUEUED_SCALE 0.0009765625
 #define I915_SAMPLE_RUNNABLE_SCALE 0.0009765625
+#define I915_SAMPLE_RUNNING_SCALE 0.0009765625
 
 static struct attribute **
 create_event_attributes(struct drm_i915_private *i915)
@@ -864,6 +873,8 @@ create_event_attributes(struct drm_i915_private *i915)
 __stringify(I915_SAMPLE_QUEUED_SCALE)),
__engine_event_scale(I915_SAMPLE_RUNNABLE, "runnable",
 __stringify(I915_SAMPLE_RUNNABLE_SCALE)),
+   __engine_event_scale(I915_SAMPLE_RUNNING, "running",
+__stringify(I915_SAMPLE_RUNNING_SCALE)),
};
unsigned int count = 0;
struct perf_pmu_events_attr *pmu_attr = NULL, *pmu_iter;
@@ -879,6 +890,9 @@ create_event_attributes(struct drm_i915_private *i915)
BUILD_BUG_ON(I915_SAMPLE_RUNNABLE_DIVISOR !=
 (1 / I915_SAMPLE_RUNNABLE_SCALE));
 
+   BUILD_BUG_ON(I915_SAMPLE_RUNNING_DIVISOR !=
+(1 / I915_SAMPLE_RUNNING_SCALE));
+
/* Count how many counters we will be exposing. */
for (i = 0; i < ARRAY_SIZE(events); i++) {
if (!config_status(i915, events[i].config))
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 3803b544fb2e..092b786b18ad 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -386,7 +386,7 @@ struct intel_engine_cs {
 *
 * Our internal timer stores the current counters in this field.
 */
-#define I915_ENGINE_SAMPLE_MAX (I915_SAMPLE_RUNNABLE + 1)
+#define I915_ENGINE_SAMPLE_MAX (I915_SAMPLE_RUNNING + 1)
struct i915_pmu_sample sample[I915_ENGINE_SAMPLE_MAX];
} pmu;
 
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 3e59cc009c4f..038276505e80 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -113,11 +113,13 @@ enum drm_i915_pmu_engine_sample {
I915_SAMPLE_SEMA = 2,
I915_SAMPLE_QUEUED = 3,
I915_SAMPLE_RUNNABLE = 4,
+   I915_SAMPLE_RUNNING = 5,
 };
 
  /* Divide counter value by divisor to get the real value. */
 #define I915_SAMPLE_QUEUED_DIVISOR (1024)
 #define I915_SAMPLE_RUNNABLE_DIVISOR (1024)
+#define I915_SAMPLE_RUNNING_DIVISOR (1024)
 
 #define 

[Intel-gfx] [PATCH 4/6] drm/i915/pmu: Add queued counter

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

We add a PMU counter to expose the number of requests which have been
submitted from userspace but are not yet runnable due dependencies and
unsignaled fences.

This is useful to analyze the overall load of the system.

v2:
 * Rebase for name change and re-order.
 * Drop floating point constant. (Chris Wilson)

v3:
 * Change scale to 1024 for faster arithmetics. (Chris Wilson)

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_pmu.c | 40 +
 drivers/gpu/drm/i915/intel_ringbuffer.h |  2 +-
 include/uapi/drm/i915_drm.h |  9 +++-
 3 files changed, 45 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index a0ae7ca220fd..7a8e02824021 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -36,7 +36,8 @@
 #define ENGINE_SAMPLE_MASK \
(BIT(I915_SAMPLE_BUSY) | \
 BIT(I915_SAMPLE_WAIT) | \
-BIT(I915_SAMPLE_SEMA))
+BIT(I915_SAMPLE_SEMA) | \
+BIT(I915_SAMPLE_QUEUED))
 
 #define ENGINE_SAMPLE_BITS (1 << I915_PMU_SAMPLE_BITS)
 
@@ -220,6 +221,11 @@ static void engines_sample(struct drm_i915_private 
*dev_priv)
 
update_sample(>pmu.sample[I915_SAMPLE_SEMA],
  PERIOD, !!(val & RING_WAIT_SEMAPHORE));
+
+   if (engine->pmu.enable & BIT(I915_SAMPLE_QUEUED))
+   update_sample(>pmu.sample[I915_SAMPLE_QUEUED],
+ I915_SAMPLE_QUEUED_DIVISOR,
+ 
atomic_read(>request_stats.queued));
}
 
if (fw)
@@ -317,6 +323,7 @@ engine_event_status(struct intel_engine_cs *engine,
switch (sample) {
case I915_SAMPLE_BUSY:
case I915_SAMPLE_WAIT:
+   case I915_SAMPLE_QUEUED:
break;
case I915_SAMPLE_SEMA:
if (INTEL_GEN(engine->i915) < 6)
@@ -524,6 +531,9 @@ static u64 __i915_pmu_event_read(struct perf_event *event, 
bool locked)
} else {
val = engine->pmu.sample[sample].cur;
}
+
+   if (sample == I915_SAMPLE_QUEUED)
+   val = div_u64(val, FREQUENCY);
} else {
switch (event->attr.config) {
case I915_PMU_ACTUAL_FREQUENCY:
@@ -779,6 +789,16 @@ static const struct attribute_group 
*i915_pmu_attr_groups[] = {
 { \
.sample = (__sample), \
.name = (__name), \
+   .suffix = "unit", \
+   .value = "ns", \
+}
+
+#define __engine_event_scale(__sample, __name, __scale) \
+{ \
+   .sample = (__sample), \
+   .name = (__name), \
+   .suffix = "scale", \
+   .value = (__scale), \
 }
 
 static struct i915_ext_attribute *
@@ -806,6 +826,9 @@ add_pmu_attr(struct perf_pmu_events_attr *attr, const char 
*name,
return ++attr;
 }
 
+/* No brackets or quotes below please. */
+#define I915_SAMPLE_QUEUED_SCALE 0.0009765625
+
 static struct attribute **
 create_event_attributes(struct drm_i915_private *i915)
 {
@@ -822,10 +845,14 @@ create_event_attributes(struct drm_i915_private *i915)
static const struct {
enum drm_i915_pmu_engine_sample sample;
char *name;
+   char *suffix;
+   char *value;
} engine_events[] = {
__engine_event(I915_SAMPLE_BUSY, "busy"),
__engine_event(I915_SAMPLE_SEMA, "sema"),
__engine_event(I915_SAMPLE_WAIT, "wait"),
+   __engine_event_scale(I915_SAMPLE_QUEUED, "queued",
+__stringify(I915_SAMPLE_QUEUED_SCALE)),
};
unsigned int count = 0;
struct perf_pmu_events_attr *pmu_attr = NULL, *pmu_iter;
@@ -835,6 +862,9 @@ create_event_attributes(struct drm_i915_private *i915)
enum intel_engine_id id;
unsigned int i;
 
+   BUILD_BUG_ON(I915_SAMPLE_QUEUED_DIVISOR !=
+(1 / I915_SAMPLE_QUEUED_SCALE));
+
/* Count how many counters we will be exposing. */
for (i = 0; i < ARRAY_SIZE(events); i++) {
if (!config_status(i915, events[i].config))
@@ -912,13 +942,15 @@ create_event_attributes(struct drm_i915_private *i915)

engine->instance,

engine_events[i].sample));
 
-   str = kasprintf(GFP_KERNEL, "%s-%s.unit",
-   engine->name, engine_events[i].name);
+   str = kasprintf(GFP_KERNEL, "%s-%s.%s",
+   engine->name, engine_events[i].name,
+   engine_events[i].suffix);
if (!str)
goto err;
 

[Intel-gfx] [PATCH 2/6] drm/i915: Keep a count of requests waiting for a slot on GPU

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Keep a per-engine number of runnable (waiting for GPU time) requests.

v2:
 * Move queued increment from insert_request to execlist_submit_request to
   avoid bumping when re-ordering for priority.
 * Support the counter on the ringbuffer submission path as well, albeit
   just notionally. (Chris Wilson)

v3:
 * Rebase.

v4:
 * Rename and move the stats into a container structure. (Chris Wilson)

v5:
 * Re-order fields in struct intel_engine_cs. (Chris Wilson)

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem_request.c | 7 +++
 drivers/gpu/drm/i915/intel_engine_cs.c  | 5 +++--
 drivers/gpu/drm/i915/intel_lrc.c| 2 ++
 drivers/gpu/drm/i915/intel_ringbuffer.h | 9 +
 4 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 8bc7c50b8418..19b8714a8d2f 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -511,6 +511,9 @@ void __i915_gem_request_submit(struct drm_i915_gem_request 
*request)
engine->emit_breadcrumb(request,
request->ring->vaddr + request->postfix);
 
+   GEM_BUG_ON(engine->request_stats.runnable == 0);
+   engine->request_stats.runnable--;
+
spin_lock(>timeline->lock);
list_move_tail(>link, >requests);
spin_unlock(>timeline->lock);
@@ -526,6 +529,8 @@ void i915_gem_request_submit(struct drm_i915_gem_request 
*request)
/* Will be called from irq-context when using foreign fences. */
spin_lock_irqsave(>timeline->lock, flags);
 
+   engine->request_stats.runnable++;
+
__i915_gem_request_submit(request);
 
spin_unlock_irqrestore(>timeline->lock, flags);
@@ -559,6 +564,8 @@ void __i915_gem_request_unsubmit(struct 
drm_i915_gem_request *request)
timeline = request->timeline;
GEM_BUG_ON(timeline == engine->timeline);
 
+   engine->request_stats.runnable++;
+
spin_lock(>lock);
list_move(>link, >requests);
spin_unlock(>lock);
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 0ad9184eba97..da5b592ce49f 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1727,12 +1727,13 @@ void intel_engine_dump(struct intel_engine_cs *engine,
if (i915_terminally_wedged(>i915->gpu_error))
drm_printf(m, "*** WEDGED ***\n");
 
-   drm_printf(m, "\tcurrent seqno %x, last %x, hangcheck %x [%d ms], 
inflight %d\n",
+   drm_printf(m, "\tcurrent seqno %x, last %x, hangcheck %x [%d ms], 
inflight %d, runnable %u\n",
   intel_engine_get_seqno(engine),
   intel_engine_last_submit(engine),
   engine->hangcheck.seqno,
   jiffies_to_msecs(jiffies - 
engine->hangcheck.action_timestamp),
-  engine->timeline->inflight_seqnos);
+  engine->timeline->inflight_seqnos,
+  engine->request_stats.runnable);
drm_printf(m, "\tReset count: %d (global %d)\n",
   i915_reset_engine_count(error, engine),
   i915_reset_count(error));
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index c2c8380a0121..827c6a3d30b8 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -929,6 +929,8 @@ static void execlists_submit_request(struct 
drm_i915_gem_request *request)
/* Will be called from irq-context when using foreign fences. */
spin_lock_irqsave(>timeline->lock, flags);
 
+   engine->request_stats.runnable++;
+
insert_request(engine, >priotree, request->priotree.priority);
 
GEM_BUG_ON(!engine->execlists.first);
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 3e98a589716a..43942cd17212 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -310,6 +310,15 @@ struct intel_engine_cs {
 
struct drm_i915_gem_object *default_state;
 
+   struct {
+   /**
+* @runnable: Number of runnable requests sent to the backend.
+*
+* Count of requests waiting for the GPU to execute them.
+*/
+   unsigned int runnable;
+   } request_stats;
+
atomic_t irq_count;
unsigned long irq_posted;
 #define ENGINE_IRQ_BREADCRUMB 0
-- 
2.14.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 5/6] drm/i915/pmu: Add runnable counter

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

We add a PMU counter to expose the number of requests with resolved
dependencies waiting for a slot on the GPU to run.

This is useful to analyze the overall load of the system.

v2: Don't limit to gen8+.

v3:
 * Rebase for dynamic sysfs.
 * Drop currently executing requests.

v4:
 * Sync with internal renaming.
 * Drop floating point constant. (Chris Wilson)

v5:
 * Change scale to 1024 for faster arithmetics. (Chris Wilson)

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_pmu.c | 18 --
 drivers/gpu/drm/i915/intel_ringbuffer.h |  2 +-
 include/uapi/drm/i915_drm.h |  7 ++-
 3 files changed, 23 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 7a8e02824021..7acf5cf96266 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -37,7 +37,8 @@
(BIT(I915_SAMPLE_BUSY) | \
 BIT(I915_SAMPLE_WAIT) | \
 BIT(I915_SAMPLE_SEMA) | \
-BIT(I915_SAMPLE_QUEUED))
+BIT(I915_SAMPLE_QUEUED) | \
+BIT(I915_SAMPLE_RUNNABLE))
 
 #define ENGINE_SAMPLE_BITS (1 << I915_PMU_SAMPLE_BITS)
 
@@ -226,6 +227,11 @@ static void engines_sample(struct drm_i915_private 
*dev_priv)
update_sample(>pmu.sample[I915_SAMPLE_QUEUED],
  I915_SAMPLE_QUEUED_DIVISOR,
  
atomic_read(>request_stats.queued));
+
+   if (engine->pmu.enable & BIT(I915_SAMPLE_RUNNABLE))
+   update_sample(>pmu.sample[I915_SAMPLE_RUNNABLE],
+ I915_SAMPLE_RUNNABLE_DIVISOR,
+ engine->request_stats.runnable);
}
 
if (fw)
@@ -324,6 +330,7 @@ engine_event_status(struct intel_engine_cs *engine,
case I915_SAMPLE_BUSY:
case I915_SAMPLE_WAIT:
case I915_SAMPLE_QUEUED:
+   case I915_SAMPLE_RUNNABLE:
break;
case I915_SAMPLE_SEMA:
if (INTEL_GEN(engine->i915) < 6)
@@ -532,7 +539,8 @@ static u64 __i915_pmu_event_read(struct perf_event *event, 
bool locked)
val = engine->pmu.sample[sample].cur;
}
 
-   if (sample == I915_SAMPLE_QUEUED)
+   if (sample == I915_SAMPLE_QUEUED ||
+   sample == I915_SAMPLE_RUNNABLE)
val = div_u64(val, FREQUENCY);
} else {
switch (event->attr.config) {
@@ -828,6 +836,7 @@ add_pmu_attr(struct perf_pmu_events_attr *attr, const char 
*name,
 
 /* No brackets or quotes below please. */
 #define I915_SAMPLE_QUEUED_SCALE 0.0009765625
+#define I915_SAMPLE_RUNNABLE_SCALE 0.0009765625
 
 static struct attribute **
 create_event_attributes(struct drm_i915_private *i915)
@@ -853,6 +862,8 @@ create_event_attributes(struct drm_i915_private *i915)
__engine_event(I915_SAMPLE_WAIT, "wait"),
__engine_event_scale(I915_SAMPLE_QUEUED, "queued",
 __stringify(I915_SAMPLE_QUEUED_SCALE)),
+   __engine_event_scale(I915_SAMPLE_RUNNABLE, "runnable",
+__stringify(I915_SAMPLE_RUNNABLE_SCALE)),
};
unsigned int count = 0;
struct perf_pmu_events_attr *pmu_attr = NULL, *pmu_iter;
@@ -865,6 +876,9 @@ create_event_attributes(struct drm_i915_private *i915)
BUILD_BUG_ON(I915_SAMPLE_QUEUED_DIVISOR !=
 (1 / I915_SAMPLE_QUEUED_SCALE));
 
+   BUILD_BUG_ON(I915_SAMPLE_RUNNABLE_DIVISOR !=
+(1 / I915_SAMPLE_RUNNABLE_SCALE));
+
/* Count how many counters we will be exposing. */
for (i = 0; i < ARRAY_SIZE(events); i++) {
if (!config_status(i915, events[i].config))
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 41555fe9a1a0..3803b544fb2e 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -386,7 +386,7 @@ struct intel_engine_cs {
 *
 * Our internal timer stores the current counters in this field.
 */
-#define I915_ENGINE_SAMPLE_MAX (I915_SAMPLE_QUEUED + 1)
+#define I915_ENGINE_SAMPLE_MAX (I915_SAMPLE_RUNNABLE + 1)
struct i915_pmu_sample sample[I915_ENGINE_SAMPLE_MAX];
} pmu;
 
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index b65c80b39e8b..3e59cc009c4f 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -111,11 +111,13 @@ enum drm_i915_pmu_engine_sample {
I915_SAMPLE_BUSY = 0,
I915_SAMPLE_WAIT = 1,
I915_SAMPLE_SEMA = 2,
-   I915_SAMPLE_QUEUED = 3
+   I915_SAMPLE_QUEUED = 3,
+   I915_SAMPLE_RUNNABLE = 4,
 };
 
  /* Divide counter value by divisor to get the real 

[Intel-gfx] [PATCH 3/6] drm/i915: Keep a count of requests submitted from userspace

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Keep a count of requests submitted from userspace and not yet runnable due
unresolved dependencies.

v2: Rename and move under the container struct. (Chris Wilson)

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem_request.c | 3 +++
 drivers/gpu/drm/i915/intel_engine_cs.c  | 3 ++-
 drivers/gpu/drm/i915/intel_ringbuffer.h | 8 
 3 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 19b8714a8d2f..9bb74836c602 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -610,6 +610,7 @@ submit_notify(struct i915_sw_fence *fence, enum 
i915_sw_fence_notify state)
rcu_read_lock();
request->engine->submit_request(request);
rcu_read_unlock();
+   atomic_dec(>engine->request_stats.queued);
break;
 
case FENCE_FREE:
@@ -1083,6 +1084,8 @@ void __i915_add_request(struct drm_i915_gem_request 
*request, bool flush_caches)
if (engine->schedule)
engine->schedule(request, request->ctx->priority);
 
+   atomic_inc(>request_stats.queued);
+
local_bh_disable();
i915_sw_fence_commit(>submit);
local_bh_enable(); /* Kick the execlists tasklet if just scheduled */
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index da5b592ce49f..e861b5404a78 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1727,12 +1727,13 @@ void intel_engine_dump(struct intel_engine_cs *engine,
if (i915_terminally_wedged(>i915->gpu_error))
drm_printf(m, "*** WEDGED ***\n");
 
-   drm_printf(m, "\tcurrent seqno %x, last %x, hangcheck %x [%d ms], 
inflight %d, runnable %u\n",
+   drm_printf(m, "\tcurrent seqno %x, last %x, hangcheck %x [%d ms], 
inflight %d, queued %u, runnable %u\n",
   intel_engine_get_seqno(engine),
   intel_engine_last_submit(engine),
   engine->hangcheck.seqno,
   jiffies_to_msecs(jiffies - 
engine->hangcheck.action_timestamp),
   engine->timeline->inflight_seqnos,
+  atomic_read(>request_stats.queued),
   engine->request_stats.runnable);
drm_printf(m, "\tReset count: %d (global %d)\n",
   i915_reset_engine_count(error, engine),
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 43942cd17212..6309e761bf69 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -311,6 +311,14 @@ struct intel_engine_cs {
struct drm_i915_gem_object *default_state;
 
struct {
+   /**
+* @queued: Number of submitted requests with dependencies.
+*
+* Count of requests waiting for dependencies before they can be
+* submitted to the backend.
+*/
+   atomic_t queued;
+
/**
 * @runnable: Number of runnable requests sent to the backend.
 *
-- 
2.14.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 0/6] Queued/runnable/running engine stats

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Per-engine queue depths are an interesting metric for analyzing the system load
and also for users who wish to use it to load balance their submissions based
on it.

In this version I have split the metrics into three separate counters:

1. QUEUED - From execbuf time to request being runnable - runnable meaning until
dependencies have been resolved and fences signaled.
2. RUNNABLE - From runnable to running on the GPU.
3. RUNNING - Running on the GPU.

When inspected with perf stat the output looks roughly like this:

#   time counts unit events
   201.160490145   0.01  i915/rcs0-queued/
   201.160490145  19.13  i915/rcs0-runnable/
   201.160490145   2.39  i915/rcs0-running/

The reported numbers are average queue depths for the last query period.

Having split out metrics should be more flexible for all users, and it is still
possible to fetch an atomic snapshot of all using the perf groups for those
wanting to combine them.

For users wanting instantanous numbers instead of averaged, we could potentially
expose them using the query API Lionel is working on.
(https://patchwork.freedesktop.org/series/36622/)

For instance a query packet could look like:

#define DRM_I915_QUERY_ENGINE_QUEUES0x04

struct drm_i915_query_engine_queues {
__u8 class;
__u8 instance

__u8 pad[2];

__u32 queued;
__u32 runnable;
__u32 running;
};

I also have patches to expose this via intel-gpu-top, using the perf API.

v2:
 * Review feedback (see patch changelogs).
 * Renamed the counters and re-ordered some patches.

v3:
 * Review feedback and rebase.

Tvrtko Ursulin (6):
  drm/i915/pmu: Fix enable count array size and bounds checking
  drm/i915: Keep a count of requests waiting for a slot on GPU
  drm/i915: Keep a count of requests submitted from userspace
  drm/i915/pmu: Add queued counter
  drm/i915/pmu: Add runnable counter
  drm/i915/pmu: Add running counter

 drivers/gpu/drm/i915/i915_gem_request.c | 10 
 drivers/gpu/drm/i915/i915_pmu.c | 81 +
 drivers/gpu/drm/i915/intel_engine_cs.c  |  6 ++-
 drivers/gpu/drm/i915/intel_lrc.c|  2 +
 drivers/gpu/drm/i915/intel_ringbuffer.h | 21 -
 include/uapi/drm/i915_drm.h | 19 +++-
 6 files changed, 126 insertions(+), 13 deletions(-)

-- 
2.14.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/5] drm: Allow determining if current task is output poll worker

[Lukas Wunner]

On Mon, Feb 12, 2018 at 05:50:12PM +, Chris Wilson wrote:
> Quoting Lyude Paul (2018-02-12 17:46:11)
> > On Sun, 2018-02-11 at 10:38 +0100, Lukas Wunner wrote:
> > > Introduce a helper to determine if the current task is an output poll
> > > worker.
> > > 
> > > This allows us to fix a long-standing deadlock in several DRM drivers
> > > wherein the ->runtime_suspend callback waits for the output poll worker
> > > to finish and the worker in turn calls a ->detect callback which waits
> > > for runtime suspend to finish.  The ->detect callback is invoked from
> > > multiple call sites and waiting for runtime suspend to finish is the
> > > correct thing to do except if it's executing in the context of the
> > > worker.
> > > 
> > > Cc: Dave Airlie 
> > > Cc: Ben Skeggs 
> > > Cc: Alex Deucher 
> > > Signed-off-by: Lukas Wunner 
> > > ---
> > >  drivers/gpu/drm/drm_probe_helper.c | 14 ++
> > >  include/drm/drm_crtc_helper.h  |  1 +
> > >  2 files changed, 15 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_probe_helper.c
> > > b/drivers/gpu/drm/drm_probe_helper.c
> > > index 555fbe54d6e2..019881d15ce1 100644
> > > --- a/drivers/gpu/drm/drm_probe_helper.c
> > > +++ b/drivers/gpu/drm/drm_probe_helper.c
> > > @@ -653,6 +653,20 @@ static void output_poll_execute(struct work_struct
> > > *work)
> > >   schedule_delayed_work(delayed_work,
> > > DRM_OUTPUT_POLL_PERIOD);
> > >  }
> > >  
> > > +/**
> > > + * drm_kms_helper_is_poll_worker - is %current task an output poll 
> > > worker?
> > > + *
> > > + * Determine if %current task is an output poll worker.  This can be used
> > > + * to select distinct code paths for output polling versus other 
> > > contexts.
> > > + */
> > > +bool drm_kms_helper_is_poll_worker(void)
> > > +{
> > > + struct work_struct *work = current_work();
> > > +
> > > + return work && work->func == output_poll_execute;
> 
> What ensures that work is accessible? Does this need rcu_read_lock
> protection or more?

The work_struct exists as long this kthread is working on it.
Since this is called by the kthread itself, it is guaranteed to exist.
So there's no protection needed.

Thanks,

Lukas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [igt-dev] [PATCH igt] igt/gem_exec_capture: MI_STORE_DWORD requires EXEC_SECURE + DRM_MASTER on ctg/ilk

[Ville Syrjälä]

On Mon, Feb 12, 2018 at 05:37:56PM +, Chris Wilson wrote:
> Quoting Ville Syrjälä (2018-02-12 17:30:52)
> > On Sat, Feb 10, 2018 at 09:43:38PM +, Chris Wilson wrote:
> > > On ctg/ilk, for whatever reason, MI_STORE_DWORD is a privileged operation
> > > so we must request a SECURE batch.
> > 
> > IIRC ctg supposedly introduced some form of ppgtt. Isn't that the
> > reason?
> > 
> > Hmm. Now I wonder how anything works on these platforms. Should the
> > batch itself be executed via ppgtt if it's non-secure? Maybe the hw
> > has a fallback mechanism of some sort to execute via ggtt if ppgtt
> > isn't enabled...
> > 
> > ppgtt enable bit:
> > "When this bit is clear, all memory accesses will be completed using the
> > GGTT. Privileged memory protections will not be enforced (it is
> > acceptable for a non-secure batch buffer to access GGTT space)"
> > 
> > OK. That seems to confirm that part of the theory.
> > 
> > For pre-ctg the spec says:
> > "Although Buffer Security Indicator is implemented, there is no usage
> >  model for it and it need not be validated."
> > 
> > So I'm thinking we should never set the non-secure bit on these old
> > platforms.
> 
> That does open a large can of worms with the ability to write any
> register from userspace or manipulate the pagetables; i.e. requires the
> cmdparser. The usage model has been such that very few commands are
> affected; certainly no one [else] has noticed (afaik).

I suppose. I can't find any notes about this being wrong in the gen2/3
docs. And the gen4 quote just says "need not be validated" after all so
I suppose it doesn't necessarily mean it wasn't validated. And I guess
we should have found out long ago if it's hopelessly broken.

Patch is
Reviewed-by: Ville Syrjälä 

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for AWOOGA: Revert "ALSA: hda: Make use of core codec functions to sync power state"

[Patchwork]

== Series Details ==

Series: AWOOGA: Revert "ALSA: hda: Make use of core codec functions to sync 
power state"
URL   : https://patchwork.freedesktop.org/series/38097/
State : success

== Summary ==

Series 38097v1 AWOOGA: Revert "ALSA: hda: Make use of core codec functions to 
sync power state"
https://patchwork.freedesktop.org/api/1.0/series/38097/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713
Test pm_rpm:
Subgroup basic-pci-d3-state:
fail   -> PASS   (fi-hsw-4770)
fail   -> PASS   (fi-bdw-5557u)
Subgroup basic-rte:
fail   -> PASS   (fi-hsw-4770)
fail   -> PASS   (fi-bdw-5557u)

fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:417s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:423s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:375s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:495s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:288s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:482s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:488s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:469s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:455s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:564s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:574s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:417s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:282s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:515s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:391s
fi-ilk-650   total:288  pass:227  dwarn:0   dfail:0   fail:1   skip:60  
time:409s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:451s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:421s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:459s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:497s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:502s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:593s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:429s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:505s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:525s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:484s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:480s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:418s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:431s
fi-snb-2520m total:3pass:2dwarn:0   dfail:0   fail:0   skip:0  
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:397s

83878f486e686dd291ef3566a45103962d7617ed drm-tip: 2018y-02m-12d-17h-43m-07s UTC 
integration manifest
26049ad1632f AWOOGA: Revert "ALSA: hda: Make use of core codec functions to 
sync power state"

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7984/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH igt] igt/gem_exec_schedule: Limit smoketest to the desired engines

[Belgaumkar, Vinay]

On 2/10/2018 1:00 AM, Chris Wilson wrote:

We run the per-engine scheduling smoketests across all engines, the
opposite of what was intended!

Signed-off-by: Chris Wilson 
---
  tests/gem_exec_schedule.c | 12 
  1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/tests/gem_exec_schedule.c b/tests/gem_exec_schedule.c
index b45ba1670..ec02d9943 100644
--- a/tests/gem_exec_schedule.c
+++ b/tests/gem_exec_schedule.c
@@ -208,11 +208,15 @@ static void smoketest(int fd, unsigned ring, unsigned 
timeout)
uint32_t *ptr;
  
  	nengine = 0;

-   for_each_engine(fd, engine) {
-   if (ignore_engine(fd, engine))
-   continue;
+   if (ring == -1) {
+   for_each_engine(fd, engine) {
+   if (ignore_engine(fd, engine))
+   continue;
  
-		engines[nengine++] = engine;

+   engines[nengine++] = engine;
+   }
+   } else {
+   engines[nengine++] = ring;
}
igt_require(nengine);


LGTM. However, do we need the random number generation(from 0 to 
nengine) in the following code if a single engine is selected?


Reviewed-by: vinay.belgaum...@intel.com

  


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for drm: Use idr_init_base(1) when using id==0 for invalid

[Patchwork]

== Series Details ==

Series: drm: Use idr_init_base(1) when using id==0 for invalid
URL   : https://patchwork.freedesktop.org/series/38089/
State : success

== Summary ==

Test gem_softpin:
Subgroup noreloc-s4:
fail   -> SKIP   (shard-snb) fdo#103375
Test gem_eio:
Subgroup in-flight-external:
fail   -> PASS   (shard-hsw) fdo#104676
Test kms_flip:
Subgroup modeset-vs-vblank-race:
fail   -> PASS   (shard-hsw) fdo#103060 +1
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-pri-shrfb-draw-mmap-wc:
pass   -> FAIL   (shard-apl) fdo#103167 +1
Test pm_rpm:
Subgroup i2c:
fail   -> PASS   (shard-hsw)
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047
Test perf:
Subgroup oa-exponents:
pass   -> FAIL   (shard-apl) fdo#102254

fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#104676 https://bugs.freedesktop.org/show_bug.cgi?id=104676
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254

shard-apltotal:3410 pass:1765 dwarn:1   dfail:0   fail:23  skip:1619 
time:13622s
shard-hswtotal:3427 pass:1716 dwarn:1   dfail:0   fail:55  skip:1654 
time:14765s
shard-snbtotal:3427 pass:1349 dwarn:1   dfail:0   fail:9   skip:2068 
time:7625s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7982/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Keep vblank irq enabled during vblank evasion.

[Ville Syrjälä]

On Mon, Feb 12, 2018 at 05:24:54PM +, Chris Wilson wrote:
> Quoting Ville Syrjälä (2018-02-12 16:55:28)
> > On Mon, Feb 12, 2018 at 04:41:05PM +0100, Maarten Lankhorst wrote:
> > > Op 12-02-18 om 16:31 schreef Chris Wilson:
> > > > Quoting Maarten Lankhorst (2018-02-12 15:27:34)
> > > >> Op 12-02-18 om 16:22 schreef Chris Wilson:
> > > >>> Quoting Maarten Lankhorst (2018-02-12 15:16:39)
> > >  Op 12-02-18 om 16:10 schreef Chris Wilson:
> > > > Quoting Maarten Lankhorst (2018-02-09 09:54:00)
> > > >> This is a nice preparation for grabbing the uncore lock during 
> > > >> evasion.
> > > >> Grabbing the spinlock with the lock held messes up the locking,
> > > >> so it's easier to handover the reference to the eve
> > > >>
> > > >> Signed-off-by: Maarten Lankhorst 
> > > >> 
> > > >> ---
> > > >>  drivers/gpu/drm/i915/intel_sprite.c | 11 ---
> > > >>  1 file changed, 4 insertions(+), 7 deletions(-)
> > > >>
> > > >> diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
> > > >> b/drivers/gpu/drm/i915/intel_sprite.c
> > > >> index 3be22c0fcfb5..971a1ea0db45 100644
> > > >> --- a/drivers/gpu/drm/i915/intel_sprite.c
> > > >> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > > >> @@ -109,10 +109,10 @@ void intel_pipe_update_start(const struct 
> > > >> intel_crtc_state *new_crtc_state)
> > > >>  
> > > >> local_irq_disable();
> > > >>  
> > > >> -   if (min <= 0 || max <= 0)
> > > >> +   if (WARN_ON(drm_crtc_vblank_get(>base)))
> > > >> return;
> > > >>  
> > > >> -   if (WARN_ON(drm_crtc_vblank_get(>base)))
> > > >> +   if (min <= 0 || max <= 0)
> > > >> return;
> > > >>  
> > > > The corresponding vblank_put is the one later in update_start(), 
> > > > right?
> > > > I don't think you intended to keep this chunk.
> > > > -Chris
> > >  I'm not sure what you mean? The vblank_put is now in 
> > >  pipe_update_end, except if the
> > >  event takes over the reference. I think the code is correct. :)
> > > >>> Then it's unbalanced in the case of error still.
> > > >>> -Chris
> > > >> It already would have been for events, hence the WARN_ON there.
> > > >> I don't think we can do anything about it, this shouldn't ever
> > > >> happen in practice, could be a BUG_ON for all I care. :)
> > > > I would much prefer that over intentionally bad code.
> > > >
> > > > But do we really need to enable the vblank irq here? If the event
> > > > requires it, doesn't it already enable the vblank. Here, we only need it
> > > > when sleeping, can we not determine we have enough time before the
> > > > vblank without enabling the interrupt?
> > > I'm not sure why we get a reference to the vblank counter here. Perhaps 
> > > Ville does?
> > 
> > We need the vblank irq to be enabled before we check the scanline since
> > otherwise we may end up doing:
> > 
> > 1. check scanline
> > 3. vblank irq fires
> > 2. enable vblank irq
> > 3. wait for the next vblank
> > 
> > So we'd end up wasting an entire frame.
> 
> Step: 2.5, check_scanline?
> 
> Something like,
> 
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
> b/drivers/gpu/drm/i915/intel_sprite.c
> index 574bd02c5a2e..70c2ee1c7b8c 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -97,6 +97,7 @@ void intel_pipe_update_start(const struct intel_crtc_state 
> *new_crtc_state)
> bool need_vlv_dsi_wa = (IS_VALLEYVIEW(dev_priv) || 
> IS_CHERRYVIEW(dev_priv)) &&
> intel_crtc_has_type(new_crtc_state, INTEL_OUTPUT_DSI);
> DEFINE_WAIT(wait);
> +   bool have_vblank_irq = false;
>  
> vblank_start = adjusted_mode->crtc_vblank_start;
> if (adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE)
> @@ -112,9 +113,6 @@ void intel_pipe_update_start(const struct 
> intel_crtc_state *new_crtc_state)
> if (min <= 0 || max <= 0)
> return;
>  
> -   if (WARN_ON(drm_crtc_vblank_get(>base)))
> -   return;
> -
> crtc->debug.min_vbl = min;
> crtc->debug.max_vbl = max;
> trace_i915_pipe_update_start(crtc);
> @@ -127,6 +125,10 @@ void intel_pipe_update_start(const struct 
> intel_crtc_state *new_crtc_state)
>  */
> prepare_to_wait(wq, , TASK_UNINTERRUPTIBLE);
>  
> +   if (!have_vblank_irq)
> +   have_vblank_irq = !drm_crtc_vblank_get(>base);
> +

This doesn't seem to change anything.

Did you mean something like this perhaps?

for (;;) {
prepare_to_wait();

if (scanline ok)
break;

if (!have_vbl_irq) {
have_vbl_irq = !vbl_get();
/*
 * Check the scanline again to make sure
 * we didn't just miss the vblank interrupt.
 */
 

Re: [Intel-gfx] [PATCH 2/5] drm: Allow determining if current task is output poll worker

[Chris Wilson]

Quoting Lyude Paul (2018-02-12 17:46:11)
> On Sun, 2018-02-11 at 10:38 +0100, Lukas Wunner wrote:
> > Introduce a helper to determine if the current task is an output poll
> > worker.
> > 
> > This allows us to fix a long-standing deadlock in several DRM drivers
> > wherein the ->runtime_suspend callback waits for the output poll worker
> > to finish and the worker in turn calls a ->detect callback which waits
> > for runtime suspend to finish.  The ->detect callback is invoked from
> > multiple call sites and waiting for runtime suspend to finish is the
> > correct thing to do except if it's executing in the context of the
> > worker.
> > 
> > Cc: Dave Airlie 
> > Cc: Ben Skeggs 
> > Cc: Alex Deucher 
> > Signed-off-by: Lukas Wunner 
> > ---
> >  drivers/gpu/drm/drm_probe_helper.c | 14 ++
> >  include/drm/drm_crtc_helper.h  |  1 +
> >  2 files changed, 15 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_probe_helper.c
> > b/drivers/gpu/drm/drm_probe_helper.c
> > index 555fbe54d6e2..019881d15ce1 100644
> > --- a/drivers/gpu/drm/drm_probe_helper.c
> > +++ b/drivers/gpu/drm/drm_probe_helper.c
> > @@ -653,6 +653,20 @@ static void output_poll_execute(struct work_struct
> > *work)
> >   schedule_delayed_work(delayed_work,
> > DRM_OUTPUT_POLL_PERIOD);
> >  }
> >  
> > +/**
> > + * drm_kms_helper_is_poll_worker - is %current task an output poll worker?
> > + *
> > + * Determine if %current task is an output poll worker.  This can be used
> > + * to select distinct code paths for output polling versus other contexts.
> > + */
> For this, it would be worth explicitly noting in the comments herethat this
> should be called by DRM drivers in order to prevent racing with hotplug
> polling workers, so that new drivers in the future can avoid implementing this
> race condition in their driver.
> 
> > +bool drm_kms_helper_is_poll_worker(void)
> > +{
> > + struct work_struct *work = current_work();
> > +
> > + return work && work->func == output_poll_execute;

What ensures that work is accessible? Does this need rcu_read_lock
protection or more?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Always catch incorrect usage of intel_runtime_pm_get

[Patchwork]

== Series Details ==

Series: drm/i915: Always catch incorrect usage of intel_runtime_pm_get
URL   : https://patchwork.freedesktop.org/series/38074/
State : success

== Summary ==

Series 38074v1 drm/i915: Always catch incorrect usage of intel_runtime_pm_get
https://patchwork.freedesktop.org/api/1.0/series/38074/revisions/1/mbox/

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
incomplete -> PASS   (fi-snb-2520m) fdo#103713

fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713

fi-bdw-5557u total:288  pass:265  dwarn:0   dfail:0   fail:2   skip:21  
time:442s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:424s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:376s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:492s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:287s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:487s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:482s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:470s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:457s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:582s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:580s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:415s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:284s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:511s
fi-hsw-4770  total:288  pass:259  dwarn:0   dfail:0   fail:2   skip:27  
time:411s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:414s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:466s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:414s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:457s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:495s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:499s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:592s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:438s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:506s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:527s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:487s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:479s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:430s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:526s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:397s
Blacklisted hosts:
fi-glk-dsi   total:118  pass:105  dwarn:0   dfail:0   fail:0   skip:12 

9c365b708180066caa8e392828ff07324dd4988e drm-tip: 2018y-02m-12d-15h-35m-40s UTC 
integration manifest
1f84ed642216 drm/i915: Always catch incorrect usage of intel_runtime_pm_get

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7983/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Disable dynamic setup of device_info->num_rings

[Ville Syrjälä]

On Sat, Feb 10, 2018 at 08:39:08AM +, Chris Wilson wrote:
> Quoting Oscar Mateo (2018-02-09 23:46:31)
> > 
> > On 02/09/2018 02:35 PM, Chris Wilson wrote:
> > > In order to allow the compiler to use a known constant number of
> > > available engines, disable modification of intel_device_static_info
> > > during engine bring up. Instead of trying to gracefully hide the broken
> > > setup, error out -- in theory, this should be caught during power on.
> > 
> > We are about to have a case for dynamic number of available engines. 
> > It's one of the ICL patches:
> > 
> > drm/i915/icl: Check for fused-off VDBOX and VEBOX instances
> > 
> > intel_device_runtime_info as well?
> 
> Hmm, ring_mask is more widely used than I was expecting. I think we want
> both, static_info if we ever think we can benefit from single-platform
> LTO of the engines, but whether to use runtime_info or i915->gt.engine_mask
> (and move the engine maps to i915->gt as well).
> 
> Advantage of runtime_info, centralised place for debugging.
> Disadvantage of runtime_info, centralised place far from code.
> 
> Maybe we don't need to say everything is inside runtime_info (just
> anything that doesn't fit elsewhere?), but use the hooks for debugging?
> Maybe having a central runtime_info is simply a bad idea?

Yeah, I don't like the "far from the code" aspect of runtime_info
(or even the static info in some cases).

Another counter argument is perhaps that people are more likely to
update the info for new platforms if it's in a central location, as
opposed having to trawl the entire codebase.

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/5] drm: Allow determining if current task is output poll worker

[Lyude Paul]

On Sun, 2018-02-11 at 10:38 +0100, Lukas Wunner wrote:
> Introduce a helper to determine if the current task is an output poll
> worker.
> 
> This allows us to fix a long-standing deadlock in several DRM drivers
> wherein the ->runtime_suspend callback waits for the output poll worker
> to finish and the worker in turn calls a ->detect callback which waits
> for runtime suspend to finish.  The ->detect callback is invoked from
> multiple call sites and waiting for runtime suspend to finish is the
> correct thing to do except if it's executing in the context of the
> worker.
> 
> Cc: Dave Airlie 
> Cc: Ben Skeggs 
> Cc: Alex Deucher 
> Signed-off-by: Lukas Wunner 
> ---
>  drivers/gpu/drm/drm_probe_helper.c | 14 ++
>  include/drm/drm_crtc_helper.h  |  1 +
>  2 files changed, 15 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_probe_helper.c
> b/drivers/gpu/drm/drm_probe_helper.c
> index 555fbe54d6e2..019881d15ce1 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -653,6 +653,20 @@ static void output_poll_execute(struct work_struct
> *work)
>   schedule_delayed_work(delayed_work,
> DRM_OUTPUT_POLL_PERIOD);
>  }
>  
> +/**
> + * drm_kms_helper_is_poll_worker - is %current task an output poll worker?
> + *
> + * Determine if %current task is an output poll worker.  This can be used
> + * to select distinct code paths for output polling versus other contexts.
> + */
For this, it would be worth explicitly noting in the comments herethat this
should be called by DRM drivers in order to prevent racing with hotplug
polling workers, so that new drivers in the future can avoid implementing this
race condition in their driver.

> +bool drm_kms_helper_is_poll_worker(void)
> +{
> + struct work_struct *work = current_work();
> +
> + return work && work->func == output_poll_execute;
> +}
> +EXPORT_SYMBOL(drm_kms_helper_is_poll_worker);
> +
>  /**
>   * drm_kms_helper_poll_disable - disable output polling
>   * @dev: drm_device
> diff --git a/include/drm/drm_crtc_helper.h b/include/drm/drm_crtc_helper.h
> index 76e237bd989b..6914633037a5 100644
> --- a/include/drm/drm_crtc_helper.h
> +++ b/include/drm/drm_crtc_helper.h
> @@ -77,5 +77,6 @@ void drm_kms_helper_hotplug_event(struct drm_device *dev);
>  
>  void drm_kms_helper_poll_disable(struct drm_device *dev);
>  void drm_kms_helper_poll_enable(struct drm_device *dev);
> +bool drm_kms_helper_is_poll_worker(void);
>  
>  #endif
-- 
Cheers,
Lyude Paul
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Lyude Paul]

This patchset is a no-brainer for me. I'm ashamed to say I think I might have
seen this issue before, but polling gets used so rarely nowadays it slipped
under the rug by accident.

Anyway, for the whole series  (except patch #2, which I will respond to with a
short comment in just a moment):

Reviewed-by: Lyude Paul 

On Sun, 2018-02-11 at 10:38 +0100, Lukas Wunner wrote:
> Fix a deadlock on hybrid graphics laptops that's been present since 2013:
> 
> DRM drivers poll connectors in 10 sec intervals.  The poll worker is
> stopped on ->runtime_suspend with cancel_delayed_work_sync().  However
> the poll worker invokes the DRM drivers' ->detect callbacks, which call
> pm_runtime_get_sync().  If the poll worker starts after runtime suspend
> has begun, pm_runtime_get_sync() will wait for runtime suspend to finish
> with the intention of runtime resuming the device afterwards.  The result
> is a circular wait between poll worker and autosuspend worker.
> 
> I'm seeing this deadlock so often it's not funny anymore. I've also found
> 3 nouveau bugzillas about it and 1 radeon bugzilla. (See patch [3/5] and
> [4/5].)
> 
> One theoretical solution would be to add a flag to the ->detect callback
> to tell it that it's running in the poll worker's context.  In that case
> it doesn't need to call pm_runtime_get_sync() because the poll worker is
> only enabled while runtime active and we know that ->runtime_suspend
> waits for it to finish.  But this approach would require touching every
> single DRM driver's ->detect hook.  Moreover the ->detect hook is called
> from numerous other places, both in the DRM library as well as in each
> driver, making it necessary to trace every possible call chain and check
> if it's coming from the poll worker or not.  I've tried to do that for
> nouveau (see the call sites listed in the commit message of patch [3/5])
> and concluded that this approach is a nightmare to implement.
> 
> Another reason for the infeasibility of this approach is that ->detect
> is called from within the DRM library without driver involvement, e.g.
> via DRM's sysfs interface.  In those cases, pm_runtime_get_sync() would
> have to be called by the DRM library, but the DRM library is supposed to
> stay generic, wheras runtime PM is driver-specific.
> 
> So instead, I've come up with this much simpler solution which gleans
> from the current task's flags if it's a workqueue worker, retrieves the
> work_struct and checks if it's the poll worker.  All that's needed is
> one small helper in the workqueue code and another small helper in the
> DRM library.  This solution lends itself nicely to stable-backporting.
> 
> The patches for radeon and amdgpu are compile-tested only, I only have a
> MacBook Pro with an Nvidia GK107 to test.  To test the patches, add an
> "msleep(12*1000);" at the top of the driver's ->runtime_suspend hook.
> This ensures that the poll worker runs after ->runtime_suspend has begun.
> Wait 12 sec after the GPU has begun runtime suspend, then check
> /sys/bus/pci/devices/:01:00.0/power/runtime_status.  Without this
> series, the status will be stuck at "suspending" and you'll get hung task
> errors in dmesg after a few minutes.
> 
> i915, malidp and msm "solved" this issue by not stopping the poll worker
> on runtime suspend.  But this results in the GPU bouncing back and forth
> between D0 and D3 continuously.  That's a total no-go for GPUs which
> runtime suspend to D3cold since every suspend/resume cycle costs a
> significant amount of time and energy.  (i915 and malidp do not seem
> to acquire a runtime PM ref in the ->detect callbacks, which seems
> questionable.  msm however does and would also deadlock if it disabled
> the poll worker on runtime suspend.  cc += Archit, Liviu, intel-gfx)
> 
> Please review.  Thanks,
> 
> Lukas
> 
> Lukas Wunner (5):
>   workqueue: Allow retrieval of current task's work struct
>   drm: Allow determining if current task is output poll worker
>   drm/nouveau: Fix deadlock on runtime suspend
>   drm/radeon: Fix deadlock on runtime suspend
>   drm/amdgpu: Fix deadlock on runtime suspend
> 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 58 +---
>  drivers/gpu/drm/drm_probe_helper.c | 14 +
>  drivers/gpu/drm/nouveau/nouveau_connector.c| 18 +--
>  drivers/gpu/drm/radeon/radeon_connectors.c | 74 +
> -
>  include/drm/drm_crtc_helper.h  |  1 +
>  include/linux/workqueue.h  |  1 +
>  kernel/workqueue.c | 16 ++
>  7 files changed, 132 insertions(+), 50 deletions(-)
> 
-- 
Cheers,
Lyude Paul
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/3] PSR lag fixes

[Pandiyan, Dhinakaran]

On Mon, 2018-02-12 at 09:45 +0100, Hans de Goede wrote:
> Hi,
> 
> On 12-02-18 07:08, Dhinakaran Pandiyan wrote:
> > PSR currently when enabled results in semi-permanent freezes or noticeable
> > cursor lags.
> > 
> > https://patchwork.freedesktop.org/series/37598/ will fix long freezes due
> > to frame counter resets.
> > 
> > This series has three more fixes -
> > Patch 1 eliminates PSR exit for flips and makes us rely on the HW to do it.
> > Patch 2 fixes cusor move lag by relying on HW to exit PSR.
> > Patch 3 fixes temporary freeze seen with fbdev.
> > 
> > With both the series applied, PSR on my SKL ThinkPad feels pretty good.
> 
> Thank you for your great work on this.
> 
> Are there any more PSR fixes in the pipeline?

Yeah, there are a few more fixes that I hope will appear on the list in
the next two weeks or so.

> If not I think I should do
> a custom Fedora kernel build based on 4.15 + recent fixes and ask all my
> testers to retest with that.
> 
> I do have some questions before I do this:
> 
> 1) I believe that only testers with skylake (normal or LP) or newer should
> re-test, correct?

These fixes do apply for HSW/BDW, so essentially all the big cores
supporting PSR. But, HSW/BDW need fixes for AUX channel-PSR interaction
also. I haven't looked into CHV/VLV.

> 
> 2) I know there are 2 series (including this one), can someone provide a link
> to the latest patchwork version of those 2 series, or even better a git
> branch with 4.15 + those patches? Any patches I'm missing if I pick up these
> 2 series?

https://patchwork.freedesktop.org/series/37598/
https://patchwork.freedesktop.org/series/38067/


> 3) I'm thinking 4.15 atm, but I could also do a 4.16-rc1 test kernel instead
> if that would be better, would that be better ?

I can't think of any diff that would affect PSR, but the latest is
better I suppose.


> 
> Regards,
> 
> Hans
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [igt-dev] [PATCH igt] igt/gem_exec_capture: MI_STORE_DWORD requires EXEC_SECURE + DRM_MASTER on ctg/ilk

[Chris Wilson]

Quoting Ville Syrjälä (2018-02-12 17:30:52)
> On Sat, Feb 10, 2018 at 09:43:38PM +, Chris Wilson wrote:
> > On ctg/ilk, for whatever reason, MI_STORE_DWORD is a privileged operation
> > so we must request a SECURE batch.
> 
> IIRC ctg supposedly introduced some form of ppgtt. Isn't that the
> reason?
> 
> Hmm. Now I wonder how anything works on these platforms. Should the
> batch itself be executed via ppgtt if it's non-secure? Maybe the hw
> has a fallback mechanism of some sort to execute via ggtt if ppgtt
> isn't enabled...
> 
> ppgtt enable bit:
> "When this bit is clear, all memory accesses will be completed using the
> GGTT. Privileged memory protections will not be enforced (it is
> acceptable for a non-secure batch buffer to access GGTT space)"
> 
> OK. That seems to confirm that part of the theory.
> 
> For pre-ctg the spec says:
> "Although Buffer Security Indicator is implemented, there is no usage
>  model for it and it need not be validated."
> 
> So I'm thinking we should never set the non-secure bit on these old
> platforms.

That does open a large can of worms with the ability to write any
register from userspace or manipulate the pagetables; i.e. requires the
cmdparser. The usage model has been such that very few commands are
affected; certainly no one [else] has noticed (afaik).
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Replace open-coded memset_p()

[Chris Wilson]

Quoting Patchwork (2018-02-12 17:19:01)
> == Series Details ==
> 
> Series: drm/i915: Replace open-coded memset_p()
> URL   : https://patchwork.freedesktop.org/series/38082/
> State : success
> 
> == Summary ==
> 
> Test pm_rpm:
> Subgroup gem-idle:
> fail   -> PASS   (shard-hsw)

Thanks for the review. Nothing screamed in horror, so pushed :)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [igt-dev] [PATCH igt] igt/gem_exec_capture: MI_STORE_DWORD requires EXEC_SECURE + DRM_MASTER on ctg/ilk

[Ville Syrjälä]

On Sat, Feb 10, 2018 at 09:43:38PM +, Chris Wilson wrote:
> On ctg/ilk, for whatever reason, MI_STORE_DWORD is a privileged operation
> so we must request a SECURE batch.

IIRC ctg supposedly introduced some form of ppgtt. Isn't that the
reason?

Hmm. Now I wonder how anything works on these platforms. Should the
batch itself be executed via ppgtt if it's non-secure? Maybe the hw
has a fallback mechanism of some sort to execute via ggtt if ppgtt
isn't enabled...

ppgtt enable bit:
"When this bit is clear, all memory accesses will be completed using the
GGTT. Privileged memory protections will not be enforced (it is
acceptable for a non-secure batch buffer to access GGTT space)"

OK. That seems to confirm that part of the theory.

For pre-ctg the spec says:
"Although Buffer Security Indicator is implemented, there is no usage
 model for it and it need not be validated."

So I'm thinking we should never set the non-secure bit on these old
platforms.

> 
> Signed-off-by: Chris Wilson 
> ---
>  tests/gem_exec_capture.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/tests/gem_exec_capture.c b/tests/gem_exec_capture.c
> index 1c7d1e7cb..3a1f70567 100644
> --- a/tests/gem_exec_capture.c
> +++ b/tests/gem_exec_capture.c
> @@ -22,6 +22,7 @@
>   */
>  
>  #include "igt.h"
> +#include "igt_device.h"
>  #include "igt_sysfs.h"
>  
>  #define LOCAL_OBJECT_CAPTURE (1 << 7)
> @@ -141,6 +142,8 @@ static void __capture(int fd, int dir, unsigned ring, 
> uint32_t target)
>   execbuf.buffers_ptr = (uintptr_t)obj;
>   execbuf.buffer_count = ARRAY_SIZE(obj);
>   execbuf.flags = ring;
> + if (gen > 3 && gen < 6)
> + execbuf.flags |= I915_EXEC_SECURE;
>   gem_execbuf(fd, );
>  
>   /* Wait for the request to start */
> @@ -204,7 +207,14 @@ igt_main
>   igt_skip_on_simulation();
>  
>   igt_fixture {
> + int gen;
> +
>   fd = drm_open_driver(DRIVER_INTEL);
> +
> + gen = intel_gen(intel_get_drm_devid(fd));
> + if (gen > 3 && gen < 6) /* ctg and ilk need secure batches */
> + igt_device_set_master(fd);
> +
>   igt_require_gem(fd);
>   gem_require_mmap_wc(fd);
>   igt_require(has_capture(fd));
> -- 
> 2.16.1
> 
> ___
> igt-dev mailing list
> igt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Improve PSR activation timing

[Rodrigo Vivi]

On Sat, Feb 10, 2018 at 09:43:59AM +, Chris Wilson wrote:
> Quoting Andy Lutomirski (2018-02-09 17:55:38)
> > On Fri, Feb 9, 2018 at 7:39 AM, Rodrigo Vivi  wrote:
> > > Rodrigo Vivi  writes:
> > > So, I move the hacked scheduled to 10s and forced psr_activate 10ms
> > > after that and the result is this:
> > >
> > >
> > > [   11.757909] [drm:intel_psr_enable [i915]] *ERROR* I915-DEBUG:
> > > Scheduling 10s
> > > [   11.778586] [drm:intel_psr_flush [i915]] *ERROR* I915-DEBUG: Work busy!
> > > ...
> > > a bunch more of Work busy
> > > ...
> > > [   21.980643] [drm:intel_psr_flush [i915]] *ERROR* I915-DEBUG: Work busy!
> > 
> > This like ("Work busy!") is intel_psr_flush() noticing that
> > work_busy() returns true (which it does indeed do when the work is
> > scheduled for the future).  But this means that intel_psr_flush()
> > wants to keep PSR off for a little bit (10s with your patch applied)
> > because the screen isn't idle.
> > 
> > > [   21.983060] [drm:intel_psr_work [i915]] *ERROR* I915-DEBUG: Work 
> > > running
> > 
> > And here's intel_psr_work() turning PSR back on 3ms later.
> > 
> > So I think you're seeing exactly the bug I described.

Well, not in the way you described though.

As we can see on the log work running get executed only 10 seconds after
intel_psr_enable wanted. None of the thousand flushes happening there will
trigger psr activate before the wanted 10s.

So the hack indeed work as expected.

Given that description I proved that it works as expected and move away.
But since you insisted I step back and re-read your patch like if you had
never mentioned the hack on intel_psr_enable ever, but only focusing
on the regular calls from intel_psr_flush and you are right,
we do have a bug that would affect VLV/CHV here.

In the current code the psr_activate can happen any moment from 0ms to 100ms
after the flush.

This 100ms would just reduce the amount of fast exit-activate cases,
but not eliminate the possibility of enabling before 100ms.

On core platforms it shouldn't be any problem because HW tracking would
take care of waiting the extra idle frames.

This could be a particular problem for VLV/CHV platforms where I believe
we should wait few frames before really activating it back.

So, probably we can go ahead with your patch so we get this covered for
VLV/CHV, but I'd like a version without mentioning the intel_psr_enable
case that is already proven work as expected.

But meanwhile I will check back on the hack and see if we can already
remove that since many things got fixed and improved around eDP link training
and psr itself.

Also I will discuss with DK and check the possibility of a immediate activate
on platforms with HW tracking. Specially now that we are moving towards more
use of HW tracking.

In this case we would reduce this scheduled/timer based solution only for 
VLV/CHV.

And then on VLV/CHV front there are even more issues to sync with VBLANK etc in
a platform that probably went to the market without any single unit with PSR 
panels
that was to expensive when those platforms got released.

I even consider totally removing VLV/CHV code completely.

> 
> It's also evident in the tests that PSR isn't being disabled as
> often/quick as we need for frontbuffer updates to be seen.

Yeap, it is evident we have many bugs there, but I'm afraid this is not
the answer for the lag.
DK found some promising ones...

> -Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] AWOOGA: Revert "ALSA: hda: Make use of core codec functions to sync power state"

[Chris Wilson]

This reverts commit 3b5b899ca67db07a4c4825911072221f99e157e2.

Fixes: 3b5b899ca67d ("ALSA: hda: Make use of core codec functions to sync power 
state")
Cc: Abhijeet Kumar 
Cc: Takashi Iwai 
---
 sound/pci/hda/hda_codec.c | 28 +++-
 sound/pci/hda/hda_local.h |  6 +-
 2 files changed, 28 insertions(+), 6 deletions(-)

diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
index 5bc3a7468e17..e018ecbf78a8 100644
--- a/sound/pci/hda/hda_codec.c
+++ b/sound/pci/hda/hda_codec.c
@@ -2702,6 +2702,32 @@ void snd_hda_codec_set_power_to_all(struct hda_codec 
*codec, hda_nid_t fg,
 }
 EXPORT_SYMBOL_GPL(snd_hda_codec_set_power_to_all);
 
+/*
+ * wait until the state is reached, returns the current state
+ */
+static unsigned int hda_sync_power_state(struct hda_codec *codec,
+hda_nid_t fg,
+unsigned int power_state)
+{
+   unsigned long end_time = jiffies + msecs_to_jiffies(500);
+   unsigned int state, actual_state;
+
+   for (;;) {
+   state = snd_hda_codec_read(codec, fg, 0,
+  AC_VERB_GET_POWER_STATE, 0);
+   if (state & AC_PWRST_ERROR)
+   break;
+   actual_state = (state >> 4) & 0x0f;
+   if (actual_state == power_state)
+   break;
+   if (time_after_eq(jiffies, end_time))
+   break;
+   /* wait until the codec reachs to the target state */
+   msleep(1);
+   }
+   return state;
+}
+
 /**
  * snd_hda_codec_eapd_power_filter - A power filter callback for EAPD
  * @codec: the HDA codec
@@ -2764,7 +2790,7 @@ static unsigned int hda_set_power_state(struct hda_codec 
*codec,
   state);
snd_hda_codec_set_power_to_all(codec, fg, power_state);
}
-   state = snd_hda_sync_power_state(codec, fg, power_state);
+   state = hda_sync_power_state(codec, fg, power_state);
if (!(state & AC_PWRST_ERROR))
break;
}
diff --git a/sound/pci/hda/hda_local.h b/sound/pci/hda/hda_local.h
index 321e78baa63c..5b5c324c99b9 100644
--- a/sound/pci/hda/hda_local.h
+++ b/sound/pci/hda/hda_local.h
@@ -622,11 +622,7 @@ snd_hda_check_power_state(struct hda_codec *codec, 
hda_nid_t nid,
 {
return snd_hdac_check_power_state(>core, nid, target_state);
 }
-static inline bool snd_hda_sync_power_state(struct hda_codec *codec,
-  hda_nid_t nid, unsigned int target_state)
-{
-   return snd_hdac_sync_power_state(>core, nid, target_state);
-}
+
 unsigned int snd_hda_codec_eapd_power_filter(struct hda_codec *codec,
 hda_nid_t nid,
 unsigned int power_state);
-- 
2.16.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Keep vblank irq enabled during vblank evasion.

[Chris Wilson]

Quoting Ville Syrjälä (2018-02-12 16:55:28)
> On Mon, Feb 12, 2018 at 04:41:05PM +0100, Maarten Lankhorst wrote:
> > Op 12-02-18 om 16:31 schreef Chris Wilson:
> > > Quoting Maarten Lankhorst (2018-02-12 15:27:34)
> > >> Op 12-02-18 om 16:22 schreef Chris Wilson:
> > >>> Quoting Maarten Lankhorst (2018-02-12 15:16:39)
> >  Op 12-02-18 om 16:10 schreef Chris Wilson:
> > > Quoting Maarten Lankhorst (2018-02-09 09:54:00)
> > >> This is a nice preparation for grabbing the uncore lock during 
> > >> evasion.
> > >> Grabbing the spinlock with the lock held messes up the locking,
> > >> so it's easier to handover the reference to the eve
> > >>
> > >> Signed-off-by: Maarten Lankhorst 
> > >> ---
> > >>  drivers/gpu/drm/i915/intel_sprite.c | 11 ---
> > >>  1 file changed, 4 insertions(+), 7 deletions(-)
> > >>
> > >> diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
> > >> b/drivers/gpu/drm/i915/intel_sprite.c
> > >> index 3be22c0fcfb5..971a1ea0db45 100644
> > >> --- a/drivers/gpu/drm/i915/intel_sprite.c
> > >> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > >> @@ -109,10 +109,10 @@ void intel_pipe_update_start(const struct 
> > >> intel_crtc_state *new_crtc_state)
> > >>  
> > >> local_irq_disable();
> > >>  
> > >> -   if (min <= 0 || max <= 0)
> > >> +   if (WARN_ON(drm_crtc_vblank_get(>base)))
> > >> return;
> > >>  
> > >> -   if (WARN_ON(drm_crtc_vblank_get(>base)))
> > >> +   if (min <= 0 || max <= 0)
> > >> return;
> > >>  
> > > The corresponding vblank_put is the one later in update_start(), 
> > > right?
> > > I don't think you intended to keep this chunk.
> > > -Chris
> >  I'm not sure what you mean? The vblank_put is now in pipe_update_end, 
> >  except if the
> >  event takes over the reference. I think the code is correct. :)
> > >>> Then it's unbalanced in the case of error still.
> > >>> -Chris
> > >> It already would have been for events, hence the WARN_ON there.
> > >> I don't think we can do anything about it, this shouldn't ever
> > >> happen in practice, could be a BUG_ON for all I care. :)
> > > I would much prefer that over intentionally bad code.
> > >
> > > But do we really need to enable the vblank irq here? If the event
> > > requires it, doesn't it already enable the vblank. Here, we only need it
> > > when sleeping, can we not determine we have enough time before the
> > > vblank without enabling the interrupt?
> > I'm not sure why we get a reference to the vblank counter here. Perhaps 
> > Ville does?
> 
> We need the vblank irq to be enabled before we check the scanline since
> otherwise we may end up doing:
> 
> 1. check scanline
> 3. vblank irq fires
> 2. enable vblank irq
> 3. wait for the next vblank
> 
> So we'd end up wasting an entire frame.

Step: 2.5, check_scanline?

Something like,

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 574bd02c5a2e..70c2ee1c7b8c 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -97,6 +97,7 @@ void intel_pipe_update_start(const struct intel_crtc_state 
*new_crtc_state)
bool need_vlv_dsi_wa = (IS_VALLEYVIEW(dev_priv) || 
IS_CHERRYVIEW(dev_priv)) &&
intel_crtc_has_type(new_crtc_state, INTEL_OUTPUT_DSI);
DEFINE_WAIT(wait);
+   bool have_vblank_irq = false;
 
vblank_start = adjusted_mode->crtc_vblank_start;
if (adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE)
@@ -112,9 +113,6 @@ void intel_pipe_update_start(const struct intel_crtc_state 
*new_crtc_state)
if (min <= 0 || max <= 0)
return;
 
-   if (WARN_ON(drm_crtc_vblank_get(>base)))
-   return;
-
crtc->debug.min_vbl = min;
crtc->debug.max_vbl = max;
trace_i915_pipe_update_start(crtc);
@@ -127,6 +125,10 @@ void intel_pipe_update_start(const struct intel_crtc_state 
*new_crtc_state)
 */
prepare_to_wait(wq, , TASK_UNINTERRUPTIBLE);
 
+   if (!have_vblank_irq)
+   have_vblank_irq = !drm_crtc_vblank_get(>base);
+
scanline = intel_get_crtc_scanline(crtc);
if (scanline < min || scanline > max)
break;
@@ -145,8 +147,8 @@ void intel_pipe_update_start(const struct intel_crtc_state 
*new_crtc_state)
}
 
finish_wait(wq, );
-
-   drm_crtc_vblank_put(>base);
+   if (have_vblank_irq)
+   drm_crtc_vblank_put(>base);
 
/*
 * On VLV/CHV DSI the scanline counter would appear to

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Replace open-coded memset_p()

[Patchwork]

== Series Details ==

Series: drm/i915: Replace open-coded memset_p()
URL   : https://patchwork.freedesktop.org/series/38082/
State : success

== Summary ==

Test pm_rpm:
Subgroup gem-idle:
fail   -> PASS   (shard-hsw)

shard-apltotal:3391 pass:1763 dwarn:1   dfail:0   fail:20  skip:1606 
time:12502s
shard-hswtotal:3444 pass:1718 dwarn:1   dfail:0   fail:54  skip:1670 
time:11997s
shard-snbtotal:3444 pass:1351 dwarn:1   dfail:0   fail:10  skip:2082 
time:6713s
Blacklisted hosts:
shard-kbltotal:3444 pass:1913 dwarn:1   dfail:0   fail:22  skip:1508 
time:9748s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7980/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm: Use idr_init_base(1) when using id==0 for invalid

[Ville Syrjälä]

On Mon, Feb 12, 2018 at 02:55:33PM +, Chris Wilson wrote:
> Use the new idr_init_base() function to create an IDR that knows id==0
> is never allocated as it maps to an invalid identifier. By knowing that
> id==0 is invalid, the IDR can start from id=1 instead avoiding the issue
> of having to start each lookup from the zeroth leaf as id==0 is always
> unused (and thus the tree-of-bitmaps indicate that is the first
> available).
> 
> References: 6ce711f27500 ("idr: Make 1-based IDRs more efficient")
> Signed-off-by: Chris Wilson 
> Cc: Daniel Vetter 
> Cc: Christian Konig 
> Cc: Dave Airlie 

Yep, looks like all of these pass start==1 to idr_alloc().
Reviewed-by: Ville Syrjälä 

Looks like at least tile_idr and crtc_idr could use this as well,
although I suppose they're not hit nearly as hard as the gem stuff.
Also someone should really s/crtc_idr/obj_id_idr/ or something
along those lines.

> ---
> Note this requires 4.16-rc1.
> ---
>  drivers/gpu/drm/drm_gem.c | 4 ++--
>  drivers/gpu/drm/drm_syncobj.c | 2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 01f8d9481211..4975ba9a7bc8 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -98,7 +98,7 @@ drm_gem_init(struct drm_device *dev)
>   struct drm_vma_offset_manager *vma_offset_manager;
>  
>   mutex_init(>object_name_lock);
> - idr_init(>object_name_idr);
> + idr_init_base(>object_name_idr, 1);
>  
>   vma_offset_manager = kzalloc(sizeof(*vma_offset_manager), GFP_KERNEL);
>   if (!vma_offset_manager) {
> @@ -776,7 +776,7 @@ drm_gem_open_ioctl(struct drm_device *dev, void *data,
>  void
>  drm_gem_open(struct drm_device *dev, struct drm_file *file_private)
>  {
> - idr_init(_private->object_idr);
> + idr_init_base(_private->object_idr, 1);
>   spin_lock_init(_private->table_lock);
>  }
>  
> diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
> index 0b7b0d1ad2d5..d4f4ce484529 100644
> --- a/drivers/gpu/drm/drm_syncobj.c
> +++ b/drivers/gpu/drm/drm_syncobj.c
> @@ -546,7 +546,7 @@ static int drm_syncobj_export_sync_file(struct drm_file 
> *file_private,
>  void
>  drm_syncobj_open(struct drm_file *file_private)
>  {
> - idr_init(_private->syncobj_idr);
> + idr_init_base(_private->syncobj_idr, 1);
>   spin_lock_init(_private->syncobj_table_lock);
>  }
>  
> -- 
> 2.16.1
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/5] workqueue: Allow retrieval of current task's work struct

[Tejun Heo]

Hello,

On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
> Introduce a helper to retrieve the current task's work struct if it is
> a workqueue worker.
> 
> This allows us to fix a long-standing deadlock in several DRM drivers
> wherein the ->runtime_suspend callback waits for a specific worker to
> finish and that worker in turn calls a function which waits for runtime
> suspend to finish.  That function is invoked from multiple call sites
> and waiting for runtime suspend to finish is the correct thing to do
> except if it's executing in the context of the worker.
> 
> Cc: Tejun Heo 
> Cc: Lai Jiangshan 
> Cc: Dave Airlie 
> Cc: Ben Skeggs 
> Cc: Alex Deucher 
> Signed-off-by: Lukas Wunner 

I wonder whether it's too generic a name but there are other functions
named in a similar fashion and AFAICS current_work isn't used by
anyone in the tree, so it seems okay.

Acked-by: Tejun Heo 

Please feel free to route as you see fit.

Thanks.

-- 
tejun
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/5] drm/i915: Grab the vblank evasion lock around the entire evasion.

[Ville Syrjälä]

On Fri, Feb 09, 2018 at 06:21:08PM +0100, Maarten Lankhorst wrote:
> Op 09-02-18 om 11:04 schreef Chris Wilson:
> > Quoting Maarten Lankhorst (2018-02-09 09:53:59)
> >> Some cleanups to move the uncore.lock around vblank evasion, so run
> >> to completion without racing on uncore.lock. Hopefully this will reduce
> >> the chance of underruns, and perhaps allows us to decrease 
> >> VBLANK_EVASION_TIME_US as well as a followup patch.
> >>
> >> Tested on KBL and BSW.
> > * shivers
> >
> > uncore.lock is a brutally contested lock. Ville's patches did work on
> > splitting the uncore.lock into forcewake and display variants, which
> > cuts down on the nasty side effects.
> >
> > Latency profiling, another item for the CI/QA wishlist.
> > -Chris
> 
> Yeah, unfortunately this is not different from status quo. We already
> require everything inside vblank evasion to run as fast as possible,
> and it's down to a list of register writes and a few reads. Those
> already need the uncore.lock, so all we do now is being more explicit
> about when we take it and eliminate contention when we write out the
> register values.

Would be nice to have some results for this though. IIRC when I was
benchmarking my update optimizations and the de_lock stuff I was
simply logging how long the updates take, and staring at histograms
of that after running a bunch of igts and whatnot. I'm not sure I
have the results anymore, but IIRC I did see some improvement.

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: Grab the vblank evasion lock around the entire evasion.

[Patchwork]

== Series Details ==

Series: drm/i915: Grab the vblank evasion lock around the entire evasion.
URL   : https://patchwork.freedesktop.org/series/37986/
State : warning

== Summary ==

Test gem_eio:
Subgroup in-flight:
pass   -> DMESG-WARN (shard-snb) fdo#104058
Test pm_rpm:
Subgroup gem-evict-pwrite:
fail   -> PASS   (shard-hsw)
Subgroup pm-caching:
fail   -> PASS   (shard-hsw)
Subgroup universal-planes-dpms:
fail   -> PASS   (shard-hsw)
Test kms_frontbuffer_tracking:
Subgroup fbc-2p-primscrn-pri-indfb-draw-pwrite:
pass   -> SKIP   (shard-hsw)
Test drv_suspend:
Subgroup fence-restore-untiled:
pass   -> SKIP   (shard-snb)

fdo#104058 https://bugs.freedesktop.org/show_bug.cgi?id=104058

shard-apltotal:3391 pass:1763 dwarn:1   dfail:0   fail:20  skip:1606 
time:12575s
shard-hswtotal:3444 pass:1719 dwarn:1   dfail:0   fail:52  skip:1671 
time:11907s
shard-snbtotal:3444 pass:1349 dwarn:2   dfail:0   fail:10  skip:2083 
time:6712s
Blacklisted hosts:
shard-kbltotal:3444 pass:1914 dwarn:1   dfail:0   fail:21  skip:1508 
time:9740s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7979/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Keep vblank irq enabled during vblank evasion.

[Ville Syrjälä]

On Mon, Feb 12, 2018 at 04:41:05PM +0100, Maarten Lankhorst wrote:
> Op 12-02-18 om 16:31 schreef Chris Wilson:
> > Quoting Maarten Lankhorst (2018-02-12 15:27:34)
> >> Op 12-02-18 om 16:22 schreef Chris Wilson:
> >>> Quoting Maarten Lankhorst (2018-02-12 15:16:39)
>  Op 12-02-18 om 16:10 schreef Chris Wilson:
> > Quoting Maarten Lankhorst (2018-02-09 09:54:00)
> >> This is a nice preparation for grabbing the uncore lock during evasion.
> >> Grabbing the spinlock with the lock held messes up the locking,
> >> so it's easier to handover the reference to the eve
> >>
> >> Signed-off-by: Maarten Lankhorst 
> >> ---
> >>  drivers/gpu/drm/i915/intel_sprite.c | 11 ---
> >>  1 file changed, 4 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
> >> b/drivers/gpu/drm/i915/intel_sprite.c
> >> index 3be22c0fcfb5..971a1ea0db45 100644
> >> --- a/drivers/gpu/drm/i915/intel_sprite.c
> >> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> >> @@ -109,10 +109,10 @@ void intel_pipe_update_start(const struct 
> >> intel_crtc_state *new_crtc_state)
> >>  
> >> local_irq_disable();
> >>  
> >> -   if (min <= 0 || max <= 0)
> >> +   if (WARN_ON(drm_crtc_vblank_get(>base)))
> >> return;
> >>  
> >> -   if (WARN_ON(drm_crtc_vblank_get(>base)))
> >> +   if (min <= 0 || max <= 0)
> >> return;
> >>  
> > The corresponding vblank_put is the one later in update_start(), right?
> > I don't think you intended to keep this chunk.
> > -Chris
>  I'm not sure what you mean? The vblank_put is now in pipe_update_end, 
>  except if the
>  event takes over the reference. I think the code is correct. :)
> >>> Then it's unbalanced in the case of error still.
> >>> -Chris
> >> It already would have been for events, hence the WARN_ON there.
> >> I don't think we can do anything about it, this shouldn't ever
> >> happen in practice, could be a BUG_ON for all I care. :)
> > I would much prefer that over intentionally bad code.
> >
> > But do we really need to enable the vblank irq here? If the event
> > requires it, doesn't it already enable the vblank. Here, we only need it
> > when sleeping, can we not determine we have enough time before the
> > vblank without enabling the interrupt?
> I'm not sure why we get a reference to the vblank counter here. Perhaps Ville 
> does?

We need the vblank irq to be enabled before we check the scanline since
otherwise we may end up doing:

1. check scanline
3. vblank irq fires
2. enable vblank irq
3. wait for the next vblank

So we'd end up wasting an entire frame.

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 10/10] drm/i915: Make a mutable copy of intel_device_static_info.has_fbc

[Ville Syrjälä]

On Fri, Feb 09, 2018 at 09:16:54PM +, Chris Wilson wrote:
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  | 2 +-
>  drivers/gpu/drm/i915/intel_device_info.c | 1 +
>  drivers/gpu/drm/i915/intel_device_info.h | 2 ++
>  drivers/gpu/drm/i915/intel_fbc.c | 3 ++-
>  4 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index a662d5f28080..8bf782b08fe0 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2807,7 +2807,7 @@ runtime_info(const struct drm_i915_private *dev_priv)
>  #define I915_HAS_HOTPLUG(dev_priv)   (DEVICE_INFO(dev_priv)->has_hotplug)
>  
>  #define HAS_FW_BLC(dev_priv) (INTEL_GEN(dev_priv) > 2)
> -#define HAS_FBC(dev_priv)(DEVICE_INFO(dev_priv)->has_fbc)
> +#define HAS_FBC(dev_priv)(DEVICE_INFO(dev_priv)->has_fbc & 
> RUNTIME_INFO(dev_priv)->has_fbc)
>  #define HAS_CUR_FBC(dev_priv)(!HAS_GMCH_DISPLAY(dev_priv) && 
> DEVICE_INFO(dev_priv)->gen >= 7)
>  
>  #define HAS_IPS(dev_priv)(IS_HSW_ULT(dev_priv) || IS_BROADWELL(dev_priv))
> diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
> b/drivers/gpu/drm/i915/intel_device_info.c
> index 1a5b2c1c9df9..580ca5b0a1e3 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.c
> +++ b/drivers/gpu/drm/i915/intel_device_info.c
> @@ -587,6 +587,7 @@ void intel_device_runtime_info_print(const struct 
> intel_device_runtime_info *inf
>   sseu_dump(>sseu, p);
>  
>   drm_printf(p, "Num display pipes: %d\n", info->num_pipes);
> + drm_printf(p, "Has FBC: %s\n", yesno(info->has_fbc));
>  }
>  
>  void intel_driver_caps_print(const struct intel_driver_caps *caps,
> diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
> b/drivers/gpu/drm/i915/intel_device_info.h
> index 09e0200f7afa..3f21b3ea25b1 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.h
> +++ b/drivers/gpu/drm/i915/intel_device_info.h
> @@ -167,6 +167,8 @@ struct intel_device_runtime_info { /* device info probed 
> at runtime */
>   u8 num_sprites[I915_MAX_PIPES];
>   u8 num_scalers[I915_MAX_PIPES];
>  
> + bool has_fbc:1;
> +
>   /* Slice/subslice/EU info */
>   struct sseu_dev_info sseu;
>  
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c 
> b/drivers/gpu/drm/i915/intel_fbc.c
> index d7d1ac79c38a..73aa904f7f56 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -1361,8 +1361,9 @@ void intel_fbc_init(struct drm_i915_private *dev_priv)
>   fbc->active = false;
>   fbc->work.scheduled = false;
>  
> + dev_priv->device_runtime.has_fbc = DEVICE_INFO(dev_priv)->has_fbc;
>   if (need_fbc_vtd_wa(dev_priv))
> - mkwrite_device_info(dev_priv)->has_fbc = false;
> + dev_priv->device_runtime.has_fbc = false;

IIRC I sent a patch series adding a plane->has_fbc, so if we were to
have that we might not need this one. Not sure. But I suppose there
isn't much harm in having this in the runtime info though, and we
can always revisit it later.

>  
>   i915_modparams.enable_fbc = intel_sanitize_fbc_option(dev_priv);
>   DRM_DEBUG_KMS("Sanitized enable_fbc value: %d\n",
> -- 
> 2.16.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 08/10] drm/i915: Move SSEU runtime info to intel_device_runtime_info

[Ville Syrjälä]

On Fri, Feb 09, 2018 at 09:16:52PM +, Chris Wilson wrote:
> diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
> b/drivers/gpu/drm/i915/intel_device_info.h
> index 8a570f75d67e..d5f34f124e34 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.h
> +++ b/drivers/gpu/drm/i915/intel_device_info.h
> @@ -98,7 +98,6 @@ enum intel_platform {
>   func(has_logical_ring_contexts); \
>   func(has_logical_ring_preemption); \
>   func(has_overlay); \
> - func(has_pooled_eu); \
>   func(has_psr); \
>   func(has_rc6); \
>   func(has_rc6p); \
> @@ -123,6 +122,7 @@ struct sseu_dev_info {
>   u8 has_slice_pg:1;
>   u8 has_subslice_pg:1;
>   u8 has_eu_pg:1;
> + u8 has_pooled_eu:1;
>  };
>  
>  struct intel_device_static_info {
> @@ -139,8 +139,6 @@ struct intel_device_static_info {
>   u32 display_mmio_offset;
>  
>   u8 num_pipes;
> - u8 num_sprites[I915_MAX_PIPES];
> - u8 num_scalers[I915_MAX_PIPES];

num_sprites and num_scalers are actually static information, so we could
consider removing the runtime initialization for them instead.

Not sure what to do with num_sprites actually. We might think about just
removing it entirely, although we'd still want something to figure out
how many planes to initialize. That something could be just a local
variable in the display init code though. Oh, and I suppose the same
could be done for num_scalers since we copy it over into
crtc->num_scalers anyway.

PS. the patch subject is misleading since you do a lot more than the
sseu stuff here.

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/5] drm/i915: Call i915_pipe_update_start with uncore.lock held.

[Maarten Lankhorst]

Op 12-02-18 om 16:44 schreef Chris Wilson:
> Quoting Maarten Lankhorst (2018-02-12 15:39:16)
>> Op 12-02-18 om 16:19 schreef Chris Wilson:
>>> Quoting Maarten Lankhorst (2018-02-09 09:54:02)
 This requires being able to read the vblank counter with the
 uncore.lock already held. This is also a preparation for
 being able to run the entire vblank update sequence with
 the uncore lock held.

 Signed-off-by: Maarten Lankhorst 
 ---
  drivers/gpu/drm/i915/i915_irq.c | 66 
 ++---
  drivers/gpu/drm/i915/i915_trace.h   |  5 ++-
  drivers/gpu/drm/i915/intel_drv.h|  1 +
  drivers/gpu/drm/i915/intel_sprite.c |  3 +-
  4 files changed, 60 insertions(+), 15 deletions(-)

 diff --git a/drivers/gpu/drm/i915/i915_irq.c 
 b/drivers/gpu/drm/i915/i915_irq.c
 index eda9543a0199..6c491e63e07c 100644
 --- a/drivers/gpu/drm/i915/i915_irq.c
 +++ b/drivers/gpu/drm/i915/i915_irq.c
 @@ -736,13 +736,12 @@ static void i915_enable_asle_pipestat(struct 
 drm_i915_private *dev_priv)
  /* Called from drm generic code, passed a 'crtc', which
   * we use as a pipe index
   */
 -static u32 i915_get_vblank_counter(struct drm_device *dev, unsigned int 
 pipe)
 +static u32 __i915_get_vblank_counter(struct intel_crtc *crtc)
  {
 -   struct drm_i915_private *dev_priv = to_i915(dev);
 +   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
 i915_reg_t high_frame, low_frame;
 u32 high1, high2, low, pixel, vbl_start, hsync_start, htotal;
 -   const struct drm_display_mode *mode = >vblank[pipe].hwmode;
 -   unsigned long irqflags;
 +   const struct drm_display_mode *mode = 
 >base.dev->vblank[crtc->pipe].hwmode;
>>> lockdep_assert_held(_priv->uncore.lock);
>>>
  
 htotal = mode->crtc_htotal;
 hsync_start = mode->crtc_hsync_start;
 @@ -756,10 +755,8 @@ static u32 i915_get_vblank_counter(struct drm_device 
 *dev, unsigned int pipe)
 /* Start of vblank event occurs at start of hsync */
 vbl_start -= htotal - hsync_start;
  
 -   high_frame = PIPEFRAME(pipe);
 -   low_frame = PIPEFRAMEPIXEL(pipe);
 -
 -   spin_lock_irqsave(_priv->uncore.lock, irqflags);
 +   high_frame = PIPEFRAME(crtc->pipe);
 +   low_frame = PIPEFRAMEPIXEL(crtc->pipe);
  
 /*
  * High & low register fields aren't synchronized, so make sure
 @@ -772,8 +769,6 @@ static u32 i915_get_vblank_counter(struct drm_device 
 *dev, unsigned int pipe)
 high2 = I915_READ_FW(high_frame) & PIPE_FRAME_HIGH_MASK;
 } while (high1 != high2);
  
 -   spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
 -
 high1 >>= PIPE_FRAME_HIGH_SHIFT;
 pixel = low & PIPE_PIXEL_MASK;
 low >>= PIPE_FRAME_LOW_SHIFT;
 @@ -786,11 +781,60 @@ static u32 i915_get_vblank_counter(struct drm_device 
 *dev, unsigned int pipe)
 return (((high1 << 8) | low) + (pixel >= vbl_start)) & 0xff;
  }
  
 +static u32 i915_get_vblank_counter(struct drm_device *dev, unsigned int 
 pipe)
 +{
 +   struct drm_i915_private *dev_priv = to_i915(dev);
 +   unsigned long irqflags;
 +   u32 ret;
 +
 +   spin_lock_irqsave(_priv->uncore.lock, irqflags);
 +   ret = i915_get_vblank_counter(dev, pipe);
 +   spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
 +
 +   return ret;
 +}
 +
 +static u32 __g4x_get_vblank_counter(struct intel_crtc *crtc)
 +{
 +   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>>> lockdep_assert_held(_priv->uncore.lock); ?
>>>
>>> Ok, why do we need uncore.lock held here at all? Serialisation of mmio
>>> access to the same cacheline is the age old reason, can we guarantee
>>> that doesn't happen anyway? (Probably not, but really most callers do
>>> not need the mmio w/a.)
>> Is the serialization only needed for writing?
> No, sadly not. Concurrent access of any type to the same cacheline is
> the trigger. (Supposed to be ivb-only.)
It's gonna be a pain to find all users, so I think keeping the uncore lock is 
good enough for now, or we need to split off the display engine lock..

>  
>> The only thing that can race with nonblocking atomic commits are legacy
>> cursor updates, but those can only happen if the cursor plane are not part
>> of the previous atomic commit. Those are also protected by plane->mutex,
>> so in theory same cache lines on the same pipes probably can't race..
> At worst, we could just use a vblank->spinlock?
Perhaps, but the amount of registers isn't exactly small, so I feel better if 
we use the same lock consistently..
___
Intel-gfx 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Use idr_init_base(1) when using id==0 for invalid

[Patchwork]

== Series Details ==

Series: drm: Use idr_init_base(1) when using id==0 for invalid
URL   : https://patchwork.freedesktop.org/series/38089/
State : success

== Summary ==

Series 38089v1 drm: Use idr_init_base(1) when using id==0 for invalid
https://patchwork.freedesktop.org/api/1.0/series/38089/revisions/1/mbox/

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
incomplete -> PASS   (fi-snb-2520m) fdo#103713
Subgroup suspend-read-crc-pipe-c:
pass   -> DMESG-WARN (fi-skl-6700k2) fdo#104108

fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#104108 https://bugs.freedesktop.org/show_bug.cgi?id=104108

fi-bdw-5557u total:288  pass:265  dwarn:0   dfail:0   fail:2   skip:21  
time:441s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:428s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:376s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:486s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:286s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:479s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:484s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:468s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:456s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:568s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:579s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:415s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:284s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:509s
fi-hsw-4770  total:288  pass:259  dwarn:0   dfail:0   fail:2   skip:27  
time:410s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:411s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:459s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:412s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:458s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:498s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:503s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:590s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:435s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:509s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:526s
fi-skl-6700k2total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:483s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:474s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:430s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:521s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:400s
Blacklisted hosts:
fi-glk-dsi   total:117  pass:105  dwarn:0   dfail:0   fail:0   skip:12 

9c365b708180066caa8e392828ff07324dd4988e drm-tip: 2018y-02m-12d-15h-35m-40s UTC 
integration manifest
6cb062771a75 drm: Use idr_init_base(1) when using id==0 for invalid

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7982/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/5] drm/i915: Call i915_pipe_update_start with uncore.lock held.

[Chris Wilson]

Quoting Maarten Lankhorst (2018-02-12 15:39:16)
> Op 12-02-18 om 16:19 schreef Chris Wilson:
> > Quoting Maarten Lankhorst (2018-02-09 09:54:02)
> >> This requires being able to read the vblank counter with the
> >> uncore.lock already held. This is also a preparation for
> >> being able to run the entire vblank update sequence with
> >> the uncore lock held.
> >>
> >> Signed-off-by: Maarten Lankhorst 
> >> ---
> >>  drivers/gpu/drm/i915/i915_irq.c | 66 
> >> ++---
> >>  drivers/gpu/drm/i915/i915_trace.h   |  5 ++-
> >>  drivers/gpu/drm/i915/intel_drv.h|  1 +
> >>  drivers/gpu/drm/i915/intel_sprite.c |  3 +-
> >>  4 files changed, 60 insertions(+), 15 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> >> b/drivers/gpu/drm/i915/i915_irq.c
> >> index eda9543a0199..6c491e63e07c 100644
> >> --- a/drivers/gpu/drm/i915/i915_irq.c
> >> +++ b/drivers/gpu/drm/i915/i915_irq.c
> >> @@ -736,13 +736,12 @@ static void i915_enable_asle_pipestat(struct 
> >> drm_i915_private *dev_priv)
> >>  /* Called from drm generic code, passed a 'crtc', which
> >>   * we use as a pipe index
> >>   */
> >> -static u32 i915_get_vblank_counter(struct drm_device *dev, unsigned int 
> >> pipe)
> >> +static u32 __i915_get_vblank_counter(struct intel_crtc *crtc)
> >>  {
> >> -   struct drm_i915_private *dev_priv = to_i915(dev);
> >> +   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> >> i915_reg_t high_frame, low_frame;
> >> u32 high1, high2, low, pixel, vbl_start, hsync_start, htotal;
> >> -   const struct drm_display_mode *mode = >vblank[pipe].hwmode;
> >> -   unsigned long irqflags;
> >> +   const struct drm_display_mode *mode = 
> >> >base.dev->vblank[crtc->pipe].hwmode;
> > lockdep_assert_held(_priv->uncore.lock);
> >
> >>  
> >> htotal = mode->crtc_htotal;
> >> hsync_start = mode->crtc_hsync_start;
> >> @@ -756,10 +755,8 @@ static u32 i915_get_vblank_counter(struct drm_device 
> >> *dev, unsigned int pipe)
> >> /* Start of vblank event occurs at start of hsync */
> >> vbl_start -= htotal - hsync_start;
> >>  
> >> -   high_frame = PIPEFRAME(pipe);
> >> -   low_frame = PIPEFRAMEPIXEL(pipe);
> >> -
> >> -   spin_lock_irqsave(_priv->uncore.lock, irqflags);
> >> +   high_frame = PIPEFRAME(crtc->pipe);
> >> +   low_frame = PIPEFRAMEPIXEL(crtc->pipe);
> >>  
> >> /*
> >>  * High & low register fields aren't synchronized, so make sure
> >> @@ -772,8 +769,6 @@ static u32 i915_get_vblank_counter(struct drm_device 
> >> *dev, unsigned int pipe)
> >> high2 = I915_READ_FW(high_frame) & PIPE_FRAME_HIGH_MASK;
> >> } while (high1 != high2);
> >>  
> >> -   spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
> >> -
> >> high1 >>= PIPE_FRAME_HIGH_SHIFT;
> >> pixel = low & PIPE_PIXEL_MASK;
> >> low >>= PIPE_FRAME_LOW_SHIFT;
> >> @@ -786,11 +781,60 @@ static u32 i915_get_vblank_counter(struct drm_device 
> >> *dev, unsigned int pipe)
> >> return (((high1 << 8) | low) + (pixel >= vbl_start)) & 0xff;
> >>  }
> >>  
> >> +static u32 i915_get_vblank_counter(struct drm_device *dev, unsigned int 
> >> pipe)
> >> +{
> >> +   struct drm_i915_private *dev_priv = to_i915(dev);
> >> +   unsigned long irqflags;
> >> +   u32 ret;
> >> +
> >> +   spin_lock_irqsave(_priv->uncore.lock, irqflags);
> >> +   ret = i915_get_vblank_counter(dev, pipe);
> >> +   spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
> >> +
> >> +   return ret;
> >> +}
> >> +
> >> +static u32 __g4x_get_vblank_counter(struct intel_crtc *crtc)
> >> +{
> >> +   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > lockdep_assert_held(_priv->uncore.lock); ?
> >
> > Ok, why do we need uncore.lock held here at all? Serialisation of mmio
> > access to the same cacheline is the age old reason, can we guarantee
> > that doesn't happen anyway? (Probably not, but really most callers do
> > not need the mmio w/a.)
> 
> Is the serialization only needed for writing?

No, sadly not. Concurrent access of any type to the same cacheline is
the trigger. (Supposed to be ivb-only.)
 
> The only thing that can race with nonblocking atomic commits are legacy
> cursor updates, but those can only happen if the cursor plane are not part
> of the previous atomic commit. Those are also protected by plane->mutex,
> so in theory same cache lines on the same pipes probably can't race..

At worst, we could just use a vblank->spinlock?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Always catch incorrect usage of intel_runtime_pm_get

[Patchwork]

== Series Details ==

Series: drm/i915: Always catch incorrect usage of intel_runtime_pm_get
URL   : https://patchwork.freedesktop.org/series/38074/
State : failure

== Summary ==

Series 38074v1 drm/i915: Always catch incorrect usage of intel_runtime_pm_get
https://patchwork.freedesktop.org/api/1.0/series/38074/revisions/1/mbox/

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713
incomplete -> PASS   (fi-skl-6260u)
Subgroup suspend-read-crc-pipe-c:
pass   -> INCOMPLETE (fi-bxt-dsi)
Test prime_vgem:
Subgroup basic-fence-flip:
fail   -> PASS   (fi-ilk-650)

fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713

fi-bdw-5557u total:288  pass:265  dwarn:0   dfail:0   fail:2   skip:21  
time:438s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:423s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:374s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:498s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:288s
fi-bxt-dsi   total:246  pass:219  dwarn:0   dfail:0   fail:0   skip:26 
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:490s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:468s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:465s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:572s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:575s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:416s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:279s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:509s
fi-hsw-4770  total:288  pass:259  dwarn:0   dfail:0   fail:2   skip:27  
time:410s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:412s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:452s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:421s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:454s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:499s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:499s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:593s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:432s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:504s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:524s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:483s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:493s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:431s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:395s
Blacklisted hosts:
fi-glk-dsi   total:117  pass:105  dwarn:0   dfail:0   fail:0   skip:12 
fi-skl-guc failed to collect. IGT log at Patchwork_7981/fi-skl-guc/run0.log

817d13e99013266e1dc5e7fc056faa960e9a53dc drm-tip: 2018y-02m-12d-13h-34m-48s UTC 
integration manifest
1532d67a0557 drm/i915: Always catch incorrect usage of intel_runtime_pm_get

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7981/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Don't query PCODE RC6VIDS on platforms not supporting it

[Imre Deak]

On Fri, Feb 09, 2018 at 03:24:28AM +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: Don't query PCODE RC6VIDS on platforms not supporting it
> URL   : https://patchwork.freedesktop.org/series/37936/
> State : success

Pushed it to -dinq with the s/Reference:/References:/ change. Thanks for
the review.

> 
> == Summary ==
> 
> Test kms_cursor_crc:
> Subgroup cursor-64x64-offscreen:
> skip   -> PASS   (shard-apl)
> Test gem_exec_suspend:
> Subgroup basic-s4:
> skip   -> FAIL   (shard-snb) fdo#103375
> Test drv_suspend:
> Subgroup debugfs-reader:
> skip   -> PASS   (shard-snb) fdo#102365 +1
> Test gem_eio:
> Subgroup in-flight-contexts:
> pass   -> FAIL   (shard-hsw) fdo#104676 +1
> Test kms_sysfs_edid_timing:
> warn   -> PASS   (shard-apl) fdo#100047
> Test kms_flip:
> Subgroup 2x-plain-flip-fb-recreate-interruptible:
> fail   -> PASS   (shard-hsw)
> Test kms_frontbuffer_tracking:
> Subgroup fbc-1p-primscrn-cur-indfb-draw-mmap-gtt:
> pass   -> FAIL   (shard-apl) fdo#101623
> Test perf_pmu:
> Subgroup semaphore-wait-idle-bcs0:
> fail   -> PASS   (shard-apl) fdo#105011
> Test kms_cursor_legacy:
> Subgroup cursor-vs-flip-legacy:
> fail   -> PASS   (shard-apl) fdo#103355
> Test kms_plane:
> Subgroup plane-panning-bottom-right-suspend-pipe-b-planes:
> pass   -> SKIP   (shard-hsw) fdo#103540
> 
> fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
> fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
> fdo#104676 https://bugs.freedesktop.org/show_bug.cgi?id=104676
> fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
> fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
> fdo#105011 https://bugs.freedesktop.org/show_bug.cgi?id=105011
> fdo#103355 https://bugs.freedesktop.org/show_bug.cgi?id=103355
> fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
> 
> shard-apltotal:3354 pass:1738 dwarn:1   dfail:0   fail:20  skip:1594 
> time:12341s
> shard-hswtotal:3444 pass:1759 dwarn:1   dfail:0   fail:11  skip:1672 
> time:11773s
> shard-snbtotal:3444 pass:1350 dwarn:1   dfail:0   fail:11  skip:2082 
> time:6581s
> Blacklisted hosts:
> shard-kbltotal:3380 pass:1876 dwarn:1   dfail:0   fail:21  skip:1481 
> time:9422s
> 
> == Logs ==
> 
> For more details see: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7959/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Keep vblank irq enabled during vblank evasion.

[Maarten Lankhorst]

Op 12-02-18 om 16:31 schreef Chris Wilson:
> Quoting Maarten Lankhorst (2018-02-12 15:27:34)
>> Op 12-02-18 om 16:22 schreef Chris Wilson:
>>> Quoting Maarten Lankhorst (2018-02-12 15:16:39)
 Op 12-02-18 om 16:10 schreef Chris Wilson:
> Quoting Maarten Lankhorst (2018-02-09 09:54:00)
>> This is a nice preparation for grabbing the uncore lock during evasion.
>> Grabbing the spinlock with the lock held messes up the locking,
>> so it's easier to handover the reference to the eve
>>
>> Signed-off-by: Maarten Lankhorst 
>> ---
>>  drivers/gpu/drm/i915/intel_sprite.c | 11 ---
>>  1 file changed, 4 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
>> b/drivers/gpu/drm/i915/intel_sprite.c
>> index 3be22c0fcfb5..971a1ea0db45 100644
>> --- a/drivers/gpu/drm/i915/intel_sprite.c
>> +++ b/drivers/gpu/drm/i915/intel_sprite.c
>> @@ -109,10 +109,10 @@ void intel_pipe_update_start(const struct 
>> intel_crtc_state *new_crtc_state)
>>  
>> local_irq_disable();
>>  
>> -   if (min <= 0 || max <= 0)
>> +   if (WARN_ON(drm_crtc_vblank_get(>base)))
>> return;
>>  
>> -   if (WARN_ON(drm_crtc_vblank_get(>base)))
>> +   if (min <= 0 || max <= 0)
>> return;
>>  
> The corresponding vblank_put is the one later in update_start(), right?
> I don't think you intended to keep this chunk.
> -Chris
 I'm not sure what you mean? The vblank_put is now in pipe_update_end, 
 except if the
 event takes over the reference. I think the code is correct. :)
>>> Then it's unbalanced in the case of error still.
>>> -Chris
>> It already would have been for events, hence the WARN_ON there.
>> I don't think we can do anything about it, this shouldn't ever
>> happen in practice, could be a BUG_ON for all I care. :)
> I would much prefer that over intentionally bad code.
>
> But do we really need to enable the vblank irq here? If the event
> requires it, doesn't it already enable the vblank. Here, we only need it
> when sleeping, can we not determine we have enough time before the
> vblank without enabling the interrupt?
I'm not sure why we get a reference to the vblank counter here. Perhaps Ville 
does?

~Maarten
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/5] drm/i915: Call i915_pipe_update_start with uncore.lock held.

[Maarten Lankhorst]

Op 12-02-18 om 16:19 schreef Chris Wilson:
> Quoting Maarten Lankhorst (2018-02-09 09:54:02)
>> This requires being able to read the vblank counter with the
>> uncore.lock already held. This is also a preparation for
>> being able to run the entire vblank update sequence with
>> the uncore lock held.
>>
>> Signed-off-by: Maarten Lankhorst 
>> ---
>>  drivers/gpu/drm/i915/i915_irq.c | 66 
>> ++---
>>  drivers/gpu/drm/i915/i915_trace.h   |  5 ++-
>>  drivers/gpu/drm/i915/intel_drv.h|  1 +
>>  drivers/gpu/drm/i915/intel_sprite.c |  3 +-
>>  4 files changed, 60 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_irq.c 
>> b/drivers/gpu/drm/i915/i915_irq.c
>> index eda9543a0199..6c491e63e07c 100644
>> --- a/drivers/gpu/drm/i915/i915_irq.c
>> +++ b/drivers/gpu/drm/i915/i915_irq.c
>> @@ -736,13 +736,12 @@ static void i915_enable_asle_pipestat(struct 
>> drm_i915_private *dev_priv)
>>  /* Called from drm generic code, passed a 'crtc', which
>>   * we use as a pipe index
>>   */
>> -static u32 i915_get_vblank_counter(struct drm_device *dev, unsigned int 
>> pipe)
>> +static u32 __i915_get_vblank_counter(struct intel_crtc *crtc)
>>  {
>> -   struct drm_i915_private *dev_priv = to_i915(dev);
>> +   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>> i915_reg_t high_frame, low_frame;
>> u32 high1, high2, low, pixel, vbl_start, hsync_start, htotal;
>> -   const struct drm_display_mode *mode = >vblank[pipe].hwmode;
>> -   unsigned long irqflags;
>> +   const struct drm_display_mode *mode = 
>> >base.dev->vblank[crtc->pipe].hwmode;
> lockdep_assert_held(_priv->uncore.lock);
>
>>  
>> htotal = mode->crtc_htotal;
>> hsync_start = mode->crtc_hsync_start;
>> @@ -756,10 +755,8 @@ static u32 i915_get_vblank_counter(struct drm_device 
>> *dev, unsigned int pipe)
>> /* Start of vblank event occurs at start of hsync */
>> vbl_start -= htotal - hsync_start;
>>  
>> -   high_frame = PIPEFRAME(pipe);
>> -   low_frame = PIPEFRAMEPIXEL(pipe);
>> -
>> -   spin_lock_irqsave(_priv->uncore.lock, irqflags);
>> +   high_frame = PIPEFRAME(crtc->pipe);
>> +   low_frame = PIPEFRAMEPIXEL(crtc->pipe);
>>  
>> /*
>>  * High & low register fields aren't synchronized, so make sure
>> @@ -772,8 +769,6 @@ static u32 i915_get_vblank_counter(struct drm_device 
>> *dev, unsigned int pipe)
>> high2 = I915_READ_FW(high_frame) & PIPE_FRAME_HIGH_MASK;
>> } while (high1 != high2);
>>  
>> -   spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
>> -
>> high1 >>= PIPE_FRAME_HIGH_SHIFT;
>> pixel = low & PIPE_PIXEL_MASK;
>> low >>= PIPE_FRAME_LOW_SHIFT;
>> @@ -786,11 +781,60 @@ static u32 i915_get_vblank_counter(struct drm_device 
>> *dev, unsigned int pipe)
>> return (((high1 << 8) | low) + (pixel >= vbl_start)) & 0xff;
>>  }
>>  
>> +static u32 i915_get_vblank_counter(struct drm_device *dev, unsigned int 
>> pipe)
>> +{
>> +   struct drm_i915_private *dev_priv = to_i915(dev);
>> +   unsigned long irqflags;
>> +   u32 ret;
>> +
>> +   spin_lock_irqsave(_priv->uncore.lock, irqflags);
>> +   ret = i915_get_vblank_counter(dev, pipe);
>> +   spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
>> +
>> +   return ret;
>> +}
>> +
>> +static u32 __g4x_get_vblank_counter(struct intel_crtc *crtc)
>> +{
>> +   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> lockdep_assert_held(_priv->uncore.lock); ?
>
> Ok, why do we need uncore.lock held here at all? Serialisation of mmio
> access to the same cacheline is the age old reason, can we guarantee
> that doesn't happen anyway? (Probably not, but really most callers do
> not need the mmio w/a.)

Is the serialization only needed for writing?

The only thing that can race with nonblocking atomic commits are legacy
cursor updates, but those can only happen if the cursor plane are not part
of the previous atomic commit. Those are also protected by plane->mutex,
so in theory same cache lines on the same pipes probably can't race..

~Maarten

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Keep vblank irq enabled during vblank evasion.

[Chris Wilson]

Quoting Maarten Lankhorst (2018-02-12 15:27:34)
> Op 12-02-18 om 16:22 schreef Chris Wilson:
> > Quoting Maarten Lankhorst (2018-02-12 15:16:39)
> >> Op 12-02-18 om 16:10 schreef Chris Wilson:
> >>> Quoting Maarten Lankhorst (2018-02-09 09:54:00)
>  This is a nice preparation for grabbing the uncore lock during evasion.
>  Grabbing the spinlock with the lock held messes up the locking,
>  so it's easier to handover the reference to the eve
> 
>  Signed-off-by: Maarten Lankhorst 
>  ---
>   drivers/gpu/drm/i915/intel_sprite.c | 11 ---
>   1 file changed, 4 insertions(+), 7 deletions(-)
> 
>  diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
>  b/drivers/gpu/drm/i915/intel_sprite.c
>  index 3be22c0fcfb5..971a1ea0db45 100644
>  --- a/drivers/gpu/drm/i915/intel_sprite.c
>  +++ b/drivers/gpu/drm/i915/intel_sprite.c
>  @@ -109,10 +109,10 @@ void intel_pipe_update_start(const struct 
>  intel_crtc_state *new_crtc_state)
>   
>  local_irq_disable();
>   
>  -   if (min <= 0 || max <= 0)
>  +   if (WARN_ON(drm_crtc_vblank_get(>base)))
>  return;
>   
>  -   if (WARN_ON(drm_crtc_vblank_get(>base)))
>  +   if (min <= 0 || max <= 0)
>  return;
>   
> >>> The corresponding vblank_put is the one later in update_start(), right?
> >>> I don't think you intended to keep this chunk.
> >>> -Chris
> >> I'm not sure what you mean? The vblank_put is now in pipe_update_end, 
> >> except if the
> >> event takes over the reference. I think the code is correct. :)
> > Then it's unbalanced in the case of error still.
> > -Chris
> 
> It already would have been for events, hence the WARN_ON there.
> I don't think we can do anything about it, this shouldn't ever
> happen in practice, could be a BUG_ON for all I care. :)

I would much prefer that over intentionally bad code.

But do we really need to enable the vblank irq here? If the event
requires it, doesn't it already enable the vblank. Here, we only need it
when sleeping, can we not determine we have enough time before the
vblank without enabling the interrupt?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Keep vblank irq enabled during vblank evasion.

[Maarten Lankhorst]

Op 12-02-18 om 16:22 schreef Chris Wilson:
> Quoting Maarten Lankhorst (2018-02-12 15:16:39)
>> Op 12-02-18 om 16:10 schreef Chris Wilson:
>>> Quoting Maarten Lankhorst (2018-02-09 09:54:00)
 This is a nice preparation for grabbing the uncore lock during evasion.
 Grabbing the spinlock with the lock held messes up the locking,
 so it's easier to handover the reference to the eve

 Signed-off-by: Maarten Lankhorst 
 ---
  drivers/gpu/drm/i915/intel_sprite.c | 11 ---
  1 file changed, 4 insertions(+), 7 deletions(-)

 diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
 b/drivers/gpu/drm/i915/intel_sprite.c
 index 3be22c0fcfb5..971a1ea0db45 100644
 --- a/drivers/gpu/drm/i915/intel_sprite.c
 +++ b/drivers/gpu/drm/i915/intel_sprite.c
 @@ -109,10 +109,10 @@ void intel_pipe_update_start(const struct 
 intel_crtc_state *new_crtc_state)
  
 local_irq_disable();
  
 -   if (min <= 0 || max <= 0)
 +   if (WARN_ON(drm_crtc_vblank_get(>base)))
 return;
  
 -   if (WARN_ON(drm_crtc_vblank_get(>base)))
 +   if (min <= 0 || max <= 0)
 return;
  
>>> The corresponding vblank_put is the one later in update_start(), right?
>>> I don't think you intended to keep this chunk.
>>> -Chris
>> I'm not sure what you mean? The vblank_put is now in pipe_update_end, except 
>> if the
>> event takes over the reference. I think the code is correct. :)
> Then it's unbalanced in the case of error still.
> -Chris

It already would have been for events, hence the WARN_ON there.
I don't think we can do anything about it, this shouldn't ever
happen in practice, could be a BUG_ON for all I care. :)

~Maarten

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Keep vblank irq enabled during vblank evasion.

[Chris Wilson]

Quoting Maarten Lankhorst (2018-02-12 15:16:39)
> Op 12-02-18 om 16:10 schreef Chris Wilson:
> > Quoting Maarten Lankhorst (2018-02-09 09:54:00)
> >> This is a nice preparation for grabbing the uncore lock during evasion.
> >> Grabbing the spinlock with the lock held messes up the locking,
> >> so it's easier to handover the reference to the eve
> >>
> >> Signed-off-by: Maarten Lankhorst 
> >> ---
> >>  drivers/gpu/drm/i915/intel_sprite.c | 11 ---
> >>  1 file changed, 4 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
> >> b/drivers/gpu/drm/i915/intel_sprite.c
> >> index 3be22c0fcfb5..971a1ea0db45 100644
> >> --- a/drivers/gpu/drm/i915/intel_sprite.c
> >> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> >> @@ -109,10 +109,10 @@ void intel_pipe_update_start(const struct 
> >> intel_crtc_state *new_crtc_state)
> >>  
> >> local_irq_disable();
> >>  
> >> -   if (min <= 0 || max <= 0)
> >> +   if (WARN_ON(drm_crtc_vblank_get(>base)))
> >> return;
> >>  
> >> -   if (WARN_ON(drm_crtc_vblank_get(>base)))
> >> +   if (min <= 0 || max <= 0)
> >> return;
> >>  
> > The corresponding vblank_put is the one later in update_start(), right?
> > I don't think you intended to keep this chunk.
> > -Chris
> 
> I'm not sure what you mean? The vblank_put is now in pipe_update_end, except 
> if the
> event takes over the reference. I think the code is correct. :)

Then it's unbalanced in the case of error still.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/5] drm/i915: Call i915_pipe_update_start with uncore.lock held.

[Chris Wilson]

Quoting Maarten Lankhorst (2018-02-09 09:54:02)
> This requires being able to read the vblank counter with the
> uncore.lock already held. This is also a preparation for
> being able to run the entire vblank update sequence with
> the uncore lock held.
> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/i915_irq.c | 66 
> ++---
>  drivers/gpu/drm/i915/i915_trace.h   |  5 ++-
>  drivers/gpu/drm/i915/intel_drv.h|  1 +
>  drivers/gpu/drm/i915/intel_sprite.c |  3 +-
>  4 files changed, 60 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index eda9543a0199..6c491e63e07c 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -736,13 +736,12 @@ static void i915_enable_asle_pipestat(struct 
> drm_i915_private *dev_priv)
>  /* Called from drm generic code, passed a 'crtc', which
>   * we use as a pipe index
>   */
> -static u32 i915_get_vblank_counter(struct drm_device *dev, unsigned int pipe)
> +static u32 __i915_get_vblank_counter(struct intel_crtc *crtc)
>  {
> -   struct drm_i915_private *dev_priv = to_i915(dev);
> +   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> i915_reg_t high_frame, low_frame;
> u32 high1, high2, low, pixel, vbl_start, hsync_start, htotal;
> -   const struct drm_display_mode *mode = >vblank[pipe].hwmode;
> -   unsigned long irqflags;
> +   const struct drm_display_mode *mode = 
> >base.dev->vblank[crtc->pipe].hwmode;

lockdep_assert_held(_priv->uncore.lock);

>  
> htotal = mode->crtc_htotal;
> hsync_start = mode->crtc_hsync_start;
> @@ -756,10 +755,8 @@ static u32 i915_get_vblank_counter(struct drm_device 
> *dev, unsigned int pipe)
> /* Start of vblank event occurs at start of hsync */
> vbl_start -= htotal - hsync_start;
>  
> -   high_frame = PIPEFRAME(pipe);
> -   low_frame = PIPEFRAMEPIXEL(pipe);
> -
> -   spin_lock_irqsave(_priv->uncore.lock, irqflags);
> +   high_frame = PIPEFRAME(crtc->pipe);
> +   low_frame = PIPEFRAMEPIXEL(crtc->pipe);
>  
> /*
>  * High & low register fields aren't synchronized, so make sure
> @@ -772,8 +769,6 @@ static u32 i915_get_vblank_counter(struct drm_device 
> *dev, unsigned int pipe)
> high2 = I915_READ_FW(high_frame) & PIPE_FRAME_HIGH_MASK;
> } while (high1 != high2);
>  
> -   spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
> -
> high1 >>= PIPE_FRAME_HIGH_SHIFT;
> pixel = low & PIPE_PIXEL_MASK;
> low >>= PIPE_FRAME_LOW_SHIFT;
> @@ -786,11 +781,60 @@ static u32 i915_get_vblank_counter(struct drm_device 
> *dev, unsigned int pipe)
> return (((high1 << 8) | low) + (pixel >= vbl_start)) & 0xff;
>  }
>  
> +static u32 i915_get_vblank_counter(struct drm_device *dev, unsigned int pipe)
> +{
> +   struct drm_i915_private *dev_priv = to_i915(dev);
> +   unsigned long irqflags;
> +   u32 ret;
> +
> +   spin_lock_irqsave(_priv->uncore.lock, irqflags);
> +   ret = i915_get_vblank_counter(dev, pipe);
> +   spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
> +
> +   return ret;
> +}
> +
> +static u32 __g4x_get_vblank_counter(struct intel_crtc *crtc)
> +{
> +   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);

lockdep_assert_held(_priv->uncore.lock); ?

Ok, why do we need uncore.lock held here at all? Serialisation of mmio
access to the same cacheline is the age old reason, can we guarantee
that doesn't happen anyway? (Probably not, but really most callers do
not need the mmio w/a.)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Replace open-coded memset_p()

[Patchwork]

== Series Details ==

Series: drm/i915: Replace open-coded memset_p()
URL   : https://patchwork.freedesktop.org/series/38082/
State : success

== Summary ==

Series 38082v1 drm/i915: Replace open-coded memset_p()
https://patchwork.freedesktop.org/api/1.0/series/38082/revisions/1/mbox/

Test kms_chamelium:
Subgroup dp-edid-read:
pass   -> FAIL   (fi-kbl-7500u) fdo#102505
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
incomplete -> PASS   (fi-skl-6260u)
Test prime_vgem:
Subgroup basic-fence-flip:
fail   -> PASS   (fi-ilk-650)

fdo#102505 https://bugs.freedesktop.org/show_bug.cgi?id=102505

fi-bdw-5557u total:288  pass:265  dwarn:0   dfail:0   fail:2   skip:21  
time:444s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:423s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:381s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:487s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:290s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:480s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:480s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:469s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:457s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:572s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:573s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:417s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:284s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:510s
fi-hsw-4770  total:288  pass:259  dwarn:0   dfail:0   fail:2   skip:27  
time:417s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:411s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:456s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:414s
fi-kbl-7500u total:288  pass:262  dwarn:1   dfail:0   fail:1   skip:24  
time:454s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:497s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:501s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:590s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:425s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:511s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:528s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:484s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:485s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:415s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:429s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:515s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:396s
Blacklisted hosts:
fi-glk-dsi   total:117  pass:104  dwarn:0   dfail:0   fail:0   skip:12 

817d13e99013266e1dc5e7fc056faa960e9a53dc drm-tip: 2018y-02m-12d-13h-34m-48s UTC 
integration manifest
69cf51ac5a10 drm/i915: Replace open-coded memset_p()

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7980/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Keep vblank irq enabled during vblank evasion.

[Maarten Lankhorst]

Op 12-02-18 om 16:10 schreef Chris Wilson:
> Quoting Maarten Lankhorst (2018-02-09 09:54:00)
>> This is a nice preparation for grabbing the uncore lock during evasion.
>> Grabbing the spinlock with the lock held messes up the locking,
>> so it's easier to handover the reference to the eve
>>
>> Signed-off-by: Maarten Lankhorst 
>> ---
>>  drivers/gpu/drm/i915/intel_sprite.c | 11 ---
>>  1 file changed, 4 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
>> b/drivers/gpu/drm/i915/intel_sprite.c
>> index 3be22c0fcfb5..971a1ea0db45 100644
>> --- a/drivers/gpu/drm/i915/intel_sprite.c
>> +++ b/drivers/gpu/drm/i915/intel_sprite.c
>> @@ -109,10 +109,10 @@ void intel_pipe_update_start(const struct 
>> intel_crtc_state *new_crtc_state)
>>  
>> local_irq_disable();
>>  
>> -   if (min <= 0 || max <= 0)
>> +   if (WARN_ON(drm_crtc_vblank_get(>base)))
>> return;
>>  
>> -   if (WARN_ON(drm_crtc_vblank_get(>base)))
>> +   if (min <= 0 || max <= 0)
>> return;
>>  
> The corresponding vblank_put is the one later in update_start(), right?
> I don't think you intended to keep this chunk.
> -Chris

I'm not sure what you mean? The vblank_put is now in pipe_update_end, except if 
the
event takes over the reference. I think the code is correct. :)

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/5] drm/i915: Grab uncore.lock around enabling vblank evasion

[Chris Wilson]

Quoting Maarten Lankhorst (2018-02-09 09:54:01)
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/i915_irq.c |  2 +-
>  drivers/gpu/drm/i915/intel_drv.h|  1 +
>  drivers/gpu/drm/i915/intel_sprite.c | 10 ++
>  3 files changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index b886bd459acc..eda9543a0199 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -845,7 +845,7 @@ static u32 
> __intel_get_crtc_scanline_from_timestamp(struct intel_crtc *crtc)
>  }
>  
>  /* I915_READ_FW, only for fast reads of display block, no need for forcewake 
> etc. */
> -static int __intel_get_crtc_scanline(struct intel_crtc *crtc)
> +int __intel_get_crtc_scanline(struct intel_crtc *crtc)
>  {
> struct drm_device *dev = crtc->base.dev;
> struct drm_i915_private *dev_priv = to_i915(dev);
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 468ec1e90e16..fbdbbe741b2f 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1340,6 +1340,7 @@ static inline bool intel_irqs_enabled(struct 
> drm_i915_private *dev_priv)
>  }
>  
>  int intel_get_crtc_scanline(struct intel_crtc *crtc);
> +int __intel_get_crtc_scanline(struct intel_crtc *crtc);
>  void gen8_irq_power_well_post_enable(struct drm_i915_private *dev_priv,
>  u8 pipe_mask);
>  void gen8_irq_power_well_pre_disable(struct drm_i915_private *dev_priv,
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
> b/drivers/gpu/drm/i915/intel_sprite.c
> index 971a1ea0db45..3a34be4fd956 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -119,6 +119,7 @@ void intel_pipe_update_start(const struct 
> intel_crtc_state *new_crtc_state)
> crtc->debug.max_vbl = max;
> trace_i915_pipe_update_start(crtc);
>  
> +   spin_lock(_priv->uncore.lock);
> for (;;) {
> /*
>  * prepare_to_wait() has a memory barrier, which guarantees
> @@ -127,7 +128,7 @@ void intel_pipe_update_start(const struct 
> intel_crtc_state *new_crtc_state)
>  */
> prepare_to_wait(wq, , TASK_UNINTERRUPTIBLE);
>  
> -   scanline = intel_get_crtc_scanline(crtc);
> +   scanline = __intel_get_crtc_scanline(crtc);
> if (scanline < min || scanline > max)
> break;
>  
> @@ -137,11 +138,11 @@ void intel_pipe_update_start(const struct 
> intel_crtc_state *new_crtc_state)
> break;
> }
>  
> -   local_irq_enable();
> +   spin_unlock_irq(_priv->uncore.lock);
>  
> timeout = schedule_timeout(timeout);
>  
> -   local_irq_disable();
> +   spin_lock_irq(_priv->uncore.lock);
> }
>  
> finish_wait(wq, );

There's no danger that drm_crtc_vblank_put() does something crazy here.
(Feels like a layering violation to call into DRM with the low level
uncore.lock held at least.) It looks like the driver can be tricked into
called ->disable_vblank()?

Overall though, I think it is just this need_vlv_dsi_wa chunk that has
any benefit here (although trading lock_irq for lock_irqsave is enough
to justify a change if frequently hit).
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Keep vblank irq enabled during vblank evasion.

[Chris Wilson]

Quoting Maarten Lankhorst (2018-02-09 09:54:00)
> This is a nice preparation for grabbing the uncore lock during evasion.
> Grabbing the spinlock with the lock held messes up the locking,
> so it's easier to handover the reference to the event.
> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_sprite.c | 11 ---
>  1 file changed, 4 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
> b/drivers/gpu/drm/i915/intel_sprite.c
> index 3be22c0fcfb5..971a1ea0db45 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -109,10 +109,10 @@ void intel_pipe_update_start(const struct 
> intel_crtc_state *new_crtc_state)
>  
> local_irq_disable();
>  
> -   if (min <= 0 || max <= 0)
> +   if (WARN_ON(drm_crtc_vblank_get(>base)))
> return;
>  
> -   if (WARN_ON(drm_crtc_vblank_get(>base)))
> +   if (min <= 0 || max <= 0)
> return;
>  

The corresponding vblank_put is the one later in update_start(), right?
I don't think you intended to keep this chunk.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Grab the vblank evasion lock around the entire evasion.

[Patchwork]

== Series Details ==

Series: drm/i915: Grab the vblank evasion lock around the entire evasion.
URL   : https://patchwork.freedesktop.org/series/37986/
State : success

== Summary ==

Series 37986v1 drm/i915: Grab the vblank evasion lock around the entire evasion.
https://patchwork.freedesktop.org/api/1.0/series/37986/revisions/1/mbox/

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
incomplete -> PASS   (fi-skl-6260u)
Test prime_vgem:
Subgroup basic-fence-flip:
fail   -> PASS   (fi-ilk-650)

fi-bdw-5557u total:288  pass:265  dwarn:0   dfail:0   fail:2   skip:21  
time:446s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:422s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:504s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:482s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:490s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:473s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:465s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:568s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:574s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:417s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:512s
fi-hsw-4770  total:288  pass:259  dwarn:0   dfail:0   fail:2   skip:27  
time:414s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:413s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:453s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:419s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:460s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:496s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:501s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:430s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:510s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:527s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:487s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:486s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:415s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:430s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:520s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:399s
Blacklisted hosts:
fi-glk-dsi   total:117  pass:105  dwarn:0   dfail:0   fail:0   skip:12 

817d13e99013266e1dc5e7fc056faa960e9a53dc drm-tip: 2018y-02m-12d-13h-34m-48s UTC 
integration manifest
c178e786a11c drm/i915: Use DOUBLE_BUFFER_CTL on top of vblank evasion for GEN9+.
a5c32a2c2484 drm/i915: Move all locking for plane updates to caller
dc25ed08f485 drm/i915: Call i915_pipe_update_start with uncore.lock held.
01ef705a11de drm/i915: Grab uncore.lock around enabling vblank evasion
7b997261ce22 drm/i915: Keep vblank irq enabled during vblank evasion.

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7979/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm: Use idr_init_base(1) when using id==0 for invalid

[Chris Wilson]

Use the new idr_init_base() function to create an IDR that knows id==0
is never allocated as it maps to an invalid identifier. By knowing that
id==0 is invalid, the IDR can start from id=1 instead avoiding the issue
of having to start each lookup from the zeroth leaf as id==0 is always
unused (and thus the tree-of-bitmaps indicate that is the first
available).

References: 6ce711f27500 ("idr: Make 1-based IDRs more efficient")
Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Christian Konig 
Cc: Dave Airlie 
---
Note this requires 4.16-rc1.
---
 drivers/gpu/drm/drm_gem.c | 4 ++--
 drivers/gpu/drm/drm_syncobj.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 01f8d9481211..4975ba9a7bc8 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -98,7 +98,7 @@ drm_gem_init(struct drm_device *dev)
struct drm_vma_offset_manager *vma_offset_manager;
 
mutex_init(>object_name_lock);
-   idr_init(>object_name_idr);
+   idr_init_base(>object_name_idr, 1);
 
vma_offset_manager = kzalloc(sizeof(*vma_offset_manager), GFP_KERNEL);
if (!vma_offset_manager) {
@@ -776,7 +776,7 @@ drm_gem_open_ioctl(struct drm_device *dev, void *data,
 void
 drm_gem_open(struct drm_device *dev, struct drm_file *file_private)
 {
-   idr_init(_private->object_idr);
+   idr_init_base(_private->object_idr, 1);
spin_lock_init(_private->table_lock);
 }
 
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 0b7b0d1ad2d5..d4f4ce484529 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -546,7 +546,7 @@ static int drm_syncobj_export_sync_file(struct drm_file 
*file_private,
 void
 drm_syncobj_open(struct drm_file *file_private)
 {
-   idr_init(_private->syncobj_idr);
+   idr_init_base(_private->syncobj_idr, 1);
spin_lock_init(_private->syncobj_table_lock);
 }
 
-- 
2.16.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 1/2] lib/igt_kms.c: modify kmstest_dump_mode to print aspect ratio of a mode

[Mika Kahola]

On Wed, 2018-01-24 at 18:20 +0530, Nautiyal, Ankit K wrote:
> From: Ankit Nautiyal 
> 
> This patch adds the support to print the aspect ratio of the modes
> (if provided) along with other mode information.
> 
> Signed-off-by: Ankit Nautiyal 
> ---
>  lib/igt_kms.c | 31 +--
>  1 file changed, 29 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/igt_kms.c b/lib/igt_kms.c
> index eb57f4a..585f94d 100644
> --- a/lib/igt_kms.c
> +++ b/lib/igt_kms.c
> @@ -56,6 +56,14 @@
>  #include "igt_sysfs.h"
>  #include "sw_sync.h"
>  
> +#ifndef DRM_MODE_FLAG_PIC_AR_64_27
> +#define DRM_MODE_FLAG_PIC_AR_64_27 (3<<19)
> +#endif
> +
> +#ifndef DRM_MODE_FLAG_PIC_AR_256_135
> +#define DRM_MODE_FLAG_PIC_AR_256_135 (4<<19)
> +#endif
> +
Shouldn't these be defined in /include/uapi/drm/drm_mode.h? Although, I
wasn't able to find these definitions from that file. Do we have a
patch under review in drm to fill this gap?

Otherwise, the patch looks good.

Acked-by: Mika Kahola 

>  /**
>   * SECTION:igt_kms
>   * @short_description: Kernel modesetting support library
> @@ -491,6 +499,22 @@ static const char *mode_stereo_name(const
> drmModeModeInfo *mode)
>   }
>  }
>  
> +static const char *mode_aspect_name(const drmModeModeInfo *mode)
> +{
> + switch (mode->flags & DRM_MODE_FLAG_PIC_AR_MASK) {
> + case DRM_MODE_FLAG_PIC_AR_4_3:
> + return "4:3";
> + case DRM_MODE_FLAG_PIC_AR_16_9:
> + return "16:9";
> + case DRM_MODE_FLAG_PIC_AR_64_27:
> + return "64:27";
> + case DRM_MODE_FLAG_PIC_AR_256_135:
> + return "256:135";
> + default:
> + return NULL;
> + }
> +}
> +
>  /**
>   * kmstest_dump_mode:
>   * @mode: libdrm mode structure
> @@ -500,8 +524,9 @@ static const char *mode_stereo_name(const
> drmModeModeInfo *mode)
>  void kmstest_dump_mode(drmModeModeInfo *mode)
>  {
>   const char *stereo = mode_stereo_name(mode);
> + const char *aspect_ratio = mode_aspect_name(mode);
>  
> - igt_info("  %s %d %d %d %d %d %d %d %d %d 0x%x 0x%x
> %d%s%s%s\n",
> + igt_info("  %s %d %d %d %d %d %d %d %d %d 0x%x 0x%x %d%s%s%s
> %s%s%s\n",
>    mode->name, mode->vrefresh,
>    mode->hdisplay, mode->hsync_start,
>    mode->hsync_end, mode->htotal,
> @@ -509,7 +534,9 @@ void kmstest_dump_mode(drmModeModeInfo *mode)
>    mode->vsync_end, mode->vtotal,
>    mode->flags, mode->type, mode->clock,
>    stereo ? " (3D:" : "",
> -  stereo ? stereo : "", stereo ? ")" : "");
> +  stereo ? stereo : "", stereo ? ")" : "",
> +  aspect_ratio ? " (Pixel Aspect Ratio:" : "",
> +  aspect_ratio ? aspect_ratio : "", aspect_ratio ?
> ")" : "");
>  }
>  
>  /**
-- 
Mika Kahola - Intel OTC

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Replace open-coded memset_p()

[Mika Kuoppala]

Chris Wilson  writes:

> When initialising the page directories, we set the GTT entries and the
> tree to the scratch page. We have already replaced the DMA fill with
> memset64(), but we can similarly use memset_p() to set the pointer array.
>
> References: 4dd504f7d98a ("drm/i915: Use memset64() to prefill the GTT page")
> Signed-off-by: Chris Wilson 
> Cc: Tvrtko Ursulin 
> Cc: Matthew Auld 
> Cc: Mika Kuoppala 

Reviewed-by: Mika Kuoppala 

> ---
>  drivers/gpu/drm/i915/i915_gem_gtt.c | 14 +++---
>  1 file changed, 3 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 0c0f1affddad..a44eccda7d48 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -673,27 +673,22 @@ static void free_pd(struct i915_address_space *vm,
>  static void gen8_initialize_pd(struct i915_address_space *vm,
>  struct i915_page_directory *pd)
>  {
> - unsigned int i;
> -
>   fill_px(vm, pd,
>   gen8_pde_encode(px_dma(vm->scratch_pt), I915_CACHE_LLC));
> - for (i = 0; i < I915_PDES; i++)
> - pd->page_table[i] = vm->scratch_pt;
> + memset_p((void **)pd->page_table, vm->scratch_pt, I915_PDES);
>  }
>  
>  static int __pdp_init(struct i915_address_space *vm,
> struct i915_page_directory_pointer *pdp)
>  {
>   const unsigned int pdpes = i915_pdpes_per_pdp(vm);
> - unsigned int i;
>  
>   pdp->page_directory = kmalloc_array(pdpes, sizeof(*pdp->page_directory),
>   GFP_KERNEL | __GFP_NOWARN);
>   if (unlikely(!pdp->page_directory))
>   return -ENOMEM;
>  
> - for (i = 0; i < pdpes; i++)
> - pdp->page_directory[i] = vm->scratch_pd;
> + memset_p((void **)pdp->page_directory, vm->scratch_pd, pdpes);
>  
>   return 0;
>  }
> @@ -764,12 +759,9 @@ static void gen8_initialize_pdp(struct 
> i915_address_space *vm,
>  static void gen8_initialize_pml4(struct i915_address_space *vm,
>struct i915_pml4 *pml4)
>  {
> - unsigned int i;
> -
>   fill_px(vm, pml4,
>   gen8_pml4e_encode(px_dma(vm->scratch_pdp), I915_CACHE_LLC));
> - for (i = 0; i < GEN8_PML4ES_PER_PML4; i++)
> - pml4->pdps[i] = vm->scratch_pdp;
> + memset_p((void **)pml4->pdps, vm->scratch_pdp, GEN8_PML4ES_PER_PML4);
>  }
>  
>  /* Broadwell Page Directory Pointer Descriptors */
> -- 
> 2.16.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Replace open-coded memset_p()

[Matthew Auld]

On 12 February 2018 at 13:31, Chris Wilson  wrote:
> When initialising the page directories, we set the GTT entries and the
> tree to the scratch page. We have already replaced the DMA fill with
> memset64(), but we can similarly use memset_p() to set the pointer array.
>
> References: 4dd504f7d98a ("drm/i915: Use memset64() to prefill the GTT page")
> Signed-off-by: Chris Wilson 
> Cc: Tvrtko Ursulin 
> Cc: Matthew Auld 
> Cc: Mika Kuoppala 
Reviewed-by: Matthew Auld 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Hold rpm wakeref for printing the engine's register state

[Chris Wilson]

Quoting Mika Kuoppala (2018-02-12 13:28:54)
> Chris Wilson  writes:
> 
> > When dumping the engine, we print out the current register values. This
> > requires the rpm wakeref. If the device is alseep, we can assume the
> > engine is asleep (and the register state is uninteresting) so skip and
> > only acquire the rpm wakeref if the device is already awake.
> >
> > Reported-by: Tvrtko Ursulin 
> > Signed-off-by: Chris Wilson 
> > Cc: Tvrtko Ursulin 
> > Cc: Mika Kuoppala 
> > ---
> > + if (intel_runtime_pm_get_if_in_use(engine->i915)) {
> > + intel_engine_print_registers(engine, m);
> > + intel_runtime_pm_put(engine->i915);
> > + } else {
> > + drm_printf(m, "Device is alseep; skipping register dump\n");
> > + }
> 
> s/alseep/asleep
> 
> Reviewed-by: Mika Kuoppala 

Done, and both pushed. Now to try Tvrtko's warning patch on the new
baseline. Thanks,
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Replace open-coded memset_p()

[Chris Wilson]

When initialising the page directories, we set the GTT entries and the
tree to the scratch page. We have already replaced the DMA fill with
memset64(), but we can similarly use memset_p() to set the pointer array.

References: 4dd504f7d98a ("drm/i915: Use memset64() to prefill the GTT page")
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Matthew Auld 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 0c0f1affddad..a44eccda7d48 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -673,27 +673,22 @@ static void free_pd(struct i915_address_space *vm,
 static void gen8_initialize_pd(struct i915_address_space *vm,
   struct i915_page_directory *pd)
 {
-   unsigned int i;
-
fill_px(vm, pd,
gen8_pde_encode(px_dma(vm->scratch_pt), I915_CACHE_LLC));
-   for (i = 0; i < I915_PDES; i++)
-   pd->page_table[i] = vm->scratch_pt;
+   memset_p((void **)pd->page_table, vm->scratch_pt, I915_PDES);
 }
 
 static int __pdp_init(struct i915_address_space *vm,
  struct i915_page_directory_pointer *pdp)
 {
const unsigned int pdpes = i915_pdpes_per_pdp(vm);
-   unsigned int i;
 
pdp->page_directory = kmalloc_array(pdpes, sizeof(*pdp->page_directory),
GFP_KERNEL | __GFP_NOWARN);
if (unlikely(!pdp->page_directory))
return -ENOMEM;
 
-   for (i = 0; i < pdpes; i++)
-   pdp->page_directory[i] = vm->scratch_pd;
+   memset_p((void **)pdp->page_directory, vm->scratch_pd, pdpes);
 
return 0;
 }
@@ -764,12 +759,9 @@ static void gen8_initialize_pdp(struct i915_address_space 
*vm,
 static void gen8_initialize_pml4(struct i915_address_space *vm,
 struct i915_pml4 *pml4)
 {
-   unsigned int i;
-
fill_px(vm, pml4,
gen8_pml4e_encode(px_dma(vm->scratch_pdp), I915_CACHE_LLC));
-   for (i = 0; i < GEN8_PML4ES_PER_PML4; i++)
-   pml4->pdps[i] = vm->scratch_pdp;
+   memset_p((void **)pml4->pdps, vm->scratch_pdp, GEN8_PML4ES_PER_PML4);
 }
 
 /* Broadwell Page Directory Pointer Descriptors */
-- 
2.16.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Hold rpm wakeref for printing the engine's register state

[Mika Kuoppala]

Chris Wilson  writes:

> When dumping the engine, we print out the current register values. This
> requires the rpm wakeref. If the device is alseep, we can assume the
> engine is asleep (and the register state is uninteresting) so skip and
> only acquire the rpm wakeref if the device is already awake.
>
> Reported-by: Tvrtko Ursulin 
> Signed-off-by: Chris Wilson 
> Cc: Tvrtko Ursulin 
> Cc: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/intel_engine_cs.c  | 162 
> ++--
>  drivers/gpu/drm/i915/intel_ringbuffer.h |   6 +-
>  2 files changed, 94 insertions(+), 74 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index 3efc589a7f37..2df9a2d038ee 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -691,7 +691,7 @@ void intel_engine_cleanup_common(struct intel_engine_cs 
> *engine)
>   engine->context_unpin(engine, engine->i915->kernel_context);
>  }
>  
> -u64 intel_engine_get_active_head(struct intel_engine_cs *engine)
> +u64 intel_engine_get_active_head(const struct intel_engine_cs *engine)
>  {
>   struct drm_i915_private *dev_priv = engine->i915;
>   u64 acthd;
> @@ -707,7 +707,7 @@ u64 intel_engine_get_active_head(struct intel_engine_cs 
> *engine)
>   return acthd;
>  }
>  
> -u64 intel_engine_get_last_batch_head(struct intel_engine_cs *engine)
> +u64 intel_engine_get_last_batch_head(const struct intel_engine_cs *engine)
>  {
>   struct drm_i915_private *dev_priv = engine->i915;
>   u64 bbaddr;
> @@ -1705,73 +1705,20 @@ static void hexdump(struct drm_printer *m, const void 
> *buf, size_t len)
>   }
>  }
>  
> -void intel_engine_dump(struct intel_engine_cs *engine,
> -struct drm_printer *m,
> -const char *header, ...)
> +static void intel_engine_print_registers(const struct intel_engine_cs 
> *engine,
> +  struct drm_printer *m)
>  {
> - struct intel_breadcrumbs * const b = >breadcrumbs;
> - const struct intel_engine_execlists * const execlists = 
> >execlists;
> - struct i915_gpu_error * const error = >i915->gpu_error;
>   struct drm_i915_private *dev_priv = engine->i915;
> - struct drm_i915_gem_request *rq;
> - struct rb_node *rb;
> - char hdr[80];
> + const struct intel_engine_execlists * const execlists =
> + >execlists;
>   u64 addr;
>  
> - if (header) {
> - va_list ap;
> -
> - va_start(ap, header);
> - drm_vprintf(m, header, );
> - va_end(ap);
> - }
> -
> - if (i915_terminally_wedged(>i915->gpu_error))
> - drm_printf(m, "*** WEDGED ***\n");
> -
> - drm_printf(m, "\tcurrent seqno %x, last %x, hangcheck %x [%d ms], 
> inflight %d\n",
> -intel_engine_get_seqno(engine),
> -intel_engine_last_submit(engine),
> -engine->hangcheck.seqno,
> -jiffies_to_msecs(jiffies - 
> engine->hangcheck.action_timestamp),
> -engine->timeline->inflight_seqnos);
> - drm_printf(m, "\tReset count: %d (global %d)\n",
> -i915_reset_engine_count(error, engine),
> -i915_reset_count(error));
> -
> - rcu_read_lock();
> -
> - drm_printf(m, "\tRequests:\n");
> -
> - rq = list_first_entry(>timeline->requests,
> -   struct drm_i915_gem_request, link);
> - if (>link != >timeline->requests)
> - print_request(m, rq, "\t\tfirst  ");
> -
> - rq = list_last_entry(>timeline->requests,
> -  struct drm_i915_gem_request, link);
> - if (>link != >timeline->requests)
> - print_request(m, rq, "\t\tlast   ");
> -
> - rq = i915_gem_find_active_request(engine);
> - if (rq) {
> - print_request(m, rq, "\t\tactive ");
> - drm_printf(m,
> -"\t\t[head %04x, postfix %04x, tail %04x, batch 
> 0x%08x_%08x]\n",
> -rq->head, rq->postfix, rq->tail,
> -rq->batch ? upper_32_bits(rq->batch->node.start) : 
> ~0u,
> -rq->batch ? lower_32_bits(rq->batch->node.start) : 
> ~0u);
> - }
> -
> - drm_printf(m, "\tRING_START: 0x%08x [0x%08x]\n",
> -I915_READ(RING_START(engine->mmio_base)),
> -rq ? i915_ggtt_offset(rq->ring->vma) : 0);
> - drm_printf(m, "\tRING_HEAD:  0x%08x [0x%08x]\n",
> -I915_READ(RING_HEAD(engine->mmio_base)) & HEAD_ADDR,
> -rq ? rq->ring->head : 0);
> - drm_printf(m, "\tRING_TAIL:  0x%08x [0x%08x]\n",
> -I915_READ(RING_TAIL(engine->mmio_base)) & TAIL_ADDR,
> -rq ? rq->ring->tail : 0);
> + drm_printf(m, 

Re: [Intel-gfx] [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Imre Deak]

On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
> [...]
> i915, malidp and msm "solved" this issue by not stopping the poll worker
> on runtime suspend.  But this results in the GPU bouncing back and forth
> between D0 and D3 continuously.  That's a total no-go for GPUs which
> runtime suspend to D3cold since every suspend/resume cycle costs a
> significant amount of time and energy.  (i915 and malidp do not seem
> to acquire a runtime PM ref in the ->detect callbacks, which seems
> questionable.  msm however does and would also deadlock if it disabled
> the poll worker on runtime suspend.  cc += Archit, Liviu, intel-gfx)

In i915 polling is on during runtime suspend only if there are outputs
without hotplug interrupt support. A special case is when an output has
working HPD interrupts when in D0, but no interrupts when runtime
suspended. For these we start polling (from a scheduled work) in the
runtime suspend hook and stop it in the runtime resume hook (again from
a scheduled work).

Imo whether to leave polling on or not for the above purpose is a policy
question (configurable with the drm_kms_helper.poll param).

--Imre

> 
> Please review.  Thanks,
> 
> Lukas
> 
> Lukas Wunner (5):
>   workqueue: Allow retrieval of current task's work struct
>   drm: Allow determining if current task is output poll worker
>   drm/nouveau: Fix deadlock on runtime suspend
>   drm/radeon: Fix deadlock on runtime suspend
>   drm/amdgpu: Fix deadlock on runtime suspend
> 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 58 +---
>  drivers/gpu/drm/drm_probe_helper.c | 14 +
>  drivers/gpu/drm/nouveau/nouveau_connector.c| 18 +--
>  drivers/gpu/drm/radeon/radeon_connectors.c | 74 
> +-
>  include/drm/drm_crtc_helper.h  |  1 +
>  include/linux/workqueue.h  |  1 +
>  kernel/workqueue.c | 16 ++
>  7 files changed, 132 insertions(+), 50 deletions(-)
> 
> -- 
> 2.15.1
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Hold rpm wakeref for printing the engine's register state

[Patchwork]

== Series Details ==

Series: drm/i915: Hold rpm wakeref for printing the engine's register state
URL   : https://patchwork.freedesktop.org/series/38077/
State : success

== Summary ==

Test perf:
Subgroup oa-exponents:
pass   -> FAIL   (shard-apl) fdo#102254
Test gem_softpin:
Subgroup noreloc-s3:
dmesg-warn -> PASS   (shard-snb) fdo#103375 +1
Test perf_pmu:
Subgroup rc6:
skip   -> PASS   (shard-hsw)
Test kms_cursor_legacy:
Subgroup cursor-vs-flip-atomic-transitions:
fail   -> PASS   (shard-apl) fdo#103355
Subgroup flip-vs-cursor-atomic:
fail   -> PASS   (shard-hsw) fdo#102670
Test kms_frontbuffer_tracking:
Subgroup fbc-rgb565-draw-blt:
fail   -> PASS   (shard-apl) fdo#101623
Test pm_rps:
Subgroup min-max-config-loaded:
fail   -> PASS   (shard-apl) fdo#104060

fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#103355 https://bugs.freedesktop.org/show_bug.cgi?id=103355
fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#104060 https://bugs.freedesktop.org/show_bug.cgi?id=104060

shard-apltotal:3420 pass:1774 dwarn:1   dfail:0   fail:21  skip:1623 
time:12470s
shard-hswtotal:3444 pass:1760 dwarn:1   dfail:0   fail:11  skip:1671 
time:11876s
shard-snbtotal:3444 pass:1351 dwarn:1   dfail:0   fail:9   skip:2083 
time:6638s
Blacklisted hosts:
shard-kbltotal:3444 pass:1913 dwarn:1   dfail:0   fail:21  skip:1509 
time:9640s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7978/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Don't query PCODE RC6VIDS on platforms not supporting it

[Imre Deak]

On Mon, Feb 12, 2018 at 12:33:57PM +0200, Jani Nikula wrote:
> On Thu, 08 Feb 2018, Imre Deak  wrote:
> > On BXT/GLK GEN6_PCODE_READ_RC6VIDS fails with
> > MAILBOX_P24C_CC_ILLEGAL_CMD, so don't try to do the query on these
> > platforms. Do it only on SNB, IVB and HSW, where we use this command
> > anyway for RC6 enabling.
> >
> > Based on my tests the command also succeeds on all LLC platforms, but
> > it's not clear if it's really supported on those (it returns 0 aka 245mv
> > for all RC6 states everywhere except on SNB). BSpec lists the command as
> > supported on SKL+ (see P24C_PCODE_MAILBOX_INTERFACE) but that's clearly
> > incorrect, since on SKL/KBL the same command ID is used for
> > SKL_PCODE_LOAD_HDCP_KEYS. Since the command fails on BXT/GLK, the BSpec
> > command list is also incorrect for those platforms (see
> > P_CR_P24C_PCODE_MAILBOX_INTERFACE_0_2_0_GTTMMADR).
> >
> > I filed a request to update that info in Bspec, but for now let's
> > assume a minimal set of platforms where the command is supported.
> >
> > Reference: https://bugs.freedesktop.org/show_bug.cgi?id=103337
> 
> If the patch fixes the bug, please use Bugzilla:.
> 
> If the patch is related to the bug, please use References:.

It fixes a bug reported in that bug, but there are multiple issues
included in the report. So I suppose References: is the correct tag
then. 

> 
> 
> BR,
> Jani.
> 
> 
> > Signed-off-by: Imre Deak 
> > ---
> >  drivers/gpu/drm/i915/i915_debugfs.c | 24 +++-
> >  1 file changed, 15 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 2bdce9fea671..8f9045fae3cf 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -1484,9 +1484,12 @@ static int gen6_drpc_info(struct seq_file *m)
> > gen9_powergate_status = I915_READ(GEN9_PWRGT_DOMAIN_STATUS);
> > }
> >  
> > -   mutex_lock(_priv->pcu_lock);
> > -   sandybridge_pcode_read(dev_priv, GEN6_PCODE_READ_RC6VIDS, );
> > -   mutex_unlock(_priv->pcu_lock);
> > +   if (INTEL_GEN(dev_priv) <= 7) {
> > +   mutex_lock(_priv->pcu_lock);
> > +   sandybridge_pcode_read(dev_priv, GEN6_PCODE_READ_RC6VIDS,
> > +  );
> > +   mutex_unlock(_priv->pcu_lock);
> > +   }
> >  
> > seq_printf(m, "RC1e Enabled: %s\n",
> >yesno(rcctl1 & GEN6_RC_CTL_RC1e_ENABLE));
> > @@ -1542,12 +1545,15 @@ static int gen6_drpc_info(struct seq_file *m)
> > print_rc6_res(m, "RC6+ residency since boot:", GEN6_GT_GFX_RC6p);
> > print_rc6_res(m, "RC6++ residency since boot:", GEN6_GT_GFX_RC6pp);
> >  
> > -   seq_printf(m, "RC6   voltage: %dmV\n",
> > -  GEN6_DECODE_RC6_VID(((rc6vids >> 0) & 0xff)));
> > -   seq_printf(m, "RC6+  voltage: %dmV\n",
> > -  GEN6_DECODE_RC6_VID(((rc6vids >> 8) & 0xff)));
> > -   seq_printf(m, "RC6++ voltage: %dmV\n",
> > -  GEN6_DECODE_RC6_VID(((rc6vids >> 16) & 0xff)));
> > +   if (INTEL_GEN(dev_priv) <= 7) {
> > +   seq_printf(m, "RC6   voltage: %dmV\n",
> > +  GEN6_DECODE_RC6_VID(((rc6vids >> 0) & 0xff)));
> > +   seq_printf(m, "RC6+  voltage: %dmV\n",
> > +  GEN6_DECODE_RC6_VID(((rc6vids >> 8) & 0xff)));
> > +   seq_printf(m, "RC6++ voltage: %dmV\n",
> > +  GEN6_DECODE_RC6_VID(((rc6vids >> 16) & 0xff)));
> > +   }
> > +
> > return i915_forcewake_domains(m, NULL);
> >  }
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Don't query PCODE RC6VIDS on platforms not supporting it

[Imre Deak]

On Mon, Feb 12, 2018 at 11:19:09AM +, Chris Wilson wrote:
> Quoting Imre Deak (2018-02-08 18:44:41)
> > On Thu, Feb 08, 2018 at 06:33:03PM +, Chris Wilson wrote:
> > > Quoting Imre Deak (2018-02-08 17:41:02)
> > > > On BXT/GLK GEN6_PCODE_READ_RC6VIDS fails with
> > > > MAILBOX_P24C_CC_ILLEGAL_CMD, so don't try to do the query on these
> > > > platforms. Do it only on SNB, IVB and HSW, where we use this command
> > > > anyway for RC6 enabling.
> > > > 
> > > > Based on my tests the command also succeeds on all LLC platforms, but
> > > > it's not clear if it's really supported on those (it returns 0 aka 245mv
> > > > for all RC6 states everywhere except on SNB). BSpec lists the command as
> > > > supported on SKL+ (see P24C_PCODE_MAILBOX_INTERFACE) but that's clearly
> > > > incorrect, since on SKL/KBL the same command ID is used for
> > > > SKL_PCODE_LOAD_HDCP_KEYS. Since the command fails on BXT/GLK, the BSpec
> > > > command list is also incorrect for those platforms (see
> > > > P_CR_P24C_PCODE_MAILBOX_INTERFACE_0_2_0_GTTMMADR).
> > > > 
> > > > I filed a request to update that info in Bspec, but for now let's
> > > > assume a minimal set of platforms where the command is supported.
> > > > 
> > > > Reference: https://bugs.freedesktop.org/show_bug.cgi?id=103337
> > > > Signed-off-by: Imre Deak 
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_debugfs.c | 24 +++-
> > > >  1 file changed, 15 insertions(+), 9 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> > > > b/drivers/gpu/drm/i915/i915_debugfs.c
> > > > index 2bdce9fea671..8f9045fae3cf 100644
> > > > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > > > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > > > @@ -1484,9 +1484,12 @@ static int gen6_drpc_info(struct seq_file *m)
> > > > gen9_powergate_status = 
> > > > I915_READ(GEN9_PWRGT_DOMAIN_STATUS);
> > > > }
> > > >  
> > > > -   mutex_lock(_priv->pcu_lock);
> > > > -   sandybridge_pcode_read(dev_priv, GEN6_PCODE_READ_RC6VIDS, 
> > > > );
> > > > -   mutex_unlock(_priv->pcu_lock);
> > > > +   if (INTEL_GEN(dev_priv) <= 7) {
> > > > +   mutex_lock(_priv->pcu_lock);
> > > > +   sandybridge_pcode_read(dev_priv, 
> > > > GEN6_PCODE_READ_RC6VIDS,
> > > > +  );
> > > > +   mutex_unlock(_priv->pcu_lock);
> > > > +   }
> > > >  
> > > > seq_printf(m, "RC1e Enabled: %s\n",
> > > >yesno(rcctl1 & GEN6_RC_CTL_RC1e_ENABLE));
> > > > @@ -1542,12 +1545,15 @@ static int gen6_drpc_info(struct seq_file *m)
> > > > print_rc6_res(m, "RC6+ residency since boot:", 
> > > > GEN6_GT_GFX_RC6p);
> > > > print_rc6_res(m, "RC6++ residency since boot:", 
> > > > GEN6_GT_GFX_RC6pp);
> > > >  
> > > > -   seq_printf(m, "RC6   voltage: %dmV\n",
> > > > -  GEN6_DECODE_RC6_VID(((rc6vids >> 0) & 0xff)));
> > > > -   seq_printf(m, "RC6+  voltage: %dmV\n",
> > > > -  GEN6_DECODE_RC6_VID(((rc6vids >> 8) & 0xff)));
> > > > -   seq_printf(m, "RC6++ voltage: %dmV\n",
> > > > -  GEN6_DECODE_RC6_VID(((rc6vids >> 16) & 0xff)));
> > > > +   if (INTEL_GEN(dev_priv) <= 7) {
> > > 
> > > I expect this will confuse gcc-4.4 and it will emit a
> > > maybe-used-uninitialised. I would set rc6vids=0 and then test if
> > > (rc6vids) here.
> > 
> > It's inited already to 0, so shouldn't warn. (0 is a valid value
> > otherwise).
> 
> (Valid but not validated ;)

True, so we don't know if the platforms returning 0 (with the PCODE
command otherwise succeeding) return an actually correct value. Checking
again it's only SNB where we use the value (so not even IVB/HSW) and
that's the only one returning a non-zero value. I hope someone will
follow-up on my bspec update request and clarify this.

> 
> Reviewed-by: Chris Wilson 
> -Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Reduce context HW ID lifetime

[Lionel Landwerlin]

On 12/02/18 11:08, Chris Wilson wrote:

Quoting Lionel Landwerlin (2018-02-12 11:00:10)

On 12/02/18 10:41, Chris Wilson wrote:

Quoting Lionel Landwerlin (2018-02-12 10:37:52)

On 09/02/18 20:53, Chris Wilson wrote:

Quoting Lionel Landwerlin (2018-02-09 17:47:44)

Hey Chris,

From the i915/perf point of view, I'm fine with this change.
The pinning of the hw_id when monitoring a single context (with OA)
doesn't break the existing userspace (I can only think of Mesa).

I'm also trying to build up a system wide monitoring feature in GPUTop
with a timeline display. This change makes it a bit more challenging.
But this isn't really an expected feature, it's just nice to have.

What I'm thinking of would be to keep a circular buffer of requests in
the order they're submitted to an engine.
Then the i915 perf driver could correlate between the context-switch
tagged reports coming from OA and the requests submitted.
Much like the OA buffer, this circular buffer could overflow at which
point we signal the application using the i915 perf driver and it'll
most likely close the driver and try again.

I would need that have the hw_id added to the requests. Does that sounds
possible?

You already add hw_id to the tracepoint. For the requests, it is just
req->ctx->hw_id, valid from submission to retirement. Hmm, the
tracepoint is broken (use-after-free in ctx->hw_id). What value do you
want for HSW? (This patch will assign all legacy submission to HW ID 0.)
But aiui, for HSW oa you want lrca not HW ID. So both the use-after-free
and alternative ids suggest storing it on the request directly.

HSW doesn't have a hw_id field in the OA reports.
I'll have to come up with something slightly different.


How do you get the HW ID out, via the tracepoint right?

It's in the OA reports.

I mean how do you correlate the HW ID with userspace?
-Chris


Right now, with tracepoints. But as I wrote above, I don't think it's
reliable (because of the timestamp correlation).
My idea was to let the i915 perf driver do it for userspace by attaching
the pid/tid to the drm_i915_perf_record.
On submission i915 would put the request into a circular buffer and i915
perf would read back the tail of that buffer to match what is coming out
of the OA unit.

And I read that as doing the tracing entirely in userspace. Inside the
kernel we should be able to do a much better job of knowing what
requests/contexts are active, it may just be we take an extra ref and/or
context pin for perf tracking.
-Chris


Then I must be failing to communicate :)
What you wrote is precisely what I would like to do :)

-
Lionel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Don't wake the device up to check if the engine is asleep

[Patchwork]

== Series Details ==

Series: drm/i915: Don't wake the device up to check if the engine is asleep
URL   : https://patchwork.freedesktop.org/series/38075/
State : failure

== Summary ==

Test perf:
Subgroup oa-exponents:
pass   -> FAIL   (shard-apl) fdo#102254
Subgroup enable-disable:
pass   -> FAIL   (shard-apl) fdo#103715
Test perf_pmu:
Subgroup rc6:
skip   -> PASS   (shard-hsw)
Subgroup busy-idle-vcs0:
pass   -> FAIL   (shard-snb)
Test kms_cursor_legacy:
Subgroup cursor-vs-flip-atomic-transitions:
fail   -> PASS   (shard-apl) fdo#103355
Subgroup flip-vs-cursor-atomic:
fail   -> PASS   (shard-hsw) fdo#102670
Test pm_rps:
Subgroup waitboost:
pass   -> FAIL   (shard-apl) fdo#102250
Subgroup min-max-config-loaded:
fail   -> PASS   (shard-apl) fdo#104060
Test gem_eio:
Subgroup in-flight:
pass   -> FAIL   (shard-hsw) fdo#104676
Test gem_softpin:
Subgroup noreloc-s3:
dmesg-warn -> PASS   (shard-snb) fdo#103375
Test kms_flip:
Subgroup flip-vs-panning-vs-hang:
pass   -> DMESG-WARN (shard-snb) fdo#103821
Subgroup 2x-flip-vs-expired-vblank:
pass   -> FAIL   (shard-hsw) fdo#102887
Subgroup plain-flip-ts-check-interruptible:
pass   -> FAIL   (shard-hsw) fdo#100368
Subgroup 2x-flip-vs-blocking-wf-vblank:
pass   -> FAIL   (shard-hsw)
Test kms_frontbuffer_tracking:
Subgroup fbc-rgb565-draw-blt:
fail   -> PASS   (shard-apl) fdo#101623

fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254
fdo#103715 https://bugs.freedesktop.org/show_bug.cgi?id=103715
fdo#103355 https://bugs.freedesktop.org/show_bug.cgi?id=103355
fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670
fdo#102250 https://bugs.freedesktop.org/show_bug.cgi?id=102250
fdo#104060 https://bugs.freedesktop.org/show_bug.cgi?id=104060
fdo#104676 https://bugs.freedesktop.org/show_bug.cgi?id=104676
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#103821 https://bugs.freedesktop.org/show_bug.cgi?id=103821
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623

shard-apltotal:3420 pass:1772 dwarn:1   dfail:0   fail:23  skip:1623 
time:12543s
shard-hswtotal:3444 pass:1756 dwarn:1   dfail:0   fail:15  skip:1671 
time:11755s
shard-snbtotal:3444 pass:1349 dwarn:2   dfail:0   fail:11  skip:2082 
time:6651s
Blacklisted hosts:
shard-kbltotal:3444 pass:1904 dwarn:10  dfail:1   fail:22  skip:1507 
time:9622s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7977/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Don't query PCODE RC6VIDS on platforms not supporting it

[Chris Wilson]

Quoting Imre Deak (2018-02-08 18:44:41)
> On Thu, Feb 08, 2018 at 06:33:03PM +, Chris Wilson wrote:
> > Quoting Imre Deak (2018-02-08 17:41:02)
> > > On BXT/GLK GEN6_PCODE_READ_RC6VIDS fails with
> > > MAILBOX_P24C_CC_ILLEGAL_CMD, so don't try to do the query on these
> > > platforms. Do it only on SNB, IVB and HSW, where we use this command
> > > anyway for RC6 enabling.
> > > 
> > > Based on my tests the command also succeeds on all LLC platforms, but
> > > it's not clear if it's really supported on those (it returns 0 aka 245mv
> > > for all RC6 states everywhere except on SNB). BSpec lists the command as
> > > supported on SKL+ (see P24C_PCODE_MAILBOX_INTERFACE) but that's clearly
> > > incorrect, since on SKL/KBL the same command ID is used for
> > > SKL_PCODE_LOAD_HDCP_KEYS. Since the command fails on BXT/GLK, the BSpec
> > > command list is also incorrect for those platforms (see
> > > P_CR_P24C_PCODE_MAILBOX_INTERFACE_0_2_0_GTTMMADR).
> > > 
> > > I filed a request to update that info in Bspec, but for now let's
> > > assume a minimal set of platforms where the command is supported.
> > > 
> > > Reference: https://bugs.freedesktop.org/show_bug.cgi?id=103337
> > > Signed-off-by: Imre Deak 
> > > ---
> > >  drivers/gpu/drm/i915/i915_debugfs.c | 24 +++-
> > >  1 file changed, 15 insertions(+), 9 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> > > b/drivers/gpu/drm/i915/i915_debugfs.c
> > > index 2bdce9fea671..8f9045fae3cf 100644
> > > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > > @@ -1484,9 +1484,12 @@ static int gen6_drpc_info(struct seq_file *m)
> > > gen9_powergate_status = 
> > > I915_READ(GEN9_PWRGT_DOMAIN_STATUS);
> > > }
> > >  
> > > -   mutex_lock(_priv->pcu_lock);
> > > -   sandybridge_pcode_read(dev_priv, GEN6_PCODE_READ_RC6VIDS, 
> > > );
> > > -   mutex_unlock(_priv->pcu_lock);
> > > +   if (INTEL_GEN(dev_priv) <= 7) {
> > > +   mutex_lock(_priv->pcu_lock);
> > > +   sandybridge_pcode_read(dev_priv, GEN6_PCODE_READ_RC6VIDS,
> > > +  );
> > > +   mutex_unlock(_priv->pcu_lock);
> > > +   }
> > >  
> > > seq_printf(m, "RC1e Enabled: %s\n",
> > >yesno(rcctl1 & GEN6_RC_CTL_RC1e_ENABLE));
> > > @@ -1542,12 +1545,15 @@ static int gen6_drpc_info(struct seq_file *m)
> > > print_rc6_res(m, "RC6+ residency since boot:", GEN6_GT_GFX_RC6p);
> > > print_rc6_res(m, "RC6++ residency since boot:", 
> > > GEN6_GT_GFX_RC6pp);
> > >  
> > > -   seq_printf(m, "RC6   voltage: %dmV\n",
> > > -  GEN6_DECODE_RC6_VID(((rc6vids >> 0) & 0xff)));
> > > -   seq_printf(m, "RC6+  voltage: %dmV\n",
> > > -  GEN6_DECODE_RC6_VID(((rc6vids >> 8) & 0xff)));
> > > -   seq_printf(m, "RC6++ voltage: %dmV\n",
> > > -  GEN6_DECODE_RC6_VID(((rc6vids >> 16) & 0xff)));
> > > +   if (INTEL_GEN(dev_priv) <= 7) {
> > 
> > I expect this will confuse gcc-4.4 and it will emit a
> > maybe-used-uninitialised. I would set rc6vids=0 and then test if
> > (rc6vids) here.
> 
> It's inited already to 0, so shouldn't warn. (0 is a valid value
> otherwise).

(Valid but not validated ;)

Reviewed-by: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Reduce context HW ID lifetime

[Chris Wilson]

Quoting Lionel Landwerlin (2018-02-12 11:00:10)
> On 12/02/18 10:41, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2018-02-12 10:37:52)
> >> On 09/02/18 20:53, Chris Wilson wrote:
> >>> Quoting Lionel Landwerlin (2018-02-09 17:47:44)
>  Hey Chris,
> 
> From the i915/perf point of view, I'm fine with this change.
>  The pinning of the hw_id when monitoring a single context (with OA)
>  doesn't break the existing userspace (I can only think of Mesa).
> 
>  I'm also trying to build up a system wide monitoring feature in GPUTop
>  with a timeline display. This change makes it a bit more challenging.
>  But this isn't really an expected feature, it's just nice to have.
> 
>  What I'm thinking of would be to keep a circular buffer of requests in
>  the order they're submitted to an engine.
>  Then the i915 perf driver could correlate between the context-switch
>  tagged reports coming from OA and the requests submitted.
>  Much like the OA buffer, this circular buffer could overflow at which
>  point we signal the application using the i915 perf driver and it'll
>  most likely close the driver and try again.
> 
>  I would need that have the hw_id added to the requests. Does that sounds
>  possible?
> >>> You already add hw_id to the tracepoint. For the requests, it is just
> >>> req->ctx->hw_id, valid from submission to retirement. Hmm, the
> >>> tracepoint is broken (use-after-free in ctx->hw_id). What value do you
> >>> want for HSW? (This patch will assign all legacy submission to HW ID 0.)
> >>> But aiui, for HSW oa you want lrca not HW ID. So both the use-after-free
> >>> and alternative ids suggest storing it on the request directly.
> >> HSW doesn't have a hw_id field in the OA reports.
> >> I'll have to come up with something slightly different.
> >>
> >>> How do you get the HW ID out, via the tracepoint right?
> >> It's in the OA reports.
> > I mean how do you correlate the HW ID with userspace?
> > -Chris
> >
> Right now, with tracepoints. But as I wrote above, I don't think it's 
> reliable (because of the timestamp correlation).
> My idea was to let the i915 perf driver do it for userspace by attaching 
> the pid/tid to the drm_i915_perf_record.
> On submission i915 would put the request into a circular buffer and i915 
> perf would read back the tail of that buffer to match what is coming out 
> of the OA unit.

And I read that as doing the tracing entirely in userspace. Inside the
kernel we should be able to do a much better job of knowing what
requests/contexts are active, it may just be we take an extra ref and/or
context pin for perf tracking.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx