Re: [Intel-gfx] [PATCH v4 3/7] drm: Add DisplayPort colorspace property
On Mon, 2019-09-09 at 13:25 +0300, Ville Syrjälä wrote: > On Sat, Sep 07, 2019 at 11:19:55PM +, Mun, Gwan-gyeong wrote: > > On Fri, 2019-09-06 at 09:24 -0400, Ilia Mirkin wrote: > > > On Fri, Sep 6, 2019 at 7:43 AM Ville Syrjälä > > > wrote: > > > > On Fri, Sep 06, 2019 at 11:31:55AM +, Shankar, Uma wrote: > > > > > > -Original Message- > > > > > > From: Ilia Mirkin > > > > > > Sent: Tuesday, September 3, 2019 6:12 PM > > > > > > To: Mun, Gwan-gyeong > > > > > > Cc: Intel Graphics Development < > > > > > > intel-gfx@lists.freedesktop.org > > > > > > > ; Shankar, Uma > > > > > > ; dri-devel < > > > > > > dri-de...@lists.freedesktop.org> > > > > > > Subject: Re: [PATCH v4 3/7] drm: Add DisplayPort colorspace > > > > > > property > > > > > > > > > > > > So how would this work with a DP++ connector? Should it > > > > > > list > > > > > > the HDMI or DP > > > > > > properties? Or do we need a custom property checker which > > > > > > is > > > > > > aware of what is > > > > > > currently plugged in to validate the values? > > > > > > > > > > AFAIU For DP++ cases, we detect what kind of sink its driving > > > > > DP > > > > > or HDMI (with a passive dongle). > > > > > Based on the type of sink detected, we should expose DP or > > > > > HDMI > > > > > colorspaces to userspace. > > > > > > > > For i915 DP connector always drives DP mode, HDMI connector > > > > always > > > > drives > > > > HDMI mode, even when the physical connector is DP++. > > > > > > Right, i915 creates 2 connectors, while nouveau, radeon, and > > > amdgpu > > > create 1 connector (not sure about other drivers) for a single > > > physical DP++ socket. Since we supply the list of valid values at > > > the > > > time of creating the connector, we can't know at that point > > > whether > > > in > > > the future a HDMI or DP will be plugged into it. > > > > > > -ilia > > Ilia, does it mean that the drm_connector type is > > DRM_MODE_CONNECTOR_DisplayPort and protocol is DP++ mode? > > > > And Ville and Uma, when we are useing dp active dongle (DP to HDMI > > dongle and DP branch device is HDMI) should we expose HDMI > > colorspace? > > We still set it up via DP MSA/VSC no? In that case it should follow > the > DP spec I think. LSPCON is probably different because we manually Yes, I agree too. - G.G. > generate > the AVI infoframe for it. But I'm not sure how we're going to > reconcile > that with the DP stuff we also set up for it. > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 05/11] drm/i915/dsb: Check DSB engine status.
On 9/10/2019 8:44 AM, Sharma, Shashank wrote: -Original Message- From: Manna, Animesh Sent: Monday, September 9, 2019 10:27 PM To: Sharma, Shashank ; intel- g...@lists.freedesktop.org Cc: Thierry, Michel ; Nikula, Jani ; Vivi, Rodrigo Subject: Re: [PATCH v5 05/11] drm/i915/dsb: Check DSB engine status. On 9/9/2019 6:43 PM, Sharma, Shashank wrote: On 9/7/2019 4:37 PM, Animesh Manna wrote: +#define _DSBSL_INSTANCE_BASE0x70B00 +#define DSBSL_INSTANCE(pipe, id)(_DSBSL_INSTANCE_BASE + \ + (pipe) * 0x1000 + (id) * 100) Why is pipe in () ? mmio offset per DSB depend on pipe and dsb-id (3 DSB per pipe.) offset of PIPE_A DSB1-> 70B00 offset of PIPE_B DSB1-> 71B00 and so on... The question here is why is the 'pipe' in braces ? why is it '(pipe)', instead of 'pipe'. I don’t see a reason. Just followed general macro definition rule, am I missing anything. for example: #define double(x) x*2 double(2+3) will give wrong result if we do not define as #define double(x) (x)*2 Regards, Animesh - Shashank Regards, Animesh ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 3/7] drm: Add DisplayPort colorspace property
On Sat, 2019-09-07 at 21:43 -0400, Ilia Mirkin wrote: > On Sat, Sep 7, 2019 at 7:20 PM Mun, Gwan-gyeong > wrote: > > On Fri, 2019-09-06 at 09:24 -0400, Ilia Mirkin wrote: > > > On Fri, Sep 6, 2019 at 7:43 AM Ville Syrjälä > > > wrote: > > > > On Fri, Sep 06, 2019 at 11:31:55AM +, Shankar, Uma wrote: > > > > > > -Original Message- > > > > > > From: Ilia Mirkin > > > > > > Sent: Tuesday, September 3, 2019 6:12 PM > > > > > > To: Mun, Gwan-gyeong > > > > > > Cc: Intel Graphics Development < > > > > > > intel-gfx@lists.freedesktop.org > > > > > > > ; Shankar, Uma > > > > > > ; dri-devel < > > > > > > dri-de...@lists.freedesktop.org> > > > > > > Subject: Re: [PATCH v4 3/7] drm: Add DisplayPort colorspace > > > > > > property > > > > > > > > > > > > So how would this work with a DP++ connector? Should it > > > > > > list > > > > > > the HDMI or DP > > > > > > properties? Or do we need a custom property checker which > > > > > > is > > > > > > aware of what is > > > > > > currently plugged in to validate the values? > > > > > > > > > > AFAIU For DP++ cases, we detect what kind of sink its driving > > > > > DP > > > > > or HDMI (with a passive dongle). > > > > > Based on the type of sink detected, we should expose DP or > > > > > HDMI > > > > > colorspaces to userspace. > > > > > > > > For i915 DP connector always drives DP mode, HDMI connector > > > > always > > > > drives > > > > HDMI mode, even when the physical connector is DP++. > > > > > > Right, i915 creates 2 connectors, while nouveau, radeon, and > > > amdgpu > > > create 1 connector (not sure about other drivers) for a single > > > physical DP++ socket. Since we supply the list of valid values at > > > the > > > time of creating the connector, we can't know at that point > > > whether > > > in > > > the future a HDMI or DP will be plugged into it. > > > > > > -ilia > > Ilia, does it mean that the drm_connector type is > > DRM_MODE_CONNECTOR_DisplayPort and protocol is DP++ mode? > > That is correct. The connector type is "DisplayPort" in such a case. > > Cheers, > > -ilia For now drm_mode_create_colorspace_property() is only used for i915. IMHO, when other drivers ( nouveau, radeon, and amdgpu ) are ready for using of drm_mode_create_colorspace_property(), what about do we add a variable which can identify DP++ and DP to drm_connector? And when the drivers (nouveau, radeon, and amdgpu) detect the current protocol, the drivers will set the variable. Br, - G.G. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/gt: Allow clobbering gpu resets if the display is off
On Mon, Sep 09, 2019 at 11:55:35PM +0100, Chris Wilson wrote:
> If the display is inactive, we need not worry about the gpu reset
> clobbering the display!
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/gt/intel_reset.c | 18 +-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
> b/drivers/gpu/drm/i915/gt/intel_reset.c
> index b9d84d52e986..fe57296b790c 100644
> --- a/drivers/gpu/drm/i915/gt/intel_reset.c
> +++ b/drivers/gpu/drm/i915/gt/intel_reset.c
> @@ -7,6 +7,7 @@
> #include
> #include
>
> +#include "display/intel_display.h"
> #include "display/intel_display_types.h"
> #include "display/intel_overlay.h"
>
> @@ -729,6 +730,21 @@ static void nop_submit_request(struct i915_request
> *request)
> intel_engine_queue_breadcrumbs(engine);
> }
>
> +static bool reset_clobbers_display(struct drm_i915_private *i915)
> +{
> + struct intel_crtc *crtc;
> +
> + if (!INTEL_INFO(i915)->gpu_reset_clobbers_display)
> + return false;
> +
> + for_each_intel_crtc(&i915->drm, crtc) {
> + if (crtc->active)
> + return true;
> + }
This feels racy. crtc->active gets set somewhere in the middle of the
modeset, so looks like now we could clobber all the stuff we've already
set up before crtc->active got set.
> +
> + return false;
> +}
> +
> static void __intel_gt_set_wedged(struct intel_gt *gt)
> {
> struct intel_engine_cs *engine;
> @@ -755,7 +771,7 @@ static void __intel_gt_set_wedged(struct intel_gt *gt)
> awake = reset_prepare(gt);
>
> /* Even if the GPU reset fails, it should still stop the engines */
> - if (!INTEL_INFO(gt->i915)->gpu_reset_clobbers_display)
> + if (!reset_clobbers_display(gt->i915))
> __intel_gt_reset(gt, ALL_ENGINES);
>
> for_each_engine(engine, gt->i915, id)
> --
> 2.23.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
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/gt: Only unwedge if we can reset first
Hi Chris, On Tuesday, September 10, 2019 12:55:36 AM CEST Chris Wilson wrote: > Unwedging the GPU requires a successful GPU reset before we restore the > default submission, or else we may see residual context switch events > that we were not expecting. > > Reported-by: Janusz Krzysztofik > Signed-off-by: Chris Wilson > Cc: Janusz Krzysztofik > Cc: Daniele Ceraolo Spurio > --- > drivers/gpu/drm/i915/gt/intel_reset.c | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c b/drivers/gpu/drm/i915/ gt/intel_reset.c > index fe57296b790c..5242496a893a 100644 > --- a/drivers/gpu/drm/i915/gt/intel_reset.c > +++ b/drivers/gpu/drm/i915/gt/intel_reset.c > @@ -809,6 +809,7 @@ static bool __intel_gt_unset_wedged(struct intel_gt *gt) > struct intel_gt_timelines *timelines = >->timelines; > struct intel_timeline *tl; > unsigned long flags; > + bool ok; > > if (!test_bit(I915_WEDGED, >->reset.flags)) > return true; > @@ -854,7 +855,11 @@ static bool __intel_gt_unset_wedged(struct intel_gt *gt) > } > spin_unlock_irqrestore(&timelines->lock, flags); > > - intel_gt_sanitize(gt, false); > + ok = false; > + if (!reset_clobbers_display(gt->i915)) > + ok = __intel_gt_reset(gt, ALL_ENGINES) == 0; > + if (!ok) > + return false; Before your change, that code was executed inside intel_gt_sanitize(gt, false) which unfortunately didn't return any result. The same outcome could be achieved by redefining intel_gt_sanitize() to return that result and saying: if (!intel_gt_sanitize(gt, false) return false; Is there any specific reason for intel_gt_sanitize() returning void? Thanks, Janusz > > /* >* Undo nop_submit_request. We prevent all new i915 requests from > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 3/7] drm: Add DisplayPort colorspace property
On Tue, Sep 10, 2019 at 07:34:31AM +, Mun, Gwan-gyeong wrote: > On Sat, 2019-09-07 at 21:43 -0400, Ilia Mirkin wrote: > > On Sat, Sep 7, 2019 at 7:20 PM Mun, Gwan-gyeong > > wrote: > > > On Fri, 2019-09-06 at 09:24 -0400, Ilia Mirkin wrote: > > > > On Fri, Sep 6, 2019 at 7:43 AM Ville Syrjälä > > > > wrote: > > > > > On Fri, Sep 06, 2019 at 11:31:55AM +, Shankar, Uma wrote: > > > > > > > -Original Message- > > > > > > > From: Ilia Mirkin > > > > > > > Sent: Tuesday, September 3, 2019 6:12 PM > > > > > > > To: Mun, Gwan-gyeong > > > > > > > Cc: Intel Graphics Development < > > > > > > > intel-gfx@lists.freedesktop.org > > > > > > > > ; Shankar, Uma > > > > > > > ; dri-devel < > > > > > > > dri-de...@lists.freedesktop.org> > > > > > > > Subject: Re: [PATCH v4 3/7] drm: Add DisplayPort colorspace > > > > > > > property > > > > > > > > > > > > > > So how would this work with a DP++ connector? Should it > > > > > > > list > > > > > > > the HDMI or DP > > > > > > > properties? Or do we need a custom property checker which > > > > > > > is > > > > > > > aware of what is > > > > > > > currently plugged in to validate the values? > > > > > > > > > > > > AFAIU For DP++ cases, we detect what kind of sink its driving > > > > > > DP > > > > > > or HDMI (with a passive dongle). > > > > > > Based on the type of sink detected, we should expose DP or > > > > > > HDMI > > > > > > colorspaces to userspace. > > > > > > > > > > For i915 DP connector always drives DP mode, HDMI connector > > > > > always > > > > > drives > > > > > HDMI mode, even when the physical connector is DP++. > > > > > > > > Right, i915 creates 2 connectors, while nouveau, radeon, and > > > > amdgpu > > > > create 1 connector (not sure about other drivers) for a single > > > > physical DP++ socket. Since we supply the list of valid values at > > > > the > > > > time of creating the connector, we can't know at that point > > > > whether > > > > in > > > > the future a HDMI or DP will be plugged into it. > > > > > > > > -ilia > > > Ilia, does it mean that the drm_connector type is > > > DRM_MODE_CONNECTOR_DisplayPort and protocol is DP++ mode? > > > > That is correct. The connector type is "DisplayPort" in such a case. > > > > Cheers, > > > > -ilia > > For now drm_mode_create_colorspace_property() is only used for i915. > IMHO, when other drivers ( nouveau, radeon, and amdgpu ) are ready for > using of drm_mode_create_colorspace_property(), > what about do we add a variable which can identify DP++ and DP to > drm_connector? > And when the drivers (nouveau, radeon, and amdgpu) detect the current > protocol, the drivers will set the variable. IMO better to just have two functions in that case: one for DP, another for HDMI. -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/execlists: Clear STOP_RING bit on reset
During reset, we try to ensure no forward progress of the CS prior to
the reset by setting the STOP_RING bit in RING_MI_MODE. Since gen9, this
register is context saved and do we end up in the odd situation where we
save the STOP_RING bit and so try to stop the engine again immediately
upon resume. This is quite unexpected and causes us to complain about an
early CS completion event!
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111514
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 10 ++
drivers/gpu/drm/i915/gt/intel_lrc_reg.h | 2 ++
2 files changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index f073aea6a1fe..761f5cbd90d3 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2368,6 +2368,15 @@ static struct i915_request *active_request(struct
i915_request *rq)
return active;
}
+static void __execlists_reset_reg_state(const struct intel_context *ce,
+ const struct intel_engine_cs *engine)
+{
+ u32 *regs = ce->lrc_reg_state;
+
+ if (INTEL_GEN(engine->i915) >= 9)
+ regs[GEN9_CTX_RING_MI_MODE + 1] |=
_MASKED_BIT_DISABLE(STOP_RING);
+}
+
static void __execlists_reset(struct intel_engine_cs *engine, bool stalled)
{
struct intel_engine_execlists * const execlists = &engine->execlists;
@@ -2455,6 +2464,7 @@ static void __execlists_reset(struct intel_engine_cs
*engine, bool stalled)
GEM_TRACE("%s replay {head:%04x, tail:%04x\n",
engine->name, ce->ring->head, ce->ring->tail);
intel_ring_update_space(ce->ring);
+ __execlists_reset_reg_state(ce, engine);
__execlists_update_reg_state(ce, engine);
mutex_release(&ce->pin_mutex.dep_map, 0, _THIS_IP_);
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc_reg.h
b/drivers/gpu/drm/i915/gt/intel_lrc_reg.h
index 68caf8541866..7e773e74a3fe 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc_reg.h
+++ b/drivers/gpu/drm/i915/gt/intel_lrc_reg.h
@@ -39,6 +39,8 @@
#define CTX_R_PWR_CLK_STATE0x42
#define CTX_END0x44
+#define GEN9_CTX_RING_MI_MODE 0x54
+
/* GEN12+ Reg State Context */
#define GEN12_CTX_BB_PER_CTX_PTR 0x12
#define GEN12_CTX_LRI_HEADER_3 0x41
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/execlists: Clear STOP_RING bit on reset
During reset, we try to ensure no forward progress of the CS prior to
the reset by setting the STOP_RING bit in RING_MI_MODE. Since gen9, this
register is context saved and do we end up in the odd situation where we
save the STOP_RING bit and so try to stop the engine again immediately
upon resume. This is quite unexpected and causes us to complain about an
early CS completion event!
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111514
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 12
drivers/gpu/drm/i915/gt/intel_lrc_reg.h | 2 ++
2 files changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index f073aea6a1fe..64170ce0c91b 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2368,6 +2368,17 @@ static struct i915_request *active_request(struct
i915_request *rq)
return active;
}
+static void __execlists_reset_reg_state(const struct intel_context *ce,
+ const struct intel_engine_cs *engine)
+{
+ u32 *regs = ce->lrc_reg_state;
+
+ if (INTEL_GEN(engine->i915) >= 9) {
+ regs[GEN9_CTX_RING_MI_MODE + 1] &= ~STOP_RING;
+ regs[GEN9_CTX_RING_MI_MODE + 1] |= STOP_RING << 16;
+ }
+}
+
static void __execlists_reset(struct intel_engine_cs *engine, bool stalled)
{
struct intel_engine_execlists * const execlists = &engine->execlists;
@@ -2455,6 +2466,7 @@ static void __execlists_reset(struct intel_engine_cs
*engine, bool stalled)
GEM_TRACE("%s replay {head:%04x, tail:%04x\n",
engine->name, ce->ring->head, ce->ring->tail);
intel_ring_update_space(ce->ring);
+ __execlists_reset_reg_state(ce, engine);
__execlists_update_reg_state(ce, engine);
mutex_release(&ce->pin_mutex.dep_map, 0, _THIS_IP_);
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc_reg.h
b/drivers/gpu/drm/i915/gt/intel_lrc_reg.h
index 68caf8541866..7e773e74a3fe 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc_reg.h
+++ b/drivers/gpu/drm/i915/gt/intel_lrc_reg.h
@@ -39,6 +39,8 @@
#define CTX_R_PWR_CLK_STATE0x42
#define CTX_END0x44
+#define GEN9_CTX_RING_MI_MODE 0x54
+
/* GEN12+ Reg State Context */
#define GEN12_CTX_BB_PER_CTX_PTR 0x12
#define GEN12_CTX_LRI_HEADER_3 0x41
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 9/9] drm/i915: Expand subslice mask
On 10/09/2019 05:53, Summers, Stuart wrote:
On Fri, 2019-09-06 at 19:13 +0100, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-09-02 14:42:44)
On 24/07/2019 14:05, Tvrtko Ursulin wrote:
On 23/07/2019 16:49, Stuart Summers wrote:
+u32 intel_sseu_get_subslices(const struct sseu_dev_info *sseu,
u8 slice)
+{
+int i, offset = slice * sseu->ss_stride;
+u32 mask = 0;
+
+if (slice >= sseu->max_slices) {
+DRM_ERROR("%s: invalid slice %d, max: %d\n",
+ __func__, slice, sseu->max_slices);
+return 0;
+}
+
+if (sseu->ss_stride > sizeof(mask)) {
+DRM_ERROR("%s: invalid subslice stride %d, max:
%lu\n",
+ __func__, sseu->ss_stride, sizeof(mask));
+return 0;
+}
+
+for (i = 0; i < sseu->ss_stride; i++)
+mask |= (u32)sseu->subslice_mask[offset + i] <<
+i * BITS_PER_BYTE;
+
+return mask;
+}
Why do you actually need these complications when the plan from
the
start was that the driver and user sseu representation structures
can be
different?
I only gave it a quick look so I might be wrong, but why not just
expand
the driver representations of subslice mask up from u8? Userspace
API
should be able to cope with strides already.
I never got an answer to this and the series was merged in the
meantime.
Thanks for the note here Tvrtko and sorry for the missed response! For
some reason I hadn't caught this comment earlier :(
Ok no worries.
Maybe not much harm but I still don't understand why all the
complications seemingly just to avoid bumping the *internal* ss
mask up
from u8. As long as the internal and abi sseu info struct are well
separated and access point few and well controlled (I think they
are)
then I don't see why the internal side had to be converted to u8
and
strides. But maybe I am missing something.
I looked at it and thought it was open-coding bitmap.h as well. I
accepted it in good faith that it improved certain use cases and
should
even make tidying up the code without regressing those easier.
The goal here is to make sure we have an infrastructure in place that
always provides a consistent bit layout to userspace regardless of
underlying architecture endianness. Perhaps this could have been made
more clear in the commit message here.
My point was that internal and userspace representation do not have to
match and that it probably would have been much simpler code if that
principle remained. We already had a split between internal and ABI sseu
structs and whereas the latter understands concept of stride already,
the former could have just had it's subslice mask field expended from u8
to u16, or whatever. But anyway, at this point I don't even remember all
the details your series did, and given it's merged I won't be going
re-reading it.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/gt: Allow clobbering gpu resets if the display is off
Quoting Ville Syrjälä (2019-09-10 08:39:31)
> On Mon, Sep 09, 2019 at 11:55:35PM +0100, Chris Wilson wrote:
> > If the display is inactive, we need not worry about the gpu reset
> > clobbering the display!
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/gt/intel_reset.c | 18 +-
> > 1 file changed, 17 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
> > b/drivers/gpu/drm/i915/gt/intel_reset.c
> > index b9d84d52e986..fe57296b790c 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_reset.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_reset.c
> > @@ -7,6 +7,7 @@
> > #include
> > #include
> >
> > +#include "display/intel_display.h"
> > #include "display/intel_display_types.h"
> > #include "display/intel_overlay.h"
> >
> > @@ -729,6 +730,21 @@ static void nop_submit_request(struct i915_request
> > *request)
> > intel_engine_queue_breadcrumbs(engine);
> > }
> >
> > +static bool reset_clobbers_display(struct drm_i915_private *i915)
> > +{
> > + struct intel_crtc *crtc;
> > +
> > + if (!INTEL_INFO(i915)->gpu_reset_clobbers_display)
> > + return false;
> > +
> > + for_each_intel_crtc(&i915->drm, crtc) {
> > + if (crtc->active)
> > + return true;
> > + }
>
> This feels racy. crtc->active gets set somewhere in the middle of the
> modeset, so looks like now we could clobber all the stuff we've already
> set up before crtc->active got set.
The question is, does it matter? After we unwedge, we clobber again for
realz. Not that we have anything deliberately trying to race
wedge-vs-modeset(on/off).
-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/execlists: Clear STOP_RING bit on reset (rev2)
== Series Details ==
Series: drm/i915/execlists: Clear STOP_RING bit on reset (rev2)
URL : https://patchwork.freedesktop.org/series/66473/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6857 -> Patchwork_14336
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14336/
Known issues
Here are the changes found in Patchwork_14336 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_switch@legacy-render:
- fi-cml-u2: [PASS][1] -> [INCOMPLETE][2] ([fdo#110566] /
[fdo#111381])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6857/fi-cml-u2/igt@gem_ctx_swi...@legacy-render.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14336/fi-cml-u2/igt@gem_ctx_swi...@legacy-render.html
Possible fixes
* igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850: [INCOMPLETE][3] ([fdo#107718]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6857/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14336/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#110566]: https://bugs.freedesktop.org/show_bug.cgi?id=110566
[fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381
[fdo#111593]: https://bugs.freedesktop.org/show_bug.cgi?id=111593
Participating hosts (53 -> 42)
--
Missing(11): fi-ilk-m540 fi-cml-s fi-hsw-4200u fi-byt-squawks fi-icl-u2
fi-bsw-cyan fi-icl-u3 fi-icl-y fi-byt-clapper fi-bdw-samus fi-snb-2600
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6857 -> Patchwork_14336
CI-20190529: 20190529
CI_DRM_6857: 4dd97e0eb8e88d369c067c71f5796568f41585c1 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5177: 8f351d693352d21c96cef38c3fd77f778c6d7c33 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14336: 11751f7acb4e405718ea6f90a5df8aabdd98679e @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
11751f7acb4e drm/i915/execlists: Clear STOP_RING bit on reset
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14336/
___
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/tgl: Implement Wa_1409142259 (rev2)
== Series Details == Series: drm/i915/tgl: Implement Wa_1409142259 (rev2) URL : https://patchwork.freedesktop.org/series/66364/ State : success == Summary == CI Bug Log - changes from CI_DRM_6855_full -> Patchwork_14335_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14335_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@vcs1-dirty-create: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#109276]) +16 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6855/shard-iclb4/igt@gem_ctx_isolat...@vcs1-dirty-create.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14335/shard-iclb6/igt@gem_ctx_isolat...@vcs1-dirty-create.html * igt@gem_exec_schedule@preempt-other-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#111325]) +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6855/shard-iclb7/igt@gem_exec_sched...@preempt-other-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14335/shard-iclb1/igt@gem_exec_sched...@preempt-other-bsd.html * igt@kms_cursor_legacy@long-nonblocking-modeset-vs-cursor-atomic: - shard-skl: [PASS][5] -> [DMESG-WARN][6] ([fdo#105541]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6855/shard-skl2/igt@kms_cursor_leg...@long-nonblocking-modeset-vs-cursor-atomic.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14335/shard-skl3/igt@kms_cursor_leg...@long-nonblocking-modeset-vs-cursor-atomic.html * igt@kms_draw_crc@draw-method-rgb565-mmap-wc-untiled: - shard-skl: [PASS][7] -> [FAIL][8] ([fdo#103184] / [fdo#103232]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6855/shard-skl5/igt@kms_draw_...@draw-method-rgb565-mmap-wc-untiled.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14335/shard-skl8/igt@kms_draw_...@draw-method-rgb565-mmap-wc-untiled.html * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: [PASS][9] -> [FAIL][10] ([fdo#105363]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6855/shard-skl9/igt@kms_f...@flip-vs-expired-vblank.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14335/shard-skl5/igt@kms_f...@flip-vs-expired-vblank.html * igt@kms_flip@flip-vs-suspend: - shard-skl: [PASS][11] -> [INCOMPLETE][12] ([fdo#109507]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6855/shard-skl6/igt@kms_f...@flip-vs-suspend.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14335/shard-skl3/igt@kms_f...@flip-vs-suspend.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-render: - shard-iclb: [PASS][13] -> [FAIL][14] ([fdo#103167]) +3 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6855/shard-iclb3/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-spr-indfb-draw-render.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14335/shard-iclb7/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-spr-indfb-draw-render.html * igt@kms_plane_lowres@pipe-a-tiling-x: - shard-iclb: [PASS][15] -> [FAIL][16] ([fdo#103166]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6855/shard-iclb8/igt@kms_plane_low...@pipe-a-tiling-x.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14335/shard-iclb5/igt@kms_plane_low...@pipe-a-tiling-x.html * igt@kms_psr@psr2_sprite_render: - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109441]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6855/shard-iclb2/igt@kms_psr@psr2_sprite_render.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14335/shard-iclb3/igt@kms_psr@psr2_sprite_render.html * igt@kms_vblank@pipe-b-ts-continuation-suspend: - shard-apl: [PASS][19] -> [DMESG-WARN][20] ([fdo#108566]) +4 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6855/shard-apl5/igt@kms_vbl...@pipe-b-ts-continuation-suspend.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14335/shard-apl4/igt@kms_vbl...@pipe-b-ts-continuation-suspend.html * igt@prime_busy@hang-default: - shard-iclb: [PASS][21] -> [INCOMPLETE][22] ([fdo#107713]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6855/shard-iclb2/igt@prime_b...@hang-default.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14335/shard-iclb1/igt@prime_b...@hang-default.html Possible fixes * igt@gem_ctx_shared@exec-single-timeline-bsd: - shard-iclb: [SKIP][23] ([fdo#110841]) -> [PASS][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6855/shard-iclb1/igt@gem_ctx_sha...@exec-single-timeline-bsd.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14335/shard-iclb7/igt@gem_ctx_sha...@exec-single-timeline-bsd.html
Re: [Intel-gfx] [PATCH 1/2] drm/i915/gt: Allow clobbering gpu resets if the display is off
On Tue, Sep 10, 2019 at 09:32:45AM +0100, Chris Wilson wrote:
> Quoting Ville Syrjälä (2019-09-10 08:39:31)
> > On Mon, Sep 09, 2019 at 11:55:35PM +0100, Chris Wilson wrote:
> > > If the display is inactive, we need not worry about the gpu reset
> > > clobbering the display!
> > >
> > > Signed-off-by: Chris Wilson
> > > ---
> > > drivers/gpu/drm/i915/gt/intel_reset.c | 18 +-
> > > 1 file changed, 17 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
> > > b/drivers/gpu/drm/i915/gt/intel_reset.c
> > > index b9d84d52e986..fe57296b790c 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_reset.c
> > > +++ b/drivers/gpu/drm/i915/gt/intel_reset.c
> > > @@ -7,6 +7,7 @@
> > > #include
> > > #include
> > >
> > > +#include "display/intel_display.h"
> > > #include "display/intel_display_types.h"
> > > #include "display/intel_overlay.h"
> > >
> > > @@ -729,6 +730,21 @@ static void nop_submit_request(struct i915_request
> > > *request)
> > > intel_engine_queue_breadcrumbs(engine);
> > > }
> > >
> > > +static bool reset_clobbers_display(struct drm_i915_private *i915)
> > > +{
> > > + struct intel_crtc *crtc;
> > > +
> > > + if (!INTEL_INFO(i915)->gpu_reset_clobbers_display)
> > > + return false;
> > > +
> > > + for_each_intel_crtc(&i915->drm, crtc) {
> > > + if (crtc->active)
> > > + return true;
> > > + }
> >
> > This feels racy. crtc->active gets set somewhere in the middle of the
> > modeset, so looks like now we could clobber all the stuff we've already
> > set up before crtc->active got set.
>
> The question is, does it matter? After we unwedge, we clobber again for
> realz. Not that we have anything deliberately trying to race
> wedge-vs-modeset(on/off).
Not sure. But I suspect the hw might decide to hang the box if eg.
the PLL is borked when we touch something that really needs the clock.
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Prune 2560x2880 mode for 5K tiled dual DP monitors
On Mon, 09 Sep 2019, Manasi Navare wrote: > On Thu, Sep 05, 2019 at 11:03:12AM +0530, Nautiyal, Ankit K wrote: >> Hi, >> >> I was able to get 5K HPz27q 317b monitor for some time. Below are the >> observation on HPz27q Monitor with two DP cables connected to a KBL machine. >> >> *General Observation* >> The monitor settings has two modes, DP1.0 and DP1.2. >> One of the connector is enumerated as 'tiled' and the other as non tiled. >> >> The non-tiled connector has modes starting from 2K and below, and the tiled >> connector has just one mode 2560x2880. >> No corruption observed in this case. >> >> In case of DP2.0 two connectors are enumerated, both tiled. >> One connector has modes from 3849x2160 and below. 2560x2880 being preferred >> mode. >> The other has 2560x2880 mode, also preferred. >> >> The issue is seen when both the modes selected are 2560x2880. This results >> like two halves of screens not in sync. >> >> *Experiment with different patches* >> >> As discussed I collected logs in 3 cases: >> 1. Without any patch (vanilla) >> 2. With patch to prune the 2560x2880 mode, only for tile with HLOC and VLOC >> as 0. >> 3. With a patch to force the connector property as 'false' >> >> Logs for which are attached in fdo bug #97244 >> https://bugs.freedesktop.org/show_bug.cgi?id=97244 >> https://bugs.freedesktop.org/attachment.cgi?id=145267 >> >> Note 1: I had changed the display info to provide the Tile information, in >> case the connector 'has_tile' is true. >> Note 2: I had checked and collected logs with single display and also with >> dual display configuration with DP1.2 monitor settings. >> Note 3: The mode is changed using xrandr. >> >> case1: >> -Without any patch : 2560x2880 modeset on both connectors causes corruption. >> >> case2: >> -With 2560x2880 mode pruned for one of the tile : Only one of the connector >> shows 2560x2880 mode. >> 2560x2880 modeset on any the remaining connector resulted in blank screen. >> Any other modeset works. >> >> case3: >> -With has_tile connector property forcibly reset : The connector are listed >> as not tiled but still, 2560x2880 modeset on any the connectors causes blank >> screen. >> Any other modeset works. >> >> To summarize, pruning on just one tiled connector does not solve the issue, >> if we need to prune, we need to do it for both the connectors. >> Secondly, the forcible setting of has_tile = 'false' also, does not help, >> and resulted in blank screen when 2560x2880 mode is applied. >> So IMHO if we need to prune the mode 2560x2880, we need to prune it for both >> the connectors. >> > > Thanks Ankit for these experiments and logs. > So looks like the solution would be to add a quirk for thsi specific EDID for > the panel and then prune 2560x2880 on both connectors. > > Jani does that sound like a good acceptable solution? So you'd have to disable the mode for both displays, but then it would seem odd to expose the tiling configuration with a non-existing mode, wouldn't it? The quirk should be: on these displays, disable tiling and prune the modes listed in the tile info. That's a fairly generic quirk that makes sense to *define* in drm. However you'd only *implement* that quirk in affected drivers, i.e. i915. The question remains, what does it take to actually fix this? I haven't looked at the patches in detail, what makes them so icl specific? I'll repeat what I said up-thread: On Wed, 28 Aug 2019, Jani Nikula wrote: > Finally, and perhaps most importantly, there are people on the bug that > are going to be rather underwhelmed that after three years they get a > patch that simply rejects the very mode that was the reason for buying > the display they have. Insult to injury, the real fix is for a platform > that didn't exist when they bought the displays. Some of those folks apparently can actually make it work when they try hard enough. You'd take that away too. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/6] Remaining patches to enable Transcoder Port Sync for tiled displays
On Sun, 08 Sep 2019, Manasi Navare wrote: > This patch series addresses all review comments and now the enable and > disable paths follow the method of obtaining slave states from master > and updating master-slaves in correct order during master modeset. Main high level question: what does it take to enable this on gen9+? BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/execlists: Clear STOP_RING bit on reset
Chris Wilson writes:
> During reset, we try to ensure no forward progress of the CS prior to
> the reset by setting the STOP_RING bit in RING_MI_MODE. Since gen9, this
> register is context saved and do we end up in the odd situation where we
> save the STOP_RING bit and so try to stop the engine again immediately
> upon resume. This is quite unexpected and causes us to complain about an
> early CS completion event!
The completion event is a product of resume with a stop set?
If my memory serves me well, we have fought this before.
But I have still missing pieces. Why would we not want to
set this for all contexts primed for execution? In gen8 too.
I mean, queuing context with a ring stopped just doesn't
sound right on any gen.
-Mika
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111514
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 10 ++
> drivers/gpu/drm/i915/gt/intel_lrc_reg.h | 2 ++
> 2 files changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index f073aea6a1fe..761f5cbd90d3 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -2368,6 +2368,15 @@ static struct i915_request *active_request(struct
> i915_request *rq)
> return active;
> }
>
> +static void __execlists_reset_reg_state(const struct intel_context *ce,
> + const struct intel_engine_cs *engine)
> +{
> + u32 *regs = ce->lrc_reg_state;
> +
> + if (INTEL_GEN(engine->i915) >= 9)
> + regs[GEN9_CTX_RING_MI_MODE + 1] |=
> _MASKED_BIT_DISABLE(STOP_RING);
> +}
> +
> static void __execlists_reset(struct intel_engine_cs *engine, bool stalled)
> {
> struct intel_engine_execlists * const execlists = &engine->execlists;
> @@ -2455,6 +2464,7 @@ static void __execlists_reset(struct intel_engine_cs
> *engine, bool stalled)
> GEM_TRACE("%s replay {head:%04x, tail:%04x\n",
> engine->name, ce->ring->head, ce->ring->tail);
> intel_ring_update_space(ce->ring);
> + __execlists_reset_reg_state(ce, engine);
> __execlists_update_reg_state(ce, engine);
> mutex_release(&ce->pin_mutex.dep_map, 0, _THIS_IP_);
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc_reg.h
> b/drivers/gpu/drm/i915/gt/intel_lrc_reg.h
> index 68caf8541866..7e773e74a3fe 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc_reg.h
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc_reg.h
> @@ -39,6 +39,8 @@
> #define CTX_R_PWR_CLK_STATE 0x42
> #define CTX_END 0x44
>
> +#define GEN9_CTX_RING_MI_MODE0x54
> +
> /* GEN12+ Reg State Context */
> #define GEN12_CTX_BB_PER_CTX_PTR 0x12
> #define GEN12_CTX_LRI_HEADER_3 0x41
> --
> 2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/execlists: Clear STOP_RING bit on reset
Quoting Mika Kuoppala (2019-09-10 10:31:05) > Chris Wilson writes: > > > During reset, we try to ensure no forward progress of the CS prior to > > the reset by setting the STOP_RING bit in RING_MI_MODE. Since gen9, this > > register is context saved and do we end up in the odd situation where we > > save the STOP_RING bit and so try to stop the engine again immediately > > upon resume. This is quite unexpected and causes us to complain about an > > early CS completion event! > > The completion event is a product of resume with a stop set? A completion event is the product of STOP_RING. Whether it is the completion event that we keep failing on... > If my memory serves me well, we have fought this before. Exactly. We've reduced the frequency of when we apply the STOP_RING, but have not eliminated it. > But I have still missing pieces. Why would we not want to > set this for all contexts primed for execution? In gen8 too. It's not in the gen8 context, afaict. I searched the context image for an LRI with the RING_MI_MODE register: https://patchwork.freedesktop.org/patch/329919/?series=66468&rev=1 > I mean, queuing context with a ring stopped just doesn't > sound right on any gen. We clear the STOP_RING in the register on resume just in case, and that is being flagged on Icelake (which I put down to the reset not being very thorough!). The remaining question was whether we were restoring it from the context image. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/edid: Don't look for CEA data blocks in CEA ext block rev < 3
Hi Ville,
On Mon, 2 Sep 2019 16:15:45 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> CEA ext block revisions 1 and 2 do not contain the data block
> collection. Instead that section of the extension block is
> marked as reserved for 8 byte timing descriptors. Revision 3
> changed it to contain the CEA data block collection instead.
>
> Most places that iterate the data blocks already check for
> revision >= 3, but drm_detect_hdmi_monitor() and
> drm_detect_monitor_audio() do not. So in theory when encountering
> rev 1 or 2 CEA extension block they could end up misinterpreting
> whatever data is in the reserved section as CEA data blocks.
>
> Let's have cea_db_offsets() do the revision check so that the
> callers don't even have worry about it.
>
> Cc: Jean Delvare
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_edid.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 82a4ceed3fcf..7b3072fc550b 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3690,6 +3690,9 @@ cea_revision(const u8 *cea)
> static int
> cea_db_offsets(const u8 *cea, int *start, int *end)
> {
> + if (cea_revision(cea) < 3)
> + return -ENOTSUPP;
> +
> /* DisplayID CTA extension blocks and top-level CEA EDID
>* block header definitions differ in the following bytes:
>* 1) Byte 2 of the header specifies length differently,
Reviewed-by: Jean Delvare
I like it, but then we need a subsequent patch to remove the now
redundant checks in add_cea_modes(), drm_edid_to_eld(),
drm_edid_to_sad() and drm_edid_to_speaker_allocation().
These last 2 functions are the ones my own patch modifies, so some care
is needed. If cea_db_offsets() now returns an error when CEA revisions
< 3, then these functions want to return 0 in that case (otherwise you
effectively undo the change I proposed).
By the way, both functions issue a debug message "SAD: invalid data
block offsets" when cea_db_offsets() returns an error, which becomes
misleading after your change. I think we want to move this message
inside cea_db_offsets() and only print it in the -ERANGE case.
--
Jean Delvare
SUSE L3 Support
___
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: Do not add all planes when checking scalers on glk+
On Wed, Aug 21, 2019 at 03:32:19PM +0200, Maarten Lankhorst wrote:
> We cannot switch between HQ and normal mode on GLK+, so only
> add planes on platforms where it makes sense.
>
> We could probably restrict it even more to only add when scaler
> users toggles between 1 and 2, but lets just leave it for now.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/display/intel_atomic.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
> b/drivers/gpu/drm/i915/display/intel_atomic.c
> index d267dd39475d..c442e9762ce7 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> @@ -418,6 +418,11 @@ int intel_atomic_setup_scalers(struct drm_i915_private
> *dev_priv,
>*/
> if (!plane) {
> struct drm_plane_state *state;
> +
> + /* No need to reprogram, we're not changing
> scaling mode */
> + if (INTEL_GEN(dev_priv) >= 10 ||
> IS_GEMINILAKE(dev_priv))
> + continue;
> +
This whole function is kinda nasty. Should probably
rewrite the whole thing...
add_active_planes() {
for_each_plane_on_crtc() {
if (!active)
continue;
get_plane_state();
update_planes |= plane;
}
}
update_scalers()
{
if (can_use_hq(old) != can_use_hq(new))
add_active_planes();
setup_scaler(crtc);
for_each_plane_in_state()
setup_scaler(plane);
}
or something like that?
Still doing the setup_scaler() perhaps a bit needlessly sometimes
but maybe it'd be good enough.
Also looks like the current code is missing the update_planes
bitmask update?
> plane = drm_plane_from_index(&dev_priv->drm, i);
> state = drm_atomic_get_plane_state(drm_state,
> plane);
> if (IS_ERR(state)) {
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/edid: Have cea_db_offsets() zero start/end when the data block collection isn't found
Hi Ville,
On Mon, 2 Sep 2019 16:15:46 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Let's make cea_db_offsets() a bit more convenient to use by
> setting the start/end offsets to zero whenever the data block
> collection isn't present. This makes it safe for the caller
> to blindly iterate the data blocks even if there are none.
>
> Cc: Jean Delvare
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_edid.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 7b3072fc550b..e5905dc764c1 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3690,6 +3690,9 @@ cea_revision(const u8 *cea)
> static int
> cea_db_offsets(const u8 *cea, int *start, int *end)
> {
> + *start = 0;
> + *end = 0;
> +
> if (cea_revision(cea) < 3)
> return -ENOTSUPP;
>
> @@ -4116,10 +4119,7 @@ static void drm_edid_to_eld(struct drm_connector
> *connector, struct edid *edid)
> if (cea_revision(cea) >= 3) {
> int i, start, end;
>
> - if (cea_db_offsets(cea, &start, &end)) {
> - start = 0;
> - end = 0;
> - }
> + cea_db_offsets(cea, &start, &end);
>
> for_each_cea_db(cea, i, start, end) {
> db = &cea[i];
Not sure if that's really needed. As it stands there's only one
function which wants to continue after cea_db_offsets() fails, all
others just bail out at that point. Now that cea_db_offsets() checks
for revision >= 3, the construct above could simply become:
int i, start, end;
if (cea_db_offsets(cea, &start, &end) == 0) {
for_each_cea_db(cea, i, start, end) {
db = &cea[i];
which is IMHO more elegant and does not require zeroing start and end
in cea_db_offsets().
--
Jean Delvare
SUSE L3 Support
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/edid: Have cea_db_offsets() zero start/end when the data block collection isn't found
On Tue, Sep 10, 2019 at 11:46:20AM +0200, Jean Delvare wrote:
> Hi Ville,
>
> On Mon, 2 Sep 2019 16:15:46 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Let's make cea_db_offsets() a bit more convenient to use by
> > setting the start/end offsets to zero whenever the data block
> > collection isn't present. This makes it safe for the caller
> > to blindly iterate the data blocks even if there are none.
> >
> > Cc: Jean Delvare
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/drm_edid.c | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index 7b3072fc550b..e5905dc764c1 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -3690,6 +3690,9 @@ cea_revision(const u8 *cea)
> > static int
> > cea_db_offsets(const u8 *cea, int *start, int *end)
> > {
> > + *start = 0;
> > + *end = 0;
> > +
> > if (cea_revision(cea) < 3)
> > return -ENOTSUPP;
> >
> > @@ -4116,10 +4119,7 @@ static void drm_edid_to_eld(struct drm_connector
> > *connector, struct edid *edid)
> > if (cea_revision(cea) >= 3) {
> > int i, start, end;
> >
> > - if (cea_db_offsets(cea, &start, &end)) {
> > - start = 0;
> > - end = 0;
> > - }
> > + cea_db_offsets(cea, &start, &end);
> >
> > for_each_cea_db(cea, i, start, end) {
> > db = &cea[i];
>
> Not sure if that's really needed. As it stands there's only one
> function which wants to continue after cea_db_offsets() fails, all
> others just bail out at that point. Now that cea_db_offsets() checks
> for revision >= 3, the construct above could simply become:
>
> int i, start, end;
>
> if (cea_db_offsets(cea, &start, &end) == 0) {
> for_each_cea_db(cea, i, start, end) {
> db = &cea[i];
>
> which is IMHO more elegant and does not require zeroing start and end
> in cea_db_offsets().
I dislike indentation. Also could perhaps even move the cea_db_offsets()
into the for_each_cea_db() macro so that the caller doesn't have to care
about these mundane details at all.
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/uc: Update MAKE_HUC_FW_PATH macro
On Mon, 09 Sep 2019 21:28:00 +0200, Anusha Srivatsa wrote: Update MAKE_HUC_FW_PATH macro to follow the same convention as the MAKE_GUC_FW_PATH with the separator changing from "_" to "." and removing "ver". above commit message (and patch title) is little misleading as updating a macro is secondary compared to introduced new firmware naming convention The current convention being: _uc_..patch.bin Update the versions of huc being loaded of the platforms. s/huc/HuC SKL - v2.0.0 BXT - v2.0.0 KBL - v4.0.0 GLK - v4.0.0 CFL - KBL v4.0.0 ICL - v9.0.0 CML - v4.0.0 v2: Remove the separator parameter altogether from __MAKE_UC_FW_PATH.(Daniele) - Squash all firmware update patches (Daniele) Suggested-by: Daniele Ceraolo Spurio Signed-off-by: Anusha Srivatsa --- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 25 1 file changed, 13 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c index 296a82603be0..da4bf24368bd 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c @@ -40,25 +40,26 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw, */ #define INTEL_UC_FIRMWARE_DEFS(fw_def, guc_def, huc_def) \ fw_def(ELKHARTLAKE, 0, guc_def(ehl, 33, 0, 4), huc_def(ehl, 9, 0, 0)) \ - fw_def(ICELAKE, 0, guc_def(icl, 33, 0, 0), huc_def(icl, 8, 4, 3238)) \ - fw_def(COFFEELAKE, 0, guc_def(kbl, 33, 0, 0), huc_def(kbl, 02, 00, 1810)) \ - fw_def(GEMINILAKE, 0, guc_def(glk, 33, 0, 0), huc_def(glk, 03, 01, 2893)) \ - fw_def(KABYLAKE,0, guc_def(kbl, 33, 0, 0), huc_def(kbl, 02, 00, 1810)) \ - fw_def(BROXTON, 0, guc_def(bxt, 33, 0, 0), huc_def(bxt, 01, 8, 2893)) \ - fw_def(SKYLAKE, 0, guc_def(skl, 33, 0, 0), huc_def(skl, 01, 07, 1398)) - -#define __MAKE_UC_FW_PATH(prefix_, name_, separator_, major_, minor_, patch_) \ + fw_def(COFFEELAKE, 0, guc_def(cml, 33, 0, 0), huc_def(cml, 4, 0, 0)) \ this is wrong, CML is CFL rev 5, for reference see [1] and macro ordering is also wrong (already detected by our code, yeah!): <3> [321.487555] invalid FW blob order: COFFEELAKE r0 comes before ICELAKE r0 and this wrong ordering leads to: <7> [321.487616] i915 :00:02.0: [drm:intel_uc_init_early [i915]] enable_guc=2 (guc:no submission:no huc:no) <6> [321.487618] i915 :00:02.0: Incompatible option enable_guc=2 - GuC is not supported! <6> [321.487620] i915 :00:02.0: Incompatible option enable_guc=2 - HuC is not supported! see [2] for details [1] https://patchwork.freedesktop.org/patch/319864/?series=62969&rev=5 [2] https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14333/fi-cml-u2/igt@i915_module_l...@reload-with-fault-injection.html + fw_def(ICELAKE, 0, guc_def(icl, 33, 0, 0), huc_def(icl, 9, 0, 0)) \ + fw_def(COFFEELAKE, 0, guc_def(kbl, 33, 0, 0), huc_def(kbl, 4, 0, 0)) \ + fw_def(GEMINILAKE, 0, guc_def(glk, 33, 0, 0), huc_def(glk, 4, 0, 0)) \ + fw_def(KABYLAKE,0, guc_def(kbl, 33, 0, 0), huc_def(kbl, 4, 0, 0)) \ + fw_def(BROXTON, 0, guc_def(bxt, 33, 0, 0), huc_def(bxt, 2, 0, 0)) \ + fw_def(SKYLAKE, 0, guc_def(skl, 33, 0, 0), huc_def(skl, 2, 0, 0)) + +#define __MAKE_UC_FW_PATH(prefix_, name_, major_, minor_, patch_) \ "i915/" \ __stringify(prefix_) name_ \ - __stringify(major_) separator_ \ - __stringify(minor_) separator_ \ + __stringify(major_) "." \ + __stringify(minor_) "." \ __stringify(patch_) ".bin" #define MAKE_GUC_FW_PATH(prefix_, major_, minor_, patch_) \ - __MAKE_UC_FW_PATH(prefix_, "_guc_", ".", major_, minor_, patch_) + __MAKE_UC_FW_PATH(prefix_, "_guc_", major_, minor_, patch_) #define MAKE_HUC_FW_PATH(prefix_, major_, minor_, bld_num_) \ - __MAKE_UC_FW_PATH(prefix_, "_huc_ver", "_", major_, minor_, bld_num_) + __MAKE_UC_FW_PATH(prefix_, "_huc_", major_, minor_, bld_num_) /* All blobs need to be declared via MODULE_FIRMWARE() */ #define INTEL_UC_MODULE_FW(platform_, revid_, guc_, huc_) \ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/execlists: Clear STOP_RING bit on reset
Chris Wilson writes: > Quoting Mika Kuoppala (2019-09-10 10:31:05) >> Chris Wilson writes: >> >> > During reset, we try to ensure no forward progress of the CS prior to >> > the reset by setting the STOP_RING bit in RING_MI_MODE. Since gen9, this >> > register is context saved and do we end up in the odd situation where we >> > save the STOP_RING bit and so try to stop the engine again immediately >> > upon resume. This is quite unexpected and causes us to complain about an >> > early CS completion event! >> >> The completion event is a product of resume with a stop set? > > A completion event is the product of STOP_RING. Whether it is the > completion event that we keep failing on... > >> If my memory serves me well, we have fought this before. > > Exactly. We've reduced the frequency of when we apply the STOP_RING, but > have not eliminated it. > >> But I have still missing pieces. Why would we not want to >> set this for all contexts primed for execution? In gen8 too. > > It's not in the gen8 context, afaict. I searched the context image for an > LRI with the RING_MI_MODE register: > https://patchwork.freedesktop.org/patch/329919/?series=66468&rev=1 > >> I mean, queuing context with a ring stopped just doesn't >> sound right on any gen. > > We clear the STOP_RING in the register on resume just in case, and that > is being flagged on Icelake (which I put down to the reset not being very > thorough!). The remaining question was whether we were restoring it from > the context image. Hmm yeah, I was confused of the sequence of setup. With that cleared and with the context state being worked on, perhaps we can add sanity checkers to the queuing path. Reviewed-by: Mika Kuoppala ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 6/7] drm/i915/tgl: switch between dc3co and dc5 based on display idleness
On 2019-09-08 at 20:55:17 +0300, Imre Deak wrote: Hi Imre , Thanks for review, could you please provide your response on below comments. > On Sat, Sep 07, 2019 at 10:44:42PM +0530, Anshuman Gupta wrote: > > DC3CO is useful power state, when DMC detects PSR2 idle frame > > while an active video playback, playing 30fps video on 60hz panel > > is the classic example of this use case. > > DC5 and DC6 saves more power, but can't be entered during video > > playback because there are not enough idle frames in a row to meet > > most PSR2 panel deep sleep entry requirement typically 4 frames. > > Please also explain why DC3co will be enabled only for flips but not for > other frontbuffer flush events (ORIGIN_CS/DIRTYFB etc.) and that we > could enable it for those too by switching to manual PSR tracking and > programming only 1 idle frame for deep sleep (see below). > > Also explaining that the frontbuffer invalidate event doesn't need to be > acted on (b/c of PSR exit) would be helpful. > > > > > It will be worthy to enable DC3CO after completion of each flip > > and switch back to DC5 when display is idle, as driver doesn't > > differentiate between video playback and a normal flip. > > It is safer to allow DC5 after 6 idle frame, as PSR2 requires > > minimum 6 idle frame. > > It would be clearer to say here that after a flip we enable DC3co, after > which we wait manually 6 frames (by scheduling the idle frame work) at > which point we enable PSR deep sleep with 6 idle frames. After this 6 > idle frames the HW will enter deep sleep and DC5 will be entered > after this by DMC at some point. > > The claim that we _have_ to make the HW wait for 6 idle frames before it > enters deep sleep doesn't make much sense to me, would be good to see a > reference to that if it really exists. That setting seems to only serve > the purpose to avoid update lags, but in the future (as discussed with > Ville) we should switch to manual PSR tracking and for that we would > program the HW to wait only 1 idle frame before entering deep sleep and > rely only on the manual 6 idle frame wait (via the idle frame work) to > avoid update lags. > > > > > v2: calculated s/w state to switch over dc3co when there is an > > update. [Imre] > > used cancel_delayed_work_sync() in order to avoid any race > > with already scheduled delayed work. [Imre] > > v3: cancel_delayed_work_sync() may blocked the commit work. > > Hence dropping it, dc5_idle_thread() checks the valid wakeref before > > putting the reference count, which avoids any chances of dropping > > a zero wakeref. [Imre (IRC)] > > v4: use frontbuffer flush mechanism. [Imre] > > > > Cc: Jani Nikula > > Cc: Imre Deak > > Cc: Animesh Manna > > Signed-off-by: Anshuman Gupta > > --- > > drivers/gpu/drm/i915/display/intel_display.c | 2 + > > .../drm/i915/display/intel_display_power.c| 79 +++ > > .../drm/i915/display/intel_display_power.h| 6 ++ > > .../gpu/drm/i915/display/intel_frontbuffer.c | 1 + > > drivers/gpu/drm/i915/i915_drv.h | 1 + > > 5 files changed, 89 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c > > b/drivers/gpu/drm/i915/display/intel_display.c > > index 84488f87d058..2754e8ee693f 100644 > > --- a/drivers/gpu/drm/i915/display/intel_display.c > > +++ b/drivers/gpu/drm/i915/display/intel_display.c > > @@ -16206,6 +16206,7 @@ int intel_modeset_init(struct drm_device *dev) > > init_llist_head(&dev_priv->atomic_helper.free_list); > > INIT_WORK(&dev_priv->atomic_helper.free_work, > > intel_atomic_helper_free_state_worker); > > + INIT_DELAYED_WORK(&dev_priv->csr.idle_work, tgl_dc5_idle_thread); > > > > intel_init_quirks(dev_priv); > > > > @@ -17147,6 +17148,7 @@ void intel_modeset_driver_remove(struct drm_device > > *dev) > > flush_workqueue(dev_priv->modeset_wq); > > > > flush_work(&dev_priv->atomic_helper.free_work); > > + flush_delayed_work(&dev_priv->csr.idle_work); > > This is racy as the work could be still running, but also would leave a > few other places with the work running like suspend, so let's just make > sure that it's not running any more after encoder disabling. > > > WARN_ON(!llist_empty(&dev_priv->atomic_helper.free_list)); > > > > /* > > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c > > b/drivers/gpu/drm/i915/display/intel_display_power.c > > index ecce118b5b0e..c110f04c9733 100644 > > --- a/drivers/gpu/drm/i915/display/intel_display_power.c > > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c > > @@ -20,6 +20,7 @@ > > #include "intel_sideband.h" > > #include "intel_tc.h" > > #include "intel_pm.h" > > +#include "intel_psr.h" > > > > bool intel_display_power_well_is_enabled(struct drm_i915_private *dev_priv, > > enum i915_power_well_id power_well_id); > > @@ -773,6 +774,27 @@ static void gen9_set_dc_state(struct drm_i915_pr
Re: [Intel-gfx] [PATCH] drm/i915/execlists: Clear STOP_RING bit on reset
Quoting Mika Kuoppala (2019-09-10 10:54:43) > Chris Wilson writes: > > > Quoting Mika Kuoppala (2019-09-10 10:31:05) > >> Chris Wilson writes: > >> > >> > During reset, we try to ensure no forward progress of the CS prior to > >> > the reset by setting the STOP_RING bit in RING_MI_MODE. Since gen9, this > >> > register is context saved and do we end up in the odd situation where we > >> > save the STOP_RING bit and so try to stop the engine again immediately > >> > upon resume. This is quite unexpected and causes us to complain about an > >> > early CS completion event! > >> > >> The completion event is a product of resume with a stop set? > > > > A completion event is the product of STOP_RING. Whether it is the > > completion event that we keep failing on... > > > >> If my memory serves me well, we have fought this before. > > > > Exactly. We've reduced the frequency of when we apply the STOP_RING, but > > have not eliminated it. > > > >> But I have still missing pieces. Why would we not want to > >> set this for all contexts primed for execution? In gen8 too. > > > > It's not in the gen8 context, afaict. I searched the context image for an > > LRI with the RING_MI_MODE register: > > https://patchwork.freedesktop.org/patch/329919/?series=66468&rev=1 > > > >> I mean, queuing context with a ring stopped just doesn't > >> sound right on any gen. > > > > We clear the STOP_RING in the register on resume just in case, and that > > is being flagged on Icelake (which I put down to the reset not being very > > thorough!). The remaining question was whether we were restoring it from > > the context image. > > Hmm yeah, I was confused of the sequence of setup. With that cleared > and with the context state being worked on, perhaps we can add > sanity checkers to the queuing path. Yeah, I think there's definitely some fun we can have here. At the very least a check that CTX_RING_START == ring->start would be a good sanitycheck. > Reviewed-by: Mika Kuoppala As always, the only way to be sure if this changes the mtbf is to let is soak. One day I may be able to run my own extended testing on icl! -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm: two planes with the same zpos have undefined ordering
Currently the property docs don't specify whether it's okay for two planes to have the same zpos value and what user-space should expect in this case. The rule mentionned in the past was to disambiguate with object IDs. However some drivers break this rule (that's why the ordering is documented as unspecified in case the zpos property is missing). Additionally it doesn't really make sense for a driver to user identical zpos values if it knows their relative position: the driver can just pick different values instead. So two solutions would make sense: either disallow completely identical zpos values for two different planes, either make the ordering unspecified. To allow drivers that don't know the relative ordering between two planes to still expose the zpos property, choose the latter solution. Signed-off-by: Simon Ser --- drivers/gpu/drm/drm_blend.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c index d02709dd2d4a..51bd5454e50a 100644 --- a/drivers/gpu/drm/drm_blend.c +++ b/drivers/gpu/drm/drm_blend.c @@ -132,10 +132,10 @@ * planes. Without this property the primary plane is always below the cursor * plane, and ordering between all other planes is undefined. The positive * Z axis points towards the user, i.e. planes with lower Z position values - * are underneath planes with higher Z position values. Note that the Z - * position value can also be immutable, to inform userspace about the - * hard-coded stacking of overlay planes, see - * drm_plane_create_zpos_immutable_property(). + * are underneath planes with higher Z position values. Two planes with the + * same Z position value have undefined ordering. Note that the Z position + * value can also be immutable, to inform userspace about the hard-coded + * stacking of overlay planes, see drm_plane_create_zpos_immutable_property(). * * pixel blend mode: * Pixel blend mode is set up with drm_plane_create_blend_mode_property(). -- 2.23.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/edid: Have cea_db_offsets() zero start/end when the data block collection isn't found
On Tue, 10 Sep 2019 12:48:42 +0300, Ville Syrjälä wrote:
> On Tue, Sep 10, 2019 at 11:46:20AM +0200, Jean Delvare wrote:
> > Hi Ville,
> >
> > On Mon, 2 Sep 2019 16:15:46 +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Let's make cea_db_offsets() a bit more convenient to use by
> > > setting the start/end offsets to zero whenever the data block
> > > collection isn't present. This makes it safe for the caller
> > > to blindly iterate the data blocks even if there are none.
> > >
> > > Cc: Jean Delvare
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/drm_edid.c | 8
> > > 1 file changed, 4 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > > index 7b3072fc550b..e5905dc764c1 100644
> > > --- a/drivers/gpu/drm/drm_edid.c
> > > +++ b/drivers/gpu/drm/drm_edid.c
> > > @@ -3690,6 +3690,9 @@ cea_revision(const u8 *cea)
> > > static int
> > > cea_db_offsets(const u8 *cea, int *start, int *end)
> > > {
> > > + *start = 0;
> > > + *end = 0;
> > > +
> > > if (cea_revision(cea) < 3)
> > > return -ENOTSUPP;
> > >
> > > @@ -4116,10 +4119,7 @@ static void drm_edid_to_eld(struct drm_connector
> > > *connector, struct edid *edid)
> > > if (cea_revision(cea) >= 3) {
> > > int i, start, end;
> > >
> > > - if (cea_db_offsets(cea, &start, &end)) {
> > > - start = 0;
> > > - end = 0;
> > > - }
> > > + cea_db_offsets(cea, &start, &end);
> > >
> > > for_each_cea_db(cea, i, start, end) {
> > > db = &cea[i];
> >
> > Not sure if that's really needed. As it stands there's only one
> > function which wants to continue after cea_db_offsets() fails, all
> > others just bail out at that point. Now that cea_db_offsets() checks
> > for revision >= 3, the construct above could simply become:
> >
> > int i, start, end;
> >
> > if (cea_db_offsets(cea, &start, &end) == 0) {
> > for_each_cea_db(cea, i, start, end) {
> > db = &cea[i];
> >
> > which is IMHO more elegant and does not require zeroing start and end
> > in cea_db_offsets().
>
> I dislike indentation.
It would be the same as currently, so it's not that bad. But well I'm
not maintaining that piece of code so it's not my call anyway.
> Also could perhaps even move the cea_db_offsets()
> into the for_each_cea_db() macro so that the caller doesn't have to care
> about these mundane details at all.
If the macro stays readable, why not.
--
Jean Delvare
SUSE L3 Support
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/execlists: Ignore lost completion events
Chris Wilson writes:
> Icelake hit an issue where it missed reporting a completion event and
> instead jumped straight to a idle->active event (skipping over the
> active->idle and not even hitting the lite-restore preemption).
>
> 661497511us : process_csb: rcs0 cs-irq head=11, tail=0
> 661497512us : process_csb: rcs0 csb[0]: status=0x10008002:0x0020
> [lite-restore]
> 661497512us : trace_ports: rcs0: preempted { 28cc8:11052, 0:0 }
> 661497513us : trace_ports: rcs0: promote { 28cc8:11054, 0:0 }
> 661497514us : __i915_request_submit: rcs0 fence 28cc8:11056, current 11052
> 661497514us : __execlists_submission_tasklet: rcs0:
> queue_priority_hint:-2147483648, submit:yes
> 661497515us : trace_ports: rcs0: submit { 28cc8:11056, 0:0 }
> 661497530us : process_csb: rcs0 cs-irq head=0, tail=1
> 661497530us : process_csb: rcs0 csb[1]: status=0x10008002:0x0020
> [lite-restore]
> 661497531us : trace_ports: rcs0: preempted { 28cc8:11054!, 0:0 }
> 661497535us : trace_ports: rcs0: promote { 28cc8:11056, 0:0 }
> 661497540us : __i915_request_submit: rcs0 fence 28cc8:11058, current 11054
> 661497544us : __execlists_submission_tasklet: rcs0:
> queue_priority_hint:-2147483648, submit:yes
> 661497545us : trace_ports: rcs0: submit { 28cc8:11058, 0:0 }
> 661497553us : process_csb: rcs0 cs-irq head=1, tail=2
> 661497553us : process_csb: rcs0 csb[2]: status=0x1001:0x
> [idle->active]
> 661497574us : process_csb: process_csb:1538 GEM_BUG_ON(*execlists->active)
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
Trace is convincing, tho always it feels bit uneasy
for the hardware to change the behaviour 'suddenly'.
And state folds to a binary so othing much to argue against.
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 63 +
> 1 file changed, 18 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index 0ddfbebbcbbc..3aad35b570d4 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -693,6 +693,9 @@ trace_ports(const struct intel_engine_execlists
> *execlists,
> const struct intel_engine_cs *engine =
> container_of(execlists, typeof(*engine), execlists);
>
> + if (!ports[0])
> + return;
> +
> GEM_TRACE("%s: %s { %llx:%lld%s, %llx:%lld }\n",
> engine->name, msg,
> ports[0]->fence.context,
> @@ -1381,13 +1384,6 @@ reset_in_progress(const struct intel_engine_execlists
> *execlists)
> return unlikely(!__tasklet_is_enabled(&execlists->tasklet));
> }
>
> -enum csb_step {
> - CSB_NOP,
> - CSB_PROMOTE,
> - CSB_PREEMPT,
> - CSB_COMPLETE,
> -};
> -
> /*
> * Starting with Gen12, the status has a new format:
> *
> @@ -1414,7 +1410,7 @@ enum csb_step {
> * bits 47-57: sw context id of the lrc the GT switched away from
> * bits 58-63: sw counter of the lrc the GT switched away from
> */
> -static inline enum csb_step
> +static inline bool
> gen12_csb_parse(const struct intel_engine_execlists *execlists, const u32
> *csb)
> {
> u32 lower_dw = csb[0];
> @@ -1424,7 +1420,7 @@ gen12_csb_parse(const struct intel_engine_execlists
> *execlists, const u32 *csb)
> bool new_queue = lower_dw & GEN12_CTX_STATUS_SWITCHED_TO_NEW_QUEUE;
>
> if (!ctx_away_valid && ctx_to_valid)
> - return CSB_PROMOTE;
> + return true;
>
> /*
>* The context switch detail is not guaranteed to be 5 when a preemption
> @@ -1434,7 +1430,7 @@ gen12_csb_parse(const struct intel_engine_execlists
> *execlists, const u32 *csb)
>* would require some extra handling, but we don't support that.
>*/
> if (new_queue && ctx_away_valid)
> - return CSB_PREEMPT;
> + return true;
>
> /*
>* switch detail = 5 is covered by the case above and we do not expect a
> @@ -1443,29 +1439,13 @@ gen12_csb_parse(const struct intel_engine_execlists
> *execlists, const u32 *csb)
>*/
> GEM_BUG_ON(GEN12_CTX_SWITCH_DETAIL(upper_dw));
>
> - if (*execlists->active) {
> - GEM_BUG_ON(!ctx_away_valid);
> - return CSB_COMPLETE;
> - }
> -
> - return CSB_NOP;
> + return false;
> }
>
> -static inline enum csb_step
> +static inline bool
> gen8_csb_parse(const struct intel_engine_execlists *execlists, const u32
> *csb)
> {
> - unsigned int status = *csb;
> -
> - if (status & GEN8_CTX_STATUS_IDLE_ACTIVE)
> - return CSB_PROMOTE;
> -
> - if (status & GEN8_CTX_STATUS_PREEMPTED)
> - return CSB_PREEMPT;
> -
> - if (*execlists->active)
> - return CSB_COMPLETE;
> -
> - return CSB_NOP;
> + return *csb & (GEN8_CTX_STATUS_IDLE_ACTIVE | GEN8_CTX_STATUS_PREEMPTED);
> }
>
> static void process_csb(struct intel_engine_cs *engine)
> @@ -1504,7 +1484,7 @@ static void
Re: [Intel-gfx] [v2][PATCH 0/3] adding gamma state checker for CHV and i965
On Mon, 09 Sep 2019, Swati Sharma wrote: > In this patch series, added state checker to validate gamma lut values > for cherryview and i965 platforms. It's extension of the > patch series https://patchwork.freedesktop.org/patch/328246/?series=58039 > which enabled the basic infrastructure and state checker for > few legacy platforms. > > v2: Added last index rgb lut value from PIPEGCMAX to h/w blob [Jani] Pushed, thanks for the patches. BR, Jani. > > Swati Sharma (3): > drm/i915/display: Add gamma precision function for CHV > drm/i915/display: Extract i965_read_luts() > drm/i915/display: Extract chv_read_luts() > > drivers/gpu/drm/i915/display/intel_color.c | 118 > +++-- > drivers/gpu/drm/i915/i915_reg.h| 7 ++ > 2 files changed, 119 insertions(+), 6 deletions(-) -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/ringbuffer: Flush writes before RING_TAIL update
Chris Wilson writes:
> Be paranoid and make sure we flush any and all writes out of the WCB
> before performing the UC mmio to update the RING_TAIL. (An UC write
> should itself be enough to do the flush, hence the paranoia here.) Quite
> infrequently, we see problems where the GPU seems to overshoot the
> RING_TAIL and so executes garbage hence the speculation.
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=111598
> References: https://bugs.freedesktop.org/show_bug.cgi?id=111417
> References: https://bugs.freedesktop.org/show_bug.cgi?id=111034
> Signed-off-by: Chris Wilson
It could be even that the cost is ameliorated with the uc write,
if the hw is clever enough. Regardless, we gain a datapoint
with marginal cost.
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_ringbuffer.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_ringbuffer.c
> b/drivers/gpu/drm/i915/gt/intel_ringbuffer.c
> index bbda85dcaa42..73c3ffc80218 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ringbuffer.c
> @@ -930,6 +930,7 @@ static void cancel_requests(struct intel_engine_cs
> *engine)
> static void i9xx_submit_request(struct i915_request *request)
> {
> i915_request_submit(request);
> + wmb(); /* paranoid flush writes out of the WCB before mmio */
>
> ENGINE_WRITE(request->engine, RING_TAIL,
>intel_ring_set_tail(request->ring, request->tail));
> --
> 2.23.0
>
> ___
> 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 3/6] drm/i915: Perform GGTT restore much earlier during resume
Chris Wilson writes:
> As soon as we re-enable the various functions within the HW, they may go
> off and read data via a GGTT offset. Hence, if we have not yet restored
> the GGTT PTE before then, they may read and even *write* random locations
> in memory.
>
> Detected by DMAR faults during resume.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Martin Peres
> Cc: Joonas Lahtinen
> Cc: sta...@vger.kernel.org
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gem/i915_gem_pm.c| 3 ---
> drivers/gpu/drm/i915/i915_drv.c | 5 +
> drivers/gpu/drm/i915/selftests/i915_gem.c | 6 ++
> 3 files changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> index b3993d24b83d..9b1129aaacfe 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> @@ -242,9 +242,6 @@ void i915_gem_resume(struct drm_i915_private *i915)
> mutex_lock(&i915->drm.struct_mutex);
> intel_uncore_forcewake_get(&i915->uncore, FORCEWAKE_ALL);
>
> - i915_gem_restore_gtt_mappings(i915);
> - i915_gem_restore_fences(i915);
> -
> if (i915_gem_init_hw(i915))
> goto err_wedged;
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 7b2c81a8bbaa..1af4eba968c0 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1877,6 +1877,11 @@ static int i915_drm_resume(struct drm_device *dev)
> if (ret)
> DRM_ERROR("failed to re-enable GGTT\n");
>
> + mutex_lock(&dev_priv->drm.struct_mutex);
> + i915_gem_restore_gtt_mappings(dev_priv);
> + i915_gem_restore_fences(dev_priv);
> + mutex_unlock(&dev_priv->drm.struct_mutex);
> +
> intel_csr_ucode_resume(dev_priv);
>
> i915_restore_state(dev_priv);
> diff --git a/drivers/gpu/drm/i915/selftests/i915_gem.c
> b/drivers/gpu/drm/i915/selftests/i915_gem.c
> index bb6dd54a6ff3..37593831b539 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_gem.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_gem.c
> @@ -118,6 +118,12 @@ static void pm_resume(struct drm_i915_private *i915)
> with_intel_runtime_pm(&i915->runtime_pm, wakeref) {
> intel_gt_sanitize(&i915->gt, false);
> i915_gem_sanitize(i915);
> +
> + mutex_lock(&i915->drm.struct_mutex);
> + i915_gem_restore_gtt_mappings(i915);
> + i915_gem_restore_fences(i915);
> + mutex_unlock(&i915->drm.struct_mutex);
> +
> i915_gem_resume(i915);
> }
> }
> --
> 2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/6] iommu/intel: Declare Broadwell igfx dmar support snafu
Chris Wilson writes:
> Despite the widespread and complete failure of Broadwell integrated
> graphics when DMAR is enabled, known over the years, we have never been
> able to root cause the issue. Instead, we let the failure undermine our
> confidence in the iommu system itself when we should be pushing for it to
> be always enabled. Quirk away Broadwell and remove the rotten apple.
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=89360
> Signed-off-by: Chris Wilson
> Cc: Lu Baolu
> Cc: Martin Peres
> Cc: Joerg Roedel
As a first hand witness,
Acked-by: Mika Kuoppala
> ---
> drivers/iommu/intel-iommu.c | 44 +
> 1 file changed, 35 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> index c4e0e4a9ee9e..34f6a3d93ae2 100644
> --- a/drivers/iommu/intel-iommu.c
> +++ b/drivers/iommu/intel-iommu.c
> @@ -5690,20 +5690,46 @@ const struct iommu_ops intel_iommu_ops = {
> .pgsize_bitmap = INTEL_IOMMU_PGSIZES,
> };
>
> -static void quirk_iommu_g4x_gfx(struct pci_dev *dev)
> +static void quirk_iommu_igfx(struct pci_dev *dev)
> {
> - /* G4x/GM45 integrated gfx dmar support is totally busted. */
> pci_info(dev, "Disabling IOMMU for graphics on this chipset\n");
> dmar_map_gfx = 0;
> }
>
> -DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2a40, quirk_iommu_g4x_gfx);
> -DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e00, quirk_iommu_g4x_gfx);
> -DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e10, quirk_iommu_g4x_gfx);
> -DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e20, quirk_iommu_g4x_gfx);
> -DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e30, quirk_iommu_g4x_gfx);
> -DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e40, quirk_iommu_g4x_gfx);
> -DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e90, quirk_iommu_g4x_gfx);
> +/* G4x/GM45 integrated gfx dmar support is totally busted. */
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2a40, quirk_iommu_igfx);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e00, quirk_iommu_igfx);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e10, quirk_iommu_igfx);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e20, quirk_iommu_igfx);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e30, quirk_iommu_igfx);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e40, quirk_iommu_igfx);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e90, quirk_iommu_igfx);
> +
> +/* Broadwell igfx malfunctions with dmar */
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x1606, quirk_iommu_igfx);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x160B, quirk_iommu_igfx);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x160E, quirk_iommu_igfx);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x1602, quirk_iommu_igfx);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x160A, quirk_iommu_igfx);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x160D, quirk_iommu_igfx);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x1616, quirk_iommu_igfx);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x161B, quirk_iommu_igfx);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x161E, quirk_iommu_igfx);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x1612, quirk_iommu_igfx);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x161A, quirk_iommu_igfx);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x161D, quirk_iommu_igfx);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x1626, quirk_iommu_igfx);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x162B, quirk_iommu_igfx);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x162E, quirk_iommu_igfx);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x1622, quirk_iommu_igfx);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x162A, quirk_iommu_igfx);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x162D, quirk_iommu_igfx);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x1636, quirk_iommu_igfx);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x163B, quirk_iommu_igfx);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x163E, quirk_iommu_igfx);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x1632, quirk_iommu_igfx);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x163A, quirk_iommu_igfx);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x163D, quirk_iommu_igfx);
>
> static void quirk_iommu_rwbf(struct pci_dev *dev)
> {
> --
> 2.23.0
>
> ___
> 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] [v2][PATCH 0/3] adding gamma state checker for CHV and i965
On 10-Sep-19 3:57 PM, Jani Nikula wrote: On Mon, 09 Sep 2019, Swati Sharma wrote: In this patch series, added state checker to validate gamma lut values for cherryview and i965 platforms. It's extension of the patch series https://patchwork.freedesktop.org/patch/328246/?series=58039 which enabled the basic infrastructure and state checker for few legacy platforms. v2: Added last index rgb lut value from PIPEGCMAX to h/w blob [Jani] Pushed, thanks for the patches. Thanks Jani! BR, Jani. Swati Sharma (3): drm/i915/display: Add gamma precision function for CHV drm/i915/display: Extract i965_read_luts() drm/i915/display: Extract chv_read_luts() drivers/gpu/drm/i915/display/intel_color.c | 118 +++-- drivers/gpu/drm/i915/i915_reg.h| 7 ++ 2 files changed, 119 insertions(+), 6 deletions(-) -- ~Swati Sharma ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/6] drm/i915/selftests: Take runtime wakeref for igt_ggtt_lowlevel
On Mon, 9 Sep 2019 at 12:00, Chris Wilson wrote: > > Being a "low-level" test, we opt to bypass the normal bind/unbind hooks > for the lower level insert_entries/clear_range. For ggtt, the > bind/unbind hooks provide the runtime wakeref and so we must also handle > this in exercising the low level hooks. > > <4> [538.151672] RPM raw-wakeref not held > <4> [538.151825] WARNING: CPU: 0 PID: 11 at > ./drivers/gpu/drm/i915/intel_runtime_pm.h:107 fwtable_read32+0x1be/0x300 > [i915] > <4> [538.151830] Modules linked in: i915(+) amdgpu gpu_sched ttm vgem > snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic mei_hdcp btusb > btrtl btbcm x86_pkg_temp_thermal coretemp btintel crct10dif_pclmul bluetooth > crc32_pclmul snd_intel_nhlt snd_hda_codec ecdh_generic ghash_clmulni_intel > ecc snd_hwdep snd_hda_core lpc_ich r8169 realtek snd_pcm mei_me mei > prime_numbers pinctrl_broxton pinctrl_intel [last unloaded: i915] > <4> [538.151861] CPU: 0 PID: 11 Comm: migration/0 Tainted: G U > 5.3.0-rc7-CI-Trybot_4938+ #1 > <4> [538.151864] Hardware name: Intel corporation NUC6CAYS/NUC6CAYB, BIOS > AYAPLCEL.86A.0056.2018.0926.1100 09/26/2018 > <4> [538.151960] RIP: 0010:fwtable_read32+0x1be/0x300 [i915] > <4> [538.151965] Code: e8 e7 f9 5f e0 e9 0b ff ff ff 80 3d d5 8d 26 00 00 0f > 85 81 fe ff ff 48 c7 c7 ef 01 bd a0 c6 05 c1 8d 26 00 01 e8 b2 e4 6a e0 <0f> > 0b e9 67 fe ff ff 80 3d ad 8d 26 00 00 0f 85 65 fe ff ff 48 c7 > <4> [538.151969] RSP: 0018:c907be10 EFLAGS: 00010086 > <4> [538.151972] RAX: RBX: 88826be10d50 RCX: > 0002 > <4> [538.151975] RDX: 8002 RSI: RDI: > > <4> [538.151978] RBP: R08: R09: > > <4> [538.151981] R10: R11: c907bcb0 R12: > 00101008 > <4> [538.151984] R13: R14: c936f638 R15: > 0002 > <4> [538.151987] FS: () GS:888277a0() > knlGS: > <4> [538.151990] CS: 0010 DS: ES: CR0: 80050033 > <4> [538.151993] CR2: 7fd48e7052f8 CR3: 0521 CR4: > 003406f0 > <4> [538.151995] Call Trace: > <4> [538.152106] bxt_vtd_ggtt_clear_range__cb+0x38/0x40 [i915] > > Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/tgl: Keep forcewake always for now
Forcewake handling is a prime suspect now. Keep ref always on tgl to test the theory and reveal the coverage. Testcase: igt/gem_sync Cc: Chris Wilson Suggested-by: Chris Wilson Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_gem.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 141024c66f36..2ab970b4d534 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -1144,7 +1144,10 @@ void i915_gem_sanitize(struct drm_i915_private *i915) */ intel_gt_sanitize(&i915->gt, false); - intel_uncore_forcewake_put(&i915->uncore, FORCEWAKE_ALL); + /* XXX Forcewake handling is a prime suspect now */ + if (INTEL_GEN(i915) < 12) + intel_uncore_forcewake_put(&i915->uncore, FORCEWAKE_ALL); + intel_runtime_pm_put(&i915->runtime_pm, wakeref); } -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm: two planes with the same zpos have undefined ordering
== Series Details == Series: drm: two planes with the same zpos have undefined ordering URL : https://patchwork.freedesktop.org/series/66480/ State : warning == Summary == $ dim checkpatch origin/drm-tip 7b8f1c2a9415 drm: two planes with the same zpos have undefined ordering -:6: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #6: Currently the property docs don't specify whether it's okay for two planes to total: 0 errors, 1 warnings, 0 checks, 14 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/selftests: Tighten the timeout testing for partial mmaps
Currently, if there is time remaining before the start of the loop, we
do one full iteration over many possible different chunks within the
object. A full loop may take 50+s (depending on speed of indirect GTT
mmapings) and we try separately with LINEAR, X and Y -- at which point
igt times out. If we check more frequently, we will interrupt the loop
upon our timeout -- it is hard to argue for as this significantly reduces
the test coverage as we dramatically reduce the runtime. In practical
terms, the coverage we should prioritise is in using different fence
setups, forcing verification of the tile row computations over the
current preference of checking extracting chunks. Though the exhaustive
search is great given an infinite timeout, to improve our current
coverage, we also add a randomised smoketest of partial mmaps. So let's
do both, add a randomised smoketest of partial tiling chunks and the
exhaustive (though time limited) search for failures.
Even in adding another subtest, we should shave 100s off BAT! (With,
hopefully, no loss in coverage, at least over multiple runs.)
Signed-off-by: Chris Wilson
Cc: Matthew Auld
---
.../drm/i915/gem/selftests/i915_gem_mman.c| 255 +++---
1 file changed, 223 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
index 1d27babff0ce..aefe557527f8 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
@@ -10,6 +10,7 @@
#include "gt/intel_gt_pm.h"
#include "huge_gem_object.h"
#include "i915_selftest.h"
+#include "selftests/i915_random.h"
#include "selftests/igt_flush_test.h"
struct tile {
@@ -76,18 +77,103 @@ static u64 tiled_offset(const struct tile *tile, u64 v)
static int check_partial_mapping(struct drm_i915_gem_object *obj,
const struct tile *tile,
-unsigned long end_time)
+struct rnd_state *prng)
{
- const unsigned int nreal = obj->scratch / PAGE_SIZE;
const unsigned long npages = obj->base.size / PAGE_SIZE;
+ struct i915_ggtt_view view;
struct i915_vma *vma;
unsigned long page;
+ u32 __iomem *io;
+ struct page *p;
+ unsigned int n;
+ u64 offset;
+ u32 *cpu;
int err;
- if (igt_timeout(end_time,
- "%s: timed out before tiling=%d stride=%d\n",
- __func__, tile->tiling, tile->stride))
- return -EINTR;
+ err = i915_gem_object_set_tiling(obj, tile->tiling, tile->stride);
+ if (err) {
+ pr_err("Failed to set tiling mode=%u, stride=%u, err=%d\n",
+ tile->tiling, tile->stride, err);
+ return err;
+ }
+
+ GEM_BUG_ON(i915_gem_object_get_tiling(obj) != tile->tiling);
+ GEM_BUG_ON(i915_gem_object_get_stride(obj) != tile->stride);
+
+ i915_gem_object_lock(obj);
+ err = i915_gem_object_set_to_gtt_domain(obj, true);
+ i915_gem_object_unlock(obj);
+ if (err) {
+ pr_err("Failed to flush to GTT write domain; err=%d\n", err);
+ return err;
+ }
+
+ page = i915_prandom_u32_max_state(npages, prng);
+ view = compute_partial_view(obj, page, MIN_CHUNK_PAGES);
+
+ vma = i915_gem_object_ggtt_pin(obj, &view, 0, 0, PIN_MAPPABLE);
+ if (IS_ERR(vma)) {
+ pr_err("Failed to pin partial view: offset=%lu; err=%d\n",
+ page, (int)PTR_ERR(vma));
+ return PTR_ERR(vma);
+ }
+
+ n = page - view.partial.offset;
+ GEM_BUG_ON(n >= view.partial.size);
+
+ io = i915_vma_pin_iomap(vma);
+ i915_vma_unpin(vma);
+ if (IS_ERR(io)) {
+ pr_err("Failed to iomap partial view: offset=%lu; err=%d\n",
+ page, (int)PTR_ERR(io));
+ err = PTR_ERR(io);
+ goto out;
+ }
+
+ iowrite32(page, io + n * PAGE_SIZE / sizeof(*io));
+ i915_vma_unpin_iomap(vma);
+
+ offset = tiled_offset(tile, page << PAGE_SHIFT);
+ if (offset >= obj->base.size)
+ goto out;
+
+ intel_gt_flush_ggtt_writes(&to_i915(obj->base.dev)->gt);
+
+ p = i915_gem_object_get_page(obj, offset >> PAGE_SHIFT);
+ cpu = kmap(p) + offset_in_page(offset);
+ drm_clflush_virt_range(cpu, sizeof(*cpu));
+ if (*cpu != (u32)page) {
+ pr_err("Partial view for %lu [%u] (offset=%llu, size=%u [%llu,
row size %u], fence=%d, tiling=%d, stride=%d) misalignment, expected write to
page (%llu + %u [0x%llx]) of 0x%x, found 0x%x\n",
+ page, n,
+ view.partial.offset,
+ view.partial.size,
+ vma->size >> PAGE_SHIFT,
+ tile->tiling ? tile_row_pages(obj) : 0,
+
[Intel-gfx] [PATCH] drm/i915: Use a high priority wq for nonblocking plane updates
From: Ville Syrjälä
system_unbound_wq can't keep up sometimes and we get dropped frames.
Switch to a high priority variant.
Reported-by: Heinrich Fink
Tested-by: Heinrich Fink
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 6 +-
drivers/gpu/drm/i915/i915_drv.h | 2 ++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 3b5275ab66cf..2668744007b3 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -14272,7 +14272,7 @@ static int intel_atomic_commit(struct drm_device *dev,
if (nonblock && state->modeset) {
queue_work(dev_priv->modeset_wq, &state->base.commit_work);
} else if (nonblock) {
- queue_work(system_unbound_wq, &state->base.commit_work);
+ queue_work(dev_priv->flip_wq, &state->base.commit_work);
} else {
if (state->modeset)
flush_workqueue(dev_priv->modeset_wq);
@@ -16181,6 +16181,8 @@ int intel_modeset_init(struct drm_device *dev)
int ret;
dev_priv->modeset_wq = alloc_ordered_workqueue("i915_modeset", 0);
+ dev_priv->flip_wq = alloc_workqueue("i915_flip", WQ_HIGHPRI |
+ WQ_UNBOUND, WQ_UNBOUND_MAX_ACTIVE);
drm_mode_config_init(dev);
@@ -17139,6 +17141,7 @@ void intel_modeset_driver_remove(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = to_i915(dev);
+ flush_workqueue(dev_priv->flip_wq);
flush_workqueue(dev_priv->modeset_wq);
flush_work(&dev_priv->atomic_helper.free_work);
@@ -17175,6 +17178,7 @@ void intel_modeset_driver_remove(struct drm_device *dev)
intel_gmbus_teardown(dev_priv);
+ destroy_workqueue(dev_priv->flip_wq);
destroy_workqueue(dev_priv->modeset_wq);
intel_fbc_cleanup_cfb(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e289b4ffd34b..d4177ca8ffc8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1434,6 +1434,8 @@ struct drm_i915_private {
/* ordered wq for modesets */
struct workqueue_struct *modeset_wq;
+ /* unbound hipri wq for page flips/plane updates */
+ struct workqueue_struct *flip_wq;
/* Display functions */
struct drm_i915_display_funcs display;
--
2.21.0
___
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: two planes with the same zpos have undefined ordering
== Series Details ==
Series: drm: two planes with the same zpos have undefined ordering
URL : https://patchwork.freedesktop.org/series/66480/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6860 -> Patchwork_14337
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/
Known issues
Here are the changes found in Patchwork_14337 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_reloc@basic-gtt-noreloc:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) +1
similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/fi-icl-u3/igt@gem_exec_re...@basic-gtt-noreloc.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/fi-icl-u3/igt@gem_exec_re...@basic-gtt-noreloc.html
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: [PASS][3] -> [INCOMPLETE][4] ([fdo#107718])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
* igt@i915_selftest@live_execlists:
- fi-skl-gvtdvm: [PASS][5] -> [DMESG-FAIL][6] ([fdo#08])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [PASS][7] -> [FAIL][8] ([fdo#111407])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
Possible fixes
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: [DMESG-WARN][9] ([fdo#102614]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
* igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- {fi-icl-dsi}: [DMESG-WARN][11] ([fdo#106107]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/fi-icl-dsi/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/fi-icl-dsi/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
* igt@prime_vgem@basic-fence-mmap:
- fi-icl-u3: [DMESG-WARN][13] ([fdo#107724]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/fi-icl-u3/igt@prime_v...@basic-fence-mmap.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/fi-icl-u3/igt@prime_v...@basic-fence-mmap.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#08]: https://bugs.freedesktop.org/show_bug.cgi?id=08
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
Participating hosts (53 -> 47)
--
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y
fi-byt-clapper
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6860 -> Patchwork_14337
CI-20190529: 20190529
CI_DRM_6860: 33c00059b084f42f01a168b5f67e4df670293e2c @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5177: 8f351d693352d21c96cef38c3fd77f778c6d7c33 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14337: 7b8f1c2a9415cd54c1eebbdf2cb50586ed0ccb6d @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
7b8f1c2a9415 drm: two planes with the same zpos have undefined ordering
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/8] drm/i915: Consolidate bxt/cnl/icl cdclk readout
On Fri, Sep 06, 2019 at 05:21:36PM -0700, Matt Roper wrote:
> Aside from a few minor register changes and some different clock values,
> cdclk design hasn't changed much since gen9lp. Let's consolidate the
> handlers for bxt, cnl, and icl to keep the codeflow consistent.
>
> Also, while we're at it, s/bxt_de_pll_update/bxt_de_pll_readout/ since
> "update" makes me think we should be writing to hardware rather than
> reading from it.
>
> Cc: Ville Syrjälä
> Suggested-by: Ville Syrjälä
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 325 +
> 1 file changed, 138 insertions(+), 187 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index d3e56628af70..e07de3b84cec 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -1190,6 +1190,36 @@ static u8 bxt_calc_voltage_level(int cdclk)
> return DIV_ROUND_UP(cdclk, 25000);
> }
>
> +static u8 cnl_calc_voltage_level(int cdclk)
> +{
> + if (cdclk > 336000)
> + return 2;
> + else if (cdclk > 168000)
> + return 1;
> + else
> + return 0;
> +}
> +
> +static u8 icl_calc_voltage_level(int cdclk)
> +{
> + if (cdclk > 556800)
> + return 2;
> + else if (cdclk > 326400)
Not the same numbers as the old function.
> + return 1;
> + else
> + return 0;
> +}
> +
> +static u8 ehl_calc_voltage_level(int cdclk)
> +{
> + if (cdclk > 326400)
> + return 2;
> + else if (cdclk > 18)
> + return 1;
> + else
> + return 0;
> +}
> +
> static int bxt_de_pll_vco(struct drm_i915_private *dev_priv, int cdclk)
> {
> int ratio;
> @@ -1236,23 +1266,69 @@ static int glk_de_pll_vco(struct drm_i915_private
> *dev_priv, int cdclk)
> return dev_priv->cdclk.hw.ref * ratio;
> }
>
> -static void bxt_de_pll_update(struct drm_i915_private *dev_priv,
> - struct intel_cdclk_state *cdclk_state)
> +static void cnl_readout_refclk(struct drm_i915_private *dev_priv,
> +struct intel_cdclk_state *cdclk_state)
> {
> - u32 val;
> + if (I915_READ(SKL_DSSM) & CNL_DSSM_CDCLK_PLL_REFCLK_24MHz)
> + cdclk_state->ref = 24000;
> + else
> + cdclk_state->ref = 19200;
> +}
>
> - cdclk_state->ref = 19200;
> - cdclk_state->vco = 0;
> +static void icl_readout_refclk(struct drm_i915_private *dev_priv,
> +struct intel_cdclk_state *cdclk_state)
> +{
> + u32 dssm = I915_READ(SKL_DSSM) & ICL_DSSM_CDCLK_PLL_REFCLK_MASK;
> +
> + switch (dssm) {
> + default:
> + MISSING_CASE(dssm);
> + /* fall through */
> + case ICL_DSSM_CDCLK_PLL_REFCLK_24MHz:
> + cdclk_state->ref = 24000;
> + break;
> + case ICL_DSSM_CDCLK_PLL_REFCLK_19_2MHz:
> + cdclk_state->ref = 19200;
> + break;
> + case ICL_DSSM_CDCLK_PLL_REFCLK_38_4MHz:
> + cdclk_state->ref = 38400;
> + break;
> + }
> +}
> +
> +static void bxt_de_pll_readout(struct drm_i915_private *dev_priv,
> +struct intel_cdclk_state *cdclk_state)
> +{
> + u32 val, ratio;
> +
> + if (INTEL_GEN(dev_priv) >= 11)
> + icl_readout_refclk(dev_priv, cdclk_state);
> + else if (IS_CANNONLAKE(dev_priv))
> + cnl_readout_refclk(dev_priv, cdclk_state);
> + else
> + cdclk_state->ref = 19200;
>
> val = I915_READ(BXT_DE_PLL_ENABLE);
> - if ((val & BXT_DE_PLL_PLL_ENABLE) == 0)
> + if ((val & BXT_DE_PLL_PLL_ENABLE) == 0 ||
> + (val & BXT_DE_PLL_LOCK) == 0) {
> + /*
> + * CDCLK PLL is disabled, the VCO/ratio doesn't matter, but
> + * setting it to zero is a way to signal that.
> + */
> + cdclk_state->vco = 0;
> return;
> + }
>
> - if (WARN_ON((val & BXT_DE_PLL_LOCK) == 0))
> - return;
> + /*
> + * CNL+ have the ratio directly in the PLL enable register, gen9lp had
> + * it in a separate PLL control register.
> + */
> + if (INTEL_GEN(dev_priv) >= 10)
> + ratio = val & BXT_DE_PLL_RATIO_MASK;a
CNL_CDCLK_PLL_RATIO_MASK would be more correct. Same bits, but maybe
a bit less confusing if we don't share the define across registers.
With the wrong numbers in calc_voltage_level() fixed:
Reviewed-by: Ville Syrjälä
> + else
> + ratio = I915_READ(BXT_DE_PLL_CTL) & BXT_DE_PLL_RATIO_MASK;
>
> - val = I915_READ(BXT_DE_PLL_CTL);
> - cdclk_state->vco = (val & BXT_DE_PLL_RATIO_MASK) * cdclk_state->ref;
> + cdclk_state->vco = ratio * cdclk_state->ref;
> }
>
> static void bxt_get_cdclk(struct drm_i915_private *dev_priv,
> @@ -1261,12 +1337,18 @@ static void bxt_get_cdclk(stru
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Tighten the timeout testing for partial mmaps
On Tue, 10 Sep 2019 at 13:10, Chris Wilson wrote: > > Currently, if there is time remaining before the start of the loop, we > do one full iteration over many possible different chunks within the > object. A full loop may take 50+s (depending on speed of indirect GTT > mmapings) and we try separately with LINEAR, X and Y -- at which point > igt times out. If we check more frequently, we will interrupt the loop > upon our timeout -- it is hard to argue for as this significantly reduces > the test coverage as we dramatically reduce the runtime. In practical > terms, the coverage we should prioritise is in using different fence > setups, forcing verification of the tile row computations over the > current preference of checking extracting chunks. Though the exhaustive > search is great given an infinite timeout, to improve our current > coverage, we also add a randomised smoketest of partial mmaps. So let's > do both, add a randomised smoketest of partial tiling chunks and the > exhaustive (though time limited) search for failures. > > Even in adding another subtest, we should shave 100s off BAT! (With, > hopefully, no loss in coverage, at least over multiple runs.) > > Signed-off-by: Chris Wilson > Cc: Matthew Auld 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: Use a high priority wq for nonblocking plane updates
Quoting Ville Syrjala (2019-09-10 13:13:47) > From: Ville Syrjälä > > system_unbound_wq can't keep up sometimes and we get dropped frames. > Switch to a high priority variant. > > Reported-by: Heinrich Fink > Tested-by: Heinrich Fink > Signed-off-by: Ville Syrjälä Reviewed-by: Chris Wilson I guess we might be talking about adding a WQ_RTPRI next. Doesn't actually look that difficult to do, if there's a userspace demand (as we would need to justify why our interactive task deserved to be such high priority). -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/8] drm/i915: Combine bxt_set_cdclk and cnl_set_cdclk
On Fri, Sep 06, 2019 at 05:21:38PM -0700, Matt Roper wrote:
> We'd previously combined ICL/TGL logic into the cnl_set_cdclk function,
> but BXT is pretty similar as well. Roll the cnl/icl/tgl logic back into
> the bxt function; the only things we really need to handle separately
> are punit notification and calling different functions to enable/disable
> the cdclk PLL.
>
> Cc: Ville Syrjälä
> Signed-off-by: Matt Roper
Not sure if all the ifs are getting out of hand or not. But I guess
it's still legible.
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 267 +
> 1 file changed, 119 insertions(+), 148 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 8ac31f8775f0..6b5b1328a3fa 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -1449,6 +1449,39 @@ static void bxt_de_pll_enable(struct drm_i915_private
> *dev_priv, int vco)
> dev_priv->cdclk.hw.vco = vco;
> }
>
> +static void cnl_cdclk_pll_disable(struct drm_i915_private *dev_priv)
> +{
> + u32 val;
> +
> + val = I915_READ(BXT_DE_PLL_ENABLE);
> + val &= ~BXT_DE_PLL_PLL_ENABLE;
> + I915_WRITE(BXT_DE_PLL_ENABLE, val);
> +
> + /* Timeout 200us */
> + if (wait_for((I915_READ(BXT_DE_PLL_ENABLE) & BXT_DE_PLL_LOCK) == 0, 1))
> + DRM_ERROR("timeout waiting for CDCLK PLL unlock\n");
> +
> + dev_priv->cdclk.hw.vco = 0;
> +}
> +
> +static void cnl_cdclk_pll_enable(struct drm_i915_private *dev_priv, int vco)
> +{
> + int ratio = DIV_ROUND_CLOSEST(vco, dev_priv->cdclk.hw.ref);
> + u32 val;
> +
> + val = CNL_CDCLK_PLL_RATIO(ratio);
> + I915_WRITE(BXT_DE_PLL_ENABLE, val);
> +
> + val |= BXT_DE_PLL_PLL_ENABLE;
> + I915_WRITE(BXT_DE_PLL_ENABLE, val);
> +
> + /* Timeout 200us */
> + if (wait_for((I915_READ(BXT_DE_PLL_ENABLE) & BXT_DE_PLL_LOCK) != 0, 1))
> + DRM_ERROR("timeout waiting for CDCLK PLL lock\n");
> +
> + dev_priv->cdclk.hw.vco = vco;
> +}
> +
> static void bxt_set_cdclk(struct drm_i915_private *dev_priv,
> const struct intel_cdclk_state *cdclk_state,
> enum pipe pipe)
> @@ -1458,6 +1491,27 @@ static void bxt_set_cdclk(struct drm_i915_private
> *dev_priv,
> u32 val, divider;
> int ret;
>
> + /* Inform power controller of upcoming frequency change. */
> + if (INTEL_GEN(dev_priv) >= 10)
> + ret = skl_pcode_request(dev_priv, SKL_PCODE_CDCLK_CONTROL,
> + SKL_CDCLK_PREPARE_FOR_CHANGE,
> + SKL_CDCLK_READY_FOR_CHANGE,
> + SKL_CDCLK_READY_FOR_CHANGE, 3);
> + else
> + /*
> + * BSpec requires us to wait up to 150usec, but that leads to
> + * timeouts; the 2ms used here is based on experiment.
> + */
> + ret = sandybridge_pcode_write_timeout(dev_priv,
> +
> HSW_PCODE_DE_WRITE_FREQ_REQ,
> + 0x8000, 150, 2);
> +
> + if (ret) {
> + DRM_ERROR("Failed to inform PCU about cdclk change (err %d,
> freq %d)\n",
> + ret, cdclk);
> + return;
> + }
> +
> /* cdclk = vco / 2 / div{1,1.5,2,4} */
> switch (DIV_ROUND_CLOSEST(vco, cdclk)) {
> default:
> @@ -1468,63 +1522,82 @@ static void bxt_set_cdclk(struct drm_i915_private
> *dev_priv,
> divider = BXT_CDCLK_CD2X_DIV_SEL_1;
> break;
> case 3:
> - WARN(IS_GEMINILAKE(dev_priv), "Unsupported divider\n");
> + WARN(IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) >= 10,
> + "Unsupported divider\n");
> divider = BXT_CDCLK_CD2X_DIV_SEL_1_5;
> break;
> case 4:
> divider = BXT_CDCLK_CD2X_DIV_SEL_2;
> break;
> case 8:
> + WARN(INTEL_GEN(dev_priv) >= 10, "Unsupported divider\n");
> divider = BXT_CDCLK_CD2X_DIV_SEL_4;
> break;
> }
>
> - /*
> - * Inform power controller of upcoming frequency change. BSpec
> - * requires us to wait up to 150usec, but that leads to timeouts;
> - * the 2ms used here is based on experiment.
> - */
> - ret = sandybridge_pcode_write_timeout(dev_priv,
> - HSW_PCODE_DE_WRITE_FREQ_REQ,
> - 0x8000, 150, 2);
> - if (ret) {
> - DRM_ERROR("PCode CDCLK freq change notify failed (err %d, freq
> %d)\n",
> - ret, cdclk);
> - return;
> - }
> + if (INTEL_GEN(dev_priv) >= 10) {
> + if (dev_priv->cdclk.hw.vco != 0 &&
> + dev_priv->cdclk
Re: [Intel-gfx] [PATCH 4/8] drm/i915: Kill cnl_sanitize_cdclk()
On Fri, Sep 06, 2019 at 05:21:39PM -0700, Matt Roper wrote:
> The CNL variant of this function is identical to the BXT variant aside
> from not needing to handle SSA precharge.
>
> Cc: Ville Syrjälä
> Signed-off-by: Matt Roper
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 46 +-
> 1 file changed, 2 insertions(+), 44 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 6b5b1328a3fa..f8c2a706990b 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -1645,7 +1645,7 @@ static void bxt_sanitize_cdclk(struct drm_i915_private
> *dev_priv)
>* Disable SSA Precharge when CD clock frequency < 500 MHz,
>* enable otherwise.
>*/
> - if (dev_priv->cdclk.hw.cdclk >= 50)
> + if (IS_GEN9_LP(dev_priv) && dev_priv->cdclk.hw.cdclk >= 50)
> expected |= BXT_CDCLK_SSA_PRECHARGE_ENABLE;
>
> if (cdctl == expected)
> @@ -1697,48 +1697,6 @@ static void bxt_uninit_cdclk(struct drm_i915_private
> *dev_priv)
> bxt_set_cdclk(dev_priv, &cdclk_state, INVALID_PIPE);
> }
>
> -static void cnl_sanitize_cdclk(struct drm_i915_private *dev_priv)
> -{
> - u32 cdctl, expected;
> -
> - intel_update_cdclk(dev_priv);
> - intel_dump_cdclk_state(&dev_priv->cdclk.hw, "Current CDCLK");
> -
> - if (dev_priv->cdclk.hw.vco == 0 ||
> - dev_priv->cdclk.hw.cdclk == dev_priv->cdclk.hw.bypass)
> - goto sanitize;
> -
> - /* DPLL okay; verify the cdclock
> - *
> - * Some BIOS versions leave an incorrect decimal frequency value and
> - * set reserved MBZ bits in CDCLK_CTL at least during exiting from S4,
> - * so sanitize this register.
> - */
> - cdctl = I915_READ(CDCLK_CTL);
> - /*
> - * Let's ignore the pipe field, since BIOS could have configured the
> - * dividers both synching to an active pipe, or asynchronously
> - * (PIPE_NONE).
> - */
> - cdctl &= ~BXT_CDCLK_CD2X_PIPE_NONE;
> -
> - expected = (cdctl & BXT_CDCLK_CD2X_DIV_SEL_MASK) |
> -skl_cdclk_decimal(dev_priv->cdclk.hw.cdclk);
> -
> - if (cdctl == expected)
> - /* All well; nothing to sanitize */
> - return;
> -
> -sanitize:
> - DRM_DEBUG_KMS("Sanitizing cdclk programmed by pre-os\n");
> -
> - /* force cdclk programming */
> - dev_priv->cdclk.hw.cdclk = 0;
> -
> - /* force full PLL disable + enable */
> - dev_priv->cdclk.hw.vco = -1;
> -}
> -
> static void icl_init_cdclk(struct drm_i915_private *dev_priv)
> {
> struct intel_cdclk_state sanitized_state;
> @@ -1800,7 +1758,7 @@ static void cnl_init_cdclk(struct drm_i915_private
> *dev_priv)
> {
> struct intel_cdclk_state cdclk_state;
>
> - cnl_sanitize_cdclk(dev_priv);
> + bxt_sanitize_cdclk(dev_priv);
>
> if (dev_priv->cdclk.hw.cdclk != 0 &&
> dev_priv->cdclk.hw.vco != 0)
> --
> 2.20.1
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/8] drm/i915: Consolidate {bxt, cnl, icl}_uninit_cdclk
On Fri, Sep 06, 2019 at 05:21:40PM -0700, Matt Roper wrote:
> The uninitialize flow is the same on all of these platforms, aside from
> calculating a different frequency level.
>
> Cc: Ville Syrjälä
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 48 +++---
> 1 file changed, 14 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index f8c2a706990b..a70fec82d2bc 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -1692,7 +1692,18 @@ static void bxt_uninit_cdclk(struct drm_i915_private
> *dev_priv)
>
> cdclk_state.cdclk = cdclk_state.bypass;
> cdclk_state.vco = 0;
> - cdclk_state.voltage_level = bxt_calc_voltage_level(cdclk_state.cdclk);
> + if (IS_ELKHARTLAKE(dev_priv))
> + cdclk_state.voltage_level =
> + ehl_calc_voltage_level(cdclk_state.cdclk);
> + else if (INTEL_GEN(dev_priv) >= 11)
> + cdclk_state.voltage_level =
> + icl_calc_voltage_level(cdclk_state.cdclk);
> + else if (INTEL_GEN(dev_priv) >= 10)
> + cdclk_state.voltage_level =
> + cnl_calc_voltage_level(cdclk_state.cdclk);
> + else
> + cdclk_state.voltage_level =
> + bxt_calc_voltage_level(cdclk_state.cdclk);
>
> bxt_set_cdclk(dev_priv, &cdclk_state, INVALID_PIPE);
> }
> @@ -1738,22 +1749,6 @@ static void icl_init_cdclk(struct drm_i915_private
> *dev_priv)
> bxt_set_cdclk(dev_priv, &sanitized_state, INVALID_PIPE);
> }
>
> -static void icl_uninit_cdclk(struct drm_i915_private *dev_priv)
> -{
> - struct intel_cdclk_state cdclk_state = dev_priv->cdclk.hw;
> -
> - cdclk_state.cdclk = cdclk_state.bypass;
> - cdclk_state.vco = 0;
> - if (IS_ELKHARTLAKE(dev_priv))
> - cdclk_state.voltage_level =
> - ehl_calc_voltage_level(cdclk_state.cdclk);
> - else
> - cdclk_state.voltage_level =
> - icl_calc_voltage_level(cdclk_state.cdclk);
> -
> - bxt_set_cdclk(dev_priv, &cdclk_state, INVALID_PIPE);
> -}
> -
> static void cnl_init_cdclk(struct drm_i915_private *dev_priv)
> {
> struct intel_cdclk_state cdclk_state;
> @@ -1773,17 +1768,6 @@ static void cnl_init_cdclk(struct drm_i915_private
> *dev_priv)
> bxt_set_cdclk(dev_priv, &cdclk_state, INVALID_PIPE);
> }
>
> -static void cnl_uninit_cdclk(struct drm_i915_private *dev_priv)
> -{
> - struct intel_cdclk_state cdclk_state = dev_priv->cdclk.hw;
> -
> - cdclk_state.cdclk = cdclk_state.bypass;
> - cdclk_state.vco = 0;
> - cdclk_state.voltage_level = cnl_calc_voltage_level(cdclk_state.cdclk);
> -
> - bxt_set_cdclk(dev_priv, &cdclk_state, INVALID_PIPE);
> -}
> -
> /**
> * intel_cdclk_init - Initialize CDCLK
> * @i915: i915 device
> @@ -1814,14 +1798,10 @@ void intel_cdclk_init(struct drm_i915_private *i915)
> */
> void intel_cdclk_uninit(struct drm_i915_private *i915)
> {
> - if (INTEL_GEN(i915) >= 11)
> - icl_uninit_cdclk(i915);
> - else if (IS_CANNONLAKE(i915))
> - cnl_uninit_cdclk(i915);
> + if (IS_GEN9_LP(i915) || INTEL_GEN(i915) >= 10)
I think the general concensus has been to list platforms
from new to old. Might be good to stick to that even
within conditions like this. There may have been other cases like this
in these patches that I didn't spot.
Reviewed-by: Ville Syrjälä
> + bxt_uninit_cdclk(i915);
> else if (IS_GEN9_BC(i915))
> skl_uninit_cdclk(i915);
> - else if (IS_GEN9_LP(i915))
> - bxt_uninit_cdclk(i915);
> }
>
> /**
> --
> 2.20.1
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/8] drm/i915: Add calc_voltage_level display vfunc
On Fri, Sep 06, 2019 at 05:21:41PM -0700, Matt Roper wrote:
> With all of the cdclk function consolidation, we can cut down on a lot
> of platform if/else logic by creating a vfunc that's initialized at
> startup.
Reviewed-by: Ville Syrjälä
>
> Cc: Ville Syrjälä
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 76 --
> drivers/gpu/drm/i915/i915_drv.h| 1 +
> 2 files changed, 28 insertions(+), 49 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index a70fec82d2bc..a6696697a09f 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -1403,18 +1403,8 @@ static void bxt_get_cdclk(struct drm_i915_private
> *dev_priv,
>* Can't read this out :( Let's assume it's
>* at least what the CDCLK frequency requires.
>*/
> - if (IS_ELKHARTLAKE(dev_priv))
> - cdclk_state->voltage_level =
> - ehl_calc_voltage_level(cdclk_state->cdclk);
> - else if (INTEL_GEN(dev_priv) >= 11)
> - cdclk_state->voltage_level =
> - icl_calc_voltage_level(cdclk_state->cdclk);
> - else if (INTEL_GEN(dev_priv) >= 10)
> - cdclk_state->voltage_level =
> - cnl_calc_voltage_level(cdclk_state->cdclk);
> - else
> - cdclk_state->voltage_level =
> - bxt_calc_voltage_level(cdclk_state->cdclk);
> + cdclk_state->voltage_level =
> + dev_priv->display.calc_voltage_level(cdclk_state->cdclk);
> }
>
> static void bxt_de_pll_disable(struct drm_i915_private *dev_priv)
> @@ -1681,7 +1671,8 @@ static void bxt_init_cdclk(struct drm_i915_private
> *dev_priv)
>*/
> cdclk_state.cdclk = calc_cdclk(dev_priv, 0);
> cdclk_state.vco = calc_cdclk_pll_vco(dev_priv, cdclk_state.cdclk);
> - cdclk_state.voltage_level = bxt_calc_voltage_level(cdclk_state.cdclk);
> + cdclk_state.voltage_level =
> + dev_priv->display.calc_voltage_level(cdclk_state.cdclk);
>
> bxt_set_cdclk(dev_priv, &cdclk_state, INVALID_PIPE);
> }
> @@ -1692,18 +1683,8 @@ static void bxt_uninit_cdclk(struct drm_i915_private
> *dev_priv)
>
> cdclk_state.cdclk = cdclk_state.bypass;
> cdclk_state.vco = 0;
> - if (IS_ELKHARTLAKE(dev_priv))
> - cdclk_state.voltage_level =
> - ehl_calc_voltage_level(cdclk_state.cdclk);
> - else if (INTEL_GEN(dev_priv) >= 11)
> - cdclk_state.voltage_level =
> - icl_calc_voltage_level(cdclk_state.cdclk);
> - else if (INTEL_GEN(dev_priv) >= 10)
> - cdclk_state.voltage_level =
> - cnl_calc_voltage_level(cdclk_state.cdclk);
> - else
> - cdclk_state.voltage_level =
> - bxt_calc_voltage_level(cdclk_state.cdclk);
> + cdclk_state.voltage_level =
> + dev_priv->display.calc_voltage_level(cdclk_state.cdclk);
>
> bxt_set_cdclk(dev_priv, &cdclk_state, INVALID_PIPE);
> }
> @@ -1739,12 +1720,8 @@ static void icl_init_cdclk(struct drm_i915_private
> *dev_priv)
> sanitized_state.cdclk = calc_cdclk(dev_priv, 0);
> sanitized_state.vco = calc_cdclk_pll_vco(dev_priv,
>sanitized_state.cdclk);
> - if (IS_ELKHARTLAKE(dev_priv))
> - sanitized_state.voltage_level =
> - ehl_calc_voltage_level(sanitized_state.cdclk);
> - else
> - sanitized_state.voltage_level =
> - icl_calc_voltage_level(sanitized_state.cdclk);
> + sanitized_state.voltage_level =
> + dev_priv->display.calc_voltage_level(sanitized_state.cdclk);
>
> bxt_set_cdclk(dev_priv, &sanitized_state, INVALID_PIPE);
> }
> @@ -1763,7 +1740,8 @@ static void cnl_init_cdclk(struct drm_i915_private
> *dev_priv)
>
> cdclk_state.cdclk = calc_cdclk(dev_priv, 0);
> cdclk_state.vco = calc_cdclk_pll_vco(dev_priv, cdclk_state.cdclk);
> - cdclk_state.voltage_level = cnl_calc_voltage_level(cdclk_state.cdclk);
> + cdclk_state.voltage_level =
> + dev_priv->display.calc_voltage_level(cdclk_state.cdclk);
>
> bxt_set_cdclk(dev_priv, &cdclk_state, INVALID_PIPE);
> }
> @@ -2255,7 +2233,7 @@ static int bxt_modeset_calc_cdclk(struct
> intel_atomic_state *state)
> state->cdclk.logical.vco = vco;
> state->cdclk.logical.cdclk = cdclk;
> state->cdclk.logical.voltage_level =
> - bxt_calc_voltage_level(cdclk);
> + dev_priv->display.calc_voltage_level(cdclk);
>
> if (!state->active_pipes) {
> cdclk = calc_cdclk(dev_priv, state->cdclk.force_min_cdclk);
> @@ -2264,7 +2242,7 @@ static int bxt_modeset_calc_cdclk(struct
> intel_atomic_state *state)
> state->cdclk.actual.vco = vco;
> state->c
Re: [Intel-gfx] [PATCH 7/8] drm/i915: Enhance cdclk sanitization
On Fri, Sep 06, 2019 at 05:21:42PM -0700, Matt Roper wrote:
> When reading out the BIOS-programmed cdclk state, let's make sure that
> the cdclk value is on the valid list for the platform, ensure that the
> VCO matches the cdclk, and ensure that the CD2X divider was set
> properly.
Reviewed-by: Ville Syrjälä
> Cc: Ville Syrjälä
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 34 --
> 1 file changed, 32 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index a6696697a09f..356495591cf9 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -1607,6 +1607,7 @@ static void bxt_set_cdclk(struct drm_i915_private
> *dev_priv,
> static void bxt_sanitize_cdclk(struct drm_i915_private *dev_priv)
> {
> u32 cdctl, expected;
> + int cdclk, vco;
>
> intel_update_cdclk(dev_priv);
> intel_dump_cdclk_state(&dev_priv->cdclk.hw, "Current CDCLK");
> @@ -1629,8 +1630,37 @@ static void bxt_sanitize_cdclk(struct drm_i915_private
> *dev_priv)
>*/
> cdctl &= ~BXT_CDCLK_CD2X_PIPE_NONE;
>
> - expected = (cdctl & BXT_CDCLK_CD2X_DIV_SEL_MASK) |
> - skl_cdclk_decimal(dev_priv->cdclk.hw.cdclk);
> + /* Make sure this is a legal cdclk value for the platform */
> + cdclk = calc_cdclk(dev_priv, dev_priv->cdclk.hw.cdclk);
> + if (cdclk != dev_priv->cdclk.hw.cdclk)
> + goto sanitize;
> +
> + /* Make sure the VCO is correct for the cdclk */
> + vco = calc_cdclk_pll_vco(dev_priv, cdclk);
> + if (vco != dev_priv->cdclk.hw.vco)
> + goto sanitize;
> +
> + expected = skl_cdclk_decimal(cdclk);
> +
> + /* Figure out what CD2X divider we should be using for this cdclk */
> + switch (DIV_ROUND_CLOSEST(dev_priv->cdclk.hw.vco,
> + dev_priv->cdclk.hw.cdclk)) {
> + case 2:
> + expected |= BXT_CDCLK_CD2X_DIV_SEL_1;
> + break;
> + case 3:
> + expected |= BXT_CDCLK_CD2X_DIV_SEL_1_5;
> + break;
> + case 4:
> + expected |= BXT_CDCLK_CD2X_DIV_SEL_2;
> + break;
> + case 8:
> + expected |= BXT_CDCLK_CD2X_DIV_SEL_4;
> + break;
> + default:
> + goto sanitize;
> + }
> +
> /*
>* Disable SSA Precharge when CD clock frequency < 500 MHz,
>* enable otherwise.
> --
> 2.20.1
--
Ville Syrjälä
Intel
___
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/tgl: Keep forcewake always for now
== Series Details ==
Series: drm/i915/tgl: Keep forcewake always for now
URL : https://patchwork.freedesktop.org/series/66483/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6860 -> Patchwork_14338
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14338/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_14338:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_module_load@reload:
- {fi-tgl-u}: NOTRUN -> [DMESG-WARN][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14338/fi-tgl-u/igt@i915_module_l...@reload.html
Known issues
Here are the changes found in Patchwork_14338 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850: [PASS][2] -> [INCOMPLETE][3] ([fdo#107718])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14338/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
* igt@i915_selftest@live_execlists:
- fi-skl-gvtdvm: [PASS][4] -> [DMESG-FAIL][5] ([fdo#08])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14338/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
Possible fixes
* igt@gem_exec_gttfill@basic:
- {fi-tgl-u}: [INCOMPLETE][6] ([fdo#111593]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/fi-tgl-u/igt@gem_exec_gttf...@basic.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14338/fi-tgl-u/igt@gem_exec_gttf...@basic.html
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: [DMESG-WARN][8] ([fdo#102614]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14338/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
* igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- {fi-icl-dsi}: [DMESG-WARN][10] ([fdo#106107]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/fi-icl-dsi/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14338/fi-icl-dsi/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
* igt@prime_vgem@basic-fence-mmap:
- fi-icl-u3: [DMESG-WARN][12] ([fdo#107724]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/fi-icl-u3/igt@prime_v...@basic-fence-mmap.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14338/fi-icl-u3/igt@prime_v...@basic-fence-mmap.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#08]: https://bugs.freedesktop.org/show_bug.cgi?id=08
[fdo#111593]: https://bugs.freedesktop.org/show_bug.cgi?id=111593
Participating hosts (53 -> 47)
--
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y
fi-byt-clapper
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6860 -> Patchwork_14338
CI-20190529: 20190529
CI_DRM_6860: 33c00059b084f42f01a168b5f67e4df670293e2c @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5177: 8f351d693352d21c96cef38c3fd77f778c6d7c33 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14338: 08a799f42ee6b72ffdb85c2518acda9a3cab701c @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
08a799f42ee6 drm/i915/tgl: Keep forcewake always for now
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14338/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 8/8] drm/i915: Consolidate {bxt, cnl, icl}_init_cdclk
On Fri, Sep 06, 2019 at 05:21:43PM -0700, Matt Roper wrote:
> The BXT and CNL functions were already basically identical, whereas
> ICL's function tried to do its own sanitization rather than calling
> bxt_sanitize_cdclk.
>
> This should actually fix a bug in our ICL initialization where it would
> consider the /2 CD2X divider invalid and force an unnecessary
> sanitization (we now have valid clock frequencies that use this
> divider).
>
> Cc: Ville Syrjälä
> Signed-off-by: Matt Roper
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 65 +-
> 1 file changed, 2 insertions(+), 63 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 356495591cf9..0ad83d67932d 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -1719,63 +1719,6 @@ static void bxt_uninit_cdclk(struct drm_i915_private
> *dev_priv)
> bxt_set_cdclk(dev_priv, &cdclk_state, INVALID_PIPE);
> }
>
> -static void icl_init_cdclk(struct drm_i915_private *dev_priv)
> -{
> - struct intel_cdclk_state sanitized_state;
> - u32 val;
> -
> - /* This sets dev_priv->cdclk.hw. */
> - intel_update_cdclk(dev_priv);
> - intel_dump_cdclk_state(&dev_priv->cdclk.hw, "Current CDCLK");
> -
> - /* This means CDCLK disabled. */
> - if (dev_priv->cdclk.hw.cdclk == dev_priv->cdclk.hw.bypass)
> - goto sanitize;
> -
> - val = I915_READ(CDCLK_CTL);
> -
> - if ((val & BXT_CDCLK_CD2X_DIV_SEL_MASK) != 0)
> - goto sanitize;
> -
> - if ((val & CDCLK_FREQ_DECIMAL_MASK) !=
> - skl_cdclk_decimal(dev_priv->cdclk.hw.cdclk))
> - goto sanitize;
> -
> - return;
> -
> -sanitize:
> - DRM_DEBUG_KMS("Sanitizing cdclk programmed by pre-os\n");
> -
> - sanitized_state.ref = dev_priv->cdclk.hw.ref;
> - sanitized_state.cdclk = calc_cdclk(dev_priv, 0);
> - sanitized_state.vco = calc_cdclk_pll_vco(dev_priv,
> - sanitized_state.cdclk);
> - sanitized_state.voltage_level =
> - dev_priv->display.calc_voltage_level(sanitized_state.cdclk);
> -
> - bxt_set_cdclk(dev_priv, &sanitized_state, INVALID_PIPE);
> -}
> -
> -static void cnl_init_cdclk(struct drm_i915_private *dev_priv)
> -{
> - struct intel_cdclk_state cdclk_state;
> -
> - bxt_sanitize_cdclk(dev_priv);
> -
> - if (dev_priv->cdclk.hw.cdclk != 0 &&
> - dev_priv->cdclk.hw.vco != 0)
> - return;
> -
> - cdclk_state = dev_priv->cdclk.hw;
> -
> - cdclk_state.cdclk = calc_cdclk(dev_priv, 0);
> - cdclk_state.vco = calc_cdclk_pll_vco(dev_priv, cdclk_state.cdclk);
> - cdclk_state.voltage_level =
> - dev_priv->display.calc_voltage_level(cdclk_state.cdclk);
> -
> - bxt_set_cdclk(dev_priv, &cdclk_state, INVALID_PIPE);
> -}
> -
> /**
> * intel_cdclk_init - Initialize CDCLK
> * @i915: i915 device
> @@ -1787,14 +1730,10 @@ static void cnl_init_cdclk(struct drm_i915_private
> *dev_priv)
> */
> void intel_cdclk_init(struct drm_i915_private *i915)
> {
> - if (INTEL_GEN(i915) >= 11)
> - icl_init_cdclk(i915);
> - else if (IS_CANNONLAKE(i915))
> - cnl_init_cdclk(i915);
> + if (IS_GEN9_LP(i915) || INTEL_GEN(i915) >= 10)
> + bxt_init_cdclk(i915);
> else if (IS_GEN9_BC(i915))
> skl_init_cdclk(i915);
> - else if (IS_GEN9_LP(i915))
> - bxt_init_cdclk(i915);
> }
>
> /**
> --
> 2.20.1
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/8] drm/i915: Use literal representation of cdclk tables
On Sat, Sep 07, 2019 at 09:05:00PM -0700, Matt Roper wrote:
> The bspec lays out legal cdclk frequencies, PLL ratios, and CD2X
> dividers in an easy-to-read table for most recent platforms. We've been
> translating the data from that table into platform-specific code logic,
> but it's easy to overlook an area we need to update when adding new
> cdclk values or enabling new platforms. Let's just add a form of the
> bspec table to the code and then adjust our functions to pull what they
> need directly out of the table.
>
> v2: Fix comparison when finding best cdclk.
>
> v3: Another logic fix for calc_cdclk.
>
> Cc: Ville Syrjälä
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 318 -
> drivers/gpu/drm/i915/display/intel_cdclk.h | 8 +
> drivers/gpu/drm/i915/i915_drv.h| 4 +
> 3 files changed, 125 insertions(+), 205 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index e07de3b84cec..ca64143b6d7e 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -1161,28 +1161,96 @@ static void skl_uninit_cdclk(struct drm_i915_private
> *dev_priv)
> skl_set_cdclk(dev_priv, &cdclk_state, INVALID_PIPE);
> }
>
> -static int bxt_calc_cdclk(int min_cdclk)
> -{
> - if (min_cdclk > 576000)
> - return 624000;
> - else if (min_cdclk > 384000)
> - return 576000;
> - else if (min_cdclk > 288000)
> - return 384000;
> - else if (min_cdclk > 144000)
> - return 288000;
> - else
> - return 144000;
> +static const struct intel_cdclk_vals bxt_cdclk_table[] = {
> + { 144000, 8, 60 },
> + { 288000, 4, 60 },
> + { 384000, 3, 60 },
> + { 576000, 2, 60 },
> + { 624000, 2, 65 },
Named initializers might make this number soup digestible.
> +};
> +
> +static const struct intel_cdclk_vals glk_cdclk_table[] = {
> + { 79200, 8, 33 },
> + { 158400, 4, 33 },
> + { 316800, 2, 33 },
> +};
> +
> +static const struct intel_cdclk_vals cnl_cdclk_table[] = {
> + { 168000, 4, 35, 28 },
> + { 336000, 2, 35, 28 },
> + { 528000, 2, 55, 44 },
> +};
> +
> +static const struct intel_cdclk_vals icl_cdclk_table[] = {
> + { 172800, 2, 18, 0, 9 },
> + { 18, 2, 0, 15, 0 },
> + { 192000, 2, 20, 16, 10 },
> + { 307200, 2, 32, 0, 16 },
> + { 312000, 2, 0, 26, 0 },
> + { 324000, 4, 0, 54, 0 },
> + { 326400, 4, 68, 0, 34 },
> + { 552000, 2, 0, 46, 0 },
> + { 556800, 2, 58, 0, 29 },
> + { 648000, 2, 0, 54, 0 },
> + { 652800, 2, 68, 0, 34 },
> +};
> +
> +static int calc_cdclk(struct drm_i915_private *dev_priv,
> + int min_cdclk)
> +{
> + const struct intel_cdclk_vals *table = dev_priv->cdclk.table;
> + unsigned int ref = dev_priv->cdclk.hw.ref;
> + int best_cdclk = 0;
> + int i;
> +
> + if (WARN_ON(ref != 19200 && ref != 24000 && ref != 38400))
> + ref = 19200;
Feels a bit like dead code.
> +
> + for (i = 0; i < dev_priv->cdclk.table_size; i++) {
> + if ((ref == 19200 && table[i].ratio_19 == 0) ||
> + (ref == 24000 && table[i].ratio_24 == 0) ||
> + (ref == 38400 && table[i].ratio_38 == 0))
> + continue;
> +
> + best_cdclk = table[i].cdclk;
> + if (table[i].cdclk >= min_cdclk)
> + return best_cdclk;
> + }
> +
> + WARN(1, "Cannot satisfy minimum cdclk %d\n", min_cdclk);
> + return best_cdclk;
Same for the best_cdclk thing. I'd probably just MISSING_CASE()
and return 0, or something.
> }
>
> -static int glk_calc_cdclk(int min_cdclk)
> +static int calc_cdclk_pll_vco(struct drm_i915_private *dev_priv, int cdclk)
We still use these things for bxt+ only, so would be nice if
the names kept reflecting that fact.
Though I suppose we should be able to extend this more
declarative approach backwards to older platforms as well.
> {
> - if (min_cdclk > 158400)
> - return 316800;
> - else if (min_cdclk > 79200)
> - return 158400;
> - else
> - return 79200;
> + const struct intel_cdclk_vals *table = dev_priv->cdclk.table;
> + int ratio, best_ratio, i;
> +
> + if (cdclk == dev_priv->cdclk.hw.bypass)
> + return 0;
> +
> + for (i = 0; i < dev_priv->cdclk.table_size; i++) {
> + if (dev_priv->cdclk.hw.ref == 19200)
> + ratio = table[i].ratio_19;
> + else if (dev_priv->cdclk.hw.ref == 24000)
> + ratio = table[i].ratio_24;
> + else
> + ratio = table[i].ratio_38;
> +
> + if (ratio == 0)
> + continue;
> + else
> + best_ratio = ratio;
> +
> + if (table[i].cdclk == cdclk ||
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/selftests: Tighten the timeout testing for partial mmaps
== Series Details == Series: drm/i915/selftests: Tighten the timeout testing for partial mmaps URL : https://patchwork.freedesktop.org/series/66484/ State : warning == Summary == $ dim checkpatch origin/drm-tip 8b28c802b06b drm/i915/selftests: Tighten the timeout testing for partial mmaps -:274: WARNING:LINE_SPACING: Missing a blank line after declarations #274: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c:431: + intel_wakeref_t wakeref; + I915_RND_STATE(prng); -:276: WARNING:LINE_SPACING: Missing a blank line after declarations #276: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c:433: + unsigned long count; + IGT_TIMEOUT(end); -:293: WARNING:LONG_LINE: line over 100 characters #293: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c:450: + (1 + next_prime_number(i915->ggtt.vm.total >> PAGE_SHIFT)) << PAGE_SHIFT); total: 0 errors, 3 warnings, 0 checks, 329 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 3/7] drm: Add DisplayPort colorspace property
On Tue, Sep 10, 2019 at 3:34 AM Mun, Gwan-gyeong wrote: > > On Sat, 2019-09-07 at 21:43 -0400, Ilia Mirkin wrote: > > On Sat, Sep 7, 2019 at 7:20 PM Mun, Gwan-gyeong > > wrote: > > > On Fri, 2019-09-06 at 09:24 -0400, Ilia Mirkin wrote: > > > > On Fri, Sep 6, 2019 at 7:43 AM Ville Syrjälä > > > > wrote: > > > > > On Fri, Sep 06, 2019 at 11:31:55AM +, Shankar, Uma wrote: > > > > > > > -Original Message- > > > > > > > From: Ilia Mirkin > > > > > > > Sent: Tuesday, September 3, 2019 6:12 PM > > > > > > > To: Mun, Gwan-gyeong > > > > > > > Cc: Intel Graphics Development < > > > > > > > intel-gfx@lists.freedesktop.org > > > > > > > > ; Shankar, Uma > > > > > > > ; dri-devel < > > > > > > > dri-de...@lists.freedesktop.org> > > > > > > > Subject: Re: [PATCH v4 3/7] drm: Add DisplayPort colorspace > > > > > > > property > > > > > > > > > > > > > > So how would this work with a DP++ connector? Should it > > > > > > > list > > > > > > > the HDMI or DP > > > > > > > properties? Or do we need a custom property checker which > > > > > > > is > > > > > > > aware of what is > > > > > > > currently plugged in to validate the values? > > > > > > > > > > > > AFAIU For DP++ cases, we detect what kind of sink its driving > > > > > > DP > > > > > > or HDMI (with a passive dongle). > > > > > > Based on the type of sink detected, we should expose DP or > > > > > > HDMI > > > > > > colorspaces to userspace. > > > > > > > > > > For i915 DP connector always drives DP mode, HDMI connector > > > > > always > > > > > drives > > > > > HDMI mode, even when the physical connector is DP++. > > > > > > > > Right, i915 creates 2 connectors, while nouveau, radeon, and > > > > amdgpu > > > > create 1 connector (not sure about other drivers) for a single > > > > physical DP++ socket. Since we supply the list of valid values at > > > > the > > > > time of creating the connector, we can't know at that point > > > > whether > > > > in > > > > the future a HDMI or DP will be plugged into it. > > > > > > > > -ilia > > > Ilia, does it mean that the drm_connector type is > > > DRM_MODE_CONNECTOR_DisplayPort and protocol is DP++ mode? > > > > That is correct. The connector type is "DisplayPort" in such a case. > > > > Cheers, > > > > -ilia > > For now drm_mode_create_colorspace_property() is only used for i915. > IMHO, when other drivers ( nouveau, radeon, and amdgpu ) are ready for > using of drm_mode_create_colorspace_property(), > what about do we add a variable which can identify DP++ and DP to > drm_connector? > And when the drivers (nouveau, radeon, and amdgpu) detect the current > protocol, the drivers will set the variable. I've been working on adding this to nouveau. Can/should such properties be added/removed at "runtime", rather than at connector creation time? Either way, the function drm_mode_create_colorspace_property as proposed would not be reusable, since it looks at the connector type, which will always be "DisplayPort" in such cases. -ilia ___ 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/selftests: Tighten the timeout testing for partial mmaps
== Series Details ==
Series: drm/i915/selftests: Tighten the timeout testing for partial mmaps
URL : https://patchwork.freedesktop.org/series/66484/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6860 -> Patchwork_14339
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14339/
Known issues
Here are the changes found in Patchwork_14339 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_param@basic:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) +1
similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/fi-icl-u3/igt@gem_ctx_pa...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14339/fi-icl-u3/igt@gem_ctx_pa...@basic.html
* igt@kms_chamelium@dp-edid-read:
- fi-kbl-7500u: [PASS][3] -> [WARN][4] ([fdo#109483])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/fi-kbl-7500u/igt@kms_chamel...@dp-edid-read.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14339/fi-kbl-7500u/igt@kms_chamel...@dp-edid-read.html
* igt@kms_frontbuffer_tracking@basic:
- fi-icl-u2: [PASS][5] -> [FAIL][6] ([fdo#103167])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14339/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
Possible fixes
* igt@i915_module_load@reload:
- fi-blb-e6850: [INCOMPLETE][7] ([fdo#107718]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/fi-blb-e6850/igt@i915_module_l...@reload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14339/fi-blb-e6850/igt@i915_module_l...@reload.html
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: [DMESG-WARN][9] ([fdo#102614]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14339/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
* igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- {fi-icl-dsi}: [DMESG-WARN][11] ([fdo#106107]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/fi-icl-dsi/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14339/fi-icl-dsi/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
* igt@prime_vgem@basic-fence-mmap:
- fi-icl-u3: [DMESG-WARN][13] ([fdo#107724]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/fi-icl-u3/igt@prime_v...@basic-fence-mmap.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14339/fi-icl-u3/igt@prime_v...@basic-fence-mmap.html
Warnings
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-icl-u2: [DMESG-WARN][15] ([fdo#102505] / [fdo#110390]) ->
[FAIL][16] ([fdo#109483])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/fi-icl-u2/igt@kms_chamel...@common-hpd-after-suspend.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14339/fi-icl-u2/igt@kms_chamel...@common-hpd-after-suspend.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102505]: https://bugs.freedesktop.org/show_bug.cgi?id=102505
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#109483]: https://bugs.freedesktop.org/show_bug.cgi?id=109483
[fdo#110390]: https://bugs.freedesktop.org/show_bug.cgi?id=110390
Participating hosts (53 -> 47)
--
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y
fi-byt-clapper
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6860 -> Patchwork_14339
CI-20190529: 20190529
CI_DRM_6860: 33c00059b084f42f01a168b5f67e4df670293e2c @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5177: 8f351d693352d21c96cef38c3fd77f778c6d7c33 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14339: 8b28c802b06bc9304764c12ef4269ec698c10839 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
8b28c802b06b drm/i915/selftests: Tighten the timeout testing for partial mmaps
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14339/
___
Intel-gfx mailing list
Intel-gfx@list
Re: [Intel-gfx] [PATCH] drm/i915/tgl: Keep forcewake always for now
Quoting Mika Kuoppala (2019-09-10 12:35:47) > Forcewake handling is a prime suspect now. Keep ref > always on tgl to test the theory and reveal the coverage. > > Testcase: igt/gem_sync > Cc: Chris Wilson > Suggested-by: Chris Wilson > Signed-off-by: Mika Kuoppala Gets us as far as reload, before we hit the WARN for the unbalanced forcewake. Seems like a worthwhile approach if we can refine it slightly. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 1/3] drm/i915: Force compilation with intel-iommu for CI validation
Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/Kconfig.debug | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/Kconfig.debug b/drivers/gpu/drm/i915/Kconfig.debug index 00786a142ff0..06709dd6a2e0 100644 --- a/drivers/gpu/drm/i915/Kconfig.debug +++ b/drivers/gpu/drm/i915/Kconfig.debug @@ -20,6 +20,12 @@ config DRM_I915_WERROR config DRM_I915_DEBUG bool "Enable additional driver debugging" depends on DRM_I915 + select PCI_MSI + select IOMMU_API + select IOMMU_IOVA + select NEED_DMA_MAP_STATE + select DMAR_TABLE + select INTEL_IOMMU select DEBUG_FS select PREEMPT_COUNT select REFCOUNT_FULL -- 2.23.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 3/3] iommu/intel: Ignore igfx_off
---
drivers/iommu/intel-iommu.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 34f6a3d93ae2..c98cdfd91691 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -439,8 +439,6 @@ static int __init intel_iommu_setup(char *str)
no_platform_optin = 1;
pr_info("IOMMU disabled\n");
} else if (!strncmp(str, "igfx_off", 8)) {
- dmar_map_gfx = 0;
- pr_info("Disable GFX device mapping\n");
} else if (!strncmp(str, "forcedac", 8)) {
pr_info("Forcing DAC for PCI devices\n");
dmar_forcedac = 1;
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 2/3] iommu/intel: Declare Broadwell igfx dmar support snafu
Despite the widespread and complete failure of Broadwell integrated
graphics when DMAR is enabled, known over the years, we have never been
able to root cause the issue. Instead, we let the failure undermine our
confidence in the iommu system itself when we should be pushing for it to
be always enabled. Quirk away Broadwell and remove the rotten apple.
References: https://bugs.freedesktop.org/show_bug.cgi?id=89360
Signed-off-by: Chris Wilson
Cc: Lu Baolu
Cc: Martin Peres
Cc: Joerg Roedel
Acked-by: Mika Kuoppala
---
drivers/iommu/intel-iommu.c | 44 +
1 file changed, 35 insertions(+), 9 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index c4e0e4a9ee9e..34f6a3d93ae2 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -5690,20 +5690,46 @@ const struct iommu_ops intel_iommu_ops = {
.pgsize_bitmap = INTEL_IOMMU_PGSIZES,
};
-static void quirk_iommu_g4x_gfx(struct pci_dev *dev)
+static void quirk_iommu_igfx(struct pci_dev *dev)
{
- /* G4x/GM45 integrated gfx dmar support is totally busted. */
pci_info(dev, "Disabling IOMMU for graphics on this chipset\n");
dmar_map_gfx = 0;
}
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2a40, quirk_iommu_g4x_gfx);
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e00, quirk_iommu_g4x_gfx);
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e10, quirk_iommu_g4x_gfx);
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e20, quirk_iommu_g4x_gfx);
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e30, quirk_iommu_g4x_gfx);
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e40, quirk_iommu_g4x_gfx);
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e90, quirk_iommu_g4x_gfx);
+/* G4x/GM45 integrated gfx dmar support is totally busted. */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2a40, quirk_iommu_igfx);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e00, quirk_iommu_igfx);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e10, quirk_iommu_igfx);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e20, quirk_iommu_igfx);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e30, quirk_iommu_igfx);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e40, quirk_iommu_igfx);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e90, quirk_iommu_igfx);
+
+/* Broadwell igfx malfunctions with dmar */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x1606, quirk_iommu_igfx);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x160B, quirk_iommu_igfx);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x160E, quirk_iommu_igfx);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x1602, quirk_iommu_igfx);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x160A, quirk_iommu_igfx);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x160D, quirk_iommu_igfx);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x1616, quirk_iommu_igfx);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x161B, quirk_iommu_igfx);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x161E, quirk_iommu_igfx);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x1612, quirk_iommu_igfx);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x161A, quirk_iommu_igfx);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x161D, quirk_iommu_igfx);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x1626, quirk_iommu_igfx);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x162B, quirk_iommu_igfx);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x162E, quirk_iommu_igfx);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x1622, quirk_iommu_igfx);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x162A, quirk_iommu_igfx);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x162D, quirk_iommu_igfx);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x1636, quirk_iommu_igfx);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x163B, quirk_iommu_igfx);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x163E, quirk_iommu_igfx);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x1632, quirk_iommu_igfx);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x163A, quirk_iommu_igfx);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x163D, quirk_iommu_igfx);
static void quirk_iommu_rwbf(struct pci_dev *dev)
{
--
2.23.0
___
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/execlists: Clear STOP_RING bit on reset (rev2)
== Series Details == Series: drm/i915/execlists: Clear STOP_RING bit on reset (rev2) URL : https://patchwork.freedesktop.org/series/66473/ State : success == Summary == CI Bug Log - changes from CI_DRM_6857_full -> Patchwork_14336_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14336_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_schedule@pi-ringfull-bsd: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#111325]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6857/shard-iclb5/igt@gem_exec_sched...@pi-ringfull-bsd.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14336/shard-iclb2/igt@gem_exec_sched...@pi-ringfull-bsd.html * igt@gem_exec_schedule@promotion-bsd1: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276]) +16 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6857/shard-iclb4/igt@gem_exec_sched...@promotion-bsd1.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14336/shard-iclb5/igt@gem_exec_sched...@promotion-bsd1.html * igt@gem_workarounds@suspend-resume-context: - shard-skl: [PASS][5] -> [INCOMPLETE][6] ([fdo#104108]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6857/shard-skl3/igt@gem_workarou...@suspend-resume-context.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14336/shard-skl1/igt@gem_workarou...@suspend-resume-context.html * igt@i915_suspend@fence-restore-tiled2untiled: - shard-apl: [PASS][7] -> [DMESG-WARN][8] ([fdo#108566]) +3 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6857/shard-apl5/igt@i915_susp...@fence-restore-tiled2untiled.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14336/shard-apl8/igt@i915_susp...@fence-restore-tiled2untiled.html * igt@kms_atomic_transition@1x-modeset-transitions-fencing: - shard-apl: [PASS][9] -> [INCOMPLETE][10] ([fdo#103927]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6857/shard-apl6/igt@kms_atomic_transit...@1x-modeset-transitions-fencing.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14336/shard-apl5/igt@kms_atomic_transit...@1x-modeset-transitions-fencing.html * igt@kms_cursor_crc@pipe-b-cursor-128x128-offscreen: - shard-iclb: [PASS][11] -> [INCOMPLETE][12] ([fdo#107713]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6857/shard-iclb5/igt@kms_cursor_...@pipe-b-cursor-128x128-offscreen.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14336/shard-iclb7/igt@kms_cursor_...@pipe-b-cursor-128x128-offscreen.html * igt@kms_cursor_crc@pipe-b-cursor-64x64-sliding: - shard-snb: [PASS][13] -> [SKIP][14] ([fdo#109271]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6857/shard-snb1/igt@kms_cursor_...@pipe-b-cursor-64x64-sliding.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14336/shard-snb2/igt@kms_cursor_...@pipe-b-cursor-64x64-sliding.html * igt@kms_cursor_edge_walk@pipe-b-128x128-right-edge: - shard-snb: [PASS][15] -> [SKIP][16] ([fdo#109271] / [fdo#109278]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6857/shard-snb1/igt@kms_cursor_edge_w...@pipe-b-128x128-right-edge.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14336/shard-snb2/igt@kms_cursor_edge_w...@pipe-b-128x128-right-edge.html * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy: - shard-hsw: [PASS][17] -> [FAIL][18] ([fdo#105767]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6857/shard-hsw7/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14336/shard-hsw4/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html * igt@kms_cursor_legacy@cursor-vs-flip-atomic: - shard-hsw: [PASS][19] -> [FAIL][20] ([fdo#103355]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6857/shard-hsw1/igt@kms_cursor_leg...@cursor-vs-flip-atomic.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14336/shard-hsw8/igt@kms_cursor_leg...@cursor-vs-flip-atomic.html * igt@kms_fbcon_fbt@psr: - shard-skl: [PASS][21] -> [DMESG-WARN][22] ([fdo#106107]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6857/shard-skl6/igt@kms_fbcon_...@psr.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14336/shard-skl1/igt@kms_fbcon_...@psr.html * igt@kms_frontbuffer_tracking@basic: - shard-iclb: [PASS][23] -> [FAIL][24] ([fdo#103167]) +2 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6857/shard-iclb7/igt@kms_frontbuffer_track...@basic.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14336/shard-iclb4/igt@kms_frontbuffer_track.
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Use a high priority wq for nonblocking plane updates
== Series Details ==
Series: drm/i915: Use a high priority wq for nonblocking plane updates
URL : https://patchwork.freedesktop.org/series/66485/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6860 -> Patchwork_14340
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14340/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_14340:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_suspend@basic-s4-devices:
- {fi-tgl-u}: NOTRUN -> [INCOMPLETE][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14340/fi-tgl-u/igt@gem_exec_susp...@basic-s4-devices.html
Known issues
Here are the changes found in Patchwork_14340 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload:
- fi-icl-u3: [PASS][2] -> [DMESG-WARN][3] ([fdo#107724] /
[fdo#111214])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/fi-icl-u3/igt@i915_module_l...@reload.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14340/fi-icl-u3/igt@i915_module_l...@reload.html
Possible fixes
* igt@gem_exec_gttfill@basic:
- {fi-tgl-u}: [INCOMPLETE][4] ([fdo#111593]) -> [PASS][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/fi-tgl-u/igt@gem_exec_gttf...@basic.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14340/fi-tgl-u/igt@gem_exec_gttf...@basic.html
* igt@i915_module_load@reload:
- fi-blb-e6850: [INCOMPLETE][6] ([fdo#107718]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/fi-blb-e6850/igt@i915_module_l...@reload.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14340/fi-blb-e6850/igt@i915_module_l...@reload.html
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: [DMESG-WARN][8] ([fdo#102614]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14340/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
* igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- {fi-icl-dsi}: [DMESG-WARN][10] ([fdo#106107]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/fi-icl-dsi/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14340/fi-icl-dsi/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
* igt@prime_vgem@basic-fence-mmap:
- fi-icl-u3: [DMESG-WARN][12] ([fdo#107724]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/fi-icl-u3/igt@prime_v...@basic-fence-mmap.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14340/fi-icl-u3/igt@prime_v...@basic-fence-mmap.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#111214]: https://bugs.freedesktop.org/show_bug.cgi?id=111214
[fdo#111593]: https://bugs.freedesktop.org/show_bug.cgi?id=111593
Participating hosts (53 -> 47)
--
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y
fi-byt-clapper
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6860 -> Patchwork_14340
CI-20190529: 20190529
CI_DRM_6860: 33c00059b084f42f01a168b5f67e4df670293e2c @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5177: 8f351d693352d21c96cef38c3fd77f778c6d7c33 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14340: a9ae0bdb3315d83c884e77f50ca8d98b4808b537 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
a9ae0bdb3315 drm/i915: Use a high priority wq for nonblocking plane updates
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14340/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: 5.3-rc3: Frozen graphics with kcompactd migrating i915 pages
On Fri, Aug 09, 2019 at 01:53:43PM +0100, Chris Wilson wrote:
> Quoting Martin Wilck (2019-08-09 13:41:42)
> > This happened to me today, running kernel 5.3.0-rc3-1.g571863b-default
> > (5.3-rc3 with just a few patches on top), after starting a KVM virtual
> > machine. The X screen was frozen. Remote login via ssh was still
> > possible, thus I was able to retrieve basic logs.
> >
> > sysrq-w showed two blocked processes (kcompactd0 and KVM). After a
> > minute, the same two processes were still blocked. KVM seems to try to
> > acquire a lock that kcompactd is holding. kcompactd is waiting for IO
> > to complete on pages owned by the i915 driver.
>
> My bad, it's known. We haven't decided on whether to revert the
> unfortunate recursive locking (and so hit another warn elsewhere) or to
> ignore the dirty pages (and so risk losing data across swap).
>
> cb6d7c7dc7ff ("drm/i915/userptr: Acquire the page lock around
> set_page_dirty()")
> -Chris
Hi Chris. Is this exactly what I'm hitting at
https://bugs.freedesktop.org/show_bug.cgi?id=111500 perhaps?
It reliably breaks the graphics userland, as the machine consistently
freezes at any random moment.
Any workaround options, even if with a performance penalty? Revert
cb6d7c7dc7ff but side effects?
5.3 has useful NVMe power mgmt updates for laptops, I'd like to stick
with the newest if possible.
--
Leho Kraav, senior technology & digital marketing architect
[Intel-gfx] [PATCH] drm/i915: Force compilation with intel-iommu for CI validation
Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/Kconfig.debug | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/i915/Kconfig.debug b/drivers/gpu/drm/i915/Kconfig.debug index 00786a142ff0..c5c00cad6ba1 100644 --- a/drivers/gpu/drm/i915/Kconfig.debug +++ b/drivers/gpu/drm/i915/Kconfig.debug @@ -20,6 +20,13 @@ config DRM_I915_WERROR config DRM_I915_DEBUG bool "Enable additional driver debugging" depends on DRM_I915 + select PCI_MSI + select IOMMU_API + select IOMMU_IOVA + select NEED_DMA_MAP_STATE + select DMAR_TABLE + select INTEL_IOMMU + select INTEL_IOMMU_DEFAULT_ON select DEBUG_FS select PREEMPT_COUNT select REFCOUNT_FULL -- 2.23.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with drm/i915: Force compilation with intel-iommu for CI validation (rev2)
== Series Details == Series: series starting with drm/i915: Force compilation with intel-iommu for CI validation (rev2) URL : https://patchwork.freedesktop.org/series/66487/ State : warning == Summary == $ dim checkpatch origin/drm-tip f0df04b62a3b drm/i915: Force compilation with intel-iommu for CI validation -:8: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one total: 0 errors, 1 warnings, 0 checks, 13 lines checked 4d7e17c9a6b3 iommu/intel: Declare Broadwell igfx dmar support snafu 05b66dedf0bb iommu/intel: Ignore igfx_off -:8: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one -:19: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s) total: 1 errors, 1 warnings, 0 checks, 8 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm/i915: Move GT init to intel_gt.c
From: Tvrtko Ursulin
Code in i915_gem_init_hw is all about GT init so move it to intel_gt.c
renaming to intel_gt_init_hw.
Existing intel_gt_init_hw is renamed to intel_gt_init_hw_early since it
is currently called from driver probe.
Signed-off-by: Tvrtko Ursulin
Cc: Andi Shyti
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_pm.c| 2 +-
drivers/gpu/drm/i915/gt/intel_gt.c| 92 ++-
drivers/gpu/drm/i915/gt/intel_gt.h| 3 +-
drivers/gpu/drm/i915/gt/intel_reset.c | 2 +-
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/i915_gem.c | 91 +-
drivers/gpu/drm/i915/selftests/mock_gtt.c | 2 +-
8 files changed, 98 insertions(+), 97 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
index 9b1129aaacfe..3bd764104d41 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
@@ -242,7 +242,7 @@ void i915_gem_resume(struct drm_i915_private *i915)
mutex_lock(&i915->drm.struct_mutex);
intel_uncore_forcewake_get(&i915->uncore, FORCEWAKE_ALL);
- if (i915_gem_init_hw(i915))
+ if (intel_gt_init_hw(&i915->gt))
goto err_wedged;
/*
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index e2cc697d27fb..eef9bdae8ebb 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -6,6 +6,7 @@
#include "i915_drv.h"
#include "intel_gt.h"
#include "intel_gt_pm.h"
+#include "intel_mocs.h"
#include "intel_uncore.h"
#include "intel_pm.h"
@@ -25,7 +26,7 @@ void intel_gt_init_early(struct intel_gt *gt, struct
drm_i915_private *i915)
intel_uc_init_early(>->uc);
}
-void intel_gt_init_hw(struct drm_i915_private *i915)
+void intel_gt_init_hw_early(struct drm_i915_private *i915)
{
i915->gt.ggtt = &i915->ggtt;
@@ -33,6 +34,95 @@ void intel_gt_init_hw(struct drm_i915_private *i915)
intel_gt_pm_disable(&i915->gt);
}
+static void init_unused_ring(struct intel_gt *gt, u32 base)
+{
+ struct intel_uncore *uncore = gt->uncore;
+
+ intel_uncore_write(uncore, RING_CTL(base), 0);
+ intel_uncore_write(uncore, RING_HEAD(base), 0);
+ intel_uncore_write(uncore, RING_TAIL(base), 0);
+ intel_uncore_write(uncore, RING_START(base), 0);
+}
+
+static void init_unused_rings(struct intel_gt *gt)
+{
+ struct drm_i915_private *i915 = gt->i915;
+
+ if (IS_I830(i915)) {
+ init_unused_ring(gt, PRB1_BASE);
+ init_unused_ring(gt, SRB0_BASE);
+ init_unused_ring(gt, SRB1_BASE);
+ init_unused_ring(gt, SRB2_BASE);
+ init_unused_ring(gt, SRB3_BASE);
+ } else if (IS_GEN(i915, 2)) {
+ init_unused_ring(gt, SRB0_BASE);
+ init_unused_ring(gt, SRB1_BASE);
+ } else if (IS_GEN(i915, 3)) {
+ init_unused_ring(gt, PRB1_BASE);
+ init_unused_ring(gt, PRB2_BASE);
+ }
+}
+
+int intel_gt_init_hw(struct intel_gt *gt)
+{
+ struct drm_i915_private *i915 = gt->i915;
+ struct intel_uncore *uncore = gt->uncore;
+ int ret;
+
+ BUG_ON(!i915->kernel_context);
+ ret = intel_gt_terminally_wedged(gt);
+ if (ret)
+ return ret;
+
+ gt->last_init_time = ktime_get();
+
+ /* Double layer security blanket, see i915_gem_init() */
+ intel_uncore_forcewake_get(uncore, FORCEWAKE_ALL);
+
+ if (HAS_EDRAM(i915) && INTEL_GEN(i915) < 9)
+ intel_uncore_rmw(uncore, HSW_IDICR, 0, IDIHASHMSK(0xf));
+
+ if (IS_HASWELL(i915))
+ intel_uncore_write(uncore,
+ MI_PREDICATE_RESULT_2,
+ IS_HSW_GT3(i915) ?
+ LOWER_SLICE_ENABLED : LOWER_SLICE_DISABLED);
+
+ /* Apply the GT workarounds... */
+ intel_gt_apply_workarounds(gt);
+ /* ...and determine whether they are sticking. */
+ intel_gt_verify_workarounds(gt, "init");
+
+ intel_gt_init_swizzling(gt);
+
+ /*
+* At least 830 can leave some of the unused rings
+* "active" (ie. head != tail) after resume which
+* will prevent c3 entry. Makes sure all unused rings
+* are totally idle.
+*/
+ init_unused_rings(gt);
+
+ ret = i915_ppgtt_init_hw(gt);
+ if (ret) {
+ DRM_ERROR("Enabling PPGTT failed (%d)\n", ret);
+ goto out;
+ }
+
+ /* We can't enable contexts until all firmware is loaded */
+ ret = intel_uc_init_hw(>->uc);
+ if (ret) {
+ i915_probe_error(i915, "Enabling uc failed (%d)\n", ret);
+ goto out;
+ }
+
+ intel_mocs_init(gt);
+
+out:
+ intel_uncore_forcewake_put(uncore, FORCEWAKE_ALL);
+ return r
[Intel-gfx] [PATCH 2/4] drm/i915: Make wait_for_timelines take struct intel_gt
From: Tvrtko Ursulin
Timelines live in struct intel_gt so make wait_for_timelines take
exactly what it needs.
Signed-off-by: Tvrtko Ursulin
Cc: Andi Shyti
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index db2681514a0b..2da9544fa9a4 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -888,10 +888,9 @@ void i915_gem_runtime_suspend(struct drm_i915_private
*i915)
}
static long
-wait_for_timelines(struct drm_i915_private *i915,
- unsigned int wait, long timeout)
+wait_for_timelines(struct intel_gt *gt, unsigned int wait, long timeout)
{
- struct intel_gt_timelines *timelines = &i915->gt.timelines;
+ struct intel_gt_timelines *timelines = >->timelines;
struct intel_timeline *tl;
unsigned long flags;
@@ -934,15 +933,17 @@ wait_for_timelines(struct drm_i915_private *i915,
int i915_gem_wait_for_idle(struct drm_i915_private *i915,
unsigned int flags, long timeout)
{
+ struct intel_gt *gt = &i915->gt;
+
/* If the device is asleep, we have no requests outstanding */
- if (!intel_gt_pm_is_awake(&i915->gt))
+ if (!intel_gt_pm_is_awake(gt))
return 0;
GEM_TRACE("flags=%x (%s), timeout=%ld%s\n",
flags, flags & I915_WAIT_LOCKED ? "locked" : "unlocked",
timeout, timeout == MAX_SCHEDULE_TIMEOUT ? " (forever)" : "");
- timeout = wait_for_timelines(i915, flags, timeout);
+ timeout = wait_for_timelines(gt, flags, timeout);
if (timeout < 0)
return timeout;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/i915: Avoid round-trip via i915 in intel_gt_park
From: Tvrtko Ursulin
Both in the container_of and getting to gt->awake there is no need to go
via i915 since both the wakeref and awake are members of gt.
Signed-off-by: Tvrtko Ursulin
Cc: Andi Shyti
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_gt_pm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
index 6ba0d2069f87..a2e29bcc9671 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -56,9 +56,9 @@ static int __gt_unpark(struct intel_wakeref *wf)
static int __gt_park(struct intel_wakeref *wf)
{
- struct drm_i915_private *i915 =
- container_of(wf, typeof(*i915), gt.wakeref);
- intel_wakeref_t wakeref = fetch_and_zero(&i915->gt.awake);
+ struct intel_gt *gt = container_of(wf, typeof(*gt), wakeref);
+ intel_wakeref_t wakeref = fetch_and_zero(>->awake);
+ struct drm_i915_private *i915 = gt->i915;
GEM_TRACE("\n");
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/4] Few loose end intel_gt cleanups
From: Tvrtko Ursulin A few patches left hanging since late July. First one old in spirit but adjusted and renamed and the rest update for latest drm-tip. Happy to receive thoughts on whether this cleanup makes sense. Cc: Andi Shyti Cc: Chris Wilson Tvrtko Ursulin (4): drm/i915: Move GT init to intel_gt.c drm/i915: Make wait_for_timelines take struct intel_gt drm/i915: Avoid round-trip via i915 in intel_gt_park drm/i915: Make pm_notify take intel_gt drivers/gpu/drm/i915/gem/i915_gem_pm.c| 2 +- drivers/gpu/drm/i915/gt/intel_gt.c| 92 ++- drivers/gpu/drm/i915/gt/intel_gt.h| 3 +- drivers/gpu/drm/i915/gt/intel_gt_pm.c | 14 +-- drivers/gpu/drm/i915/gt/intel_reset.c | 2 +- drivers/gpu/drm/i915/i915_drv.c | 2 +- drivers/gpu/drm/i915/i915_drv.h | 1 - drivers/gpu/drm/i915/i915_gem.c | 102 ++ drivers/gpu/drm/i915/selftests/mock_gtt.c | 2 +- 9 files changed, 111 insertions(+), 109 deletions(-) -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] drm/i915: Make pm_notify take intel_gt
From: Tvrtko Ursulin
These notifications operate on intel_gt so make the code take what it
needs.
Signed-off-by: Tvrtko Ursulin
Cc: Andi Shyti
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_gt_pm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
index a2e29bcc9671..2ccf8cacaa0a 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -13,9 +13,9 @@
#include "intel_pm.h"
#include "intel_wakeref.h"
-static void pm_notify(struct drm_i915_private *i915, int state)
+static void pm_notify(struct intel_gt *gt, int state)
{
- blocking_notifier_call_chain(&i915->gt.pm_notifications, state, i915);
+ blocking_notifier_call_chain(>->pm_notifications, state, gt->i915);
}
static int __gt_unpark(struct intel_wakeref *wf)
@@ -49,7 +49,7 @@ static int __gt_unpark(struct intel_wakeref *wf)
intel_gt_queue_hangcheck(gt);
- pm_notify(i915, INTEL_GT_UNPARK);
+ pm_notify(gt, INTEL_GT_UNPARK);
return 0;
}
@@ -62,7 +62,7 @@ static int __gt_park(struct intel_wakeref *wf)
GEM_TRACE("\n");
- pm_notify(i915, INTEL_GT_PARK);
+ pm_notify(gt, INTEL_GT_PARK);
i915_pmu_gt_parked(i915);
if (INTEL_GEN(i915) >= 6)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Few loose end intel_gt cleanups
== Series Details == Series: Few loose end intel_gt cleanups URL : https://patchwork.freedesktop.org/series/66490/ State : warning == Summary == $ dim checkpatch origin/drm-tip 4144570a45a2 drm/i915: Move GT init to intel_gt.c -:89: WARNING:AVOID_BUG: Avoid crashing the kernel - try using WARN_ON & recovery code rather than BUG() or BUG_ON() #89: FILE: drivers/gpu/drm/i915/gt/intel_gt.c:72: + BUG_ON(!i915->kernel_context); total: 0 errors, 1 warnings, 0 checks, 261 lines checked 98290456e271 drm/i915: Make wait_for_timelines take struct intel_gt f3e26c80db02 drm/i915: Avoid round-trip via i915 in intel_gt_park ec71271e3802 drm/i915: Make pm_notify take intel_gt ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915: Move GT init to intel_gt.c
Quoting Tvrtko Ursulin (2019-09-10 15:38:20) > From: Tvrtko Ursulin > > Code in i915_gem_init_hw is all about GT init so move it to intel_gt.c > renaming to intel_gt_init_hw. > > Existing intel_gt_init_hw is renamed to intel_gt_init_hw_early since it > is currently called from driver probe. > > Signed-off-by: Tvrtko Ursulin > Cc: Andi Shyti > Cc: Chris Wilson 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/4] drm/i915: Make wait_for_timelines take struct intel_gt
Quoting Tvrtko Ursulin (2019-09-10 15:38:21) > From: Tvrtko Ursulin > > Timelines live in struct intel_gt so make wait_for_timelines take > exactly what it needs. > > Signed-off-by: Tvrtko Ursulin > Cc: Andi Shyti > Cc: Chris Wilson I've deleted this code, fwiw, merged it with request management and ended up with intel_gt_retire_requests() Still, 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 3/4] drm/i915: Avoid round-trip via i915 in intel_gt_park
Quoting Tvrtko Ursulin (2019-09-10 15:38:22) > From: Tvrtko Ursulin > > Both in the container_of and getting to gt->awake there is no need to go > via i915 since both the wakeref and awake are members of gt. > > Signed-off-by: Tvrtko Ursulin > Cc: Andi Shyti > Cc: Chris Wilson Have same chunk somewhere as well, Reviewed-by: Chris Wilson -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 series starting with drm/i915: Force compilation with intel-iommu for CI validation (rev2)
== Series Details ==
Series: series starting with drm/i915: Force compilation with intel-iommu for
CI validation (rev2)
URL : https://patchwork.freedesktop.org/series/66487/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6861 -> Patchwork_14341
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14341/
Known issues
Here are the changes found in Patchwork_14341 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_switch@legacy-render:
- fi-apl-guc: [PASS][1] -> [INCOMPLETE][2] ([fdo#103927] /
[fdo#111381])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6861/fi-apl-guc/igt@gem_ctx_swi...@legacy-render.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14341/fi-apl-guc/igt@gem_ctx_swi...@legacy-render.html
* igt@gem_flink_basic@flink-lifetime:
- fi-icl-u3: [PASS][3] -> [DMESG-WARN][4] ([fdo#107724]) +1
similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6861/fi-icl-u3/igt@gem_flink_ba...@flink-lifetime.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14341/fi-icl-u3/igt@gem_flink_ba...@flink-lifetime.html
* igt@kms_frontbuffer_tracking@basic:
- fi-icl-u3: [PASS][5] -> [FAIL][6] ([fdo#103167])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6861/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14341/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html
Possible fixes
* igt@gem_ctx_switch@legacy-render:
- {fi-icl-guc}: [INCOMPLETE][7] ([fdo#107713] / [fdo#111381]) ->
[PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6861/fi-icl-guc/igt@gem_ctx_swi...@legacy-render.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14341/fi-icl-guc/igt@gem_ctx_swi...@legacy-render.html
- fi-icl-u2: [INCOMPLETE][9] ([fdo#107713] / [fdo#111381]) ->
[PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6861/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14341/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html
* igt@gem_render_tiled_blits@basic:
- fi-icl-u3: [DMESG-WARN][11] ([fdo#107724]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6861/fi-icl-u3/igt@gem_render_tiled_bl...@basic.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14341/fi-icl-u3/igt@gem_render_tiled_bl...@basic.html
* igt@i915_selftest@live_execlists:
- fi-skl-gvtdvm: [DMESG-FAIL][13] ([fdo#08]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6861/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14341/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
* igt@kms_chamelium@dp-edid-read:
- {fi-icl-u4}:[FAIL][15] ([fdo#111045]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6861/fi-icl-u4/igt@kms_chamel...@dp-edid-read.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14341/fi-icl-u4/igt@kms_chamel...@dp-edid-read.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#08]: https://bugs.freedesktop.org/show_bug.cgi?id=08
[fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381
Participating hosts (54 -> 47)
--
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y
fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6861 -> Patchwork_14341
CI-20190529: 20190529
CI_DRM_6861: 32c81a3173640f165510de65b8e4137aa049b33f @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5178: efb4539494d94f03374874d3b61bd04ef3802aaa @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14341: 05b66dedf0bbeab4dfde17ef049ec4a6e55ba070 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
05b66dedf0bb iommu/intel: Ignore igfx_off
4d7e17c9a6b3 iommu/intel: Declare Broadwell igfx dmar support snafu
f0df04b62a3b drm/i915: Force compilation with intel-iommu for CI validation
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14341/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Make pm_notify take intel_gt
Quoting Tvrtko Ursulin (2019-09-10 15:38:23) > From: Tvrtko Ursulin > > These notifications operate on intel_gt so make the code take what it > needs. > > Signed-off-by: Tvrtko Ursulin > Cc: Andi Shyti > Cc: Chris Wilson Soon the blocking_notifier will be relieved of duty... I think it might be better if we pass gt to the notify_cb and have it extract its i915 from that, but my goal is to remove it, so it really doesn't matter! Reviewed-by: Chris Wilson -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 Few loose end intel_gt cleanups
== Series Details ==
Series: Few loose end intel_gt cleanups
URL : https://patchwork.freedesktop.org/series/66490/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6861 -> Patchwork_14342
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14342/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_14342:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_sync@basic-each:
- {fi-tgl-u}: NOTRUN -> [INCOMPLETE][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14342/fi-tgl-u/igt@gem_s...@basic-each.html
Known issues
Here are the changes found in Patchwork_14342 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_basic@create-close:
- fi-icl-u3: [PASS][2] -> [DMESG-WARN][3] ([fdo#107724]) +1
similar issue
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6861/fi-icl-u3/igt@gem_ba...@create-close.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14342/fi-icl-u3/igt@gem_ba...@create-close.html
Possible fixes
* igt@gem_ctx_switch@legacy-render:
- {fi-icl-guc}: [INCOMPLETE][4] ([fdo#107713] / [fdo#111381]) ->
[PASS][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6861/fi-icl-guc/igt@gem_ctx_swi...@legacy-render.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14342/fi-icl-guc/igt@gem_ctx_swi...@legacy-render.html
- fi-icl-u2: [INCOMPLETE][6] ([fdo#107713] / [fdo#111381]) ->
[PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6861/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14342/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html
* igt@gem_exec_gttfill@basic:
- {fi-tgl-u}: [INCOMPLETE][8] ([fdo#111593]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6861/fi-tgl-u/igt@gem_exec_gttf...@basic.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14342/fi-tgl-u/igt@gem_exec_gttf...@basic.html
* igt@gem_render_tiled_blits@basic:
- fi-icl-u3: [DMESG-WARN][10] ([fdo#107724]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6861/fi-icl-u3/igt@gem_render_tiled_bl...@basic.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14342/fi-icl-u3/igt@gem_render_tiled_bl...@basic.html
* igt@i915_selftest@live_execlists:
- fi-skl-gvtdvm: [DMESG-FAIL][12] ([fdo#08]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6861/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14342/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
Warnings
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][14] ([fdo#111096]) -> [FAIL][15] ([fdo#111407])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6861/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14342/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#08]: https://bugs.freedesktop.org/show_bug.cgi?id=08
[fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
[fdo#111593]: https://bugs.freedesktop.org/show_bug.cgi?id=111593
Participating hosts (54 -> 46)
--
Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-gdg-551 fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6861 -> Patchwork_14342
CI-20190529: 20190529
CI_DRM_6861: 32c81a3173640f165510de65b8e4137aa049b33f @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5178: efb4539494d94f03374874d3b61bd04ef3802aaa @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14342: ec71271e3802895ae608065d4914d63157adae2c @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
ec71271e3802 drm/i915: Make pm_notify take intel_gt
f3e26c80db02 drm/i915: Avoid round-trip via i915 in intel_gt_park
98290456e271 drm/i915: Make wait_for_timelines take struct intel_gt
4144570a45a2 drm/i915: Move GT init to intel_gt.c
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Pat
[Intel-gfx] [PATCH] drm/i915/tgl: Disable rc6 for debugging
References: https://bugs.freedesktop.org/show_bug.cgi?id=111593
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_pci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index fbe98a2db88e..b3cc8560696b 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -797,6 +797,7 @@ static const struct intel_device_info
intel_tigerlake_12_info = {
.display.has_modular_fia = 1,
.engine_mask =
BIT(RCS0) | BIT(BCS0) | BIT(VECS0) | BIT(VCS0) | BIT(VCS2),
+ .has_rc6 = false, /* XXX disabled for debugging */
};
#undef GEN
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 0/8] cdclk consolidation and rework for BXT-TGL
Previous version of the series was here:
https://lists.freedesktop.org/archives/intel-gfx/2019-September/211853.html
This version incorporates Ville's comments, most of which are on the
second patch where we introduce the cdclk tables. The structure and
parsing of the tables is now done in a cleaner and more future-proof
manner.
Cc: Ville Syrjälä
Matt Roper (8):
drm/i915: Consolidate bxt/cnl/icl cdclk readout
drm/i915: Use literal representation of cdclk tables
drm/i915: Combine bxt_set_cdclk and cnl_set_cdclk
drm/i915: Kill cnl_sanitize_cdclk()
drm/i915: Consolidate {bxt,cnl,icl}_uninit_cdclk
drm/i915: Add calc_voltage_level display vfunc
drm/i915: Enhance cdclk sanitization
drm/i915: Consolidate {bxt,cnl,icl}_init_cdclk
drivers/gpu/drm/i915/display/intel_cdclk.c | 965 +++--
drivers/gpu/drm/i915/display/intel_cdclk.h | 7 +
drivers/gpu/drm/i915/i915_drv.h| 4 +
3 files changed, 345 insertions(+), 631 deletions(-)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 5/8] drm/i915: Consolidate {bxt, cnl, icl}_uninit_cdclk
The uninitialize flow is the same on all of these platforms, aside from
calculating a different frequency level.
v2: Reverse platform conditional order for consistency. (Ville)
Cc: Ville Syrjälä
Signed-off-by: Matt Roper
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 48 +++---
1 file changed, 14 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 3c763c70ebea..518cc95456d3 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -1683,7 +1683,18 @@ static void bxt_uninit_cdclk(struct drm_i915_private
*dev_priv)
cdclk_state.cdclk = cdclk_state.bypass;
cdclk_state.vco = 0;
- cdclk_state.voltage_level = bxt_calc_voltage_level(cdclk_state.cdclk);
+ if (IS_ELKHARTLAKE(dev_priv))
+ cdclk_state.voltage_level =
+ ehl_calc_voltage_level(cdclk_state.cdclk);
+ else if (INTEL_GEN(dev_priv) >= 11)
+ cdclk_state.voltage_level =
+ icl_calc_voltage_level(cdclk_state.cdclk);
+ else if (INTEL_GEN(dev_priv) >= 10)
+ cdclk_state.voltage_level =
+ cnl_calc_voltage_level(cdclk_state.cdclk);
+ else
+ cdclk_state.voltage_level =
+ bxt_calc_voltage_level(cdclk_state.cdclk);
bxt_set_cdclk(dev_priv, &cdclk_state, INVALID_PIPE);
}
@@ -1729,22 +1740,6 @@ static void icl_init_cdclk(struct drm_i915_private
*dev_priv)
bxt_set_cdclk(dev_priv, &sanitized_state, INVALID_PIPE);
}
-static void icl_uninit_cdclk(struct drm_i915_private *dev_priv)
-{
- struct intel_cdclk_state cdclk_state = dev_priv->cdclk.hw;
-
- cdclk_state.cdclk = cdclk_state.bypass;
- cdclk_state.vco = 0;
- if (IS_ELKHARTLAKE(dev_priv))
- cdclk_state.voltage_level =
- ehl_calc_voltage_level(cdclk_state.cdclk);
- else
- cdclk_state.voltage_level =
- icl_calc_voltage_level(cdclk_state.cdclk);
-
- bxt_set_cdclk(dev_priv, &cdclk_state, INVALID_PIPE);
-}
-
static void cnl_init_cdclk(struct drm_i915_private *dev_priv)
{
struct intel_cdclk_state cdclk_state;
@@ -1764,17 +1759,6 @@ static void cnl_init_cdclk(struct drm_i915_private
*dev_priv)
bxt_set_cdclk(dev_priv, &cdclk_state, INVALID_PIPE);
}
-static void cnl_uninit_cdclk(struct drm_i915_private *dev_priv)
-{
- struct intel_cdclk_state cdclk_state = dev_priv->cdclk.hw;
-
- cdclk_state.cdclk = cdclk_state.bypass;
- cdclk_state.vco = 0;
- cdclk_state.voltage_level = cnl_calc_voltage_level(cdclk_state.cdclk);
-
- bxt_set_cdclk(dev_priv, &cdclk_state, INVALID_PIPE);
-}
-
/**
* intel_cdclk_init - Initialize CDCLK
* @i915: i915 device
@@ -1805,14 +1789,10 @@ void intel_cdclk_init(struct drm_i915_private *i915)
*/
void intel_cdclk_uninit(struct drm_i915_private *i915)
{
- if (INTEL_GEN(i915) >= 11)
- icl_uninit_cdclk(i915);
- else if (IS_CANNONLAKE(i915))
- cnl_uninit_cdclk(i915);
+ if (INTEL_GEN(i915) >= 10 || IS_GEN9_LP(i915))
+ bxt_uninit_cdclk(i915);
else if (IS_GEN9_BC(i915))
skl_uninit_cdclk(i915);
- else if (IS_GEN9_LP(i915))
- bxt_uninit_cdclk(i915);
}
/**
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 6/8] drm/i915: Add calc_voltage_level display vfunc
With all of the cdclk function consolidation, we can cut down on a lot
of platform if/else logic by creating a vfunc that's initialized at
startup.
Cc: Ville Syrjälä
Signed-off-by: Matt Roper
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 75 --
drivers/gpu/drm/i915/i915_drv.h| 1 +
2 files changed, 27 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 518cc95456d3..cb2fc68c9335 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -1394,18 +1394,8 @@ static void bxt_get_cdclk(struct drm_i915_private
*dev_priv,
* Can't read this out :( Let's assume it's
* at least what the CDCLK frequency requires.
*/
- if (IS_ELKHARTLAKE(dev_priv))
- cdclk_state->voltage_level =
- ehl_calc_voltage_level(cdclk_state->cdclk);
- else if (INTEL_GEN(dev_priv) >= 11)
- cdclk_state->voltage_level =
- icl_calc_voltage_level(cdclk_state->cdclk);
- else if (INTEL_GEN(dev_priv) >= 10)
- cdclk_state->voltage_level =
- cnl_calc_voltage_level(cdclk_state->cdclk);
- else
- cdclk_state->voltage_level =
- bxt_calc_voltage_level(cdclk_state->cdclk);
+ cdclk_state->voltage_level =
+ dev_priv->display.calc_voltage_level(cdclk_state->cdclk);
}
static void bxt_de_pll_disable(struct drm_i915_private *dev_priv)
@@ -1672,7 +1662,8 @@ static void bxt_init_cdclk(struct drm_i915_private
*dev_priv)
*/
cdclk_state.cdclk = bxt_calc_cdclk(dev_priv, 0);
cdclk_state.vco = bxt_calc_cdclk_pll_vco(dev_priv, cdclk_state.cdclk);
- cdclk_state.voltage_level = bxt_calc_voltage_level(cdclk_state.cdclk);
+ cdclk_state.voltage_level =
+ dev_priv->display.calc_voltage_level(cdclk_state.cdclk);
bxt_set_cdclk(dev_priv, &cdclk_state, INVALID_PIPE);
}
@@ -1683,18 +1674,8 @@ static void bxt_uninit_cdclk(struct drm_i915_private
*dev_priv)
cdclk_state.cdclk = cdclk_state.bypass;
cdclk_state.vco = 0;
- if (IS_ELKHARTLAKE(dev_priv))
- cdclk_state.voltage_level =
- ehl_calc_voltage_level(cdclk_state.cdclk);
- else if (INTEL_GEN(dev_priv) >= 11)
- cdclk_state.voltage_level =
- icl_calc_voltage_level(cdclk_state.cdclk);
- else if (INTEL_GEN(dev_priv) >= 10)
- cdclk_state.voltage_level =
- cnl_calc_voltage_level(cdclk_state.cdclk);
- else
- cdclk_state.voltage_level =
- bxt_calc_voltage_level(cdclk_state.cdclk);
+ cdclk_state.voltage_level =
+ dev_priv->display.calc_voltage_level(cdclk_state.cdclk);
bxt_set_cdclk(dev_priv, &cdclk_state, INVALID_PIPE);
}
@@ -1730,12 +1711,8 @@ static void icl_init_cdclk(struct drm_i915_private
*dev_priv)
sanitized_state.cdclk = bxt_calc_cdclk(dev_priv, 0);
sanitized_state.vco = bxt_calc_cdclk_pll_vco(dev_priv,
sanitized_state.cdclk);
- if (IS_ELKHARTLAKE(dev_priv))
- sanitized_state.voltage_level =
- ehl_calc_voltage_level(sanitized_state.cdclk);
- else
- sanitized_state.voltage_level =
- icl_calc_voltage_level(sanitized_state.cdclk);
+ sanitized_state.voltage_level =
+ dev_priv->display.calc_voltage_level(sanitized_state.cdclk);
bxt_set_cdclk(dev_priv, &sanitized_state, INVALID_PIPE);
}
@@ -1754,7 +1731,8 @@ static void cnl_init_cdclk(struct drm_i915_private
*dev_priv)
cdclk_state.cdclk = bxt_calc_cdclk(dev_priv, 0);
cdclk_state.vco = bxt_calc_cdclk_pll_vco(dev_priv, cdclk_state.cdclk);
- cdclk_state.voltage_level = cnl_calc_voltage_level(cdclk_state.cdclk);
+ cdclk_state.voltage_level =
+ dev_priv->display.calc_voltage_level(cdclk_state.cdclk);
bxt_set_cdclk(dev_priv, &cdclk_state, INVALID_PIPE);
}
@@ -2246,7 +2224,7 @@ static int bxt_modeset_calc_cdclk(struct
intel_atomic_state *state)
state->cdclk.logical.vco = vco;
state->cdclk.logical.cdclk = cdclk;
state->cdclk.logical.voltage_level =
- bxt_calc_voltage_level(cdclk);
+ dev_priv->display.calc_voltage_level(cdclk);
if (!state->active_pipes) {
cdclk = bxt_calc_cdclk(dev_priv, state->cdclk.force_min_cdclk);
@@ -2255,7 +2233,7 @@ static int bxt_modeset_calc_cdclk(struct
intel_atomic_state *state)
state->cdclk.actual.vco = vco;
state->cdclk.actual.cdclk = cdclk;
state->cdclk.actual.voltage_level =
- bxt_calc_voltag
[Intel-gfx] [PATCH v4 3/8] drm/i915: Combine bxt_set_cdclk and cnl_set_cdclk
We'd previously combined ICL/TGL logic into the cnl_set_cdclk function,
but BXT is pretty similar as well. Roll the cnl/icl/tgl logic back into
the bxt function; the only things we really need to handle separately
are punit notification and calling different functions to enable/disable
the cdclk PLL.
Cc: Ville Syrjälä
Signed-off-by: Matt Roper
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 267 +
1 file changed, 119 insertions(+), 148 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index c8cf288b8e8e..14229c68d4be 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -1440,6 +1440,39 @@ static void bxt_de_pll_enable(struct drm_i915_private
*dev_priv, int vco)
dev_priv->cdclk.hw.vco = vco;
}
+static void cnl_cdclk_pll_disable(struct drm_i915_private *dev_priv)
+{
+ u32 val;
+
+ val = I915_READ(BXT_DE_PLL_ENABLE);
+ val &= ~BXT_DE_PLL_PLL_ENABLE;
+ I915_WRITE(BXT_DE_PLL_ENABLE, val);
+
+ /* Timeout 200us */
+ if (wait_for((I915_READ(BXT_DE_PLL_ENABLE) & BXT_DE_PLL_LOCK) == 0, 1))
+ DRM_ERROR("timeout waiting for CDCLK PLL unlock\n");
+
+ dev_priv->cdclk.hw.vco = 0;
+}
+
+static void cnl_cdclk_pll_enable(struct drm_i915_private *dev_priv, int vco)
+{
+ int ratio = DIV_ROUND_CLOSEST(vco, dev_priv->cdclk.hw.ref);
+ u32 val;
+
+ val = CNL_CDCLK_PLL_RATIO(ratio);
+ I915_WRITE(BXT_DE_PLL_ENABLE, val);
+
+ val |= BXT_DE_PLL_PLL_ENABLE;
+ I915_WRITE(BXT_DE_PLL_ENABLE, val);
+
+ /* Timeout 200us */
+ if (wait_for((I915_READ(BXT_DE_PLL_ENABLE) & BXT_DE_PLL_LOCK) != 0, 1))
+ DRM_ERROR("timeout waiting for CDCLK PLL lock\n");
+
+ dev_priv->cdclk.hw.vco = vco;
+}
+
static void bxt_set_cdclk(struct drm_i915_private *dev_priv,
const struct intel_cdclk_state *cdclk_state,
enum pipe pipe)
@@ -1449,6 +1482,27 @@ static void bxt_set_cdclk(struct drm_i915_private
*dev_priv,
u32 val, divider;
int ret;
+ /* Inform power controller of upcoming frequency change. */
+ if (INTEL_GEN(dev_priv) >= 10)
+ ret = skl_pcode_request(dev_priv, SKL_PCODE_CDCLK_CONTROL,
+ SKL_CDCLK_PREPARE_FOR_CHANGE,
+ SKL_CDCLK_READY_FOR_CHANGE,
+ SKL_CDCLK_READY_FOR_CHANGE, 3);
+ else
+ /*
+* BSpec requires us to wait up to 150usec, but that leads to
+* timeouts; the 2ms used here is based on experiment.
+*/
+ ret = sandybridge_pcode_write_timeout(dev_priv,
+
HSW_PCODE_DE_WRITE_FREQ_REQ,
+ 0x8000, 150, 2);
+
+ if (ret) {
+ DRM_ERROR("Failed to inform PCU about cdclk change (err %d,
freq %d)\n",
+ ret, cdclk);
+ return;
+ }
+
/* cdclk = vco / 2 / div{1,1.5,2,4} */
switch (DIV_ROUND_CLOSEST(vco, cdclk)) {
default:
@@ -1459,63 +1513,82 @@ static void bxt_set_cdclk(struct drm_i915_private
*dev_priv,
divider = BXT_CDCLK_CD2X_DIV_SEL_1;
break;
case 3:
- WARN(IS_GEMINILAKE(dev_priv), "Unsupported divider\n");
+ WARN(IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) >= 10,
+"Unsupported divider\n");
divider = BXT_CDCLK_CD2X_DIV_SEL_1_5;
break;
case 4:
divider = BXT_CDCLK_CD2X_DIV_SEL_2;
break;
case 8:
+ WARN(INTEL_GEN(dev_priv) >= 10, "Unsupported divider\n");
divider = BXT_CDCLK_CD2X_DIV_SEL_4;
break;
}
- /*
-* Inform power controller of upcoming frequency change. BSpec
-* requires us to wait up to 150usec, but that leads to timeouts;
-* the 2ms used here is based on experiment.
-*/
- ret = sandybridge_pcode_write_timeout(dev_priv,
- HSW_PCODE_DE_WRITE_FREQ_REQ,
- 0x8000, 150, 2);
- if (ret) {
- DRM_ERROR("PCode CDCLK freq change notify failed (err %d, freq
%d)\n",
- ret, cdclk);
- return;
- }
+ if (INTEL_GEN(dev_priv) >= 10) {
+ if (dev_priv->cdclk.hw.vco != 0 &&
+ dev_priv->cdclk.hw.vco != vco)
+ cnl_cdclk_pll_disable(dev_priv);
- if (dev_priv->cdclk.hw.vco != 0 &&
- dev_priv->cdclk.hw.vco != vco)
- bxt_de_pll_disable(dev_priv);
+ if (dev_priv->cdclk.hw.v
[Intel-gfx] [PATCH v4 2/8] drm/i915: Use literal representation of cdclk tables
The bspec lays out legal cdclk frequencies, PLL ratios, and CD2X
dividers in an easy-to-read table for most recent platforms. We've been
translating the data from that table into platform-specific code logic,
but it's easy to overlook an area we need to update when adding new
cdclk values or enabling new platforms. Let's just add a form of the
bspec table to the code and then adjust our functions to pull what they
need directly out of the table.
v2: Fix comparison when finding best cdclk.
v3: Another logic fix for calc_cdclk.
v4:
- Use named initializers for cdclk tables. (Ville)
- Include refclk as a field in the table instead of adding all three
ratios for each entry. (Ville)
- Terminate tables with an empty entry to avoid needing to store the
table size. (Ville)
- Don't try so hard to return reasonable values from our lookup
functions if we get impossible inputs; just WARN and return 0.
(Ville)
- Keep a bxt_ prefix on the lookup functions since they're still only
used on bxt+ for now. We can rename them later if we extend this
table-based approach back to older platforms. (Ville)
Cc: Ville Syrjälä
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 303 +++--
drivers/gpu/drm/i915/display/intel_cdclk.h | 7 +
drivers/gpu/drm/i915/i915_drv.h| 3 +
3 files changed, 110 insertions(+), 203 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 01ed3262d91e..c8cf288b8e8e 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -1161,28 +1161,88 @@ static void skl_uninit_cdclk(struct drm_i915_private
*dev_priv)
skl_set_cdclk(dev_priv, &cdclk_state, INVALID_PIPE);
}
-static int bxt_calc_cdclk(int min_cdclk)
-{
- if (min_cdclk > 576000)
- return 624000;
- else if (min_cdclk > 384000)
- return 576000;
- else if (min_cdclk > 288000)
- return 384000;
- else if (min_cdclk > 144000)
- return 288000;
- else
- return 144000;
+static const struct intel_cdclk_vals bxt_cdclk_table[] = {
+ { .refclk = 19200, .cdclk = 144000, .divider = 8, .ratio = 60 },
+ { .refclk = 19200, .cdclk = 288000, .divider = 4, .ratio = 60 },
+ { .refclk = 19200, .cdclk = 384000, .divider = 3, .ratio = 60 },
+ { .refclk = 19200, .cdclk = 576000, .divider = 2, .ratio = 60 },
+ { .refclk = 19200, .cdclk = 624000, .divider = 2, .ratio = 65 },
+ {}
+};
+
+static const struct intel_cdclk_vals glk_cdclk_table[] = {
+ { .refclk = 19200, .cdclk = 79200, .divider = 8, .ratio = 33 },
+ { .refclk = 19200, .cdclk = 158400, .divider = 4, .ratio = 33 },
+ { .refclk = 19200, .cdclk = 316800, .divider = 2, .ratio = 33 },
+ {}
+};
+
+static const struct intel_cdclk_vals cnl_cdclk_table[] = {
+ { .refclk = 19200, .cdclk = 168000, 4, 35 },
+ { .refclk = 19200, .cdclk = 336000, 2, 35 },
+ { .refclk = 19200, .cdclk = 528000, 2, 55 },
+
+ { .refclk = 24000, .cdclk = 168000, 4, 35 },
+ { .refclk = 24000, .cdclk = 336000, 2, 35 },
+ { .refclk = 24000, .cdclk = 528000, 2, 55 },
+ {}
+};
+
+static const struct intel_cdclk_vals icl_cdclk_table[] = {
+ { .refclk = 19200, .cdclk = 172800, .divider = 2, .ratio = 18 },
+ { .refclk = 19200, .cdclk = 192000, .divider = 2, .ratio = 20 },
+ { .refclk = 19200, .cdclk = 307200, .divider = 2, .ratio = 32 },
+ { .refclk = 19200, .cdclk = 326400, .divider = 4, .ratio = 68 },
+ { .refclk = 19200, .cdclk = 556800, .divider = 2, .ratio = 58 },
+ { .refclk = 19200, .cdclk = 652800, .divider = 2, .ratio = 68 },
+
+ { .refclk = 24000, .cdclk = 18, .divider = 2, .ratio = 15 },
+ { .refclk = 24000, .cdclk = 192000, .divider = 2, .ratio = 16 },
+ { .refclk = 24000, .cdclk = 312000, .divider = 2, .ratio = 26 },
+ { .refclk = 24000, .cdclk = 324000, .divider = 4, .ratio = 54 },
+ { .refclk = 24000, .cdclk = 552000, .divider = 2, .ratio = 46 },
+ { .refclk = 24000, .cdclk = 648000, .divider = 2, .ratio = 54 },
+
+ { .refclk = 38400, .cdclk = 172800, .divider = 2, .ratio = 9 },
+ { .refclk = 38400, .cdclk = 192000, .divider = 2, .ratio = 10 },
+ { .refclk = 38400, .cdclk = 307200, .divider = 2, .ratio = 16 },
+ { .refclk = 38400, .cdclk = 326400, .divider = 4, .ratio = 34 },
+ { .refclk = 38400, .cdclk = 556800, .divider = 2, .ratio = 29 },
+ { .refclk = 38400, .cdclk = 652800, .divider = 2, .ratio = 34 },
+ {}
+};
+
+static int bxt_calc_cdclk(struct drm_i915_private *dev_priv, int min_cdclk)
+{
+ const struct intel_cdclk_vals *table = dev_priv->cdclk.table;
+ int i;
+
+ for (i = 0; table[i].refclk; i++)
+ if (table[i].refclk == dev_priv->cdclk.hw.ref &&
+ table[i].cdc
[Intel-gfx] [PATCH v4 1/8] drm/i915: Consolidate bxt/cnl/icl cdclk readout
Aside from a few minor register changes and some different clock values,
cdclk design hasn't changed much since gen9lp. Let's consolidate the
handlers for bxt, cnl, and icl to keep the codeflow consistent.
Also, while we're at it, s/bxt_de_pll_update/bxt_de_pll_readout/ since
"update" makes me think we should be writing to hardware rather than
reading from it.
v2:
- Fix icl_calc_voltage_level() limits. (Ville)
- Use CNL_CDCLK_PLL_RATIO_MASK rather than BXT_DE_PLL_RATIO_MASK on
gen10+ to avoid confusion. (Ville)
Cc: Ville Syrjälä
Suggested-by: Ville Syrjälä
Signed-off-by: Matt Roper
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 325 +
1 file changed, 138 insertions(+), 187 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index d3e56628af70..01ed3262d91e 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -1190,6 +1190,36 @@ static u8 bxt_calc_voltage_level(int cdclk)
return DIV_ROUND_UP(cdclk, 25000);
}
+static u8 cnl_calc_voltage_level(int cdclk)
+{
+ if (cdclk > 336000)
+ return 2;
+ else if (cdclk > 168000)
+ return 1;
+ else
+ return 0;
+}
+
+static u8 icl_calc_voltage_level(int cdclk)
+{
+ if (cdclk > 556800)
+ return 2;
+ else if (cdclk > 312000)
+ return 1;
+ else
+ return 0;
+}
+
+static u8 ehl_calc_voltage_level(int cdclk)
+{
+ if (cdclk > 326400)
+ return 2;
+ else if (cdclk > 18)
+ return 1;
+ else
+ return 0;
+}
+
static int bxt_de_pll_vco(struct drm_i915_private *dev_priv, int cdclk)
{
int ratio;
@@ -1236,23 +1266,69 @@ static int glk_de_pll_vco(struct drm_i915_private
*dev_priv, int cdclk)
return dev_priv->cdclk.hw.ref * ratio;
}
-static void bxt_de_pll_update(struct drm_i915_private *dev_priv,
- struct intel_cdclk_state *cdclk_state)
+static void cnl_readout_refclk(struct drm_i915_private *dev_priv,
+ struct intel_cdclk_state *cdclk_state)
{
- u32 val;
+ if (I915_READ(SKL_DSSM) & CNL_DSSM_CDCLK_PLL_REFCLK_24MHz)
+ cdclk_state->ref = 24000;
+ else
+ cdclk_state->ref = 19200;
+}
- cdclk_state->ref = 19200;
- cdclk_state->vco = 0;
+static void icl_readout_refclk(struct drm_i915_private *dev_priv,
+ struct intel_cdclk_state *cdclk_state)
+{
+ u32 dssm = I915_READ(SKL_DSSM) & ICL_DSSM_CDCLK_PLL_REFCLK_MASK;
+
+ switch (dssm) {
+ default:
+ MISSING_CASE(dssm);
+ /* fall through */
+ case ICL_DSSM_CDCLK_PLL_REFCLK_24MHz:
+ cdclk_state->ref = 24000;
+ break;
+ case ICL_DSSM_CDCLK_PLL_REFCLK_19_2MHz:
+ cdclk_state->ref = 19200;
+ break;
+ case ICL_DSSM_CDCLK_PLL_REFCLK_38_4MHz:
+ cdclk_state->ref = 38400;
+ break;
+ }
+}
+
+static void bxt_de_pll_readout(struct drm_i915_private *dev_priv,
+ struct intel_cdclk_state *cdclk_state)
+{
+ u32 val, ratio;
+
+ if (INTEL_GEN(dev_priv) >= 11)
+ icl_readout_refclk(dev_priv, cdclk_state);
+ else if (IS_CANNONLAKE(dev_priv))
+ cnl_readout_refclk(dev_priv, cdclk_state);
+ else
+ cdclk_state->ref = 19200;
val = I915_READ(BXT_DE_PLL_ENABLE);
- if ((val & BXT_DE_PLL_PLL_ENABLE) == 0)
+ if ((val & BXT_DE_PLL_PLL_ENABLE) == 0 ||
+ (val & BXT_DE_PLL_LOCK) == 0) {
+ /*
+* CDCLK PLL is disabled, the VCO/ratio doesn't matter, but
+* setting it to zero is a way to signal that.
+*/
+ cdclk_state->vco = 0;
return;
+ }
- if (WARN_ON((val & BXT_DE_PLL_LOCK) == 0))
- return;
+ /*
+* CNL+ have the ratio directly in the PLL enable register, gen9lp had
+* it in a separate PLL control register.
+*/
+ if (INTEL_GEN(dev_priv) >= 10)
+ ratio = val & CNL_CDCLK_PLL_RATIO_MASK;
+ else
+ ratio = I915_READ(BXT_DE_PLL_CTL) & BXT_DE_PLL_RATIO_MASK;
- val = I915_READ(BXT_DE_PLL_CTL);
- cdclk_state->vco = (val & BXT_DE_PLL_RATIO_MASK) * cdclk_state->ref;
+ cdclk_state->vco = ratio * cdclk_state->ref;
}
static void bxt_get_cdclk(struct drm_i915_private *dev_priv,
@@ -1261,12 +1337,18 @@ static void bxt_get_cdclk(struct drm_i915_private
*dev_priv,
u32 divider;
int div;
- bxt_de_pll_update(dev_priv, cdclk_state);
-
- cdclk_state->cdclk = cdclk_state->bypass = cdclk_state->ref;
+ if (INTEL_GEN(dev_priv) >= 12)
+ cdclk_st
[Intel-gfx] [PATCH v4 4/8] drm/i915: Kill cnl_sanitize_cdclk()
The CNL variant of this function is identical to the BXT variant aside
from not needing to handle SSA precharge.
Cc: Ville Syrjälä
Signed-off-by: Matt Roper
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 46 +-
1 file changed, 2 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 14229c68d4be..3c763c70ebea 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -1636,7 +1636,7 @@ static void bxt_sanitize_cdclk(struct drm_i915_private
*dev_priv)
* Disable SSA Precharge when CD clock frequency < 500 MHz,
* enable otherwise.
*/
- if (dev_priv->cdclk.hw.cdclk >= 50)
+ if (IS_GEN9_LP(dev_priv) && dev_priv->cdclk.hw.cdclk >= 50)
expected |= BXT_CDCLK_SSA_PRECHARGE_ENABLE;
if (cdctl == expected)
@@ -1688,48 +1688,6 @@ static void bxt_uninit_cdclk(struct drm_i915_private
*dev_priv)
bxt_set_cdclk(dev_priv, &cdclk_state, INVALID_PIPE);
}
-static void cnl_sanitize_cdclk(struct drm_i915_private *dev_priv)
-{
- u32 cdctl, expected;
-
- intel_update_cdclk(dev_priv);
- intel_dump_cdclk_state(&dev_priv->cdclk.hw, "Current CDCLK");
-
- if (dev_priv->cdclk.hw.vco == 0 ||
- dev_priv->cdclk.hw.cdclk == dev_priv->cdclk.hw.bypass)
- goto sanitize;
-
- /* DPLL okay; verify the cdclock
-*
-* Some BIOS versions leave an incorrect decimal frequency value and
-* set reserved MBZ bits in CDCLK_CTL at least during exiting from S4,
-* so sanitize this register.
-*/
- cdctl = I915_READ(CDCLK_CTL);
- /*
-* Let's ignore the pipe field, since BIOS could have configured the
-* dividers both synching to an active pipe, or asynchronously
-* (PIPE_NONE).
-*/
- cdctl &= ~BXT_CDCLK_CD2X_PIPE_NONE;
-
- expected = (cdctl & BXT_CDCLK_CD2X_DIV_SEL_MASK) |
- skl_cdclk_decimal(dev_priv->cdclk.hw.cdclk);
-
- if (cdctl == expected)
- /* All well; nothing to sanitize */
- return;
-
-sanitize:
- DRM_DEBUG_KMS("Sanitizing cdclk programmed by pre-os\n");
-
- /* force cdclk programming */
- dev_priv->cdclk.hw.cdclk = 0;
-
- /* force full PLL disable + enable */
- dev_priv->cdclk.hw.vco = -1;
-}
-
static void icl_init_cdclk(struct drm_i915_private *dev_priv)
{
struct intel_cdclk_state sanitized_state;
@@ -1791,7 +1749,7 @@ static void cnl_init_cdclk(struct drm_i915_private
*dev_priv)
{
struct intel_cdclk_state cdclk_state;
- cnl_sanitize_cdclk(dev_priv);
+ bxt_sanitize_cdclk(dev_priv);
if (dev_priv->cdclk.hw.cdclk != 0 &&
dev_priv->cdclk.hw.vco != 0)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 8/8] drm/i915: Consolidate {bxt, cnl, icl}_init_cdclk
The BXT and CNL functions were already basically identical, whereas
ICL's function tried to do its own sanitization rather than calling
bxt_sanitize_cdclk.
This should actually fix a bug in our ICL initialization where it would
consider the /2 CD2X divider invalid and force an unnecessary
sanitization (we now have valid clock frequencies that use this
divider).
Cc: Ville Syrjälä
Signed-off-by: Matt Roper
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 65 +-
1 file changed, 2 insertions(+), 63 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 686c1e6100f0..3b2966a16ec7 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -1710,63 +1710,6 @@ static void bxt_uninit_cdclk(struct drm_i915_private
*dev_priv)
bxt_set_cdclk(dev_priv, &cdclk_state, INVALID_PIPE);
}
-static void icl_init_cdclk(struct drm_i915_private *dev_priv)
-{
- struct intel_cdclk_state sanitized_state;
- u32 val;
-
- /* This sets dev_priv->cdclk.hw. */
- intel_update_cdclk(dev_priv);
- intel_dump_cdclk_state(&dev_priv->cdclk.hw, "Current CDCLK");
-
- /* This means CDCLK disabled. */
- if (dev_priv->cdclk.hw.cdclk == dev_priv->cdclk.hw.bypass)
- goto sanitize;
-
- val = I915_READ(CDCLK_CTL);
-
- if ((val & BXT_CDCLK_CD2X_DIV_SEL_MASK) != 0)
- goto sanitize;
-
- if ((val & CDCLK_FREQ_DECIMAL_MASK) !=
- skl_cdclk_decimal(dev_priv->cdclk.hw.cdclk))
- goto sanitize;
-
- return;
-
-sanitize:
- DRM_DEBUG_KMS("Sanitizing cdclk programmed by pre-os\n");
-
- sanitized_state.ref = dev_priv->cdclk.hw.ref;
- sanitized_state.cdclk = bxt_calc_cdclk(dev_priv, 0);
- sanitized_state.vco = bxt_calc_cdclk_pll_vco(dev_priv,
-sanitized_state.cdclk);
- sanitized_state.voltage_level =
- dev_priv->display.calc_voltage_level(sanitized_state.cdclk);
-
- bxt_set_cdclk(dev_priv, &sanitized_state, INVALID_PIPE);
-}
-
-static void cnl_init_cdclk(struct drm_i915_private *dev_priv)
-{
- struct intel_cdclk_state cdclk_state;
-
- bxt_sanitize_cdclk(dev_priv);
-
- if (dev_priv->cdclk.hw.cdclk != 0 &&
- dev_priv->cdclk.hw.vco != 0)
- return;
-
- cdclk_state = dev_priv->cdclk.hw;
-
- cdclk_state.cdclk = bxt_calc_cdclk(dev_priv, 0);
- cdclk_state.vco = bxt_calc_cdclk_pll_vco(dev_priv, cdclk_state.cdclk);
- cdclk_state.voltage_level =
- dev_priv->display.calc_voltage_level(cdclk_state.cdclk);
-
- bxt_set_cdclk(dev_priv, &cdclk_state, INVALID_PIPE);
-}
-
/**
* intel_cdclk_init - Initialize CDCLK
* @i915: i915 device
@@ -1778,14 +1721,10 @@ static void cnl_init_cdclk(struct drm_i915_private
*dev_priv)
*/
void intel_cdclk_init(struct drm_i915_private *i915)
{
- if (INTEL_GEN(i915) >= 11)
- icl_init_cdclk(i915);
- else if (IS_CANNONLAKE(i915))
- cnl_init_cdclk(i915);
+ if (IS_GEN9_LP(i915) || INTEL_GEN(i915) >= 10)
+ bxt_init_cdclk(i915);
else if (IS_GEN9_BC(i915))
skl_init_cdclk(i915);
- else if (IS_GEN9_LP(i915))
- bxt_init_cdclk(i915);
}
/**
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 7/8] drm/i915: Enhance cdclk sanitization
When reading out the BIOS-programmed cdclk state, let's make sure that
the cdclk value is on the valid list for the platform, ensure that the
VCO matches the cdclk, and ensure that the CD2X divider was set
properly.
Cc: Ville Syrjälä
Signed-off-by: Matt Roper
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 34 --
1 file changed, 32 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index cb2fc68c9335..686c1e6100f0 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -1598,6 +1598,7 @@ static void bxt_set_cdclk(struct drm_i915_private
*dev_priv,
static void bxt_sanitize_cdclk(struct drm_i915_private *dev_priv)
{
u32 cdctl, expected;
+ int cdclk, vco;
intel_update_cdclk(dev_priv);
intel_dump_cdclk_state(&dev_priv->cdclk.hw, "Current CDCLK");
@@ -1620,8 +1621,37 @@ static void bxt_sanitize_cdclk(struct drm_i915_private
*dev_priv)
*/
cdctl &= ~BXT_CDCLK_CD2X_PIPE_NONE;
- expected = (cdctl & BXT_CDCLK_CD2X_DIV_SEL_MASK) |
- skl_cdclk_decimal(dev_priv->cdclk.hw.cdclk);
+ /* Make sure this is a legal cdclk value for the platform */
+ cdclk = bxt_calc_cdclk(dev_priv, dev_priv->cdclk.hw.cdclk);
+ if (cdclk != dev_priv->cdclk.hw.cdclk)
+ goto sanitize;
+
+ /* Make sure the VCO is correct for the cdclk */
+ vco = bxt_calc_cdclk_pll_vco(dev_priv, cdclk);
+ if (vco != dev_priv->cdclk.hw.vco)
+ goto sanitize;
+
+ expected = skl_cdclk_decimal(cdclk);
+
+ /* Figure out what CD2X divider we should be using for this cdclk */
+ switch (DIV_ROUND_CLOSEST(dev_priv->cdclk.hw.vco,
+ dev_priv->cdclk.hw.cdclk)) {
+ case 2:
+ expected |= BXT_CDCLK_CD2X_DIV_SEL_1;
+ break;
+ case 3:
+ expected |= BXT_CDCLK_CD2X_DIV_SEL_1_5;
+ break;
+ case 4:
+ expected |= BXT_CDCLK_CD2X_DIV_SEL_2;
+ break;
+ case 8:
+ expected |= BXT_CDCLK_CD2X_DIV_SEL_4;
+ break;
+ default:
+ goto sanitize;
+ }
+
/*
* Disable SSA Precharge when CD clock frequency < 500 MHz,
* enable otherwise.
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 1/8] drm/i915: Consolidate bxt/cnl/icl cdclk readout
On Tue, Sep 10, 2019 at 08:42:45AM -0700, Matt Roper wrote:
> Aside from a few minor register changes and some different clock values,
> cdclk design hasn't changed much since gen9lp. Let's consolidate the
> handlers for bxt, cnl, and icl to keep the codeflow consistent.
>
> Also, while we're at it, s/bxt_de_pll_update/bxt_de_pll_readout/ since
> "update" makes me think we should be writing to hardware rather than
> reading from it.
>
> v2:
> - Fix icl_calc_voltage_level() limits. (Ville)
> - Use CNL_CDCLK_PLL_RATIO_MASK rather than BXT_DE_PLL_RATIO_MASK on
>gen10+ to avoid confusion. (Ville)
>
> Cc: Ville Syrjälä
> Suggested-by: Ville Syrjälä
> Signed-off-by: Matt Roper
> Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 325 +
> 1 file changed, 138 insertions(+), 187 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index d3e56628af70..01ed3262d91e 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -1190,6 +1190,36 @@ static u8 bxt_calc_voltage_level(int cdclk)
> return DIV_ROUND_UP(cdclk, 25000);
> }
>
> +static u8 cnl_calc_voltage_level(int cdclk)
> +{
> + if (cdclk > 336000)
> + return 2;
> + else if (cdclk > 168000)
> + return 1;
> + else
> + return 0;
> +}
> +
> +static u8 icl_calc_voltage_level(int cdclk)
> +{
> + if (cdclk > 556800)
> + return 2;
> + else if (cdclk > 312000)
> + return 1;
> + else
> + return 0;
> +}
> +
> +static u8 ehl_calc_voltage_level(int cdclk)
> +{
> + if (cdclk > 326400)
This still looks off.
> + return 2;
> + else if (cdclk > 18)
> + return 1;
> + else
> + return 0;
> +}
> +
> static int bxt_de_pll_vco(struct drm_i915_private *dev_priv, int cdclk)
> {
> int ratio;
> @@ -1236,23 +1266,69 @@ static int glk_de_pll_vco(struct drm_i915_private
> *dev_priv, int cdclk)
> return dev_priv->cdclk.hw.ref * ratio;
> }
>
> -static void bxt_de_pll_update(struct drm_i915_private *dev_priv,
> - struct intel_cdclk_state *cdclk_state)
> +static void cnl_readout_refclk(struct drm_i915_private *dev_priv,
> +struct intel_cdclk_state *cdclk_state)
> {
> - u32 val;
> + if (I915_READ(SKL_DSSM) & CNL_DSSM_CDCLK_PLL_REFCLK_24MHz)
> + cdclk_state->ref = 24000;
> + else
> + cdclk_state->ref = 19200;
> +}
>
> - cdclk_state->ref = 19200;
> - cdclk_state->vco = 0;
> +static void icl_readout_refclk(struct drm_i915_private *dev_priv,
> +struct intel_cdclk_state *cdclk_state)
> +{
> + u32 dssm = I915_READ(SKL_DSSM) & ICL_DSSM_CDCLK_PLL_REFCLK_MASK;
> +
> + switch (dssm) {
> + default:
> + MISSING_CASE(dssm);
> + /* fall through */
> + case ICL_DSSM_CDCLK_PLL_REFCLK_24MHz:
> + cdclk_state->ref = 24000;
> + break;
> + case ICL_DSSM_CDCLK_PLL_REFCLK_19_2MHz:
> + cdclk_state->ref = 19200;
> + break;
> + case ICL_DSSM_CDCLK_PLL_REFCLK_38_4MHz:
> + cdclk_state->ref = 38400;
> + break;
> + }
> +}
> +
> +static void bxt_de_pll_readout(struct drm_i915_private *dev_priv,
> +struct intel_cdclk_state *cdclk_state)
> +{
> + u32 val, ratio;
> +
> + if (INTEL_GEN(dev_priv) >= 11)
> + icl_readout_refclk(dev_priv, cdclk_state);
> + else if (IS_CANNONLAKE(dev_priv))
> + cnl_readout_refclk(dev_priv, cdclk_state);
> + else
> + cdclk_state->ref = 19200;
>
> val = I915_READ(BXT_DE_PLL_ENABLE);
> - if ((val & BXT_DE_PLL_PLL_ENABLE) == 0)
> + if ((val & BXT_DE_PLL_PLL_ENABLE) == 0 ||
> + (val & BXT_DE_PLL_LOCK) == 0) {
> + /*
> + * CDCLK PLL is disabled, the VCO/ratio doesn't matter, but
> + * setting it to zero is a way to signal that.
> + */
> + cdclk_state->vco = 0;
> return;
> + }
>
> - if (WARN_ON((val & BXT_DE_PLL_LOCK) == 0))
> - return;
> + /*
> + * CNL+ have the ratio directly in the PLL enable register, gen9lp had
> + * it in a separate PLL control register.
> + */
> + if (INTEL_GEN(dev_priv) >= 10)
> + ratio = val & CNL_CDCLK_PLL_RATIO_MASK;
> + else
> + ratio = I915_READ(BXT_DE_PLL_CTL) & BXT_DE_PLL_RATIO_MASK;
>
> - val = I915_READ(BXT_DE_PLL_CTL);
> - cdclk_state->vco = (val & BXT_DE_PLL_RATIO_MASK) * cdclk_state->ref;
> + cdclk_state->vco = ratio * cdclk_state->ref;
> }
>
> static void bxt_get_cdclk(struct drm_i915_private *dev_priv,
> @@ -1261,12 +1337,18 @@ static void bxt_get_cdclk(struct drm_i915_private
> *dev_priv,
>
Re: [Intel-gfx] [PATCH v4 2/8] drm/i915: Use literal representation of cdclk tables
On Tue, Sep 10, 2019 at 08:42:46AM -0700, Matt Roper wrote:
> The bspec lays out legal cdclk frequencies, PLL ratios, and CD2X
> dividers in an easy-to-read table for most recent platforms. We've been
> translating the data from that table into platform-specific code logic,
> but it's easy to overlook an area we need to update when adding new
> cdclk values or enabling new platforms. Let's just add a form of the
> bspec table to the code and then adjust our functions to pull what they
> need directly out of the table.
>
> v2: Fix comparison when finding best cdclk.
>
> v3: Another logic fix for calc_cdclk.
>
> v4:
> - Use named initializers for cdclk tables. (Ville)
> - Include refclk as a field in the table instead of adding all three
>ratios for each entry. (Ville)
> - Terminate tables with an empty entry to avoid needing to store the
>table size. (Ville)
> - Don't try so hard to return reasonable values from our lookup
>functions if we get impossible inputs; just WARN and return 0.
>(Ville)
> - Keep a bxt_ prefix on the lookup functions since they're still only
>used on bxt+ for now. We can rename them later if we extend this
>table-based approach back to older platforms. (Ville)
>
> Cc: Ville Syrjälä
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 303 +++--
> drivers/gpu/drm/i915/display/intel_cdclk.h | 7 +
> drivers/gpu/drm/i915/i915_drv.h| 3 +
> 3 files changed, 110 insertions(+), 203 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 01ed3262d91e..c8cf288b8e8e 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -1161,28 +1161,88 @@ static void skl_uninit_cdclk(struct drm_i915_private
> *dev_priv)
> skl_set_cdclk(dev_priv, &cdclk_state, INVALID_PIPE);
> }
>
> -static int bxt_calc_cdclk(int min_cdclk)
> -{
> - if (min_cdclk > 576000)
> - return 624000;
> - else if (min_cdclk > 384000)
> - return 576000;
> - else if (min_cdclk > 288000)
> - return 384000;
> - else if (min_cdclk > 144000)
> - return 288000;
> - else
> - return 144000;
> +static const struct intel_cdclk_vals bxt_cdclk_table[] = {
> + { .refclk = 19200, .cdclk = 144000, .divider = 8, .ratio = 60 },
> + { .refclk = 19200, .cdclk = 288000, .divider = 4, .ratio = 60 },
> + { .refclk = 19200, .cdclk = 384000, .divider = 3, .ratio = 60 },
> + { .refclk = 19200, .cdclk = 576000, .divider = 2, .ratio = 60 },
> + { .refclk = 19200, .cdclk = 624000, .divider = 2, .ratio = 65 },
> + {}
> +};
If only we had constexpr so we could do
BUILD_BUG_ON(ref*ratio == cdclk*div) without having to hand roll
it for every table entry. Oh well.
> +
> +static const struct intel_cdclk_vals glk_cdclk_table[] = {
> + { .refclk = 19200, .cdclk = 79200, .divider = 8, .ratio = 33 },
> + { .refclk = 19200, .cdclk = 158400, .divider = 4, .ratio = 33 },
> + { .refclk = 19200, .cdclk = 316800, .divider = 2, .ratio = 33 },
> + {}
> +};
> +
> +static const struct intel_cdclk_vals cnl_cdclk_table[] = {
> + { .refclk = 19200, .cdclk = 168000, 4, 35 },
> + { .refclk = 19200, .cdclk = 336000, 2, 35 },
> + { .refclk = 19200, .cdclk = 528000, 2, 55 },
> +
> + { .refclk = 24000, .cdclk = 168000, 4, 35 },
> + { .refclk = 24000, .cdclk = 336000, 2, 35 },
> + { .refclk = 24000, .cdclk = 528000, 2, 55 },
The ratios looks wrong here. Also missing .divider= and .ratio=.
> + {}
> +};
> +
> +static const struct intel_cdclk_vals icl_cdclk_table[] = {
> + { .refclk = 19200, .cdclk = 172800, .divider = 2, .ratio = 18 },
> + { .refclk = 19200, .cdclk = 192000, .divider = 2, .ratio = 20 },
> + { .refclk = 19200, .cdclk = 307200, .divider = 2, .ratio = 32 },
> + { .refclk = 19200, .cdclk = 326400, .divider = 4, .ratio = 68 },
> + { .refclk = 19200, .cdclk = 556800, .divider = 2, .ratio = 58 },
> + { .refclk = 19200, .cdclk = 652800, .divider = 2, .ratio = 68 },
> +
> + { .refclk = 24000, .cdclk = 18, .divider = 2, .ratio = 15 },
> + { .refclk = 24000, .cdclk = 192000, .divider = 2, .ratio = 16 },
> + { .refclk = 24000, .cdclk = 312000, .divider = 2, .ratio = 26 },
> + { .refclk = 24000, .cdclk = 324000, .divider = 4, .ratio = 54 },
> + { .refclk = 24000, .cdclk = 552000, .divider = 2, .ratio = 46 },
> + { .refclk = 24000, .cdclk = 648000, .divider = 2, .ratio = 54 },
> +
> + { .refclk = 38400, .cdclk = 172800, .divider = 2, .ratio = 9 },
> + { .refclk = 38400, .cdclk = 192000, .divider = 2, .ratio = 10 },
> + { .refclk = 38400, .cdclk = 307200, .divider = 2, .ratio = 16 },
> + { .refclk = 38400, .cdclk = 326400, .divider = 4, .ratio = 34 },
> + { .refclk = 38400, .cdclk = 556800, .divider = 2, .ratio = 29 },
> + { .re
[Intel-gfx] [PATCH v5 1/8] drm/i915: Consolidate bxt/cnl/icl cdclk readout
Aside from a few minor register changes and some different clock values,
cdclk design hasn't changed much since gen9lp. Let's consolidate the
handlers for bxt, cnl, and icl to keep the codeflow consistent.
Also, while we're at it, s/bxt_de_pll_update/bxt_de_pll_readout/ since
"update" makes me think we should be writing to hardware rather than
reading from it.
v2:
- Fix icl_calc_voltage_level() limits. (Ville)
- Use CNL_CDCLK_PLL_RATIO_MASK rather than BXT_DE_PLL_RATIO_MASK on
gen10+ to avoid confusion. (Ville)
v3:
- Also fix ehl_calc_voltage_level() limits. (Ville)
Cc: Ville Syrjälä
Suggested-by: Ville Syrjälä
Signed-off-by: Matt Roper
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 325 +
1 file changed, 138 insertions(+), 187 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index d3e56628af70..dfcb1cc58951 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -1190,6 +1190,36 @@ static u8 bxt_calc_voltage_level(int cdclk)
return DIV_ROUND_UP(cdclk, 25000);
}
+static u8 cnl_calc_voltage_level(int cdclk)
+{
+ if (cdclk > 336000)
+ return 2;
+ else if (cdclk > 168000)
+ return 1;
+ else
+ return 0;
+}
+
+static u8 icl_calc_voltage_level(int cdclk)
+{
+ if (cdclk > 556800)
+ return 2;
+ else if (cdclk > 312000)
+ return 1;
+ else
+ return 0;
+}
+
+static u8 ehl_calc_voltage_level(int cdclk)
+{
+ if (cdclk > 312000)
+ return 2;
+ else if (cdclk > 18)
+ return 1;
+ else
+ return 0;
+}
+
static int bxt_de_pll_vco(struct drm_i915_private *dev_priv, int cdclk)
{
int ratio;
@@ -1236,23 +1266,69 @@ static int glk_de_pll_vco(struct drm_i915_private
*dev_priv, int cdclk)
return dev_priv->cdclk.hw.ref * ratio;
}
-static void bxt_de_pll_update(struct drm_i915_private *dev_priv,
- struct intel_cdclk_state *cdclk_state)
+static void cnl_readout_refclk(struct drm_i915_private *dev_priv,
+ struct intel_cdclk_state *cdclk_state)
{
- u32 val;
+ if (I915_READ(SKL_DSSM) & CNL_DSSM_CDCLK_PLL_REFCLK_24MHz)
+ cdclk_state->ref = 24000;
+ else
+ cdclk_state->ref = 19200;
+}
- cdclk_state->ref = 19200;
- cdclk_state->vco = 0;
+static void icl_readout_refclk(struct drm_i915_private *dev_priv,
+ struct intel_cdclk_state *cdclk_state)
+{
+ u32 dssm = I915_READ(SKL_DSSM) & ICL_DSSM_CDCLK_PLL_REFCLK_MASK;
+
+ switch (dssm) {
+ default:
+ MISSING_CASE(dssm);
+ /* fall through */
+ case ICL_DSSM_CDCLK_PLL_REFCLK_24MHz:
+ cdclk_state->ref = 24000;
+ break;
+ case ICL_DSSM_CDCLK_PLL_REFCLK_19_2MHz:
+ cdclk_state->ref = 19200;
+ break;
+ case ICL_DSSM_CDCLK_PLL_REFCLK_38_4MHz:
+ cdclk_state->ref = 38400;
+ break;
+ }
+}
+
+static void bxt_de_pll_readout(struct drm_i915_private *dev_priv,
+ struct intel_cdclk_state *cdclk_state)
+{
+ u32 val, ratio;
+
+ if (INTEL_GEN(dev_priv) >= 11)
+ icl_readout_refclk(dev_priv, cdclk_state);
+ else if (IS_CANNONLAKE(dev_priv))
+ cnl_readout_refclk(dev_priv, cdclk_state);
+ else
+ cdclk_state->ref = 19200;
val = I915_READ(BXT_DE_PLL_ENABLE);
- if ((val & BXT_DE_PLL_PLL_ENABLE) == 0)
+ if ((val & BXT_DE_PLL_PLL_ENABLE) == 0 ||
+ (val & BXT_DE_PLL_LOCK) == 0) {
+ /*
+* CDCLK PLL is disabled, the VCO/ratio doesn't matter, but
+* setting it to zero is a way to signal that.
+*/
+ cdclk_state->vco = 0;
return;
+ }
- if (WARN_ON((val & BXT_DE_PLL_LOCK) == 0))
- return;
+ /*
+* CNL+ have the ratio directly in the PLL enable register, gen9lp had
+* it in a separate PLL control register.
+*/
+ if (INTEL_GEN(dev_priv) >= 10)
+ ratio = val & CNL_CDCLK_PLL_RATIO_MASK;
+ else
+ ratio = I915_READ(BXT_DE_PLL_CTL) & BXT_DE_PLL_RATIO_MASK;
- val = I915_READ(BXT_DE_PLL_CTL);
- cdclk_state->vco = (val & BXT_DE_PLL_RATIO_MASK) * cdclk_state->ref;
+ cdclk_state->vco = ratio * cdclk_state->ref;
}
static void bxt_get_cdclk(struct drm_i915_private *dev_priv,
@@ -1261,12 +1337,18 @@ static void bxt_get_cdclk(struct drm_i915_private
*dev_priv,
u32 divider;
int div;
- bxt_de_pll_update(dev_priv, cdclk_state);
-
- cdclk_state->cdclk = cdclk_state->bypass = cdclk_state->ref;
+
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/tgl: Disable rc6 for debugging
== Series Details ==
Series: drm/i915/tgl: Disable rc6 for debugging
URL : https://patchwork.freedesktop.org/series/66492/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6861 -> Patchwork_14343
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14343/
Known issues
Here are the changes found in Patchwork_14343 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850: [PASS][1] -> [INCOMPLETE][2] ([fdo#107718])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6861/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14343/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
* igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq: [PASS][3] -> [DMESG-WARN][4] ([fdo#105541])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6861/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14343/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
Possible fixes
* igt@gem_ctx_switch@legacy-render:
- fi-icl-u2: [INCOMPLETE][5] ([fdo#107713] / [fdo#111381]) ->
[PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6861/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14343/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html
* igt@gem_render_tiled_blits@basic:
- fi-icl-u3: [DMESG-WARN][7] ([fdo#107724]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6861/fi-icl-u3/igt@gem_render_tiled_bl...@basic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14343/fi-icl-u3/igt@gem_render_tiled_bl...@basic.html
* igt@i915_selftest@live_execlists:
- fi-skl-gvtdvm: [DMESG-FAIL][9] ([fdo#08]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6861/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14343/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
Warnings
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][11] ([fdo#111096]) -> [FAIL][12] ([fdo#111407])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6861/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14343/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#105541]: https://bugs.freedesktop.org/show_bug.cgi?id=105541
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#08]: https://bugs.freedesktop.org/show_bug.cgi?id=08
[fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
Participating hosts (54 -> 47)
--
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y
fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6861 -> Patchwork_14343
CI-20190529: 20190529
CI_DRM_6861: 32c81a3173640f165510de65b8e4137aa049b33f @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5178: efb4539494d94f03374874d3b61bd04ef3802aaa @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14343: d10adacdd12710fbf0202b2eeab8229e41ea5952 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
d10adacdd127 drm/i915/tgl: Disable rc6 for debugging
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14343/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 2/8] drm/i915: Use literal representation of cdclk tables
On Tue, Sep 10, 2019 at 08:42:46AM -0700, Matt Roper wrote:
...
> +struct intel_cdclk_vals {
> + u32 refclk;
Oh, I think (at least currently) refclk would fit into u16,
so we could pack this a bit tighter still.
> + u32 cdclk;
> + u8 divider; /* CD2X divider * 2 */
> + u8 ratio;
> +};
> +
> int intel_crtc_compute_min_cdclk(const struct intel_crtc_state *crtc_state);
> void intel_cdclk_init(struct drm_i915_private *i915);
> void intel_cdclk_uninit(struct drm_i915_private *i915);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index e289b4ffd34b..ff6aff2a4866 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1420,6 +1420,9 @@ struct drm_i915_private {
> /* The current hardware cdclk state */
> struct intel_cdclk_state hw;
>
> + /* cdclk, divider, and ratio table from bspec */
> + const struct intel_cdclk_vals *table;
> +
> int force_min_cdclk;
> } cdclk;
>
> --
> 2.20.1
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for cdclk consolidation and rework for BXT-TGL (rev5)
== Series Details ==
Series: cdclk consolidation and rework for BXT-TGL (rev5)
URL : https://patchwork.freedesktop.org/series/66365/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
c7ffbe99a9da drm/i915: Consolidate bxt/cnl/icl cdclk readout
-:81: CHECK:CAMELCASE: Avoid CamelCase:
#81: FILE: drivers/gpu/drm/i915/display/intel_cdclk.c:1272:
+ if (I915_READ(SKL_DSSM) & CNL_DSSM_CDCLK_PLL_REFCLK_24MHz)
total: 0 errors, 0 warnings, 1 checks, 412 lines checked
0b12faaf504b drm/i915: Use literal representation of cdclk tables
ade79d916b5c drm/i915: Combine bxt_set_cdclk and cnl_set_cdclk
4d1593ea66fc drm/i915: Kill cnl_sanitize_cdclk()
3b06fc2eac50 drm/i915: Consolidate {bxt, cnl, icl}_uninit_cdclk
05d3115ff981 drm/i915: Add calc_voltage_level display vfunc
202e21f4a86f drm/i915: Enhance cdclk sanitization
1dfdfc7ecb8a drm/i915: Consolidate {bxt, cnl, icl}_init_cdclk
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/tgl: Disable rc6 for debugging
Quoting Patchwork (2019-09-10 17:06:36) > External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14343/ > > Known issues > > > Here are the changes found in Patchwork_14343 that come from known issues: tgl died in gem_exec_gttfill, so not rc6, or even runtime-pm, by itself. Seems forcewake is the key. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 3/7] drm: Add DisplayPort colorspace property
On Tue, Sep 10, 2019 at 9:21 AM Ilia Mirkin wrote: > > On Tue, Sep 10, 2019 at 3:34 AM Mun, Gwan-gyeong > wrote: > > > > On Sat, 2019-09-07 at 21:43 -0400, Ilia Mirkin wrote: > > > On Sat, Sep 7, 2019 at 7:20 PM Mun, Gwan-gyeong > > > wrote: > > > > On Fri, 2019-09-06 at 09:24 -0400, Ilia Mirkin wrote: > > > > > On Fri, Sep 6, 2019 at 7:43 AM Ville Syrjälä > > > > > wrote: > > > > > > On Fri, Sep 06, 2019 at 11:31:55AM +, Shankar, Uma wrote: > > > > > > > > -Original Message- > > > > > > > > From: Ilia Mirkin > > > > > > > > Sent: Tuesday, September 3, 2019 6:12 PM > > > > > > > > To: Mun, Gwan-gyeong > > > > > > > > Cc: Intel Graphics Development < > > > > > > > > intel-gfx@lists.freedesktop.org > > > > > > > > > ; Shankar, Uma > > > > > > > > ; dri-devel < > > > > > > > > dri-de...@lists.freedesktop.org> > > > > > > > > Subject: Re: [PATCH v4 3/7] drm: Add DisplayPort colorspace > > > > > > > > property > > > > > > > > > > > > > > > > So how would this work with a DP++ connector? Should it > > > > > > > > list > > > > > > > > the HDMI or DP > > > > > > > > properties? Or do we need a custom property checker which > > > > > > > > is > > > > > > > > aware of what is > > > > > > > > currently plugged in to validate the values? > > > > > > > > > > > > > > AFAIU For DP++ cases, we detect what kind of sink its driving > > > > > > > DP > > > > > > > or HDMI (with a passive dongle). > > > > > > > Based on the type of sink detected, we should expose DP or > > > > > > > HDMI > > > > > > > colorspaces to userspace. > > > > > > > > > > > > For i915 DP connector always drives DP mode, HDMI connector > > > > > > always > > > > > > drives > > > > > > HDMI mode, even when the physical connector is DP++. > > > > > > > > > > Right, i915 creates 2 connectors, while nouveau, radeon, and > > > > > amdgpu > > > > > create 1 connector (not sure about other drivers) for a single > > > > > physical DP++ socket. Since we supply the list of valid values at > > > > > the > > > > > time of creating the connector, we can't know at that point > > > > > whether > > > > > in > > > > > the future a HDMI or DP will be plugged into it. > > > > > > > > > > -ilia > > > > Ilia, does it mean that the drm_connector type is > > > > DRM_MODE_CONNECTOR_DisplayPort and protocol is DP++ mode? > > > > > > That is correct. The connector type is "DisplayPort" in such a case. > > > > > > Cheers, > > > > > > -ilia > > > > For now drm_mode_create_colorspace_property() is only used for i915. > > IMHO, when other drivers ( nouveau, radeon, and amdgpu ) are ready for > > using of drm_mode_create_colorspace_property(), > > what about do we add a variable which can identify DP++ and DP to > > drm_connector? > > And when the drivers (nouveau, radeon, and amdgpu) detect the current > > protocol, the drivers will set the variable. > > I've been working on adding this to nouveau. > > Can/should such properties be added/removed at "runtime", rather than > at connector creation time? Either way, the function > drm_mode_create_colorspace_property as proposed would not be reusable, > since it looks at the connector type, which will always be > "DisplayPort" in such cases. Summary of conversation Ville and I had on IRC: - DP++ connectors to provide a single combined list of options for colorspace - set_property hook will check against currently plugged in thing, and reject incorrect values - in the case where someone sets e.g. an HDMI value for an HDMI-plugged-in thing, and then unplugs, and then plugs in a DP screen, the modeset should continue to succeed but use a default colorspace value. I think there was a bit of contention on that last point. Open to opinions, but we should try to avoid putting undue burden on esp non-atomic userspace. Cheers, -ilia ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 2/8] drm/i915: Use literal representation of cdclk tables
The bspec lays out legal cdclk frequencies, PLL ratios, and CD2X
dividers in an easy-to-read table for most recent platforms. We've been
translating the data from that table into platform-specific code logic,
but it's easy to overlook an area we need to update when adding new
cdclk values or enabling new platforms. Let's just add a form of the
bspec table to the code and then adjust our functions to pull what they
need directly out of the table.
v2: Fix comparison when finding best cdclk.
v3: Another logic fix for calc_cdclk.
v4:
- Use named initializers for cdclk tables. (Ville)
- Include refclk as a field in the table instead of adding all three
ratios for each entry. (Ville)
- Terminate tables with an empty entry to avoid needing to store the
table size. (Ville)
- Don't try so hard to return reasonable values from our lookup
functions if we get impossible inputs; just WARN and return 0.
(Ville)
- Keep a bxt_ prefix on the lookup functions since they're still only
used on bxt+ for now. We can rename them later if we extend this
table-based approach back to older platforms. (Ville)
v5:
- Fix cnl table's ratios for 24mhz refclk. (Ville)
- Don't miss the named initializers on the cnl table. (Ville)
- Represent refclk in table as u16 rather than u32. (Ville)
Cc: Ville Syrjälä
Signed-off-by: Matt Roper
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 303 +++--
drivers/gpu/drm/i915/display/intel_cdclk.h | 7 +
drivers/gpu/drm/i915/i915_drv.h| 3 +
3 files changed, 110 insertions(+), 203 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index dfcb1cc58951..f3431b530966 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -1161,28 +1161,88 @@ static void skl_uninit_cdclk(struct drm_i915_private
*dev_priv)
skl_set_cdclk(dev_priv, &cdclk_state, INVALID_PIPE);
}
-static int bxt_calc_cdclk(int min_cdclk)
-{
- if (min_cdclk > 576000)
- return 624000;
- else if (min_cdclk > 384000)
- return 576000;
- else if (min_cdclk > 288000)
- return 384000;
- else if (min_cdclk > 144000)
- return 288000;
- else
- return 144000;
+static const struct intel_cdclk_vals bxt_cdclk_table[] = {
+ { .refclk = 19200, .cdclk = 144000, .divider = 8, .ratio = 60 },
+ { .refclk = 19200, .cdclk = 288000, .divider = 4, .ratio = 60 },
+ { .refclk = 19200, .cdclk = 384000, .divider = 3, .ratio = 60 },
+ { .refclk = 19200, .cdclk = 576000, .divider = 2, .ratio = 60 },
+ { .refclk = 19200, .cdclk = 624000, .divider = 2, .ratio = 65 },
+ {}
+};
+
+static const struct intel_cdclk_vals glk_cdclk_table[] = {
+ { .refclk = 19200, .cdclk = 79200, .divider = 8, .ratio = 33 },
+ { .refclk = 19200, .cdclk = 158400, .divider = 4, .ratio = 33 },
+ { .refclk = 19200, .cdclk = 316800, .divider = 2, .ratio = 33 },
+ {}
+};
+
+static const struct intel_cdclk_vals cnl_cdclk_table[] = {
+ { .refclk = 19200, .cdclk = 168000, .divider = 4, .ratio = 35 },
+ { .refclk = 19200, .cdclk = 336000, .divider = 2, .ratio = 35 },
+ { .refclk = 19200, .cdclk = 528000, .divider = 2, .ratio = 55 },
+
+ { .refclk = 24000, .cdclk = 168000, .divider = 4, .ratio = 28 },
+ { .refclk = 24000, .cdclk = 336000, .divider = 2, .ratio = 28 },
+ { .refclk = 24000, .cdclk = 528000, .divider = 2, .ratio = 44 },
+ {}
+};
+
+static const struct intel_cdclk_vals icl_cdclk_table[] = {
+ { .refclk = 19200, .cdclk = 172800, .divider = 2, .ratio = 18 },
+ { .refclk = 19200, .cdclk = 192000, .divider = 2, .ratio = 20 },
+ { .refclk = 19200, .cdclk = 307200, .divider = 2, .ratio = 32 },
+ { .refclk = 19200, .cdclk = 326400, .divider = 4, .ratio = 68 },
+ { .refclk = 19200, .cdclk = 556800, .divider = 2, .ratio = 58 },
+ { .refclk = 19200, .cdclk = 652800, .divider = 2, .ratio = 68 },
+
+ { .refclk = 24000, .cdclk = 18, .divider = 2, .ratio = 15 },
+ { .refclk = 24000, .cdclk = 192000, .divider = 2, .ratio = 16 },
+ { .refclk = 24000, .cdclk = 312000, .divider = 2, .ratio = 26 },
+ { .refclk = 24000, .cdclk = 324000, .divider = 4, .ratio = 54 },
+ { .refclk = 24000, .cdclk = 552000, .divider = 2, .ratio = 46 },
+ { .refclk = 24000, .cdclk = 648000, .divider = 2, .ratio = 54 },
+
+ { .refclk = 38400, .cdclk = 172800, .divider = 2, .ratio = 9 },
+ { .refclk = 38400, .cdclk = 192000, .divider = 2, .ratio = 10 },
+ { .refclk = 38400, .cdclk = 307200, .divider = 2, .ratio = 16 },
+ { .refclk = 38400, .cdclk = 326400, .divider = 4, .ratio = 34 },
+ { .refclk = 38400, .cdclk = 556800, .divider = 2, .ratio = 29 },
+ { .refclk = 38400, .cdclk = 652800, .divider = 2, .ratio =
[Intel-gfx] [PATCH] drm/i915/tgl: Disable rc6 for debugging
References: https://bugs.freedesktop.org/show_bug.cgi?id=111593
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_pci.c | 1 +
drivers/gpu/drm/i915/intel_pm.c | 3 +--
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index fbe98a2db88e..b3cc8560696b 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -797,6 +797,7 @@ static const struct intel_device_info
intel_tigerlake_12_info = {
.display.has_modular_fia = 1,
.engine_mask =
BIT(RCS0) | BIT(BCS0) | BIT(VECS0) | BIT(VCS0) | BIT(VCS2),
+ .has_rc6 = false, /* XXX disabled for debugging */
};
#undef GEN
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 528e90ed5de4..54a8b7705bc6 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -8671,8 +8671,7 @@ void intel_disable_gt_powersave(struct drm_i915_private
*dev_priv)
{
mutex_lock(&dev_priv->gt_pm.rps.lock);
- if (HAS_RC6(dev_priv))
- intel_disable_rc6(dev_priv);
+ intel_disable_rc6(dev_priv);
intel_disable_rps(dev_priv);
if (HAS_LLC(dev_priv))
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for cdclk consolidation and rework for BXT-TGL (rev6)
== Series Details ==
Series: cdclk consolidation and rework for BXT-TGL (rev6)
URL : https://patchwork.freedesktop.org/series/66365/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
c43a4d52b847 drm/i915: Consolidate bxt/cnl/icl cdclk readout
-:81: CHECK:CAMELCASE: Avoid CamelCase:
#81: FILE: drivers/gpu/drm/i915/display/intel_cdclk.c:1272:
+ if (I915_READ(SKL_DSSM) & CNL_DSSM_CDCLK_PLL_REFCLK_24MHz)
total: 0 errors, 0 warnings, 1 checks, 412 lines checked
37ddadb11c01 drm/i915: Use literal representation of cdclk tables
ab429f360abd drm/i915: Combine bxt_set_cdclk and cnl_set_cdclk
9cb44aa8a751 drm/i915: Kill cnl_sanitize_cdclk()
780de9619be6 drm/i915: Consolidate {bxt, cnl, icl}_uninit_cdclk
3609840b0ce8 drm/i915: Add calc_voltage_level display vfunc
5c0e43cdb759 drm/i915: Enhance cdclk sanitization
a21088c79279 drm/i915: Consolidate {bxt, cnl, icl}_init_cdclk
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for cdclk consolidation and rework for BXT-TGL (rev5)
== Series Details ==
Series: cdclk consolidation and rework for BXT-TGL (rev5)
URL : https://patchwork.freedesktop.org/series/66365/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6861 -> Patchwork_14344
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14344/
Known issues
Here are the changes found in Patchwork_14344 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_mmap_gtt@basic-copy:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) +1
similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6861/fi-icl-u3/igt@gem_mmap_...@basic-copy.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14344/fi-icl-u3/igt@gem_mmap_...@basic-copy.html
Possible fixes
* igt@gem_ctx_switch@legacy-render:
- fi-icl-u2: [INCOMPLETE][3] ([fdo#107713] / [fdo#111381]) ->
[PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6861/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14344/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html
* igt@gem_render_tiled_blits@basic:
- fi-icl-u3: [DMESG-WARN][5] ([fdo#107724]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6861/fi-icl-u3/igt@gem_render_tiled_bl...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14344/fi-icl-u3/igt@gem_render_tiled_bl...@basic.html
* igt@kms_chamelium@dp-edid-read:
- {fi-icl-u4}:[FAIL][7] ([fdo#111045]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6861/fi-icl-u4/igt@kms_chamel...@dp-edid-read.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14344/fi-icl-u4/igt@kms_chamel...@dp-edid-read.html
Warnings
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][9] ([fdo#111096]) -> [FAIL][10] ([fdo#111407])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6861/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14344/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
Participating hosts (54 -> 45)
--
Missing(9): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-pnv-d510 fi-icl-y fi-icl-guc fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6861 -> Patchwork_14344
CI-20190529: 20190529
CI_DRM_6861: 32c81a3173640f165510de65b8e4137aa049b33f @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5178: efb4539494d94f03374874d3b61bd04ef3802aaa @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14344: 1dfdfc7ecb8a401d3dd6dfcb2ddfc2b237cb1bff @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
1dfdfc7ecb8a drm/i915: Consolidate {bxt, cnl, icl}_init_cdclk
202e21f4a86f drm/i915: Enhance cdclk sanitization
05d3115ff981 drm/i915: Add calc_voltage_level display vfunc
3b06fc2eac50 drm/i915: Consolidate {bxt, cnl, icl}_uninit_cdclk
4d1593ea66fc drm/i915: Kill cnl_sanitize_cdclk()
ade79d916b5c drm/i915: Combine bxt_set_cdclk and cnl_set_cdclk
0b12faaf504b drm/i915: Use literal representation of cdclk tables
c7ffbe99a9da drm/i915: Consolidate bxt/cnl/icl cdclk readout
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14344/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for cdclk consolidation and rework for BXT-TGL (rev6)
== Series Details ==
Series: cdclk consolidation and rework for BXT-TGL (rev6)
URL : https://patchwork.freedesktop.org/series/66365/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6861 -> Patchwork_14345
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14345/
Known issues
Here are the changes found in Patchwork_14345 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_mmap_gtt@basic:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) +1
similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6861/fi-icl-u3/igt@gem_mmap_...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14345/fi-icl-u3/igt@gem_mmap_...@basic.html
Possible fixes
* igt@gem_ctx_switch@legacy-render:
- {fi-icl-guc}: [INCOMPLETE][3] ([fdo#107713] / [fdo#111381]) ->
[PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6861/fi-icl-guc/igt@gem_ctx_swi...@legacy-render.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14345/fi-icl-guc/igt@gem_ctx_swi...@legacy-render.html
- fi-icl-u2: [INCOMPLETE][5] ([fdo#107713] / [fdo#111381]) ->
[PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6861/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14345/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html
* igt@gem_render_tiled_blits@basic:
- fi-icl-u3: [DMESG-WARN][7] ([fdo#107724]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6861/fi-icl-u3/igt@gem_render_tiled_bl...@basic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14345/fi-icl-u3/igt@gem_render_tiled_bl...@basic.html
* igt@i915_selftest@live_execlists:
- fi-skl-gvtdvm: [DMESG-FAIL][9] ([fdo#08]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6861/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14345/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][11] ([fdo#111096]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6861/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14345/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#08]: https://bugs.freedesktop.org/show_bug.cgi?id=08
[fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381
Participating hosts (54 -> 47)
--
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y
fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6861 -> Patchwork_14345
CI-20190529: 20190529
CI_DRM_6861: 32c81a3173640f165510de65b8e4137aa049b33f @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5178: efb4539494d94f03374874d3b61bd04ef3802aaa @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14345: a21088c79279e1d0a78c197d2d5d1029e60f9546 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
a21088c79279 drm/i915: Consolidate {bxt, cnl, icl}_init_cdclk
5c0e43cdb759 drm/i915: Enhance cdclk sanitization
3609840b0ce8 drm/i915: Add calc_voltage_level display vfunc
780de9619be6 drm/i915: Consolidate {bxt, cnl, icl}_uninit_cdclk
9cb44aa8a751 drm/i915: Kill cnl_sanitize_cdclk()
ab429f360abd drm/i915: Combine bxt_set_cdclk and cnl_set_cdclk
37ddadb11c01 drm/i915: Use literal representation of cdclk tables
c43a4d52b847 drm/i915: Consolidate bxt/cnl/icl cdclk readout
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14345/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v16 03/13] drm/i915/perf: drop list of streams
Minor comment below. With or without it,
Reviewed-by: Umesh Nerlige Ramappa
Regards,
Umesh
On Mon, Sep 09, 2019 at 12:31:06PM +0300, Lionel Landwerlin wrote:
At some point in time there was the idea that we could have multiple
stream from the same piece of HW but that never materialized and given
the hard time we already have making everything work with the
submission side, there is no real point having this list of 1 element
around.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 6 --
drivers/gpu/drm/i915/i915_perf.c | 16 +---
2 files changed, 1 insertion(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index db7480831e52..75607450ba00 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1082,11 +1082,6 @@ struct i915_perf_stream {
*/
struct drm_i915_private *dev_priv;
- /**
-* @link: Links the stream into ``&drm_i915_private->streams``
-*/
- struct list_head link;
-
/**
* @wakeref: As we keep the device awake while the perf stream is
* active, we track our runtime pm reference for later release.
@@ -1671,7 +1666,6 @@ struct drm_i915_private {
* except exclusive_stream.
*/
struct mutex lock;
- struct list_head streams;
/*
* The stream currently using the OA unit. If accessed
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index c1b764233761..d18cd332afb7 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1435,9 +1435,6 @@ static void gen7_init_oa_buffer(struct i915_perf_stream
*stream)
*/
memset(stream->oa_buffer.vaddr, 0, OA_BUFFER_SIZE);
- /* Maybe make ->pollin per-stream state if we support multiple
-* concurrent streams in the future.
-*/
stream->pollin = false;
}
@@ -1494,10 +1491,6 @@ static void gen8_init_oa_buffer(struct i915_perf_stream
*stream)
*/
memset(stream->oa_buffer.vaddr, 0, OA_BUFFER_SIZE);
- /*
-* Maybe make ->pollin per-stream state if we support multiple
-* concurrent streams in the future.
-*/
one more instance of the above comment remains in i915_perf_read.
stream->pollin = false;
}
@@ -2633,8 +2626,6 @@ static void i915_perf_destroy_locked(struct
i915_perf_stream *stream)
if (stream->ops->destroy)
stream->ops->destroy(stream);
- list_del(&stream->link);
-
if (stream->ctx)
i915_gem_context_put(stream->ctx);
@@ -2783,8 +2774,6 @@ i915_perf_open_ioctl_locked(struct drm_i915_private
*dev_priv,
goto err_flags;
}
- list_add(&stream->link, &dev_priv->perf.streams);
-
if (param->flags & I915_PERF_FLAG_FD_CLOEXEC)
f_flags |= O_CLOEXEC;
if (param->flags & I915_PERF_FLAG_FD_NONBLOCK)
@@ -2793,7 +2782,7 @@ i915_perf_open_ioctl_locked(struct drm_i915_private
*dev_priv,
stream_fd = anon_inode_getfd("[i915_perf]", &fops, stream, f_flags);
if (stream_fd < 0) {
ret = stream_fd;
- goto err_open;
+ goto err_flags;
}
if (!(param->flags & I915_PERF_FLAG_DISABLED))
@@ -2806,8 +2795,6 @@ i915_perf_open_ioctl_locked(struct drm_i915_private
*dev_priv,
return stream_fd;
-err_open:
- list_del(&stream->link);
err_flags:
if (stream->ops->destroy)
stream->ops->destroy(stream);
@@ -3643,7 +3630,6 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
}
if (dev_priv->perf.ops.enable_metric_set) {
- INIT_LIST_HEAD(&dev_priv->perf.streams);
mutex_init(&dev_priv->perf.lock);
oa_sample_rate_hard_limit = 1000 *
--
2.23.0
___
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
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm: two planes with the same zpos have undefined ordering
== Series Details == Series: drm: two planes with the same zpos have undefined ordering URL : https://patchwork.freedesktop.org/series/66480/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6860_full -> Patchwork_14337_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_14337_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_14337_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_14337_full: ### IGT changes ### Possible regressions * igt@gem_persistent_relocs@forked-thrash-inactive: - shard-kbl: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/shard-kbl3/igt@gem_persistent_rel...@forked-thrash-inactive.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/shard-kbl6/igt@gem_persistent_rel...@forked-thrash-inactive.html Known issues Here are the changes found in Patchwork_14337_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_shared@exec-single-timeline-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#110841]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/shard-iclb7/igt@gem_ctx_sha...@exec-single-timeline-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/shard-iclb4/igt@gem_ctx_sha...@exec-single-timeline-bsd.html * igt@gem_exec_balancer@smoke: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#110854]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/shard-iclb2/igt@gem_exec_balan...@smoke.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/shard-iclb3/igt@gem_exec_balan...@smoke.html * igt@gem_exec_schedule@deep-bsd: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#111325]) +3 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/shard-iclb7/igt@gem_exec_sched...@deep-bsd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/shard-iclb4/igt@gem_exec_sched...@deep-bsd.html * igt@gem_exec_schedule@promotion-bsd1: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#109276]) +16 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/shard-iclb2/igt@gem_exec_sched...@promotion-bsd1.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/shard-iclb8/igt@gem_exec_sched...@promotion-bsd1.html * igt@gem_tiled_swapping@non-threaded: - shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([fdo#108686]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/shard-kbl2/igt@gem_tiled_swapp...@non-threaded.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/shard-kbl4/igt@gem_tiled_swapp...@non-threaded.html * igt@i915_pm_rpm@gem-execbuf-stress: - shard-iclb: [PASS][13] -> [INCOMPLETE][14] ([fdo#107713] / [fdo#108840]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/shard-iclb1/igt@i915_pm_...@gem-execbuf-stress.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/shard-iclb2/igt@i915_pm_...@gem-execbuf-stress.html * igt@i915_suspend@fence-restore-tiled2untiled: - shard-apl: [PASS][15] -> [DMESG-WARN][16] ([fdo#108566]) +3 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/shard-apl2/igt@i915_susp...@fence-restore-tiled2untiled.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/shard-apl6/igt@i915_susp...@fence-restore-tiled2untiled.html * igt@kms_fbcon_fbt@fbc-suspend: - shard-skl: [PASS][17] -> [DMESG-WARN][18] ([fdo#106107]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/shard-skl10/igt@kms_fbcon_...@fbc-suspend.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/shard-skl3/igt@kms_fbcon_...@fbc-suspend.html * igt@kms_flip@2x-modeset-vs-vblank-race: - shard-glk: [PASS][19] -> [FAIL][20] ([fdo#111609]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/shard-glk3/igt@kms_f...@2x-modeset-vs-vblank-race.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/shard-glk1/igt@kms_f...@2x-modeset-vs-vblank-race.html * igt@kms_flip@flip-vs-expired-vblank: - shard-glk: [PASS][21] -> [FAIL][22] ([fdo#105363]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6860/shard-glk1/igt@kms_f...@flip-vs-expired-vblank.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14337/shard-glk9/igt@kms_f...@flip-vs-expired-vblank.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-shrfb-msflip-blt: - shard-iclb: [PASS][2
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/tgl: Disable rc6 for debugging (rev2)
== Series Details ==
Series: drm/i915/tgl: Disable rc6 for debugging (rev2)
URL : https://patchwork.freedesktop.org/series/66492/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6861 -> Patchwork_14346
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14346/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_14346:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_pm_rpm@basic-pci-d3-state:
- {fi-tgl-u}: NOTRUN -> [SKIP][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14346/fi-tgl-u/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@basic-rte:
- {fi-tgl-u}: NOTRUN -> [FAIL][2]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14346/fi-tgl-u/igt@i915_pm_...@basic-rte.html
* igt@i915_selftest@live_gem_contexts:
- {fi-tgl-u}: NOTRUN -> [DMESG-FAIL][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14346/fi-tgl-u/igt@i915_selftest@live_gem_contexts.html
Known issues
Here are the changes found in Patchwork_14346 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: [PASS][4] -> [INCOMPLETE][5] ([fdo#107718])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6861/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14346/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
* igt@prime_vgem@basic-write:
- fi-icl-u3: [PASS][6] -> [DMESG-WARN][7] ([fdo#107724]) +1
similar issue
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6861/fi-icl-u3/igt@prime_v...@basic-write.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14346/fi-icl-u3/igt@prime_v...@basic-write.html
Possible fixes
* igt@gem_ctx_switch@legacy-render:
- {fi-icl-guc}: [INCOMPLETE][8] ([fdo#107713] / [fdo#111381]) ->
[PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6861/fi-icl-guc/igt@gem_ctx_swi...@legacy-render.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14346/fi-icl-guc/igt@gem_ctx_swi...@legacy-render.html
- fi-icl-u2: [INCOMPLETE][10] ([fdo#107713] / [fdo#111381]) ->
[PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6861/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14346/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html
* igt@gem_exec_gttfill@basic:
- {fi-tgl-u}: [INCOMPLETE][12] ([fdo#111593]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6861/fi-tgl-u/igt@gem_exec_gttf...@basic.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14346/fi-tgl-u/igt@gem_exec_gttf...@basic.html
* igt@gem_render_tiled_blits@basic:
- fi-icl-u3: [DMESG-WARN][14] ([fdo#107724]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6861/fi-icl-u3/igt@gem_render_tiled_bl...@basic.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14346/fi-icl-u3/igt@gem_render_tiled_bl...@basic.html
* igt@i915_selftest@live_execlists:
- fi-skl-gvtdvm: [DMESG-FAIL][16] ([fdo#08]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6861/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14346/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#08]: https://bugs.freedesktop.org/show_bug.cgi?id=08
[fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381
[fdo#111593]: https://bugs.freedesktop.org/show_bug.cgi?id=111593
Participating hosts (54 -> 46)
--
Missing(8): fi-ilk-m540 fi-cml-s fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6861 -> Patchwork_14346
CI-20190529: 20190529
CI_DRM_6861: 32c81a3173640f165510de65b8e4137aa049b33f @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5178: efb4539494d94f03374874d3b61bd04ef3802aaa @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14346: aa75aa407970561a3866f2f08f799e9cbbf41d67 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commit
