[Intel-gfx] [PULL] gvt-fixes for 5.0-rc3
Hi, This contains one cmd parser failure fix to allow cmd access for one register, and fix region cleanup properly in vGPU destroy, and another fix for critical mmap size check mistake. Thanks. -- The following changes since commit f0e9943725186ddbdc9718a559c26c5f507262f2: drm/i915/gvt: Fix workload request allocation before request add (2019-01-09 12:59:09 +0800) are available in the Git repository at: https://github.com/intel/gvt-linux.git tags/gvt-fixes-2018-01-17 for you to fetch changes up to 51b00d8509dc69c98740da2ad07308b630d3eb7d: drm/i915/gvt: Fix mmap range check (2019-01-15 19:04:45 +0800) gvt-fixes-2018-01-17 - Fix one register cmd parser failure (Colin) - Fix region cleanup for vGPU destroy (Henry) - Fix mmap size check (Zhenyu) Colin Xu (1): drm/i915/gvt: Allow F_CMD_ACCESS on mmio 0x21f0 Hang Yuan (1): drm/i915/gvt: free VFIO region space in vgpu detach Zhenyu Wang (1): drm/i915/gvt: Fix mmap range check drivers/gpu/drm/i915/gvt/handlers.c | 1 + drivers/gpu/drm/i915/gvt/hypercall.h | 2 +- drivers/gpu/drm/i915/gvt/kvmgt.c | 30 ++ drivers/gpu/drm/i915/gvt/mpt.h | 2 +- 4 files changed, 29 insertions(+), 6 deletions(-) -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/17] drm/i915: switch to kernel fixed size types
On Wed, 16 Jan 2019, Ville Syrjälä wrote: > On Wed, Jan 16, 2019 at 11:15:18AM +0200, Jani Nikula wrote: >> Hi all - >> >> I haven't cared all that much about using C99 fixed size types (uint32_t >> etc.) in the driver in addition to kernel types, as long as only one or >> the other is used in the same struct/function/file. But the increasing >> mixed use crossed some OCD threshold the other day. It gets ugly, and >> sets a precedent that mixed use is fine. >> >> Let's switch to kernel types exclusively, shall we? >> >> Each path in the series is independent of the others, and it's mostly >> one patch per file, apart from the first patch which gathers all the >> isolated uses into one patch. I've tried to order the series from least >> to most likely to cause conflicts with in-flight work per gut feeling. >> >> Please holler if you think some of these patches need to wait for some >> other, more important stuff to land first. This was mostly scripted, >> with a few manual edits on top, so pretty quick to redo on top later. >> >> After most of these have landed, I intend to drop PREFER_KERNEL_TYPES >> from the checkpatch ignore list, and enforce. > > Did a really quick scan through and the pattern matcher in the > brain didn't complain, so seems good enough to me. > > Reviewed-by: Ville Syrjälä Thanks for the reviews Chris, Ville & José! I pushed the the patches listed below for starters. Started small. While I took care with the r-b's, I failed to record the acks from Chris and Tvrtko. :( Apologies. BR, Jani. Pushed now: >> drm/i915: small isolated c99 types to kernel types switch >> drm/i915/crt: switch to kernel types >> drm/i915/lspcon: switch to kernel types >> drm/i915/debugfs: switch to kernel types >> drm/i915/irq: switch to kernel types >> drm/i915/cdclk: switch to kernel types >> drm/i915/dpll_mgr: switch to kernel types >> drm/i915/dp: switch to kernel types >> drm/i915/sprite: switch to kernel types -- 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 13/13] drm/i915: Disable pipe gamma when C8 pixel format is used
>-Original Message-
>From: Ville Syrjala [mailto:ville.syrj...@linux.intel.com]
>Sent: Friday, January 11, 2019 10:38 PM
>To: intel-gfx@lists.freedesktop.org
>Cc: Shankar, Uma ; Roper, Matthew D
>
>Subject: [PATCH 13/13] drm/i915: Disable pipe gamma when C8 pixel format is
>used
>
>From: Ville Syrjälä
>
>Planes scanning out C8 will want to use the legacy lut as their palette. That
>means
>the LUT content are unikely to be useful for gamma correction on other planes.
Typo in unlikely.
With this fixed.
Reviewed-by: Uma Shankar
>Thus we should disable pipe gamma for all the other planes. And we should
>reject
>any non legacy LUT configurations when
>C8 planes are present.
>
>Fixes the appearance of the hw cursor when running X -depth 8.
>
>Note that CHV with it's independent CGM degamma/gamma LUTs could probably
>use the CGM for gamma correction even when the legacy LUT is used for C8. But
>that would require a new uapi for configuring the legacy LUT and CGM LUTs at
>the same time. Totally not worth it.
>
>Signed-off-by: Ville Syrjälä
>---
> drivers/gpu/drm/i915/intel_atomic_plane.c | 5 +
> drivers/gpu/drm/i915/intel_color.c| 8 +++-
> drivers/gpu/drm/i915/intel_drv.h | 1 +
> 3 files changed, 13 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
>b/drivers/gpu/drm/i915/intel_atomic_plane.c
>index 50be2c5dd76e..f311763867c4 100644
>--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
>+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
>@@ -119,6 +119,7 @@ int intel_plane_atomic_check_with_state(const struct
>intel_crtc_state *old_crtc_
>
> new_crtc_state->active_planes &= ~BIT(plane->id);
> new_crtc_state->nv12_planes &= ~BIT(plane->id);
>+ new_crtc_state->c8_planes &= ~BIT(plane->id);
> new_plane_state->base.visible = false;
>
> if (!new_plane_state->base.crtc && !old_plane_state->base.crtc) @@ -
>136,6 +137,10 @@ int intel_plane_atomic_check_with_state(const struct
>intel_crtc_state *old_crtc_
> new_plane_state->base.fb->format->format == DRM_FORMAT_NV12)
> new_crtc_state->nv12_planes |= BIT(plane->id);
>
>+ if (new_plane_state->base.visible &&
>+ new_plane_state->base.fb->format->format == DRM_FORMAT_C8)
>+ new_crtc_state->c8_planes |= BIT(plane->id);
>+
> if (new_plane_state->base.visible || old_plane_state->base.visible)
> new_crtc_state->update_planes |= BIT(plane->id);
>
>diff --git a/drivers/gpu/drm/i915/intel_color.c
>b/drivers/gpu/drm/i915/intel_color.c
>index 789b04bb51d2..c8d12653d77f 100644
>--- a/drivers/gpu/drm/i915/intel_color.c
>+++ b/drivers/gpu/drm/i915/intel_color.c
>@@ -691,7 +691,13 @@ int intel_color_check(struct intel_crtc_state
>*crtc_state)
> degamma_length = INTEL_INFO(dev_priv)->color.degamma_lut_size;
> gamma_length = INTEL_INFO(dev_priv)->color.gamma_lut_size;
>
>- crtc_state->gamma_enable = gamma_lut || degamma_lut;
>+ /* C8 needs the legacy LUT all to itself */
>+ if (crtc_state->c8_planes &&
>+ !crtc_state_is_legacy_gamma(crtc_state))
>+ return -EINVAL;
>+
>+ crtc_state->gamma_enable = (gamma_lut || degamma_lut) &&
>+ !crtc_state->c8_planes;
>
> if (INTEL_GEN(dev_priv) >= 9 ||
> IS_BROADWELL(dev_priv) || IS_HASWELL(dev_priv)) diff --git
>a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
>index a4496f799af3..4d9ea05a6825 100644
>--- a/drivers/gpu/drm/i915/intel_drv.h
>+++ b/drivers/gpu/drm/i915/intel_drv.h
>@@ -930,6 +930,7 @@ struct intel_crtc_state {
> /* bitmask of visible planes (enum plane_id) */
> u8 active_planes;
> u8 nv12_planes;
>+ u8 c8_planes;
>
> /* bitmask of planes that will be updated during the commit */
> u8 update_planes;
>--
>2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/13] drm/i915: Turn off pipe CSC when it's not needed
>-Original Message-
>From: Ville Syrjala [mailto:ville.syrj...@linux.intel.com]
>Sent: Friday, January 11, 2019 10:38 PM
>To: intel-gfx@lists.freedesktop.org
>Cc: Shankar, Uma ; Roper, Matthew D
>
>Subject: [PATCH 12/13] drm/i915: Turn off pipe CSC when it's not needed
>
>From: Ville Syrjälä
>
>As with pipe gamma we can avoid the potential precision loss from the pipe csc
>unit when there is no need to use it. And again we need the same logic for
>updating the planes.
Looks ok to me.
Reviewed-by: Uma Shankar
>Signed-off-by: Ville Syrjälä
>---
> drivers/gpu/drm/i915/intel_color.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/intel_color.c
>b/drivers/gpu/drm/i915/intel_color.c
>index a8b7428a64bf..789b04bb51d2 100644
>--- a/drivers/gpu/drm/i915/intel_color.c
>+++ b/drivers/gpu/drm/i915/intel_color.c
>@@ -659,7 +659,8 @@ intel_color_add_affected_planes(struct intel_crtc_state
>*new_crtc_state)
> intel_atomic_get_old_crtc_state(state, crtc);
> struct intel_plane *plane;
>
>- if (new_crtc_state->gamma_enable == old_crtc_state->gamma_enable)
>+ if (new_crtc_state->gamma_enable == old_crtc_state->gamma_enable
>&&
>+ new_crtc_state->csc_enable == old_crtc_state->csc_enable)
> return 0;
>
> for_each_intel_plane_on_crtc(_priv->drm, crtc, plane) { @@ -684,6
>+685,7 @@ int intel_color_check(struct intel_crtc_state *crtc_state)
> const struct drm_property_blob *gamma_lut = crtc_state-
>>base.gamma_lut;
> const struct drm_property_blob *degamma_lut = crtc_state-
>>base.degamma_lut;
> size_t gamma_length, degamma_length;
>+ bool limited_color_range = false;
> int ret;
>
> degamma_length = INTEL_INFO(dev_priv)->color.degamma_lut_size;
>@@ -693,7 +695,11 @@ int intel_color_check(struct intel_crtc_state
>*crtc_state)
>
> if (INTEL_GEN(dev_priv) >= 9 ||
> IS_BROADWELL(dev_priv) || IS_HASWELL(dev_priv))
>- crtc_state->csc_enable = true;
>+ limited_color_range = crtc_state->limited_color_range;
>+
>+ crtc_state->csc_enable =
>+ crtc_state->output_format != INTEL_OUTPUT_FORMAT_RGB ||
>+ crtc_state->base.ctm || limited_color_range;
>
> ret = intel_color_add_affected_planes(crtc_state);
> if (ret)
>--
>2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/13] drm/i915: Turn off pipe gamma when it's not needed.
>-Original Message-
>From: Ville Syrjala [mailto:ville.syrj...@linux.intel.com]
>Sent: Friday, January 11, 2019 10:38 PM
>To: intel-gfx@lists.freedesktop.org
>Cc: Shankar, Uma ; Roper, Matthew D
>
>Subject: [PATCH 11/13] drm/i915: Turn off pipe gamma when it's not needed.
Full stop can be dropped.
>
>From: Ville Syrjälä
>
>The pipe internal precision is higher than what we currently program to the
>degamma/gamma LUTs. We can get a higher quality image by bypassing the LUTs
>when they're not needed. Let's do that.
>
>Each plane has its own control bit for this, so we have to update all active
>planes.
>The way we've done this we don't actually have to run through the whole
>.check_plane() thing. And we actually do the .color_check() after
>.check_plane()
>so we couldn't even do that without shuffling the code around.
>
>Additionally on pre-skl we have to update the primary plane regardless of
>whether it's active or not on account of the primayr plane gamma enable bit
>also
Typo in primary.
Overall looks ok to me.
Reviewed-by: Uma Shankar
>affecting the pipe bottom color.
>
>Signed-off-by: Ville Syrjälä
>---
> drivers/gpu/drm/i915/intel_color.c | 55 --
> 1 file changed, 53 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/intel_color.c
>b/drivers/gpu/drm/i915/intel_color.c
>index 8d7ea902a34b..a8b7428a64bf 100644
>--- a/drivers/gpu/drm/i915/intel_color.c
>+++ b/drivers/gpu/drm/i915/intel_color.c
>@@ -633,27 +633,78 @@ void intel_color_commit(const struct intel_crtc_state
>*crtc_state)
> dev_priv->display.color_commit(crtc_state);
> }
>
>+static bool need_plane_update(struct intel_plane *plane,
>+const struct intel_crtc_state *crtc_state) {
>+ struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
>+
>+ /*
>+ * On pre-SKL the pipe gamma enable and pipe csc enable for
>+ * the pipe bottom color are configured via the primary plane.
>+ * We have to reconfigure that even if the plane is inactive.
>+ */
>+ return crtc_state->active_planes & BIT(plane->id) ||
>+ (INTEL_GEN(dev_priv) < 9 &&
>+ plane->id == PLANE_PRIMARY);
>+}
>+
>+static int
>+intel_color_add_affected_planes(struct intel_crtc_state
>+*new_crtc_state) {
>+ struct intel_crtc *crtc = to_intel_crtc(new_crtc_state->base.crtc);
>+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>+ struct intel_atomic_state *state =
>+ to_intel_atomic_state(new_crtc_state->base.state);
>+ const struct intel_crtc_state *old_crtc_state =
>+ intel_atomic_get_old_crtc_state(state, crtc);
>+ struct intel_plane *plane;
>+
>+ if (new_crtc_state->gamma_enable == old_crtc_state->gamma_enable)
>+ return 0;
>+
>+ for_each_intel_plane_on_crtc(_priv->drm, crtc, plane) {
>+ struct intel_plane_state *plane_state;
>+
>+ if (!need_plane_update(plane, new_crtc_state))
>+ continue;
>+
>+ plane_state = intel_atomic_get_plane_state(state, plane);
>+ if (IS_ERR(plane_state))
>+ return PTR_ERR(plane_state);
>+
>+ new_crtc_state->update_planes |= BIT(plane->id);
>+ }
>+
>+ return 0;
>+}
>+
> int intel_color_check(struct intel_crtc_state *crtc_state) {
> struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
> const struct drm_property_blob *gamma_lut = crtc_state-
>>base.gamma_lut;
> const struct drm_property_blob *degamma_lut = crtc_state-
>>base.degamma_lut;
> size_t gamma_length, degamma_length;
>+ int ret;
>
> degamma_length = INTEL_INFO(dev_priv)->color.degamma_lut_size;
> gamma_length = INTEL_INFO(dev_priv)->color.gamma_lut_size;
>
>- crtc_state->gamma_enable = true;
>+ crtc_state->gamma_enable = gamma_lut || degamma_lut;
>
> if (INTEL_GEN(dev_priv) >= 9 ||
> IS_BROADWELL(dev_priv) || IS_HASWELL(dev_priv))
> crtc_state->csc_enable = true;
>
>+ ret = intel_color_add_affected_planes(crtc_state);
>+ if (ret)
>+ return ret;
>+
> /*
>* We also allow no degamma lut/ctm and a gamma lut at the legacy
>* size (256 entries).
>*/
>- if (crtc_state_is_legacy_gamma(crtc_state)) {
>+ if (!crtc_state->gamma_enable ||
>+ crtc_state_is_legacy_gamma(crtc_state)) {
> crtc_state->gamma_mode = GAMMA_MODE_MODE_8BIT;
> return 0;
> }
>--
>2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/13] drm/i915: Track pipe csc enable in crtc state
>-Original Message-
>From: Roper, Matthew D
>Sent: Thursday, January 17, 2019 1:14 AM
>To: Ville Syrjala
>Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma
>Subject: Re: [PATCH 10/13] drm/i915: Track pipe csc enable in crtc state
>
>On Fri, Jan 11, 2019 at 07:08:20PM +0200, Ville Syrjala wrote:
>> From: Ville Syrjälä
>>
>> Just like we did for pipe gamma, let's also track the pipe csc state.
>> The hardware only exists on ILK+, and currently we always enable it on
>> hsw+ and never on any other platforms. Just like with pipe gamma, the
>> primary plane control register is used for the readout on pre-SKL, and
>> the pipe bottom color register on SKL+.
>>
>> Signed-off-by: Ville Syrjälä
>
>Reviewed-by: Matt Roper
Looks ok to me.
Reviewed-by: Uma Shankar
>> ---
>> drivers/gpu/drm/i915/i915_reg.h | 4 ++--
>> drivers/gpu/drm/i915/intel_color.c | 7 ++-
>> drivers/gpu/drm/i915/intel_display.c | 18 ++
>> drivers/gpu/drm/i915/intel_drv.h | 3 +++
>> drivers/gpu/drm/i915/intel_sprite.c | 6 --
>> 5 files changed, 29 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> b/drivers/gpu/drm/i915/i915_reg.h index 7f0913bc1b47..8848721dd691
>> 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -6120,7 +6120,7 @@ enum {
>> #define MCURSOR_PIPE_SELECT_SHIFT 28
>> #define MCURSOR_PIPE_SELECT(pipe) ((pipe) << 28)
>> #define MCURSOR_GAMMA_ENABLE (1 << 26)
>> -#define MCURSOR_PIPE_CSC_ENABLE (1 << 24)
>> +#define MCURSOR_PIPE_CSC_ENABLE (1 << 24) /* ilk+ */
>> #define MCURSOR_ROTATE_180(1 << 15)
>> #define MCURSOR_TRICKLE_FEED_DISABLE (1 << 14)
>> #define _CURABASE 0x70084
>> @@ -6175,7 +6175,7 @@ enum {
>> #define DISPPLANE_RGBA888 (0xf << 26)
>> #define DISPPLANE_STEREO_ENABLE (1 << 25)
>> #define DISPPLANE_STEREO_DISABLE 0
>> -#define DISPPLANE_PIPE_CSC_ENABLE (1 << 24)
>> +#define DISPPLANE_PIPE_CSC_ENABLE (1 << 24) /* ilk+ */
>> #define DISPPLANE_SEL_PIPE_SHIFT 24
>> #define DISPPLANE_SEL_PIPE_MASK (3 <<
>DISPPLANE_SEL_PIPE_SHIFT)
>> #define DISPPLANE_SEL_PIPE(pipe) ((pipe) <<
>DISPPLANE_SEL_PIPE_SHIFT)
>> diff --git a/drivers/gpu/drm/i915/intel_color.c
>> b/drivers/gpu/drm/i915/intel_color.c
>> index 313b281204fa..8d7ea902a34b 100644
>> --- a/drivers/gpu/drm/i915/intel_color.c
>> +++ b/drivers/gpu/drm/i915/intel_color.c
>> @@ -397,7 +397,8 @@ static void skl_color_commit(const struct
>intel_crtc_state *crtc_state)
>> val = 0;
>> if (crtc_state->gamma_enable)
>> val |= PIPE_BOTTOM_GAMMA_ENABLE;
>> -val |= PIPE_BOTTOM_CSC_ENABLE;
>> +if (crtc_state->csc_enable)
>> +val |= PIPE_BOTTOM_CSC_ENABLE;
>> I915_WRITE(PIPE_BOTTOM_COLOR(pipe), val);
>>
>> I915_WRITE(GAMMA_MODE(crtc->pipe), crtc_state->gamma_mode);
>@@
>> -644,6 +645,10 @@ int intel_color_check(struct intel_crtc_state
>> *crtc_state)
>>
>> crtc_state->gamma_enable = true;
>>
>> +if (INTEL_GEN(dev_priv) >= 9 ||
>> +IS_BROADWELL(dev_priv) || IS_HASWELL(dev_priv))
>> +crtc_state->csc_enable = true;
>> +
>> /*
>> * We also allow no degamma lut/ctm and a gamma lut at the legacy
>> * size (256 entries).
>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 896ce95790cb..2e66b398167e 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -3189,7 +3189,7 @@ static u32 i9xx_plane_ctl_crtc(const struct
>intel_crtc_state *crtc_state)
>> if (crtc_state->gamma_enable)
>> dspcntr |= DISPPLANE_GAMMA_ENABLE;
>>
>> -if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
>> +if (crtc_state->csc_enable)
>> dspcntr |= DISPPLANE_PIPE_CSC_ENABLE;
>>
>> if (INTEL_GEN(dev_priv) < 5)
>> @@ -3668,7 +3668,8 @@ u32 skl_plane_ctl_crtc(const struct intel_crtc_state
>*crtc_state)
>> if (crtc_state->gamma_enable)
>> plane_ctl |= PLANE_CTL_PIPE_GAMMA_ENABLE;
>>
>> -plane_ctl |= PLANE_CTL_PIPE_CSC_ENABLE;
>> +if (crtc_state->csc_enable)
>> +plane_ctl |= PLANE_CTL_PIPE_CSC_ENABLE;
>>
>> return plane_ctl;
>> }
>> @@ -3723,7 +3724,8 @@ u32 glk_plane_color_ctl_crtc(const struct
>intel_crtc_state *crtc_state)
>> if (crtc_state->gamma_enable)
>> plane_color_ctl |= PLANE_COLOR_PIPE_GAMMA_ENABLE;
>>
>> -plane_color_ctl |= PLANE_COLOR_PIPE_CSC_ENABLE;
>> +if (crtc_state->csc_enable)
>> +plane_color_ctl |= PLANE_COLOR_PIPE_CSC_ENABLE;
>>
>> return plane_color_ctl;
>> }
>> @@ -8052,6 +8054,10 @@ static void i9xx_get_pipe_color_config(struct
>> intel_crtc_state *crtc_state)
>>
>> if (tmp & DISPPLANE_GAMMA_ENABLE)
>> crtc_state->gamma_enable = true;
>> +
>> +if (!HAS_GMCH_DISPLAY(dev_priv) &&
Re: [Intel-gfx] [PATCH 09/13] drm/i915: Track pipe gamma enable/disable in crtc state
>-Original Message-
>From: Roper, Matthew D
>Sent: Thursday, January 17, 2019 1:07 AM
>To: Ville Syrjala
>Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma
>Subject: Re: [PATCH 09/13] drm/i915: Track pipe gamma enable/disable in crtc
>state
>
>On Fri, Jan 11, 2019 at 07:08:19PM +0200, Ville Syrjala wrote:
>> From: Ville Syrjälä
>>
>> Track whether pipe gamma is enabled or disabled. For now we stick to
>> the current behaviour of always enabling gamma. But we do get working
>> state readout for this now. On SKL+ we use the pipe bottom color as
>> our hardware state. On pre-SKL we read the state back from the primary
>> plane control register.
>> That only really correct for g4x+, as older platforms never gamma
>> correct pipe bottom color. But doing the readout the same way on all
>> platforms is fine, and there is no other way to do it really.
>>
>> Signed-off-by: Ville Syrjälä
>
>Reviewed-by: Matt Roper
>
>> ---
>> drivers/gpu/drm/i915/i915_reg.h | 8
>> drivers/gpu/drm/i915/intel_color.c | 24 +++-
>> drivers/gpu/drm/i915/intel_display.c | 56 ++--
>> drivers/gpu/drm/i915/intel_drv.h | 3 ++
>> drivers/gpu/drm/i915/intel_sprite.c | 17 +++--
>> 5 files changed, 92 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> b/drivers/gpu/drm/i915/i915_reg.h index 9d17ba199be4..7f0913bc1b47
>> 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -5707,6 +5707,14 @@ enum {
>> #define PIPEMISC_DITHER_TYPE_SP (0 << 2)
>> #define PIPEMISC(pipe) _MMIO_PIPE2(pipe,
>_PIPE_MISC_A)
>>
>> +/* SKL+ pipe bottom color */
>> +#define _PIPE_BOTTOM_COLOR_A0x70034
>> +#define _PIPE_BOTTOM_COLOR_B0x71034
>> +#define PIPE_BOTTOM_GAMMA_ENABLE (1 << 31)
>> +#define PIPE_BOTTOM_CSC_ENABLE(1 << 30)
>> +#define PIPE_BOTTOM_COLOR_MASK0x3FFF
>> +#define PIPE_BOTTOM_COLOR(pipe) _MMIO_PIPE2(pipe,
>_PIPE_BOTTOM_COLOR_A)
>> +
>> #define VLV_DPFLIPSTAT
> _MMIO(VLV_DISPLAY_BASE + 0x70028)
>> #define PIPEB_LINE_COMPARE_INT_EN (1 << 29)
>> #define PIPEB_HLINE_INT_EN(1 << 28)
>> diff --git a/drivers/gpu/drm/i915/intel_color.c
>> b/drivers/gpu/drm/i915/intel_color.c
>> index 6fdbfa8c4008..313b281204fa 100644
>> --- a/drivers/gpu/drm/i915/intel_color.c
>> +++ b/drivers/gpu/drm/i915/intel_color.c
>> @@ -387,6 +387,24 @@ static void hsw_color_commit(const struct
>intel_crtc_state *crtc_state)
>> ilk_load_csc_matrix(crtc_state);
>> }
>>
>> +static void skl_color_commit(const struct intel_crtc_state
>> +*crtc_state) {
>> +struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
>> +struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>> +enum pipe pipe = crtc->pipe;
>> +u32 val;
>> +
>> +val = 0;
We can initialize this above itself.
>> +if (crtc_state->gamma_enable)
>> +val |= PIPE_BOTTOM_GAMMA_ENABLE;
>> +val |= PIPE_BOTTOM_CSC_ENABLE;
>> +I915_WRITE(PIPE_BOTTOM_COLOR(pipe), val);
>> +
>> +I915_WRITE(GAMMA_MODE(crtc->pipe), crtc_state->gamma_mode);
>> +
>> +ilk_load_csc_matrix(crtc_state);
>> +}
>> +
>> static void bdw_load_degamma_lut(const struct intel_crtc_state
>> *crtc_state) {
>> struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
>> @@ -624,6 +642,8 @@ int intel_color_check(struct intel_crtc_state
>*crtc_state)
>> degamma_length = INTEL_INFO(dev_priv)->color.degamma_lut_size;
>> gamma_length = INTEL_INFO(dev_priv)->color.gamma_lut_size;
>>
>> +crtc_state->gamma_enable = true;
>> +
>> /*
>> * We also allow no degamma lut/ctm and a gamma lut at the legacy
>> * size (256 entries).
>> @@ -674,7 +694,9 @@ void intel_color_init(struct intel_crtc *crtc)
>> else
>> dev_priv->display.load_luts = i9xx_load_luts;
>>
>> -if (INTEL_GEN(dev_priv) >= 8 || IS_HASWELL(dev_priv))
>> +if (INTEL_GEN(dev_priv) >= 9)
>> +dev_priv->display.color_commit = skl_color_commit;
>> +else if (IS_BROADWELL(dev_priv) || IS_HASWELL(dev_priv))
>> dev_priv->display.color_commit = hsw_color_commit;
>> else
>> dev_priv->display.color_commit = ilk_color_commit; diff
>--git
>> a/drivers/gpu/drm/i915/intel_display.c
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 90afcae91b30..896ce95790cb 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -3186,7 +3186,8 @@ static u32 i9xx_plane_ctl_crtc(const struct
>intel_crtc_state *crtc_state)
>> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>> u32 dspcntr = 0;
>>
>> -dspcntr |= DISPPLANE_GAMMA_ENABLE;
>> +if (crtc_state->gamma_enable)
>> +dspcntr |= DISPPLANE_GAMMA_ENABLE;
>>
>> if
[Intel-gfx] linux-next: manual merge of the drm-intel tree with the drm tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/i915_gem.c
between commit:
dd847a706974 ("drm/i915: Compile fix for 64b dma-fence seqno")
from the drm tree and commit:
9f58892ea996 ("drm/i915: Pull all the reset functionality together into
i915_reset.c")
from the drm-intel tree.
I fixed it up (the latter moved the code updated by the former, and the
fix has been already been applied to the moved code) and can carry the
fix as necessary. This is now fixed as far as linux-next is concerned,
but any non trivial conflicts should be mentioned to your upstream
maintainer when your tree is submitted for merging. You may also want
to consider cooperating with the maintainer of the conflicting tree to
minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpvTfRYQe76D.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/3] drm/i915/icl: Work around broken VBTs for port F detection
On Thu, 2018-12-20 at 17:52 +0200, Imre Deak wrote: > VBT may include incorrect information about the presence of port F. > Work > around this on SKUs where we know the port is not present. If we cannot trust the data in VBT, can we not test for the absence of port-F by enabling the powerwell and checking for a timeout? Or at least mark up a non-existent port after the first timeout so that we don't keep probing it. This patch is an improvement over checking the VBT for all ports, so Reviewed-by: Dhinakaran Pandiyan > > v2: > - Fix IS_ICL_WITH_PORT_F, so it's useable from any context. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108915 > Cc: Mika Kahola > Cc: Jani Nikula > Signed-off-by: Imre Deak > --- > drivers/gpu/drm/i915/i915_drv.h | 2 ++ > drivers/gpu/drm/i915/intel_display.c | 4 +++- > 2 files changed, 5 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/i915_drv.h > b/drivers/gpu/drm/i915/i915_drv.h > index 815db160b966..e45cda9d9555 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -2317,6 +2317,8 @@ intel_info(const struct drm_i915_private > *dev_priv) >(dev_priv)->info.gt == 3) > #define IS_CNL_WITH_PORT_F(dev_priv) (IS_CANNONLAKE(dev_priv) && \ > (INTEL_DEVID(dev_priv) & > 0x0004) == 0x0004) > +#define IS_ICL_WITH_PORT_F(dev_priv) (IS_ICELAKE(dev_priv) && \ > + INTEL_DEVID(dev_priv) != > 0x8A51) > > #define IS_ALPHA_SUPPORT(intel_info) ((intel_info)- > >is_alpha_support) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index 2b81da068010..bd7fdaf7e093 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -14276,8 +14276,10 @@ static void intel_setup_outputs(struct > drm_i915_private *dev_priv) > /* >* On some ICL SKUs port F is not present. No strap > bits for >* this, so rely on VBT. > + * Work around broken VBTs on SKUs known to have no > port F. >*/ > - if (intel_bios_is_port_present(dev_priv, PORT_F)) > + if (IS_ICL_WITH_PORT_F(dev_priv) && > + intel_bios_is_port_present(dev_priv, PORT_F)) > intel_ddi_init(dev_priv, PORT_F); > > icl_dsi_init(dev_priv); ___ 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: Pull all the reset functionality together into i915_reset.c
== Series Details ==
Series: drm/i915: Pull all the reset functionality together into i915_reset.c
URL : https://patchwork.freedesktop.org/series/55308/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5435_full -> Patchwork_11307_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_11307_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@kms_chv_cursor_fail@pipe-c-256x256-top-edge:
- shard-skl: NOTRUN -> FAIL [fdo#104671]
* igt@kms_cursor_crc@cursor-64x21-offscreen:
- shard-skl: PASS -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-64x21-sliding:
- shard-apl: PASS -> FAIL [fdo#103232] +1
* igt@kms_fbcon_fbt@psr:
- shard-skl: NOTRUN -> FAIL [fdo#107882]
* igt@kms_flip@flip-vs-dpms-interruptible:
- shard-kbl: PASS -> DMESG-WARN [fdo#105345]
* igt@kms_flip@flip-vs-expired-vblank:
- shard-glk: PASS -> FAIL [fdo#105363]
* igt@kms_flip@flip-vs-rmfb-interruptible:
- shard-kbl: PASS -> DMESG-WARN [fdo#103313] / [fdo#105345]
* igt@kms_flip@single-buffer-flip-vs-dpms-off-vs-modeset-interruptible:
- shard-kbl: PASS -> DMESG-FAIL [fdo#103313]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-onoff:
- shard-apl: PASS -> FAIL [fdo#103167] +1
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-move:
- shard-glk: PASS -> FAIL [fdo#103167] +5
* igt@kms_plane@pixel-format-pipe-a-planes-source-clamping:
- shard-apl: PASS -> FAIL [fdo#108948]
* igt@kms_plane@pixel-format-pipe-b-planes:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#106885]
* igt@kms_plane@plane-position-covered-pipe-b-planes:
- shard-glk: PASS -> FAIL [fdo#103166] +1
* igt@kms_plane_alpha_blend@pipe-a-alpha-basic:
- shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145]
* igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb:
- shard-skl: NOTRUN -> FAIL [fdo#108145] +2
* igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl: PASS -> FAIL [fdo#107815] +1
* igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
- shard-apl: PASS -> FAIL [fdo#103166] +3
* igt@kms_plane_multiple@atomic-pipe-c-tiling-yf:
- shard-skl: NOTRUN -> FAIL [fdo#103166] / [fdo#107815]
* igt@kms_rotation_crc@multiplane-rotation-cropping-top:
- shard-kbl: PASS -> DMESG-FAIL [fdo#108950]
* igt@kms_sysfs_edid_timing:
- shard-skl: NOTRUN -> FAIL [fdo#100047]
Possible fixes
* igt@kms_ccs@pipe-a-crc-sprite-planes-basic:
- shard-apl: FAIL [fdo#106510] / [fdo#108145] -> PASS
* igt@kms_cursor_crc@cursor-128x128-random:
- shard-apl: FAIL [fdo#103232] -> PASS +5
* igt@kms_cursor_crc@cursor-256x256-sliding:
- shard-glk: FAIL [fdo#103232] -> PASS +2
* igt@kms_cursor_crc@cursor-256x256-suspend:
- shard-apl: FAIL [fdo#103191] / [fdo#103232] -> PASS
* igt@kms_cursor_legacy@cursor-vs-flip-atomic-transitions:
- shard-apl: INCOMPLETE [fdo#103927] -> PASS
* igt@kms_draw_crc@draw-method-xrgb2101010-pwrite-xtiled:
- shard-skl: FAIL [fdo#103184] -> PASS
* igt@kms_flip@2x-blocking-absolute-wf_vblank-interruptible:
- shard-hsw: DMESG-WARN [fdo#102614] -> PASS
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite:
- shard-apl: FAIL [fdo#103167] -> PASS +3
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-wc:
- shard-glk: FAIL [fdo#103167] -> PASS +1
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b-frame-sequence:
- shard-skl: FAIL [fdo#103191] / [fdo#107362] -> PASS
* igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
- shard-glk: FAIL [fdo#103166] -> PASS
* igt@kms_plane_multiple@atomic-pipe-c-tiling-y:
- shard-apl: FAIL [fdo#103166] -> PASS
* igt@kms_setmode@basic:
- shard-apl: FAIL [fdo#99912] -> PASS
- shard-kbl: FAIL [fdo#99912] -> PASS
* igt@kms_vblank@pipe-c-ts-continuation-suspend:
- shard-hsw: FAIL [fdo#104894] -> PASS
* igt@pm_rc6_residency@rc6-accuracy:
- shard-snb: {SKIP} [fdo#109271] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#100047]: https://bugs.freedesktop.org/show_bug.cgi?id=100047
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103184]: https://bugs.freedesktop.org/show_bug.cgi?id=103184
[fdo#103191]:
Re: [Intel-gfx] [PATCH 17/17] drm/i915/intel_drv.h: switch to kernel types
On Wed, 2019-01-16 at 11:15 +0200, Jani Nikula wrote:
> Mixed C99 and kernel types use is getting ugly. Prefer kernel types.
>
> sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g'
>
> Minor checkpatch fixes sprinkled on top of the changed lines.
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_drv.h | 94
>
> 1 file changed, 46 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index e5a436c33307..33b733d37706 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -300,13 +300,12 @@ struct intel_panel {
>
> /* Connector and platform specific backlight functions
> */
> int (*setup)(struct intel_connector *connector, enum
> pipe pipe);
> - uint32_t (*get)(struct intel_connector *connector);
> - void (*set)(const struct drm_connector_state
> *conn_state, uint32_t level);
> + u32 (*get)(struct intel_connector *connector);
> + void (*set)(const struct drm_connector_state
> *conn_state, u32 level);
> void (*disable)(const struct drm_connector_state
> *conn_state);
> void (*enable)(const struct intel_crtc_state
> *crtc_state,
> const struct drm_connector_state
> *conn_state);
> - uint32_t (*hz_to_pwm)(struct intel_connector
> *connector,
> - uint32_t hz);
> + u32 (*hz_to_pwm)(struct intel_connector *connector, u32
> hz);
> void (*power)(struct intel_connector *, bool enable);
> } backlight;
> };
> @@ -598,7 +597,7 @@ struct intel_initial_plane_config {
>
> struct intel_scaler {
> int in_use;
> - uint32_t mode;
> + u32 mode;
> };
>
> struct intel_crtc_scaler_state {
> @@ -636,7 +635,7 @@ struct intel_crtc_scaler_state {
>
> struct intel_pipe_wm {
> struct intel_wm_level wm[5];
> - uint32_t linetime;
> + u32 linetime;
> bool fbc_wm_enabled;
> bool pipe_enabled;
> bool sprites_enabled;
> @@ -652,7 +651,7 @@ struct skl_plane_wm {
>
> struct skl_pipe_wm {
> struct skl_plane_wm planes[I915_MAX_PLANES];
> - uint32_t linetime;
> + u32 linetime;
> };
>
> enum vlv_wm_level {
> @@ -665,7 +664,7 @@ enum vlv_wm_level {
> struct vlv_wm_state {
> struct g4x_pipe_wm wm[NUM_VLV_WM_LEVELS];
> struct g4x_sr_wm sr[NUM_VLV_WM_LEVELS];
> - uint8_t num_levels;
> + u8 num_levels;
> bool cxsr;
> };
>
> @@ -878,13 +877,13 @@ struct intel_crtc_state {
> /* Used by SDVO (and if we ever fix it, HDMI). */
> unsigned pixel_multiplier;
>
> - uint8_t lane_count;
> + u8 lane_count;
>
> /*
>* Used by platforms having DP/HDMI PHY with programmable lane
>* latency optimization.
>*/
> - uint8_t lane_lat_optim_mask;
> + u8 lane_lat_optim_mask;
>
> /* minimum acceptable voltage level */
> u8 min_voltage_level;
> @@ -928,7 +927,7 @@ struct intel_crtc_state {
> struct intel_crtc_wm_state wm;
>
> /* Gamma mode programmed on the pipe */
> - uint32_t gamma_mode;
> + u32 gamma_mode;
>
> /* bitmask of visible planes (enum plane_id) */
> u8 active_planes;
> @@ -1014,7 +1013,7 @@ struct intel_plane {
> enum pipe pipe;
> bool has_fbc;
> bool has_ccs;
> - uint32_t frontbuffer_bit;
> + u32 frontbuffer_bit;
>
> struct {
> u32 base, cntl, size;
> @@ -1109,9 +1108,9 @@ enum link_m_n_set {
>
> struct intel_dp_compliance_data {
> unsigned long edid;
> - uint8_t video_pattern;
> - uint16_t hdisplay, vdisplay;
> - uint8_t bpc;
> + u8 video_pattern;
> + u16 hdisplay, vdisplay;
> + u8 bpc;
> };
>
> struct intel_dp_compliance {
> @@ -1124,18 +1123,18 @@ struct intel_dp_compliance {
>
> struct intel_dp {
> i915_reg_t output_reg;
> - uint32_t DP;
> + u32 DP;
> int link_rate;
> - uint8_t lane_count;
> - uint8_t sink_count;
> + u8 lane_count;
> + u8 sink_count;
> bool link_mst;
> bool link_trained;
> bool has_audio;
> bool reset_link_params;
> - uint8_t dpcd[DP_RECEIVER_CAP_SIZE];
> - uint8_t psr_dpcd[EDP_PSR_RECEIVER_CAP_SIZE];
> - uint8_t downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
> - uint8_t edp_dpcd[EDP_DISPLAY_CTL_CAP_SIZE];
> + u8 dpcd[DP_RECEIVER_CAP_SIZE];
> + u8 psr_dpcd[EDP_PSR_RECEIVER_CAP_SIZE];
> + u8 downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
> + u8 edp_dpcd[EDP_DISPLAY_CTL_CAP_SIZE];
> u8 dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE];
> u8 fec_capable;
> /* source rates */
> @@ -1155,7 +1154,7 @@ struct intel_dp {
> /* sink or branch descriptor */
> struct drm_dp_desc desc;
> struct drm_dp_aux aux;
> - uint8_t train_set[4];
> + u8
Re: [Intel-gfx] [PATCH 16/17] drm/i915/i915_drv.h: switch to kernel types
On Wed, 2019-01-16 at 11:15 +0200, Jani Nikula wrote:
> Mixed C99 and kernel types use is getting ugly. Prefer kernel
> types.
>
> sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g'
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_drv.h | 158
>
> 1 file changed, 79 insertions(+), 79 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index da055a86db4d..ae4aedc53ca6 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -334,16 +334,16 @@ struct drm_i915_display_funcs {
> struct intel_csr {
> struct work_struct work;
> const char *fw_path;
> - uint32_t required_version;
> - uint32_t max_fw_size; /* bytes */
> - uint32_t *dmc_payload;
> - uint32_t dmc_fw_size; /* dwords */
> - uint32_t version;
> - uint32_t mmio_count;
> + u32 required_version;
> + u32 max_fw_size; /* bytes */
> + u32 *dmc_payload;
> + u32 dmc_fw_size; /* dwords */
> + u32 version;
> + u32 mmio_count;
> i915_reg_t mmioaddr[8];
> - uint32_t mmiodata[8];
> - uint32_t dc_state;
> - uint32_t allowed_dc_mask;
> + u32 mmiodata[8];
> + u32 dc_state;
> + u32 allowed_dc_mask;
> intel_wakeref_t wakeref;
> };
>
> @@ -400,7 +400,7 @@ struct intel_fbc {
>
> struct {
> unsigned int mode_flags;
> - uint32_t hsw_bdw_pixel_rate;
> + u32 hsw_bdw_pixel_rate;
> } crtc;
>
> struct {
> @@ -419,7 +419,7 @@ struct intel_fbc {
>
> int y;
>
> - uint16_t pixel_blend_mode;
> + u16 pixel_blend_mode;
> } plane;
>
> struct {
> @@ -559,7 +559,7 @@ struct i915_suspend_saved_registers {
> u32 saveSWF0[16];
> u32 saveSWF1[16];
> u32 saveSWF3[3];
> - uint64_t saveFENCE[I915_MAX_NUM_FENCES];
> + u64 saveFENCE[I915_MAX_NUM_FENCES];
> u32 savePCH_PORT_HOTPLUG;
> u16 saveGCDGMBUS;
> };
> @@ -906,9 +906,9 @@ struct i915_gem_mm {
> atomic_t bsd_engine_dispatch_index;
>
> /** Bit 6 swizzling required for X tiling */
> - uint32_t bit_6_swizzle_x;
> + u32 bit_6_swizzle_x;
> /** Bit 6 swizzling required for Y tiling */
> - uint32_t bit_6_swizzle_y;
> + u32 bit_6_swizzle_y;
>
> /* accounting, useful for userland debugging */
> spinlock_t object_stat_lock;
> @@ -935,20 +935,20 @@ struct ddi_vbt_port_info {
>* populate this field.
>*/
> #define HDMI_LEVEL_SHIFT_UNKNOWN 0xff
> - uint8_t hdmi_level_shift;
> + u8 hdmi_level_shift;
>
> - uint8_t supports_dvi:1;
> - uint8_t supports_hdmi:1;
> - uint8_t supports_dp:1;
> - uint8_t supports_edp:1;
> - uint8_t supports_typec_usb:1;
> - uint8_t supports_tbt:1;
> + u8 supports_dvi:1;
> + u8 supports_hdmi:1;
> + u8 supports_dp:1;
> + u8 supports_edp:1;
> + u8 supports_typec_usb:1;
> + u8 supports_tbt:1;
>
> - uint8_t alternate_aux_channel;
> - uint8_t alternate_ddc_pin;
> + u8 alternate_aux_channel;
> + u8 alternate_ddc_pin;
>
> - uint8_t dp_boost_level;
> - uint8_t hdmi_boost_level;
> + u8 dp_boost_level;
> + u8 hdmi_boost_level;
> int dp_max_link_rate; /* 0 for not limited by VBT
> */
> };
>
> @@ -1039,41 +1039,41 @@ enum intel_ddb_partitioning {
>
> struct intel_wm_level {
> bool enable;
> - uint32_t pri_val;
> - uint32_t spr_val;
> - uint32_t cur_val;
> - uint32_t fbc_val;
> + u32 pri_val;
> + u32 spr_val;
> + u32 cur_val;
> + u32 fbc_val;
> };
>
> struct ilk_wm_values {
> - uint32_t wm_pipe[3];
> - uint32_t wm_lp[3];
> - uint32_t wm_lp_spr[3];
> - uint32_t wm_linetime[3];
> + u32 wm_pipe[3];
> + u32 wm_lp[3];
> + u32 wm_lp_spr[3];
> + u32 wm_linetime[3];
> bool enable_fbc_wm;
> enum intel_ddb_partitioning partitioning;
> };
>
> struct g4x_pipe_wm {
> - uint16_t plane[I915_MAX_PLANES];
> - uint16_t fbc;
> + u16 plane[I915_MAX_PLANES];
> + u16 fbc;
> };
>
> struct g4x_sr_wm {
> - uint16_t plane;
> - uint16_t cursor;
> - uint16_t fbc;
> + u16 plane;
> + u16 cursor;
> + u16 fbc;
> };
>
> struct vlv_wm_ddl_values {
> - uint8_t plane[I915_MAX_PLANES];
> + u8 plane[I915_MAX_PLANES];
> };
>
> struct vlv_wm_values {
> struct g4x_pipe_wm pipe[3];
> struct g4x_sr_wm sr;
> struct vlv_wm_ddl_values ddl[3];
> - uint8_t level;
> + u8 level;
> bool cxsr;
> };
>
> @@ -1087,10 +1087,10 @@ struct g4x_wm_values {
> };
>
> struct skl_ddb_entry {
> - uint16_t start, end;/* in number of blocks, 'end' is
> exclusive */
> + u16 start, end; /* in number of blocks, 'end' is
Re: [Intel-gfx] [PATCH 15/17] drm/i915/display: switch to kernel types
On Wed, 2019-01-16 at 11:15 +0200, Jani Nikula wrote:
> Mixed C99 and kernel types use is getting ugly. Prefer kernel types.
>
> sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g'
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_display.c | 104 +--
>
> 1 file changed, 52 insertions(+), 52 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index af164d712e9e..b3d6ee7eee0e 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -49,7 +49,7 @@
> #include
>
> /* Primary plane formats for gen <= 3 */
> -static const uint32_t i8xx_primary_formats[] = {
> +static const u32 i8xx_primary_formats[] = {
> DRM_FORMAT_C8,
> DRM_FORMAT_RGB565,
> DRM_FORMAT_XRGB1555,
> @@ -57,7 +57,7 @@ static const uint32_t i8xx_primary_formats[] = {
> };
>
> /* Primary plane formats for gen >= 4 */
> -static const uint32_t i965_primary_formats[] = {
> +static const u32 i965_primary_formats[] = {
> DRM_FORMAT_C8,
> DRM_FORMAT_RGB565,
> DRM_FORMAT_XRGB,
> @@ -66,18 +66,18 @@ static const uint32_t i965_primary_formats[] = {
> DRM_FORMAT_XBGR2101010,
> };
>
> -static const uint64_t i9xx_format_modifiers[] = {
> +static const u64 i9xx_format_modifiers[] = {
> I915_FORMAT_MOD_X_TILED,
> DRM_FORMAT_MOD_LINEAR,
> DRM_FORMAT_MOD_INVALID
> };
>
> /* Cursor formats */
> -static const uint32_t intel_cursor_formats[] = {
> +static const u32 intel_cursor_formats[] = {
> DRM_FORMAT_ARGB,
> };
>
> -static const uint64_t cursor_format_modifiers[] = {
> +static const u64 cursor_format_modifiers[] = {
> DRM_FORMAT_MOD_LINEAR,
> DRM_FORMAT_MOD_INVALID
> };
> @@ -493,7 +493,7 @@ static int pnv_calc_dpll_params(int refclk,
> struct dpll *clock)
> return clock->dot;
> }
>
> -static uint32_t i9xx_dpll_compute_m(struct dpll *dpll)
> +static u32 i9xx_dpll_compute_m(struct dpll *dpll)
> {
> return 5 * (dpll->m1 + 2) + (dpll->m2 + 2);
> }
> @@ -528,8 +528,8 @@ int chv_calc_dpll_params(int refclk, struct dpll
> *clock)
> clock->p = clock->p1 * clock->p2;
> if (WARN_ON(clock->n == 0 || clock->p == 0))
> return 0;
> - clock->vco = DIV_ROUND_CLOSEST_ULL((uint64_t)refclk * clock->m,
> - clock->n << 22);
> + clock->vco = DIV_ROUND_CLOSEST_ULL((u64)refclk * clock->m,
> +clock->n << 22);
> clock->dot = DIV_ROUND_CLOSEST(clock->vco, clock->p);
>
> return clock->dot / 5;
> @@ -891,7 +891,7 @@ chv_find_best_dpll(const struct intel_limit
> *limit,
> struct drm_device *dev = crtc->base.dev;
> unsigned int best_error_ppm;
> struct dpll clock;
> - uint64_t m2;
> + u64 m2;
> int found = false;
>
> memset(best_clock, 0, sizeof(*best_clock));
> @@ -913,7 +913,7 @@ chv_find_best_dpll(const struct intel_limit
> *limit,
>
> clock.p = clock.p1 * clock.p2;
>
> - m2 = DIV_ROUND_CLOSEST_ULL(((uint64_t)target *
> clock.p *
> + m2 = DIV_ROUND_CLOSEST_ULL(((u64)target *
> clock.p *
> clock.n) << 22, refclk *
> clock.m1);
>
> if (m2 > INT_MAX/clock.m1)
> @@ -1610,7 +1610,7 @@ static void
> ironlake_enable_pch_transcoder(const struct intel_crtc_state *crtc_s
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> enum pipe pipe = crtc->pipe;
> i915_reg_t reg;
> - uint32_t val, pipeconf_val;
> + u32 val, pipeconf_val;
>
> /* Make sure PCH DPLL is enabled */
> assert_shared_dpll_enabled(dev_priv, crtc_state->shared_dpll);
> @@ -1698,7 +1698,7 @@ static void
> ironlake_disable_pch_transcoder(struct drm_i915_private *dev_priv,
> enum pipe pipe)
> {
> i915_reg_t reg;
> - uint32_t val;
> + u32 val;
>
> /* FDI relies on the transcoder */
> assert_fdi_tx_disabled(dev_priv, pipe);
> @@ -2375,7 +2375,7 @@ static int intel_fb_offset_to_xy(int *x, int
> *y,
> return 0;
> }
>
> -static unsigned int intel_fb_modifier_to_tiling(uint64_t
> fb_modifier)
> +static unsigned int intel_fb_modifier_to_tiling(u64 fb_modifier)
> {
> switch (fb_modifier) {
> case I915_FORMAT_MOD_X_TILED:
> @@ -3507,7 +3507,7 @@ u32 skl_plane_stride(const struct
> intel_plane_state *plane_state,
> return stride / skl_plane_stride_mult(fb, color_plane,
> rotation);
> }
>
> -static u32 skl_plane_ctl_format(uint32_t pixel_format)
> +static u32 skl_plane_ctl_format(u32 pixel_format)
> {
> switch (pixel_format) {
> case DRM_FORMAT_C8:
> @@ -3577,7 +3577,7 @@ static u32 glk_plane_color_ctl_alpha(const
> struct intel_plane_state *plane_state
> }
> }
>
> -static u32 skl_plane_ctl_tiling(uint64_t
Re: [Intel-gfx] [PATCH 14/17] drm/i915/csr: switch to kernel types
On Wed, 2019-01-16 at 11:15 +0200, Jani Nikula wrote:
> Mixed C99 and kernel types use is getting ugly. Prefer kernel types.
>
> sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g'
>
> Minor checkpatch fixes sprinkled on top of the changed lines.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_csr.c | 68
>
> 1 file changed, 34 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_csr.c
> b/drivers/gpu/drm/i915/intel_csr.c
> index ea5fb64d33dd..2b25cccdae16 100644
> --- a/drivers/gpu/drm/i915/intel_csr.c
> +++ b/drivers/gpu/drm/i915/intel_csr.c
> @@ -70,50 +70,50 @@ MODULE_FIRMWARE(BXT_CSR_PATH);
>
> struct intel_css_header {
> /* 0x09 for DMC */
> - uint32_t module_type;
> + u32 module_type;
>
> /* Includes the DMC specific header in dwords */
> - uint32_t header_len;
> + u32 header_len;
>
> /* always value would be 0x1 */
> - uint32_t header_ver;
> + u32 header_ver;
>
> /* Not used */
> - uint32_t module_id;
> + u32 module_id;
>
> /* Not used */
> - uint32_t module_vendor;
> + u32 module_vendor;
>
> /* in MMDD format */
> - uint32_t date;
> + u32 date;
>
> /* Size in dwords (CSS_Headerlen + PackageHeaderLen + dmc
> FWsLen)/4 */
> - uint32_t size;
> + u32 size;
>
> /* Not used */
> - uint32_t key_size;
> + u32 key_size;
>
> /* Not used */
> - uint32_t modulus_size;
> + u32 modulus_size;
>
> /* Not used */
> - uint32_t exponent_size;
> + u32 exponent_size;
>
> /* Not used */
> - uint32_t reserved1[12];
> + u32 reserved1[12];
>
> /* Major Minor */
> - uint32_t version;
> + u32 version;
>
> /* Not used */
> - uint32_t reserved2[8];
> + u32 reserved2[8];
>
> /* Not used */
> - uint32_t kernel_header_info;
> + u32 kernel_header_info;
> } __packed;
>
> struct intel_fw_info {
> - uint16_t reserved1;
> + u16 reserved1;
>
> /* Stepping (A, B, C, ..., *). * is a wildcard */
> char stepping;
> @@ -121,8 +121,8 @@ struct intel_fw_info {
> /* Sub-stepping (0, 1, ..., *). * is a wildcard */
> char substepping;
>
> - uint32_t offset;
> - uint32_t reserved2;
> + u32 offset;
> + u32 reserved2;
> } __packed;
>
> struct intel_package_header {
> @@ -135,14 +135,14 @@ struct intel_package_header {
> unsigned char reserved[10];
>
> /* Number of valid entries in the FWInfo array below */
> - uint32_t num_entries;
> + u32 num_entries;
>
> struct intel_fw_info fw_info[20];
> } __packed;
>
> struct intel_dmc_header {
> /* always value would be 0x40403E3E */
> - uint32_t signature;
> + u32 signature;
>
> /* DMC binary header length */
> unsigned char header_len;
> @@ -151,30 +151,30 @@ struct intel_dmc_header {
> unsigned char header_ver;
>
> /* Reserved */
> - uint16_t dmcc_ver;
> + u16 dmcc_ver;
>
> /* Major, Minor */
> - uint32_tproject;
> + u32 project;
>
> /* Firmware program size (excluding header) in dwords */
> - uint32_tfw_size;
> + u32 fw_size;
While at it, why not drop this taps as you did in other files?
Anyways:
Reviewed-by: José Roberto de Souza
>
> /* Major Minor version */
> - uint32_t fw_version;
> + u32 fw_version;
>
> /* Number of valid MMIO cycles present. */
> - uint32_t mmio_count;
> + u32 mmio_count;
>
> /* MMIO address */
> - uint32_t mmioaddr[8];
> + u32 mmioaddr[8];
>
> /* MMIO data */
> - uint32_t mmiodata[8];
> + u32 mmiodata[8];
>
> /* FW filename */
> unsigned char dfile[32];
>
> - uint32_t reserved1[2];
> + u32 reserved1[2];
> } __packed;
>
> struct stepping_info {
> @@ -230,7 +230,7 @@ intel_get_stepping_info(struct drm_i915_private
> *dev_priv)
>
> static void gen9_set_dc_state_debugmask(struct drm_i915_private
> *dev_priv)
> {
> - uint32_t val, mask;
> + u32 val, mask;
>
> mask = DC_STATE_DEBUG_MASK_MEMORY_UP;
>
> @@ -257,7 +257,7 @@ static void gen9_set_dc_state_debugmask(struct
> drm_i915_private *dev_priv)
> void intel_csr_load_program(struct drm_i915_private *dev_priv)
> {
> u32 *payload = dev_priv->csr.dmc_payload;
> - uint32_t i, fw_size;
> + u32 i, fw_size;
>
> if (!HAS_CSR(dev_priv)) {
> DRM_ERROR("No CSR support available for this
> platform\n");
> @@ -289,17 +289,17 @@ void intel_csr_load_program(struct
> drm_i915_private *dev_priv)
> gen9_set_dc_state_debugmask(dev_priv);
> }
>
> -static uint32_t *parse_csr_fw(struct drm_i915_private *dev_priv,
> - const struct firmware *fw)
> +static u32 *parse_csr_fw(struct drm_i915_private *dev_priv,
> + const struct firmware *fw)
> {
>
Re: [Intel-gfx] [PATCH 13/17] drm/i915/ddi: switch to kernel types
On Wed, 2019-01-16 at 11:15 +0200, Jani Nikula wrote:
> Mixed C99 and kernel types use is getting ugly. Prefer kernel types.
>
> sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g'
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 52
>
> 1 file changed, 26 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index ce44744a5f9d..b0bb8dfc2ed5 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -974,7 +974,7 @@ static void intel_wait_ddi_buf_idle(struct
> drm_i915_private *dev_priv,
> DRM_ERROR("Timeout waiting for DDI BUF %c idle bit\n",
> port_name(port));
> }
>
> -static uint32_t hsw_pll_to_ddi_pll_sel(const struct
> intel_shared_dpll *pll)
> +static u32 hsw_pll_to_ddi_pll_sel(const struct intel_shared_dpll
> *pll)
> {
> switch (pll->info->id) {
> case DPLL_ID_WRPLL1:
> @@ -995,8 +995,8 @@ static uint32_t hsw_pll_to_ddi_pll_sel(const
> struct intel_shared_dpll *pll)
> }
> }
>
> -static uint32_t icl_pll_to_ddi_pll_sel(struct intel_encoder
> *encoder,
> -const struct intel_crtc_state
> *crtc_state)
> +static u32 icl_pll_to_ddi_pll_sel(struct intel_encoder *encoder,
> + const struct intel_crtc_state
> *crtc_state)
> {
> const struct intel_shared_dpll *pll = crtc_state->shared_dpll;
> int clock = crtc_state->port_clock;
> @@ -1243,8 +1243,8 @@ static int skl_calc_wrpll_link(struct
> drm_i915_private *dev_priv,
> enum intel_dpll_id pll_id)
> {
> i915_reg_t cfgcr1_reg, cfgcr2_reg;
> - uint32_t cfgcr1_val, cfgcr2_val;
> - uint32_t p0, p1, p2, dco_freq;
> + u32 cfgcr1_val, cfgcr2_val;
> + u32 p0, p1, p2, dco_freq;
>
> cfgcr1_reg = DPLL_CFGCR1(pll_id);
> cfgcr2_reg = DPLL_CFGCR2(pll_id);
> @@ -1305,8 +1305,8 @@ static int skl_calc_wrpll_link(struct
> drm_i915_private *dev_priv,
> int cnl_calc_wrpll_link(struct drm_i915_private *dev_priv,
> enum intel_dpll_id pll_id)
> {
> - uint32_t cfgcr0, cfgcr1;
> - uint32_t p0, p1, p2, dco_freq, ref_clock;
> + u32 cfgcr0, cfgcr1;
> + u32 p0, p1, p2, dco_freq, ref_clock;
>
> if (INTEL_GEN(dev_priv) >= 11) {
> cfgcr0 = I915_READ(ICL_DPLL_CFGCR0(pll_id));
> @@ -1471,7 +1471,7 @@ static void icl_ddi_clock_get(struct
> intel_encoder *encoder,
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> enum port port = encoder->port;
> int link_clock = 0;
> - uint32_t pll_id;
> + u32 pll_id;
>
> pll_id = intel_get_shared_dpll_id(dev_priv, pipe_config-
> >shared_dpll);
> if (intel_port_is_combophy(dev_priv, port)) {
> @@ -1496,7 +1496,7 @@ static void cnl_ddi_clock_get(struct
> intel_encoder *encoder,
> {
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> int link_clock = 0;
> - uint32_t cfgcr0;
> + u32 cfgcr0;
> enum intel_dpll_id pll_id;
>
> pll_id = intel_get_shared_dpll_id(dev_priv, pipe_config-
> >shared_dpll);
> @@ -1550,7 +1550,7 @@ static void skl_ddi_clock_get(struct
> intel_encoder *encoder,
> {
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> int link_clock = 0;
> - uint32_t dpll_ctl1;
> + u32 dpll_ctl1;
> enum intel_dpll_id pll_id;
>
> pll_id = intel_get_shared_dpll_id(dev_priv, pipe_config-
> >shared_dpll);
> @@ -1739,7 +1739,7 @@ void intel_ddi_set_vc_payload_alloc(const
> struct intel_crtc_state *crtc_state,
> struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> - uint32_t temp;
> + u32 temp;
>
> temp = I915_READ(TRANS_DDI_FUNC_CTL(cpu_transcoder));
> if (state == true)
> @@ -1757,7 +1757,7 @@ void intel_ddi_enable_transcoder_func(const
> struct intel_crtc_state *crtc_state)
> enum pipe pipe = crtc->pipe;
> enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> enum port port = encoder->port;
> - uint32_t temp;
> + u32 temp;
>
> /* Enable TRANS_DDI_FUNC_CTL for the pipe to work in HDMI mode
> */
> temp = TRANS_DDI_FUNC_ENABLE;
> @@ -1841,7 +1841,7 @@ void intel_ddi_disable_transcoder_func(const
> struct intel_crtc_state *crtc_state
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> i915_reg_t reg = TRANS_DDI_FUNC_CTL(cpu_transcoder);
> - uint32_t val = I915_READ(reg);
> + u32 val = I915_READ(reg);
>
> val &= ~(TRANS_DDI_FUNC_ENABLE | TRANS_DDI_PORT_MASK |
> TRANS_DDI_DP_VC_PAYLOAD_ALLOC);
> val |= TRANS_DDI_PORT_NONE;
> @@ -1863,7 +1863,7 @@ int
Re: [Intel-gfx] [PATCH 12/17] drm/i915/pm: switch to kernel types
On Wed, 2019-01-16 at 11:15 +0200, Jani Nikula wrote:
> Mixed C99 and kernel types use is getting ugly. Prefer kernel types.
>
> sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g'
>
> Minor checkpatch fixes sprinkled on top of the changed lines.
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_pm.c | 213
>
> 1 file changed, 105 insertions(+), 108 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c
> b/drivers/gpu/drm/i915/intel_pm.c
> index 7613ae72df3d..8b63afa3a221 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -480,7 +480,7 @@ static void vlv_get_fifo_size(struct
> intel_crtc_state *crtc_state)
> int sprite0_start, sprite1_start;
>
> switch (pipe) {
> - uint32_t dsparb, dsparb2, dsparb3;
> + u32 dsparb, dsparb2, dsparb3;
> case PIPE_A:
> dsparb = I915_READ(DSPARB);
> dsparb2 = I915_READ(DSPARB2);
> @@ -513,7 +513,7 @@ static void vlv_get_fifo_size(struct
> intel_crtc_state *crtc_state)
> static int i9xx_get_fifo_size(struct drm_i915_private *dev_priv,
> enum i9xx_plane_id i9xx_plane)
> {
> - uint32_t dsparb = I915_READ(DSPARB);
> + u32 dsparb = I915_READ(DSPARB);
> int size;
>
> size = dsparb & 0x7f;
> @@ -529,7 +529,7 @@ static int i9xx_get_fifo_size(struct
> drm_i915_private *dev_priv,
> static int i830_get_fifo_size(struct drm_i915_private *dev_priv,
> enum i9xx_plane_id i9xx_plane)
> {
> - uint32_t dsparb = I915_READ(DSPARB);
> + u32 dsparb = I915_READ(DSPARB);
> int size;
>
> size = dsparb & 0x1ff;
> @@ -546,7 +546,7 @@ static int i830_get_fifo_size(struct
> drm_i915_private *dev_priv,
> static int i845_get_fifo_size(struct drm_i915_private *dev_priv,
> enum i9xx_plane_id i9xx_plane)
> {
> - uint32_t dsparb = I915_READ(DSPARB);
> + u32 dsparb = I915_READ(DSPARB);
> int size;
>
> size = dsparb & 0x7f;
> @@ -667,9 +667,9 @@ static unsigned int intel_wm_method1(unsigned int
> pixel_rate,
>unsigned int cpp,
>unsigned int latency)
> {
> - uint64_t ret;
> + u64 ret;
>
> - ret = (uint64_t) pixel_rate * cpp * latency;
> + ret = (u64)pixel_rate * cpp * latency;
> ret = DIV_ROUND_UP_ULL(ret, 1);
>
> return ret;
> @@ -1089,9 +1089,9 @@ static int g4x_fbc_fifo_size(int level)
> }
> }
>
> -static uint16_t g4x_compute_wm(const struct intel_crtc_state
> *crtc_state,
> -const struct intel_plane_state
> *plane_state,
> -int level)
> +static u16 g4x_compute_wm(const struct intel_crtc_state *crtc_state,
> + const struct intel_plane_state *plane_state,
> + int level)
> {
> struct intel_plane *plane = to_intel_plane(plane_state-
> >base.plane);
> struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
> @@ -1188,9 +1188,9 @@ static bool g4x_raw_fbc_wm_set(struct
> intel_crtc_state *crtc_state,
> return dirty;
> }
>
> -static uint32_t ilk_compute_fbc_wm(const struct intel_crtc_state
> *cstate,
> -const struct intel_plane_state
> *pstate,
> -uint32_t pri_val);
> +static u32 ilk_compute_fbc_wm(const struct intel_crtc_state *cstate,
> + const struct intel_plane_state *pstate,
> + u32 pri_val);
>
> static bool g4x_raw_plane_wm_compute(struct intel_crtc_state
> *crtc_state,
>const struct intel_plane_state
> *plane_state)
> @@ -1598,9 +1598,9 @@ static void vlv_setup_wm_latency(struct
> drm_i915_private *dev_priv)
> }
> }
>
> -static uint16_t vlv_compute_wm_level(const struct intel_crtc_state
> *crtc_state,
> - const struct intel_plane_state
> *plane_state,
> - int level)
> +static u16 vlv_compute_wm_level(const struct intel_crtc_state
> *crtc_state,
> + const struct intel_plane_state
> *plane_state,
> + int level)
> {
> struct intel_plane *plane = to_intel_plane(plane_state-
> >base.plane);
> struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
> @@ -1968,7 +1968,7 @@ static void vlv_atomic_update_fifo(struct
> intel_atomic_state *state,
> spin_lock(_priv->uncore.lock);
>
> switch (crtc->pipe) {
> - uint32_t dsparb, dsparb2, dsparb3;
> + u32 dsparb, dsparb2, dsparb3;
> case PIPE_A:
> dsparb = I915_READ_FW(DSPARB);
> dsparb2 = I915_READ_FW(DSPARB2);
> @@ -2262,8 +2262,8 @@ static void i9xx_update_wm(struct intel_crtc
> *unused_crtc)
> {
>
Re: [Intel-gfx] [PATCH 11/17] drm/i915/color: switch to kernel types
On Wed, 2019-01-16 at 11:15 +0200, Jani Nikula wrote:
> Mixed C99 and kernel types use is getting ugly. Prefer kernel
> types.
>
> sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g'
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_color.c | 40 +++-
> --
> 1 file changed, 20 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_color.c
> b/drivers/gpu/drm/i915/intel_color.c
> index 37fd9ddf762e..299eb7858adc 100644
> --- a/drivers/gpu/drm/i915/intel_color.c
> +++ b/drivers/gpu/drm/i915/intel_color.c
> @@ -142,7 +142,7 @@ static void ilk_load_csc_matrix(struct
> intel_crtc_state *crtc_state)
> struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> int i, pipe = crtc->pipe;
> - uint16_t coeffs[9] = { 0, };
> + u16 coeffs[9] = { 0, };
> bool limited_color_range = false;
>
> /*
> @@ -171,7 +171,7 @@ static void ilk_load_csc_matrix(struct
> intel_crtc_state *crtc_state)
>* hardware.
>*/
> for (i = 0; i < ARRAY_SIZE(coeffs); i++) {
> - uint64_t abs_coeff = ((1ULL << 63) - 1) &
> input[i];
> + u64 abs_coeff = ((1ULL << 63) - 1) & input[i];
>
> /*
>* Clamp input value to min/max supported by
> @@ -233,7 +233,7 @@ static void ilk_load_csc_matrix(struct
> intel_crtc_state *crtc_state)
> I915_WRITE(PIPE_CSC_PREOFF_LO(pipe), 0);
>
> if (INTEL_GEN(dev_priv) > 6) {
> - uint16_t postoff = 0;
> + u16 postoff = 0;
>
> if (limited_color_range)
> postoff = (16 * (1 << 12) / 255) & 0x1fff;
> @@ -244,7 +244,7 @@ static void ilk_load_csc_matrix(struct
> intel_crtc_state *crtc_state)
>
> I915_WRITE(PIPE_CSC_MODE(pipe), 0);
> } else {
> - uint32_t mode = CSC_MODE_YUV_TO_RGB;
> + u32 mode = CSC_MODE_YUV_TO_RGB;
>
> if (limited_color_range)
> mode |= CSC_BLACK_SCREEN_OFFSET;
> @@ -261,15 +261,15 @@ static void cherryview_load_csc_matrix(struct
> intel_crtc_state *crtc_state)
> struct drm_device *dev = crtc_state->base.crtc->dev;
> struct drm_i915_private *dev_priv = to_i915(dev);
> int pipe = to_intel_crtc(crtc_state->base.crtc)->pipe;
> - uint32_t mode;
> + u32 mode;
>
> if (crtc_state->base.ctm) {
> struct drm_color_ctm *ctm = crtc_state->base.ctm->data;
> - uint16_t coeffs[9] = { 0, };
> + u16 coeffs[9] = { 0, };
> int i;
>
> for (i = 0; i < ARRAY_SIZE(coeffs); i++) {
> - uint64_t abs_coeff =
> + u64 abs_coeff =
> ((1ULL << 63) - 1) & ctm->matrix[i];
>
> /* Round coefficient. */
> @@ -331,7 +331,7 @@ static void i9xx_load_luts_internal(struct
> intel_crtc_state *crtc_state,
> if (blob) {
> struct drm_color_lut *lut = blob->data;
> for (i = 0; i < 256; i++) {
> - uint32_t word =
> + u32 word =
> (drm_color_lut_extract(lut[i].red, 8)
> << 16) |
> (drm_color_lut_extract(lut[i].green, 8)
> << 8) |
> drm_color_lut_extract(lut[i].blue, 8);
> @@ -343,7 +343,7 @@ static void i9xx_load_luts_internal(struct
> intel_crtc_state *crtc_state,
> }
> } else {
> for (i = 0; i < 256; i++) {
> - uint32_t word = (i << 16) | (i << 8) | i;
> + u32 word = (i << 16) | (i << 8) | i;
>
> if (HAS_GMCH_DISPLAY(dev_priv))
> I915_WRITE(PALETTE(pipe, i), word);
> @@ -388,7 +388,7 @@ static void bdw_load_degamma_lut(struct
> intel_crtc_state *crtc_state)
> {
> struct drm_i915_private *dev_priv = to_i915(crtc_state-
> >base.crtc->dev);
> enum pipe pipe = to_intel_crtc(crtc_state->base.crtc)->pipe;
> - uint32_t i, lut_size = INTEL_INFO(dev_priv)-
> >color.degamma_lut_size;
> + u32 i, lut_size = INTEL_INFO(dev_priv)->color.degamma_lut_size;
>
> I915_WRITE(PREC_PAL_INDEX(pipe),
> PAL_PREC_SPLIT_MODE | PAL_PREC_AUTO_INCREMENT);
> @@ -397,7 +397,7 @@ static void bdw_load_degamma_lut(struct
> intel_crtc_state *crtc_state)
> struct drm_color_lut *lut = crtc_state-
> >base.degamma_lut->data;
>
> for (i = 0; i < lut_size; i++) {
> - uint32_t word =
> + u32 word =
> drm_color_lut_extract(lut[i].red, 10) << 20 |
> drm_color_lut_extract(lut[i].green, 10) << 10 |
> drm_color_lut_extract(lut[i].blue, 10);
> @@
Re: [Intel-gfx] [PATCH 10/17] drm/i915/sprite: switch to kernel types
On Wed, 2019-01-16 at 11:15 +0200, Jani Nikula wrote:
> Mixed C99 and kernel types use is getting ugly. Prefer kernel types.
>
> sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g'
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_sprite.c | 60 ++-
> --
> 1 file changed, 30 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> b/drivers/gpu/drm/i915/intel_sprite.c
> index 87a06fcca284..b02d3d9809e3 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -321,8 +321,8 @@ skl_program_scaler(struct intel_plane *plane,
> _state->scaler_state.scalers[scaler_id];
> int crtc_x = plane_state->base.dst.x1;
> int crtc_y = plane_state->base.dst.y1;
> - uint32_t crtc_w = drm_rect_width(_state->base.dst);
> - uint32_t crtc_h = drm_rect_height(_state->base.dst);
> + u32 crtc_w = drm_rect_width(_state->base.dst);
> + u32 crtc_h = drm_rect_height(_state->base.dst);
> u16 y_hphase, uv_rgb_hphase;
> u16 y_vphase, uv_rgb_vphase;
> int hscale, vscale;
> @@ -477,10 +477,10 @@ skl_program_plane(struct intel_plane *plane,
> u32 aux_stride = skl_plane_stride(plane_state, 1);
> int crtc_x = plane_state->base.dst.x1;
> int crtc_y = plane_state->base.dst.y1;
> - uint32_t x = plane_state->color_plane[color_plane].x;
> - uint32_t y = plane_state->color_plane[color_plane].y;
> - uint32_t src_w = drm_rect_width(_state->base.src) >> 16;
> - uint32_t src_h = drm_rect_height(_state->base.src) >> 16;
> + u32 x = plane_state->color_plane[color_plane].x;
> + u32 y = plane_state->color_plane[color_plane].y;
> + u32 src_w = drm_rect_width(_state->base.src) >> 16;
> + u32 src_h = drm_rect_height(_state->base.src) >> 16;
> struct intel_plane *linked = plane_state->linked_plane;
> const struct drm_framebuffer *fb = plane_state->base.fb;
> u8 alpha = plane_state->base.alpha >> 8;
> @@ -814,10 +814,10 @@ vlv_update_plane(struct intel_plane *plane,
> const struct drm_intel_sprite_colorkey *key = _state-
> >ckey;
> int crtc_x = plane_state->base.dst.x1;
> int crtc_y = plane_state->base.dst.y1;
> - uint32_t crtc_w = drm_rect_width(_state->base.dst);
> - uint32_t crtc_h = drm_rect_height(_state->base.dst);
> - uint32_t x = plane_state->color_plane[0].x;
> - uint32_t y = plane_state->color_plane[0].y;
> + u32 crtc_w = drm_rect_width(_state->base.dst);
> + u32 crtc_h = drm_rect_height(_state->base.dst);
> + u32 x = plane_state->color_plane[0].x;
> + u32 y = plane_state->color_plane[0].y;
> unsigned long irqflags;
>
> /* Sizes are 0 based */
> @@ -976,12 +976,12 @@ ivb_update_plane(struct intel_plane *plane,
> const struct drm_intel_sprite_colorkey *key = _state-
> >ckey;
> int crtc_x = plane_state->base.dst.x1;
> int crtc_y = plane_state->base.dst.y1;
> - uint32_t crtc_w = drm_rect_width(_state->base.dst);
> - uint32_t crtc_h = drm_rect_height(_state->base.dst);
> - uint32_t x = plane_state->color_plane[0].x;
> - uint32_t y = plane_state->color_plane[0].y;
> - uint32_t src_w = drm_rect_width(_state->base.src) >> 16;
> - uint32_t src_h = drm_rect_height(_state->base.src) >> 16;
> + u32 crtc_w = drm_rect_width(_state->base.dst);
> + u32 crtc_h = drm_rect_height(_state->base.dst);
> + u32 x = plane_state->color_plane[0].x;
> + u32 y = plane_state->color_plane[0].y;
> + u32 src_w = drm_rect_width(_state->base.src) >> 16;
> + u32 src_h = drm_rect_height(_state->base.src) >> 16;
> unsigned long irqflags;
>
> /* Sizes are 0 based */
> @@ -1152,12 +1152,12 @@ g4x_update_plane(struct intel_plane *plane,
> const struct drm_intel_sprite_colorkey *key = _state-
> >ckey;
> int crtc_x = plane_state->base.dst.x1;
> int crtc_y = plane_state->base.dst.y1;
> - uint32_t crtc_w = drm_rect_width(_state->base.dst);
> - uint32_t crtc_h = drm_rect_height(_state->base.dst);
> - uint32_t x = plane_state->color_plane[0].x;
> - uint32_t y = plane_state->color_plane[0].y;
> - uint32_t src_w = drm_rect_width(_state->base.src) >> 16;
> - uint32_t src_h = drm_rect_height(_state->base.src) >> 16;
> + u32 crtc_w = drm_rect_width(_state->base.dst);
> + u32 crtc_h = drm_rect_height(_state->base.dst);
> + u32 x = plane_state->color_plane[0].x;
> + u32 y = plane_state->color_plane[0].y;
> + u32 src_w = drm_rect_width(_state->base.src) >> 16;
> + u32 src_h = drm_rect_height(_state->base.src) >> 16;
> unsigned long irqflags;
>
> /* Sizes are 0 based */
> @@ -1706,7 +1706,7 @@ int intel_sprite_set_colorkey_ioctl(struct
> drm_device *dev, void *data,
> return ret;
> }
>
> -static const uint32_t g4x_plane_formats[] = {
> +static const u32 g4x_plane_formats[] = {
> DRM_FORMAT_XRGB,
>
Re: [Intel-gfx] [PATCH 09/17] drm/i915/dp: switch to kernel types
On Wed, 2019-01-16 at 11:15 +0200, Jani Nikula wrote:
> Mixed C99 and kernel types use is getting ugly. Prefer kernel types.
>
> sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g'
>
> Minor checkpatch/whitespace fixes sprinkled on top of the changed
> lines.
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_dp.c | 142 +---
> --
> drivers/gpu/drm/i915/intel_dp_link_training.c | 32 ++--
> 2 files changed, 87 insertions(+), 87 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> b/drivers/gpu/drm/i915/intel_dp.c
> index df4292bb1a4f..808ccdae15b8 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -429,7 +429,7 @@ static void intel_dp_set_common_rates(struct
> intel_dp *intel_dp)
> }
>
> static bool intel_dp_link_params_valid(struct intel_dp *intel_dp,
> int link_rate,
> -uint8_t lane_count)
> +u8 lane_count)
> {
> /*
>* FIXME: we need to synchronize the current link parameters
> with
> @@ -449,7 +449,7 @@ static bool intel_dp_link_params_valid(struct
> intel_dp *intel_dp, int link_rate,
>
> static bool intel_dp_can_link_train_fallback_for_edp(struct intel_dp
> *intel_dp,
>int link_rate,
> - uint8_t
> lane_count)
> + u8 lane_count)
> {
> const struct drm_display_mode *fixed_mode =
> intel_dp->attached_connector->panel.fixed_mode;
> @@ -464,7 +464,7 @@ static bool
> intel_dp_can_link_train_fallback_for_edp(struct intel_dp *intel_dp,
> }
>
> int intel_dp_get_link_train_fallback_values(struct intel_dp
> *intel_dp,
> - int link_rate, uint8_t
> lane_count)
> + int link_rate, u8
> lane_count)
> {
> int index;
>
> @@ -572,19 +572,19 @@ intel_dp_mode_valid(struct drm_connector
> *connector,
> return MODE_OK;
> }
>
> -uint32_t intel_dp_pack_aux(const uint8_t *src, int src_bytes)
> +u32 intel_dp_pack_aux(const u8 *src, int src_bytes)
> {
> - int i;
> - uint32_t v = 0;
> + int i;
> + u32 v = 0;
>
> if (src_bytes > 4)
> src_bytes = 4;
> for (i = 0; i < src_bytes; i++)
> - v |= ((uint32_t) src[i]) << ((3-i) * 8);
> + v |= ((u32)src[i]) << ((3 - i) * 8);
> return v;
> }
>
> -static void intel_dp_unpack_aux(uint32_t src, uint8_t *dst, int
> dst_bytes)
> +static void intel_dp_unpack_aux(u32 src, u8 *dst, int dst_bytes)
> {
> int i;
> if (dst_bytes > 4)
> @@ -643,7 +643,7 @@ vlv_power_sequencer_kick(struct intel_dp
> *intel_dp)
> bool pll_enabled, release_cl_override = false;
> enum dpio_phy phy = DPIO_PHY(pipe);
> enum dpio_channel ch = vlv_pipe_to_channel(pipe);
> - uint32_t DP;
> + u32 DP;
>
> if (WARN(I915_READ(intel_dp->output_reg) & DP_PORT_EN,
>"skipping pipe %c power sequencer kick due to port %c
> being active\n",
> @@ -1051,12 +1051,12 @@ intel_dp_check_edp(struct intel_dp *intel_dp)
> }
> }
>
> -static uint32_t
> +static u32
> intel_dp_aux_wait_done(struct intel_dp *intel_dp)
> {
> struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> i915_reg_t ch_ctl = intel_dp->aux_ch_ctl_reg(intel_dp);
> - uint32_t status;
> + u32 status;
> bool done;
>
> #define C (((status = I915_READ_NOTRACE(ch_ctl)) &
> DP_AUX_CH_CTL_SEND_BUSY) == 0)
> @@ -1069,7 +1069,7 @@ intel_dp_aux_wait_done(struct intel_dp
> *intel_dp)
> return status;
> }
>
> -static uint32_t g4x_get_aux_clock_divider(struct intel_dp *intel_dp,
> int index)
> +static u32 g4x_get_aux_clock_divider(struct intel_dp *intel_dp, int
> index)
> {
> struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
>
> @@ -1083,7 +1083,7 @@ static uint32_t
> g4x_get_aux_clock_divider(struct intel_dp *intel_dp, int index)
> return DIV_ROUND_CLOSEST(dev_priv->rawclk_freq, 2000);
> }
>
> -static uint32_t ilk_get_aux_clock_divider(struct intel_dp *intel_dp,
> int index)
> +static u32 ilk_get_aux_clock_divider(struct intel_dp *intel_dp, int
> index)
> {
> struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> @@ -1102,7 +1102,7 @@ static uint32_t
> ilk_get_aux_clock_divider(struct intel_dp *intel_dp, int index)
> return DIV_ROUND_CLOSEST(dev_priv->rawclk_freq, 2000);
> }
>
> -static uint32_t hsw_get_aux_clock_divider(struct intel_dp *intel_dp,
> int index)
> +static u32 hsw_get_aux_clock_divider(struct intel_dp *intel_dp, int
> index)
> {
> struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> @@
Re: [Intel-gfx] [PATCH 08/17] drm/i915/dpll_mgr: switch to kernel types
On Wed, 2019-01-16 at 11:15 +0200, Jani Nikula wrote:
> Mixed C99 and kernel types use is getting ugly. Prefer kernel types.
>
> sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g'
>
> Minor checkpatch/whitespace fixes sprinkled on top of the changed
> lines.
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_dpll_mgr.c | 145 +---
> --
> drivers/gpu/drm/i915/intel_dpll_mgr.h | 53 +-
> 2 files changed, 99 insertions(+), 99 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index 04870e960537..606f54dde086 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -346,7 +346,7 @@ static bool ibx_pch_dpll_get_hw_state(struct
> drm_i915_private *dev_priv,
> {
> const enum intel_dpll_id id = pll->info->id;
> intel_wakeref_t wakeref;
> - uint32_t val;
> + u32 val;
>
> wakeref = intel_display_power_get_if_enabled(dev_priv,
>POWER_DOMAIN_PLLS)
> ;
> @@ -490,7 +490,7 @@ static void hsw_ddi_wrpll_disable(struct
> drm_i915_private *dev_priv,
> struct intel_shared_dpll *pll)
> {
> const enum intel_dpll_id id = pll->info->id;
> - uint32_t val;
> + u32 val;
>
> val = I915_READ(WRPLL_CTL(id));
> I915_WRITE(WRPLL_CTL(id), val & ~WRPLL_PLL_ENABLE);
> @@ -500,7 +500,7 @@ static void hsw_ddi_wrpll_disable(struct
> drm_i915_private *dev_priv,
> static void hsw_ddi_spll_disable(struct drm_i915_private *dev_priv,
>struct intel_shared_dpll *pll)
> {
> - uint32_t val;
> + u32 val;
>
> val = I915_READ(SPLL_CTL);
> I915_WRITE(SPLL_CTL, val & ~SPLL_PLL_ENABLE);
> @@ -513,7 +513,7 @@ static bool hsw_ddi_wrpll_get_hw_state(struct
> drm_i915_private *dev_priv,
> {
> const enum intel_dpll_id id = pll->info->id;
> intel_wakeref_t wakeref;
> - uint32_t val;
> + u32 val;
>
> wakeref = intel_display_power_get_if_enabled(dev_priv,
>POWER_DOMAIN_PLLS)
> ;
> @@ -533,7 +533,7 @@ static bool hsw_ddi_spll_get_hw_state(struct
> drm_i915_private *dev_priv,
> struct intel_dpll_hw_state
> *hw_state)
> {
> intel_wakeref_t wakeref;
> - uint32_t val;
> + u32 val;
>
> wakeref = intel_display_power_get_if_enabled(dev_priv,
>POWER_DOMAIN_PLLS)
> ;
> @@ -639,11 +639,12 @@ static unsigned
> hsw_wrpll_get_budget_for_freq(int clock)
> return budget;
> }
>
> -static void hsw_wrpll_update_rnp(uint64_t freq2k, unsigned budget,
> - unsigned r2, unsigned n2, unsigned p,
> +static void hsw_wrpll_update_rnp(u64 freq2k, unsigned int budget,
> + unsigned int r2, unsigned int n2,
> + unsigned int p,
>struct hsw_wrpll_rnp *best)
> {
> - uint64_t a, b, c, d, diff, diff_best;
> + u64 a, b, c, d, diff, diff_best;
>
> /* No best (r,n,p) yet */
> if (best->p == 0) {
> @@ -702,7 +703,7 @@ static void
> hsw_ddi_calculate_wrpll(int clock /* in Hz */,
> unsigned *r2_out, unsigned *n2_out, unsigned
> *p_out)
> {
> - uint64_t freq2k;
> + u64 freq2k;
> unsigned p, n2, r2;
> struct hsw_wrpll_rnp best = { 0, 0, 0 };
> unsigned budget;
> @@ -768,7 +769,7 @@ static struct intel_shared_dpll
> *hsw_ddi_hdmi_get_dpll(int clock,
> struct
> intel_crtc_state *crtc_state)
> {
> struct intel_shared_dpll *pll;
> - uint32_t val;
> + u32 val;
> unsigned int p, n2, r2;
>
> hsw_ddi_calculate_wrpll(clock * 1000, , , );
> @@ -930,7 +931,7 @@ static void skl_ddi_pll_write_ctrl1(struct
> drm_i915_private *dev_priv,
> struct intel_shared_dpll *pll)
> {
> const enum intel_dpll_id id = pll->info->id;
> - uint32_t val;
> + u32 val;
>
> val = I915_READ(DPLL_CTRL1);
>
> @@ -995,7 +996,7 @@ static bool skl_ddi_pll_get_hw_state(struct
> drm_i915_private *dev_priv,
>struct intel_shared_dpll *pll,
>struct intel_dpll_hw_state
> *hw_state)
> {
> - uint32_t val;
> + u32 val;
> const struct skl_dpll_regs *regs = skl_dpll_regs;
> const enum intel_dpll_id id = pll->info->id;
> intel_wakeref_t wakeref;
> @@ -1035,7 +1036,7 @@ static bool skl_ddi_dpll0_get_hw_state(struct
> drm_i915_private *dev_priv,
> const struct skl_dpll_regs *regs = skl_dpll_regs;
> const enum intel_dpll_id id = pll->info->id;
> intel_wakeref_t wakeref;
> - uint32_t val;
> + u32 val;
> bool ret;
>
> wakeref
Re: [Intel-gfx] [PATCH 07/17] drm/i915/cdclk: switch to kernel types
On Wed, 2019-01-16 at 11:15 +0200, Jani Nikula wrote:
> Mixed C99 and kernel types use is getting ugly. Prefer kernel
> types.
>
> sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g'
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_cdclk.c | 40 +++-
> --
> 1 file changed, 20 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_cdclk.c
> b/drivers/gpu/drm/i915/intel_cdclk.c
> index 73cb7250118e..15ba950dee00 100644
> --- a/drivers/gpu/drm/i915/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> @@ -218,7 +218,7 @@ static unsigned int intel_hpll_vco(struct
> drm_i915_private *dev_priv)
> };
> const unsigned int *vco_table;
> unsigned int vco;
> - uint8_t tmp = 0;
> + u8 tmp = 0;
>
> /* FIXME other chipsets? */
> if (IS_GM45(dev_priv))
> @@ -249,13 +249,13 @@ static void g33_get_cdclk(struct
> drm_i915_private *dev_priv,
> struct intel_cdclk_state *cdclk_state)
> {
> struct pci_dev *pdev = dev_priv->drm.pdev;
> - static const uint8_t div_3200[] = { 12, 10, 8, 7, 5, 16 };
> - static const uint8_t div_4000[] = { 14, 12, 10, 8, 6, 20 };
> - static const uint8_t div_4800[] = { 20, 14, 12, 10, 8, 24 };
> - static const uint8_t div_5333[] = { 20, 16, 12, 12, 8, 28 };
> - const uint8_t *div_table;
> + static const u8 div_3200[] = { 12, 10, 8, 7, 5, 16 };
> + static const u8 div_4000[] = { 14, 12, 10, 8, 6, 20 };
> + static const u8 div_4800[] = { 20, 14, 12, 10, 8, 24 };
> + static const u8 div_5333[] = { 20, 16, 12, 12, 8, 28 };
> + const u8 *div_table;
> unsigned int cdclk_sel;
> - uint16_t tmp = 0;
> + u16 tmp = 0;
>
> cdclk_state->vco = intel_hpll_vco(dev_priv);
>
> @@ -330,12 +330,12 @@ static void i965gm_get_cdclk(struct
> drm_i915_private *dev_priv,
>struct intel_cdclk_state *cdclk_state)
> {
> struct pci_dev *pdev = dev_priv->drm.pdev;
> - static const uint8_t div_3200[] = { 16, 10, 8 };
> - static const uint8_t div_4000[] = { 20, 12, 10 };
> - static const uint8_t div_5333[] = { 24, 16, 14 };
> - const uint8_t *div_table;
> + static const u8 div_3200[] = { 16, 10, 8 };
> + static const u8 div_4000[] = { 20, 12, 10 };
> + static const u8 div_5333[] = { 24, 16, 14 };
> + const u8 *div_table;
> unsigned int cdclk_sel;
> - uint16_t tmp = 0;
> + u16 tmp = 0;
>
> cdclk_state->vco = intel_hpll_vco(dev_priv);
>
> @@ -375,7 +375,7 @@ static void gm45_get_cdclk(struct
> drm_i915_private *dev_priv,
> {
> struct pci_dev *pdev = dev_priv->drm.pdev;
> unsigned int cdclk_sel;
> - uint16_t tmp = 0;
> + u16 tmp = 0;
>
> cdclk_state->vco = intel_hpll_vco(dev_priv);
>
> @@ -403,8 +403,8 @@ static void gm45_get_cdclk(struct
> drm_i915_private *dev_priv,
> static void hsw_get_cdclk(struct drm_i915_private *dev_priv,
> struct intel_cdclk_state *cdclk_state)
> {
> - uint32_t lcpll = I915_READ(LCPLL_CTL);
> - uint32_t freq = lcpll & LCPLL_CLK_FREQ_MASK;
> + u32 lcpll = I915_READ(LCPLL_CTL);
> + u32 freq = lcpll & LCPLL_CLK_FREQ_MASK;
>
> if (lcpll & LCPLL_CD_SOURCE_FCLK)
> cdclk_state->cdclk = 80;
> @@ -672,8 +672,8 @@ static u8 bdw_calc_voltage_level(int cdclk)
> static void bdw_get_cdclk(struct drm_i915_private *dev_priv,
> struct intel_cdclk_state *cdclk_state)
> {
> - uint32_t lcpll = I915_READ(LCPLL_CTL);
> - uint32_t freq = lcpll & LCPLL_CLK_FREQ_MASK;
> + u32 lcpll = I915_READ(LCPLL_CTL);
> + u32 freq = lcpll & LCPLL_CLK_FREQ_MASK;
>
> if (lcpll & LCPLL_CD_SOURCE_FCLK)
> cdclk_state->cdclk = 80;
> @@ -700,7 +700,7 @@ static void bdw_set_cdclk(struct drm_i915_private
> *dev_priv,
> const struct intel_cdclk_state *cdclk_state)
> {
> int cdclk = cdclk_state->cdclk;
> - uint32_t val;
> + u32 val;
> int ret;
>
> if (WARN((I915_READ(LCPLL_CTL) &
> @@ -1083,7 +1083,7 @@ static void skl_set_cdclk(struct
> drm_i915_private *dev_priv,
>
> static void skl_sanitize_cdclk(struct drm_i915_private *dev_priv)
> {
> - uint32_t cdctl, expected;
> + u32 cdctl, expected;
>
> /*
>* check if the pre-os initialized the display
> @@ -2690,7 +2690,7 @@ static int vlv_hrawclk(struct drm_i915_private
> *dev_priv)
>
> static int g4x_hrawclk(struct drm_i915_private *dev_priv)
> {
> - uint32_t clkcfg;
> + u32 clkcfg;
>
> /* hrawclock is 1/4 the FSB frequency */
> clkcfg = I915_READ(CLKCFG);
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/17] drm/i915/irq: switch to kernel types
On Wed, 2019-01-16 at 11:15 +0200, Jani Nikula wrote:
> Mixed C99 and kernel types use is getting ugly. Prefer kernel
> types.
>
> sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g'
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_irq.c | 82 ---
> --
> 1 file changed, 41 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c
> b/drivers/gpu/drm/i915/i915_irq.c
> index 94187e68d39a..29bbafb5b040 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -223,10 +223,10 @@ static void gen9_guc_irq_handler(struct
> drm_i915_private *dev_priv, u32 pm_iir);
> /* For display hotplug interrupt */
> static inline void
> i915_hotplug_interrupt_update_locked(struct drm_i915_private
> *dev_priv,
> - uint32_t mask,
> - uint32_t bits)
> + u32 mask,
> + u32 bits)
> {
> - uint32_t val;
> + u32 val;
>
> lockdep_assert_held(_priv->irq_lock);
> WARN_ON(bits & ~mask);
> @@ -250,8 +250,8 @@ i915_hotplug_interrupt_update_locked(struct
> drm_i915_private *dev_priv,
> * version is also available.
> */
> void i915_hotplug_interrupt_update(struct drm_i915_private
> *dev_priv,
> -uint32_t mask,
> -uint32_t bits)
> +u32 mask,
> +u32 bits)
> {
> spin_lock_irq(_priv->irq_lock);
> i915_hotplug_interrupt_update_locked(dev_priv, mask, bits);
> @@ -300,10 +300,10 @@ static bool gen11_reset_one_iir(struct
> drm_i915_private * const i915,
> * @enabled_irq_mask: mask of interrupt bits to enable
> */
> void ilk_update_display_irq(struct drm_i915_private *dev_priv,
> - uint32_t interrupt_mask,
> - uint32_t enabled_irq_mask)
> + u32 interrupt_mask,
> + u32 enabled_irq_mask)
> {
> - uint32_t new_val;
> + u32 new_val;
>
> lockdep_assert_held(_priv->irq_lock);
>
> @@ -330,8 +330,8 @@ void ilk_update_display_irq(struct
> drm_i915_private *dev_priv,
> * @enabled_irq_mask: mask of interrupt bits to enable
> */
> static void ilk_update_gt_irq(struct drm_i915_private *dev_priv,
> - uint32_t interrupt_mask,
> - uint32_t enabled_irq_mask)
> + u32 interrupt_mask,
> + u32 enabled_irq_mask)
> {
> lockdep_assert_held(_priv->irq_lock);
>
> @@ -345,13 +345,13 @@ static void ilk_update_gt_irq(struct
> drm_i915_private *dev_priv,
> I915_WRITE(GTIMR, dev_priv->gt_irq_mask);
> }
>
> -void gen5_enable_gt_irq(struct drm_i915_private *dev_priv, uint32_t
> mask)
> +void gen5_enable_gt_irq(struct drm_i915_private *dev_priv, u32 mask)
> {
> ilk_update_gt_irq(dev_priv, mask, mask);
> POSTING_READ_FW(GTIMR);
> }
>
> -void gen5_disable_gt_irq(struct drm_i915_private *dev_priv, uint32_t
> mask)
> +void gen5_disable_gt_irq(struct drm_i915_private *dev_priv, u32
> mask)
> {
> ilk_update_gt_irq(dev_priv, mask, 0);
> }
> @@ -390,10 +390,10 @@ static i915_reg_t gen6_pm_ier(struct
> drm_i915_private *dev_priv)
> * @enabled_irq_mask: mask of interrupt bits to enable
> */
> static void snb_update_pm_irq(struct drm_i915_private *dev_priv,
> - uint32_t interrupt_mask,
> - uint32_t enabled_irq_mask)
> + u32 interrupt_mask,
> + u32 enabled_irq_mask)
> {
> - uint32_t new_val;
> + u32 new_val;
>
> WARN_ON(enabled_irq_mask & ~interrupt_mask);
>
> @@ -577,11 +577,11 @@ void gen9_disable_guc_interrupts(struct
> drm_i915_private *dev_priv)
> * @enabled_irq_mask: mask of interrupt bits to enable
> */
> static void bdw_update_port_irq(struct drm_i915_private *dev_priv,
> - uint32_t interrupt_mask,
> - uint32_t enabled_irq_mask)
> + u32 interrupt_mask,
> + u32 enabled_irq_mask)
> {
> - uint32_t new_val;
> - uint32_t old_val;
> + u32 new_val;
> + u32 old_val;
>
> lockdep_assert_held(_priv->irq_lock);
>
> @@ -611,10 +611,10 @@ static void bdw_update_port_irq(struct
> drm_i915_private *dev_priv,
> */
> void bdw_update_pipe_irq(struct drm_i915_private *dev_priv,
>enum pipe pipe,
> - uint32_t interrupt_mask,
> - uint32_t enabled_irq_mask)
> + u32 interrupt_mask,
> + u32 enabled_irq_mask)
> {
> - uint32_t new_val;
> + u32 new_val;
>
> lockdep_assert_held(_priv->irq_lock);
>
> @@ -641,10 +641,10 @@
Re: [Intel-gfx] [PATCH 05/17] drm/i915/debugfs: switch to kernel types
On Wed, 2019-01-16 at 11:15 +0200, Jani Nikula wrote:
> Mixed C99 and kernel types use is getting ugly. Prefer kernel
> types.
>
> sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g'
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 22 +++---
> 1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 8d738e6ca7b5..fc78e45778b5 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2249,7 +2249,7 @@ static void i915_guc_client_info(struct
> seq_file *m,
> {
> struct intel_engine_cs *engine;
> enum intel_engine_id id;
> - uint64_t tot = 0;
> + u64 tot = 0;
>
> seq_printf(m, "\tPriority %d, GuC stage index: %u, PD offset
> 0x%x\n",
> client->priority, client->stage_id, client-
> >proc_desc_offset);
> @@ -3637,7 +3637,7 @@ static int
> i915_displayport_test_type_show(struct seq_file *m, void *data)
> }
> DEFINE_SHOW_ATTRIBUTE(i915_displayport_test_type);
>
> -static void wm_latency_show(struct seq_file *m, const uint16_t
> wm[8])
> +static void wm_latency_show(struct seq_file *m, const u16 wm[8])
> {
> struct drm_i915_private *dev_priv = m->private;
> struct drm_device *dev = _priv->drm;
> @@ -3680,7 +3680,7 @@ static void wm_latency_show(struct seq_file *m,
> const uint16_t wm[8])
> static int pri_wm_latency_show(struct seq_file *m, void *data)
> {
> struct drm_i915_private *dev_priv = m->private;
> - const uint16_t *latencies;
> + const u16 *latencies;
>
> if (INTEL_GEN(dev_priv) >= 9)
> latencies = dev_priv->wm.skl_latency;
> @@ -3695,7 +3695,7 @@ static int pri_wm_latency_show(struct seq_file
> *m, void *data)
> static int spr_wm_latency_show(struct seq_file *m, void *data)
> {
> struct drm_i915_private *dev_priv = m->private;
> - const uint16_t *latencies;
> + const u16 *latencies;
>
> if (INTEL_GEN(dev_priv) >= 9)
> latencies = dev_priv->wm.skl_latency;
> @@ -3710,7 +3710,7 @@ static int spr_wm_latency_show(struct seq_file
> *m, void *data)
> static int cur_wm_latency_show(struct seq_file *m, void *data)
> {
> struct drm_i915_private *dev_priv = m->private;
> - const uint16_t *latencies;
> + const u16 *latencies;
>
> if (INTEL_GEN(dev_priv) >= 9)
> latencies = dev_priv->wm.skl_latency;
> @@ -3753,12 +3753,12 @@ static int cur_wm_latency_open(struct inode
> *inode, struct file *file)
> }
>
> static ssize_t wm_latency_write(struct file *file, const char __user
> *ubuf,
> - size_t len, loff_t *offp, uint16_t
> wm[8])
> + size_t len, loff_t *offp, u16 wm[8])
> {
> struct seq_file *m = file->private_data;
> struct drm_i915_private *dev_priv = m->private;
> struct drm_device *dev = _priv->drm;
> - uint16_t new[8] = { 0 };
> + u16 new[8] = { 0 };
> int num_levels;
> int level;
> int ret;
> @@ -3803,7 +3803,7 @@ static ssize_t pri_wm_latency_write(struct file
> *file, const char __user *ubuf,
> {
> struct seq_file *m = file->private_data;
> struct drm_i915_private *dev_priv = m->private;
> - uint16_t *latencies;
> + u16 *latencies;
>
> if (INTEL_GEN(dev_priv) >= 9)
> latencies = dev_priv->wm.skl_latency;
> @@ -3818,7 +3818,7 @@ static ssize_t spr_wm_latency_write(struct file
> *file, const char __user *ubuf,
> {
> struct seq_file *m = file->private_data;
> struct drm_i915_private *dev_priv = m->private;
> - uint16_t *latencies;
> + u16 *latencies;
>
> if (INTEL_GEN(dev_priv) >= 9)
> latencies = dev_priv->wm.skl_latency;
> @@ -3833,7 +3833,7 @@ static ssize_t cur_wm_latency_write(struct file
> *file, const char __user *ubuf,
> {
> struct seq_file *m = file->private_data;
> struct drm_i915_private *dev_priv = m->private;
> - uint16_t *latencies;
> + u16 *latencies;
>
> if (INTEL_GEN(dev_priv) >= 9)
> latencies = dev_priv->wm.skl_latency;
> @@ -4851,7 +4851,7 @@ static int i915_dpcd_show(struct seq_file *m,
> void *data)
> struct drm_connector *connector = m->private;
> struct intel_dp *intel_dp =
> enc_to_intel_dp(_attached_encoder(connector)-
> >base);
> - uint8_t buf[16];
> + u8 buf[16];
> ssize_t err;
> int i;
>
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/17] drm/i915/lspcon: switch to kernel types
On Wed, 2019-01-16 at 11:15 +0200, Jani Nikula wrote:
> Mixed C99 and kernel types use is getting ugly. Prefer kernel
> types.
>
> sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g'
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_lspcon.c | 20 ++--
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_lspcon.c
> b/drivers/gpu/drm/i915/intel_lspcon.c
> index 7d15be5932e0..322ba164 100644
> --- a/drivers/gpu/drm/i915/intel_lspcon.c
> +++ b/drivers/gpu/drm/i915/intel_lspcon.c
> @@ -288,12 +288,12 @@ static bool lspcon_parade_fw_ready(struct
> drm_dp_aux *aux)
> }
>
> static bool _lspcon_parade_write_infoframe_blocks(struct drm_dp_aux
> *aux,
> - uint8_t *avi_buf)
> + u8 *avi_buf)
> {
> u8 avi_if_ctrl;
> u8 block_count = 0;
> u8 *data;
> - uint16_t reg;
> + u16 reg;
> ssize_t ret;
>
> while (block_count < 4) {
> @@ -335,10 +335,10 @@ static bool
> _lspcon_parade_write_infoframe_blocks(struct drm_dp_aux *aux,
> }
>
> static bool _lspcon_write_avi_infoframe_parade(struct drm_dp_aux
> *aux,
> -const uint8_t *frame,
> +const u8 *frame,
> ssize_t len)
> {
> - uint8_t avi_if[LSPCON_PARADE_AVI_IF_DATA_SIZE] = {1, };
> + u8 avi_if[LSPCON_PARADE_AVI_IF_DATA_SIZE] = {1, };
>
> /*
>* Parade's frames contains 32 bytes of data, divided
> @@ -367,13 +367,13 @@ static bool
> _lspcon_write_avi_infoframe_parade(struct drm_dp_aux *aux,
> }
>
> static bool _lspcon_write_avi_infoframe_mca(struct drm_dp_aux *aux,
> - const uint8_t *buffer,
> ssize_t len)
> + const u8 *buffer, ssize_t
> len)
> {
> int ret;
> - uint32_t val = 0;
> - uint32_t retry;
> - uint16_t reg;
> - const uint8_t *data = buffer;
> + u32 val = 0;
> + u32 retry;
> + u16 reg;
> + const u8 *data = buffer;
>
> reg = LSPCON_MCA_AVI_IF_WRITE_OFFSET;
> while (val < len) {
> @@ -459,7 +459,7 @@ void lspcon_set_infoframes(struct intel_encoder
> *encoder,
> {
> ssize_t ret;
> union hdmi_infoframe frame;
> - uint8_t buf[VIDEO_DIP_DATA_SIZE];
> + u8 buf[VIDEO_DIP_DATA_SIZE];
> struct intel_digital_port *dig_port = enc_to_dig_port(
> >base);
> struct intel_lspcon *lspcon = _port->lspcon;
> const struct drm_display_mode *adjusted_mode =
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/17] drm/i915: small isolated c99 types to kernel types switch
On Wed, 2019-01-16 at 11:15 +0200, Jani Nikula wrote:
> Mixed C99 and kernel types use is getting ugly. Prefer kernel types.
>
> sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g'
>
> Minor checkpatch fixes sprinkled on top of the changed lines.
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_gem.c| 14 +++---
> drivers/gpu/drm/i915/i915_gem_fence_reg.c | 8
> drivers/gpu/drm/i915/i915_gpu_error.c | 10 +-
> drivers/gpu/drm/i915/i915_perf.c | 2 +-
> drivers/gpu/drm/i915/i915_reg.h| 4 ++--
> drivers/gpu/drm/i915/intel_atomic.c| 4 ++--
> drivers/gpu/drm/i915/intel_atomic_plane.c | 4 ++--
> drivers/gpu/drm/i915/intel_dp_mst.c| 2 +-
> drivers/gpu/drm/i915/intel_dpio_phy.c | 18 +-
> drivers/gpu/drm/i915/intel_engine_cs.c | 12 ++--
> drivers/gpu/drm/i915/intel_fbc.c | 2 +-
> drivers/gpu/drm/i915/intel_fifo_underrun.c | 12 ++--
> drivers/gpu/drm/i915/intel_hdcp.c | 4 ++--
> drivers/gpu/drm/i915/intel_lrc.c | 2 +-
> drivers/gpu/drm/i915/intel_pipe_crc.c | 18 +-
> drivers/gpu/drm/i915/intel_psr.c | 6 +++---
> drivers/gpu/drm/i915/intel_ringbuffer.h| 2 +-
> drivers/gpu/drm/i915/intel_runtime_pm.c| 20 ++--
> 18 files changed, 72 insertions(+), 72 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c
> b/drivers/gpu/drm/i915/i915_gem.c
> index 80264cb9ca7f..d15f7200c0e7 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -710,8 +710,8 @@ void i915_gem_object_free(struct
> drm_i915_gem_object *obj)
> static int
> i915_gem_create(struct drm_file *file,
> struct drm_i915_private *dev_priv,
> - uint64_t size,
> - uint32_t *handle_p)
> + u64 size,
> + u32 *handle_p)
> {
> struct drm_i915_gem_object *obj;
> int ret;
> @@ -1570,8 +1570,8 @@ i915_gem_set_domain_ioctl(struct drm_device
> *dev, void *data,
> {
> struct drm_i915_gem_set_domain *args = data;
> struct drm_i915_gem_object *obj;
> - uint32_t read_domains = args->read_domains;
> - uint32_t write_domain = args->write_domain;
> + u32 read_domains = args->read_domains;
> + u32 write_domain = args->write_domain;
> int err;
>
> /* Only handle setting domains to types used by the CPU. */
> @@ -1753,7 +1753,7 @@ i915_gem_mmap_ioctl(struct drm_device *dev,
> void *data,
> if (IS_ERR((void *)addr))
> return addr;
>
> - args->addr_ptr = (uint64_t) addr;
> + args->addr_ptr = (u64)addr;
>
> return 0;
> }
> @@ -2155,8 +2155,8 @@ static void
> i915_gem_object_free_mmap_offset(struct drm_i915_gem_object *obj)
> int
> i915_gem_mmap_gtt(struct drm_file *file,
> struct drm_device *dev,
> - uint32_t handle,
> - uint64_t *offset)
> + u32 handle,
> + u64 *offset)
> {
> struct drm_i915_gem_object *obj;
> int ret;
> diff --git a/drivers/gpu/drm/i915/i915_gem_fence_reg.c
> b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
> index f7947d89cf45..46e259661294 100644
> --- a/drivers/gpu/drm/i915/i915_gem_fence_reg.c
> +++ b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
> @@ -555,8 +555,8 @@ void i915_gem_restore_fences(struct
> drm_i915_private *dev_priv)
> void
> i915_gem_detect_bit_6_swizzle(struct drm_i915_private *dev_priv)
> {
> - uint32_t swizzle_x = I915_BIT_6_SWIZZLE_UNKNOWN;
> - uint32_t swizzle_y = I915_BIT_6_SWIZZLE_UNKNOWN;
> + u32 swizzle_x = I915_BIT_6_SWIZZLE_UNKNOWN;
> + u32 swizzle_y = I915_BIT_6_SWIZZLE_UNKNOWN;
>
> if (INTEL_GEN(dev_priv) >= 8 || IS_VALLEYVIEW(dev_priv)) {
> /*
> @@ -579,7 +579,7 @@ i915_gem_detect_bit_6_swizzle(struct
> drm_i915_private *dev_priv)
> swizzle_y = I915_BIT_6_SWIZZLE_NONE;
> }
> } else {
> - uint32_t dimm_c0, dimm_c1;
> + u32 dimm_c0, dimm_c1;
> dimm_c0 = I915_READ(MAD_DIMM_C0);
> dimm_c1 = I915_READ(MAD_DIMM_C1);
> dimm_c0 &= MAD_DIMM_A_SIZE_MASK |
> MAD_DIMM_B_SIZE_MASK;
> @@ -611,7 +611,7 @@ i915_gem_detect_bit_6_swizzle(struct
> drm_i915_private *dev_priv)
> swizzle_y = I915_BIT_6_SWIZZLE_NONE;
> } else if (IS_MOBILE(dev_priv) ||
> IS_I915G(dev_priv) || IS_I945G(dev_priv)) {
> - uint32_t dcc;
> + u32 dcc;
>
> /* On 9xx chipsets, channel interleave by the CPU is
>* determined by DCC. For single-channel, neither the
> CPU
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
> b/drivers/gpu/drm/i915/i915_gpu_error.c
> index 5eaf586c4d48..1f8e80e31b49 100644
> ---
Re: [Intel-gfx] [PATCH 03/17] drm/i915/sdvo: switch to kernel types
On Wed, 2019-01-16 at 11:15 +0200, Jani Nikula wrote:
> Mixed C99 and kernel types use is getting ugly. Prefer kernel
> types.
>
> sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g'
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_sdvo.c | 78 +++
>
> 1 file changed, 39 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
> b/drivers/gpu/drm/i915/intel_sdvo.c
> index df2d830a7405..e7b0884ba5a5 100644
> --- a/drivers/gpu/drm/i915/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> @@ -76,7 +76,7 @@ struct intel_sdvo {
> i915_reg_t sdvo_reg;
>
> /* Active outputs controlled by this SDVO output */
> - uint16_t controlled_output;
> + u16 controlled_output;
>
> /*
>* Capabilities of the SDVO device returned by
> @@ -91,12 +91,12 @@ struct intel_sdvo {
> * For multiple function SDVO device,
> * this is for current attached outputs.
> */
> - uint16_t attached_output;
> + u16 attached_output;
>
> /*
>* Hotplug activation bits for this device
>*/
> - uint16_t hotplug_active;
> + u16 hotplug_active;
>
> enum port port;
>
> @@ -104,19 +104,19 @@ struct intel_sdvo {
> bool has_hdmi_audio;
>
> /* DDC bus used by this SDVO encoder */
> - uint8_t ddc_bus;
> + u8 ddc_bus;
>
> /*
>* the sdvo flag gets lost in round trip: dtd->adjusted_mode-
> >dtd
>*/
> - uint8_t dtd_sdvo_flags;
> + u8 dtd_sdvo_flags;
> };
>
> struct intel_sdvo_connector {
> struct intel_connector base;
>
> /* Mark the type of connector */
> - uint16_t output_flag;
> + u16 output_flag;
>
> /* This contains all current supported TV format */
> u8 tv_format_supported[TV_FORMAT_NUM];
> @@ -184,7 +184,7 @@ to_intel_sdvo_connector(struct drm_connector
> *connector)
> container_of((conn_state), struct intel_sdvo_connector_state,
> base.base)
>
> static bool
> -intel_sdvo_output_setup(struct intel_sdvo *intel_sdvo, uint16_t
> flags);
> +intel_sdvo_output_setup(struct intel_sdvo *intel_sdvo, u16 flags);
> static bool
> intel_sdvo_tv_create_property(struct intel_sdvo *intel_sdvo,
> struct intel_sdvo_connector
> *intel_sdvo_connector,
> @@ -746,9 +746,9 @@ static bool intel_sdvo_get_input_timing(struct
> intel_sdvo *intel_sdvo,
> static bool
> intel_sdvo_create_preferred_input_timing(struct intel_sdvo
> *intel_sdvo,
>struct intel_sdvo_connector
> *intel_sdvo_connector,
> - uint16_t clock,
> - uint16_t width,
> - uint16_t height)
> + u16 clock,
> + u16 width,
> + u16 height)
> {
> struct intel_sdvo_preferred_input_timing_args args;
>
> @@ -791,9 +791,9 @@ static bool intel_sdvo_set_clock_rate_mult(struct
> intel_sdvo *intel_sdvo, u8 val
> static void intel_sdvo_get_dtd_from_mode(struct intel_sdvo_dtd *dtd,
>const struct drm_display_mode
> *mode)
> {
> - uint16_t width, height;
> - uint16_t h_blank_len, h_sync_len, v_blank_len, v_sync_len;
> - uint16_t h_sync_offset, v_sync_offset;
> + u16 width, height;
> + u16 h_blank_len, h_sync_len, v_blank_len, v_sync_len;
> + u16 h_sync_offset, v_sync_offset;
> int mode_clock;
>
> memset(dtd, 0, sizeof(*dtd));
> @@ -898,13 +898,13 @@ static bool intel_sdvo_check_supp_encode(struct
> intel_sdvo *intel_sdvo)
> }
>
> static bool intel_sdvo_set_encode(struct intel_sdvo *intel_sdvo,
> - uint8_t mode)
> + u8 mode)
> {
> return intel_sdvo_set_value(intel_sdvo, SDVO_CMD_SET_ENCODE,
> , 1);
> }
>
> static bool intel_sdvo_set_colorimetry(struct intel_sdvo
> *intel_sdvo,
> -uint8_t mode)
> +u8 mode)
> {
> return intel_sdvo_set_value(intel_sdvo,
> SDVO_CMD_SET_COLORIMETRY, , 1);
> }
> @@ -913,11 +913,11 @@ static bool intel_sdvo_set_colorimetry(struct
> intel_sdvo *intel_sdvo,
> static void intel_sdvo_dump_hdmi_buf(struct intel_sdvo *intel_sdvo)
> {
> int i, j;
> - uint8_t set_buf_index[2];
> - uint8_t av_split;
> - uint8_t buf_size;
> - uint8_t buf[48];
> - uint8_t *pos;
> + u8 set_buf_index[2];
> + u8 av_split;
> + u8 buf_size;
> + u8 buf[48];
> + u8 *pos;
>
> intel_sdvo_get_value(encoder, SDVO_CMD_GET_HBUF_AV_SPLIT,
> _split, 1);
>
> @@ -940,11 +940,11 @@ static void intel_sdvo_dump_hdmi_buf(struct
> intel_sdvo *intel_sdvo)
> #endif
>
> static bool intel_sdvo_write_infoframe(struct intel_sdvo
> *intel_sdvo,
> -
Re: [Intel-gfx] [PATCH 02/17] drm/i915/crt: switch to kernel types
On Wed, 2019-01-16 at 11:15 +0200, Jani Nikula wrote:
> Mixed C99 and kernel types use is getting ugly. Prefer kernel
> types.
>
> sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g'
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_crt.c | 22 +++---
> 1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_crt.c
> b/drivers/gpu/drm/i915/intel_crt.c
> index 081c333f30d2..c2e799a5e63e 100644
> --- a/drivers/gpu/drm/i915/intel_crt.c
> +++ b/drivers/gpu/drm/i915/intel_crt.c
> @@ -631,19 +631,19 @@ static bool intel_crt_detect_ddc(struct
> drm_connector *connector)
> }
>
> static enum drm_connector_status
> -intel_crt_load_detect(struct intel_crt *crt, uint32_t pipe)
> +intel_crt_load_detect(struct intel_crt *crt, u32 pipe)
> {
> struct drm_device *dev = crt->base.base.dev;
> struct drm_i915_private *dev_priv = to_i915(dev);
> - uint32_t save_bclrpat;
> - uint32_t save_vtotal;
> - uint32_t vtotal, vactive;
> - uint32_t vsample;
> - uint32_t vblank, vblank_start, vblank_end;
> - uint32_t dsl;
> + u32 save_bclrpat;
> + u32 save_vtotal;
> + u32 vtotal, vactive;
> + u32 vsample;
> + u32 vblank, vblank_start, vblank_end;
> + u32 dsl;
> i915_reg_t bclrpat_reg, vtotal_reg,
> vblank_reg, vsync_reg, pipeconf_reg, pipe_dsl_reg;
> - uint8_t st00;
> + u8 st00;
> enum drm_connector_status status;
>
> DRM_DEBUG_KMS("starting load-detect on CRT\n");
> @@ -669,7 +669,7 @@ intel_crt_load_detect(struct intel_crt *crt,
> uint32_t pipe)
> I915_WRITE(bclrpat_reg, 0x500050);
>
> if (!IS_GEN(dev_priv, 2)) {
> - uint32_t pipeconf = I915_READ(pipeconf_reg);
> + u32 pipeconf = I915_READ(pipeconf_reg);
> I915_WRITE(pipeconf_reg, pipeconf |
> PIPECONF_FORCE_BORDER);
> POSTING_READ(pipeconf_reg);
> /* Wait for next Vblank to substitue
> @@ -690,8 +690,8 @@ intel_crt_load_detect(struct intel_crt *crt,
> uint32_t pipe)
> * Yes, this will flicker
> */
> if (vblank_start <= vactive && vblank_end >= vtotal) {
> - uint32_t vsync = I915_READ(vsync_reg);
> - uint32_t vsync_start = (vsync & 0x) + 1;
> + u32 vsync = I915_READ(vsync_reg);
> + u32 vsync_start = (vsync & 0x) + 1;
>
> vblank_start = vsync_start;
> I915_WRITE(vblank_reg,
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [alsa-devel] Timing issues between ALSA and i915 drivers
a) compiling both SOUND and DRM as built-ins (y instead of m) b) moving the calls snd_hdac_i915_init() to the probe function instead of the worker queue (code at https://github.com/plbossart/sound/commits/fix/skl-hdmi) I added DRM+audio dmesg logs at the following link for reference: https://github.com/thesofproject/linux/issues/549 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915/psr: Store VBT TP wakeup times into a enum
Newer VBTs and the PSR registers uses a enum to set the TPs wakeup
time, so lets use this format to store wakeup times and avoid
conversions every time that PSR is activated.
Cc: Dhinakaran Pandiyan
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_drv.h | 12 +-
drivers/gpu/drm/i915/i915_reg.h | 16 ++--
drivers/gpu/drm/i915/intel_bios.c | 65 +++
drivers/gpu/drm/i915/intel_psr.c | 29 ++
4 files changed, 47 insertions(+), 75 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e717c3132692..d9893d35f0e2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -959,6 +959,14 @@ enum psr_lines_to_wait {
PSR_8_LINES_TO_WAIT
};
+enum psr_tp_wakeup_time {
+ PSR_TP_WAKEUP_TIME_500USEC = 0,
+ PSR_TP_WAKEUP_TIME_100USEC,
+ PSR_TP_WAKEUP_TIME_2500USEC,
+ PSR_TP_WAKEUP_TIME_NONE,
+ PSR_TP_WAKEUP_TIME_LAST
+};
+
struct intel_vbt_data {
struct drm_display_mode *lfp_lvds_vbt_mode; /* if any */
struct drm_display_mode *sdvo_lvds_vbt_mode; /* if any */
@@ -995,8 +1003,8 @@ struct intel_vbt_data {
bool require_aux_wakeup;
int idle_frames;
enum psr_lines_to_wait lines_to_wait;
- int tp1_wakeup_time_us;
- int tp2_tp3_tp4_wakeup_time_us;
+ enum psr_tp_wakeup_time tp1_wakeup_time;
+ enum psr_tp_wakeup_time tp2_tp3_tp4_wakeup_time;
} psr;
struct {
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index fad5a9e8b44d..5faca634ee70 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4161,14 +4161,8 @@ enum {
#define EDP_PSR_TP1_TP2_SEL (0 << 11)
#define EDP_PSR_TP1_TP3_SEL (1 << 11)
#define EDP_PSR_CRC_ENABLE (1 << 10) /* BDW+ */
-#define EDP_PSR_TP2_TP3_TIME_500us (0 << 8)
-#define EDP_PSR_TP2_TP3_TIME_100us (1 << 8)
-#define EDP_PSR_TP2_TP3_TIME_2500us (2 << 8)
-#define EDP_PSR_TP2_TP3_TIME_0us (3 << 8)
-#define EDP_PSR_TP1_TIME_500us (0 << 4)
-#define EDP_PSR_TP1_TIME_100us (1 << 4)
-#define EDP_PSR_TP1_TIME_2500us (2 << 4)
-#define EDP_PSR_TP1_TIME_0us (3 << 4)
+#define EDP_PSR_TP2_TP3_TIME_SHIFT (8)
+#define EDP_PSR_TP1_TIME_SHIFT (4)
#define EDP_PSR_IDLE_FRAME_SHIFT 0
/* Bspec claims those aren't shifted but stay at 0x64800 */
@@ -4234,11 +4228,7 @@ enum {
#define EDP_Y_COORDINATE_ENABLE (1 << 25) /* GLK and CNL+ */
#define EDP_MAX_SU_DISABLE_TIME(t) ((t) << 20)
#define EDP_MAX_SU_DISABLE_TIME_MASK (0x1f << 20)
-#define EDP_PSR2_TP2_TIME_500us (0 << 8)
-#define EDP_PSR2_TP2_TIME_100us (1 << 8)
-#define EDP_PSR2_TP2_TIME_2500us (2 << 8)
-#define EDP_PSR2_TP2_TIME_50us (3 << 8)
-#define EDP_PSR2_TP2_TIME_MASK (3 << 8)
+#define EDP_PSR2_TP2_TP3_TIME_SHIFT (8)
#define EDP_PSR2_FRAME_BEFORE_SU_SHIFT 4
#define EDP_PSR2_FRAME_BEFORE_SU_MASK(0xf << 4)
#define EDP_PSR2_FRAME_BEFORE_SU(a) ((a) << 4)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index cd99bf88bf6c..6de6f6f1deec 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -719,46 +719,43 @@ parse_psr(struct drm_i915_private *dev_priv, const struct
bdb_header *bdb)
if (bdb->version >= 205 &&
(IS_GEN9_BC(dev_priv) || IS_GEMINILAKE(dev_priv) ||
INTEL_GEN(dev_priv) >= 10)) {
- switch (psr_table->tp1_wakeup_time) {
- case 0:
- dev_priv->vbt.psr.tp1_wakeup_time_us = 500;
- break;
- case 1:
- dev_priv->vbt.psr.tp1_wakeup_time_us = 100;
- break;
- case 3:
- dev_priv->vbt.psr.tp1_wakeup_time_us = 0;
- break;
- default:
+ dev_priv->vbt.psr.tp1_wakeup_time = psr_table->tp1_wakeup_time;
+ if (dev_priv->vbt.psr.tp1_wakeup_time >=
PSR_TP_WAKEUP_TIME_LAST) {
DRM_DEBUG_KMS("VBT tp1 wakeup time value %d is outside
range[0-3], defaulting to max value 2500us\n",
- psr_table->tp1_wakeup_time);
- /* fallthrough */
- case 2:
- dev_priv->vbt.psr.tp1_wakeup_time_us = 2500;
- break;
+ dev_priv->vbt.psr.tp1_wakeup_time);
+ dev_priv->vbt.psr.tp1_wakeup_time =
PSR_TP_WAKEUP_TIME_2500USEC;
}
- switch (psr_table->tp2_tp3_tp4_wakeup_time) {
- case 0:
-
[Intel-gfx] [PATCH 3/4] drm/i915/vbt: Parse and use the new field with PSR2 TP2/3/4 wakeup time
A new field with the training pattern(TP) wakeup time for PSR2 was
added to VBT, so lets use it when available otherwise it will
fallback to PSR1 wakeup time.
BSpec: 20131
Cc: Dhinakaran Pandiyan
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_drv.h | 8
drivers/gpu/drm/i915/intel_bios.c | 10 ++
drivers/gpu/drm/i915/intel_psr.c | 2 +-
drivers/gpu/drm/i915/intel_vbt_defs.h | 3 +++
4 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d9893d35f0e2..e739ed9ce60c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -967,6 +967,13 @@ enum psr_tp_wakeup_time {
PSR_TP_WAKEUP_TIME_LAST
};
+enum psr2_tp_wakeup_time {
+ PSR2_TP_WAKEUP_TIME_500USEC = 0,
+ PSR2_TP_WAKEUP_TIME_100USEC,
+ PSR2_TP_WAKEUP_TIME_2500USEC,
+ PSR2_TP_WAKEUP_TIME_50USEC
+};
+
struct intel_vbt_data {
struct drm_display_mode *lfp_lvds_vbt_mode; /* if any */
struct drm_display_mode *sdvo_lvds_vbt_mode; /* if any */
@@ -1005,6 +1012,7 @@ struct intel_vbt_data {
enum psr_lines_to_wait lines_to_wait;
enum psr_tp_wakeup_time tp1_wakeup_time;
enum psr_tp_wakeup_time tp2_tp3_tp4_wakeup_time;
+ enum psr2_tp_wakeup_time psr2_tp2_tp3_tp4_wakeup_time;
} psr;
struct {
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 6de6f6f1deec..23130e0d5e6c 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -757,6 +757,16 @@ parse_psr(struct drm_i915_private *dev_priv, const struct
bdb_header *bdb)
dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time = wakeup_time;
}
+
+ if (bdb->version >= 226) {
+ u32 wakeup_time = psr_table->psr2_tp2_tp3_tp4_wakeup_time;
+
+ wakeup_time = (wakeup_time >> (2 * panel_type)) & 0x3;
+ dev_priv->vbt.psr.psr2_tp2_tp3_tp4_wakeup_time = wakeup_time;
+ } else {
+ /* Reusing PSR1 wakeup time for PSR2 in older VBTs */
+ dev_priv->vbt.psr.psr2_tp2_tp3_tp4_wakeup_time =
dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time;
+ }
}
static void parse_dsi_backlight_ports(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 5daf0b9e2b42..2fc537fb6e78 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -494,7 +494,7 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
val |= EDP_PSR2_FRAME_BEFORE_SU(dev_priv->psr.sink_sync_latency + 1);
- val |= dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time <<
EDP_PSR2_TP2_TP3_TIME_SHIFT;
+ val |= dev_priv->vbt.psr.psr2_tp2_tp3_tp4_wakeup_time <<
EDP_PSR2_TP2_TP3_TIME_SHIFT;
I915_WRITE(EDP_PSR2_CTL, val);
}
diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h
b/drivers/gpu/drm/i915/intel_vbt_defs.h
index 4ed66efde49f..dc0a14977953 100644
--- a/drivers/gpu/drm/i915/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
@@ -772,6 +772,9 @@ struct psr_table {
/* TP wake up time in multiple of 100 */
u16 tp1_wakeup_time;
u16 tp2_tp3_tp4_wakeup_time;
+
+ /* PSR2 TP2/TP3/TP4 wakeup time for 16 panels */
+ u32 psr2_tp2_tp3_tp4_wakeup_time;
} __packed;
struct bdb_psr {
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm/i915/vbt: Add 'tp4' to varibles holding TP2/3/4 PSR wakeup time
Recent update in spec made the field holding the TP2 and TP3 wakeup
time for PSR also hold the TP4, so lets rename the variables to
reflect that.
BSpec: 20131
Cc: Dhinakaran Pandiyan
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_bios.c | 16
drivers/gpu/drm/i915/intel_psr.c | 14 +++---
drivers/gpu/drm/i915/intel_vbt_defs.h | 2 +-
4 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 310d9e1e1620..e717c3132692 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -996,7 +996,7 @@ struct intel_vbt_data {
int idle_frames;
enum psr_lines_to_wait lines_to_wait;
int tp1_wakeup_time_us;
- int tp2_tp3_wakeup_time_us;
+ int tp2_tp3_tp4_wakeup_time_us;
} psr;
struct {
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 561a4f9f044c..cd99bf88bf6c 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -738,27 +738,27 @@ parse_psr(struct drm_i915_private *dev_priv, const struct
bdb_header *bdb)
break;
}
- switch (psr_table->tp2_tp3_wakeup_time) {
+ switch (psr_table->tp2_tp3_tp4_wakeup_time) {
case 0:
- dev_priv->vbt.psr.tp2_tp3_wakeup_time_us = 500;
+ dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time_us = 500;
break;
case 1:
- dev_priv->vbt.psr.tp2_tp3_wakeup_time_us = 100;
+ dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time_us = 100;
break;
case 3:
- dev_priv->vbt.psr.tp2_tp3_wakeup_time_us = 0;
+ dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time_us = 0;
break;
default:
- DRM_DEBUG_KMS("VBT tp2_tp3 wakeup time value %d is
outside range[0-3], defaulting to max value 2500us\n",
- psr_table->tp2_tp3_wakeup_time);
+ DRM_DEBUG_KMS("VBT tp2_tp3_tp4 wakeup time value %d is
outside range[0-3], defaulting to max value 2500us\n",
+ psr_table->tp2_tp3_tp4_wakeup_time);
/* fallthrough */
case 2:
- dev_priv->vbt.psr.tp2_tp3_wakeup_time_us = 2500;
+ dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time_us = 2500;
break;
}
} else {
dev_priv->vbt.psr.tp1_wakeup_time_us =
psr_table->tp1_wakeup_time * 100;
- dev_priv->vbt.psr.tp2_tp3_wakeup_time_us =
psr_table->tp2_tp3_wakeup_time * 100;
+ dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time_us =
psr_table->tp2_tp3_tp4_wakeup_time * 100;
}
}
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 0f6b2b4702e3..49b4b3371bef 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -468,11 +468,11 @@ static void hsw_activate_psr1(struct intel_dp *intel_dp)
else
val |= EDP_PSR_TP1_TIME_2500us;
- if (dev_priv->vbt.psr.tp2_tp3_wakeup_time_us == 0)
+ if (dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time_us == 0)
val |= EDP_PSR_TP2_TP3_TIME_0us;
- else if (dev_priv->vbt.psr.tp2_tp3_wakeup_time_us <= 100)
+ else if (dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time_us <= 100)
val |= EDP_PSR_TP2_TP3_TIME_100us;
- else if (dev_priv->vbt.psr.tp2_tp3_wakeup_time_us <= 500)
+ else if (dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time_us <= 500)
val |= EDP_PSR_TP2_TP3_TIME_500us;
else
val |= EDP_PSR_TP2_TP3_TIME_2500us;
@@ -509,12 +509,12 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
val |= EDP_PSR2_FRAME_BEFORE_SU(dev_priv->psr.sink_sync_latency + 1);
- if (dev_priv->vbt.psr.tp2_tp3_wakeup_time_us >= 0 &&
- dev_priv->vbt.psr.tp2_tp3_wakeup_time_us <= 50)
+ if (dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time_us >= 0 &&
+ dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time_us <= 50)
val |= EDP_PSR2_TP2_TIME_50us;
- else if (dev_priv->vbt.psr.tp2_tp3_wakeup_time_us <= 100)
+ else if (dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time_us <= 100)
val |= EDP_PSR2_TP2_TIME_100us;
- else if (dev_priv->vbt.psr.tp2_tp3_wakeup_time_us <= 500)
+ else if (dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time_us <= 500)
val |= EDP_PSR2_TP2_TIME_500us;
else
val |= EDP_PSR2_TP2_TIME_2500us;
diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h
[Intel-gfx] [PATCH 4/4] drm/i915/psr: Add HBR3 support
If the sink and source supports HBR3, TP4 should be used as link
training pattern.
For PSR2 there is no register to set and enable TP4 but according to
eDP spec TP3 is still a training pattern acceptable for HBR3 panels.
Cc: Manasi Navare
Cc: Dhinakaran Pandiyan
Signed-off-by: José Roberto de Souza
---
Still trying to understand how PSR1 was working on ICL while sending
TP4 to a panel that only supports HBR2.
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_dp_link_training.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_psr.c | 24 ++-
4 files changed, 21 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 5faca634ee70..1e792309a79e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4162,6 +4162,7 @@ enum {
#define EDP_PSR_TP1_TP3_SEL (1 << 11)
#define EDP_PSR_CRC_ENABLE (1 << 10) /* BDW+ */
#define EDP_PSR_TP2_TP3_TIME_SHIFT (8)
+#define EDP_PSR_TP4_TIME_SHIFT (6) /* ICL+ */
#define EDP_PSR_TP1_TIME_SHIFT (4)
#define EDP_PSR_IDLE_FRAME_SHIFT 0
diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c
b/drivers/gpu/drm/i915/intel_dp_link_training.c
index 30be0e39bd5f..3e9798a5498c 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -238,7 +238,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp
*intel_dp)
* or for 1.4 devices that support it, training Pattern 3 for HBR2
* or 1.2 devices that support it, Training Pattern 2 otherwise.
*/
-static u32 intel_dp_training_pattern(struct intel_dp *intel_dp)
+u32 intel_dp_training_pattern(struct intel_dp *intel_dp)
{
bool source_tps3, sink_tps3, source_tps4, sink_tps4;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index e5a436c33307..fc3e6ae92276 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1807,6 +1807,7 @@ int intel_dp_get_link_train_fallback_values(struct
intel_dp *intel_dp,
int link_rate, uint8_t lane_count);
void intel_dp_start_link_train(struct intel_dp *intel_dp);
void intel_dp_stop_link_train(struct intel_dp *intel_dp);
+u32 intel_dp_training_pattern(struct intel_dp *intel_dp);
int intel_dp_retrain_link(struct intel_encoder *encoder,
struct drm_modeset_acquire_ctx *ctx);
void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode);
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 2fc537fb6e78..b0525940e5e9 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -440,6 +440,7 @@ static void hsw_activate_psr1(struct intel_dp *intel_dp)
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
u32 max_sleep_time = 0x1f;
u32 val = EDP_PSR_ENABLE;
+ u32 tp;
/* Let's use 6 as the minimum to cover all known cases including the
* off-by-one issue that HW has in some cases.
@@ -460,13 +461,24 @@ static void hsw_activate_psr1(struct intel_dp *intel_dp)
val |= EDP_PSR_LINK_STANDBY;
val |= dev_priv->vbt.psr.tp1_wakeup_time << EDP_PSR_TP1_TIME_SHIFT;
- val |= dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time <<
EDP_PSR_TP2_TP3_TIME_SHIFT;
- if (intel_dp_source_supports_hbr2(intel_dp) &&
- drm_dp_tps3_supported(intel_dp->dpcd))
- val |= EDP_PSR_TP1_TP3_SEL;
- else
- val |= EDP_PSR_TP1_TP2_SEL;
+ tp = intel_dp_training_pattern(intel_dp);
+ if (tp == DP_TRAINING_PATTERN_4) {
+ /*
+* TP4 is selected by setting EDP_PSR_TP4_TIME with other value
+* than PSR_TP_WAKEUP_TIME_NONE
+*/
+ val |= dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time <<
EDP_PSR_TP4_TIME_SHIFT;
+ } else {
+ if (INTEL_GEN(dev_priv) >= 11)
+ val |= PSR_TP_WAKEUP_TIME_NONE <<
EDP_PSR_TP4_TIME_SHIFT;
+
+ val |= dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time <<
EDP_PSR_TP2_TP3_TIME_SHIFT;
+ if (tp == DP_TRAINING_PATTERN_3)
+ val |= EDP_PSR_TP1_TP3_SEL;
+ else
+ val |= EDP_PSR_TP1_TP2_SEL;
+ }
if (INTEL_GEN(dev_priv) >= 8)
val |= EDP_PSR_CRC_ENABLE;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Timing issues between ALSA and i915 drivers
I could use some feedback on HDMI audio issues exposed during the 4.21
merge window. By accident (misleading documentation) we ended up
enabling the Skylake driver instead of the HDaudio legacy, and broke
audio on a number of Skylake and ApolloLake devices where the
HDMI/iDISP codec was not detected (bit 2 not set in the
codec_mask). Linus' Dell XPS13 9350 was the first to be impacted of
course...
After debugging a bit, this issue can be resolved by either
a) compiling both SOUND and DRM as built-ins (y instead of m)
b) moving the calls snd_hdac_i915_init() to the probe function instead
of the worker queue (code at
https://github.com/plbossart/sound/commits/fix/skl-hdmi)
This isn't guaranteed to work, as request_module() might be involved,
I'm afraid.
Sorry, what would be the impact of the request_module? it'd just delay
the probe on the audio side, no?
And if the request_module failed then HDMI wouldn't be more broken
anyways...
Both solutions point to timing issues.
During internal reviews I was alerted to the fact that the suggested
fix essentially reverts patch ab1b732d53c18 ('ASoC: Intel: Skylake:
Move i915 registration to worker thread') which was introduced to
solve DRM lockup issues.
In other words, we are at a point where we either have DRM lockups or
can't detect the HDMI audio codec, none of which are too good.
I don't have the background for the DRM lockup stuff, nor do I
understand why snd_hdac_i915_init has to be called from a thread
context. Is this really a requirement?
I also don't get what sort of timing issues would come from an
initialization. What happens on the i915 side and is there some sort
of mandatory delay between the completion of the i915_init and issuing
a snd_hdac_chip_readw(bus, STATESTS) to get the codec masks on the
HDaudio links?
snd_hdac_i915_init() waits for the binding with the i915 audio
component, so a possible solution would be just to delay the audio
component registration at the really last stage, like the change
below.
If this still doesn't work, it'll be more deeply inside, and I have
little clue for now...
I tried this suggestion and no luck, same error with the iDISP codec not
exposed.
I added a delay after snd_hdac_i915_init(), doesn't seem to do anything.
One possibility is that this is a side effect of the Skylake driver
initializing the link twice for some odd reason.
And I still don't get what the motivation for moving this init to a work
queue was in the first place.
Doesn't seem like an easy one to fix...
thanks,
Takashi
---
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1577,8 +1577,6 @@ static void i915_driver_register(struct drm_i915_private
*dev_priv)
if (IS_GEN5(dev_priv))
intel_gpu_ips_init(dev_priv);
- intel_audio_init(dev_priv);
-
/*
* Some ports require correctly set-up hpd registers for detection to
* work properly (leading to ghost connected connector status), e.g. VGA
@@ -1597,6 +1595,8 @@ static void i915_driver_register(struct drm_i915_private
*dev_priv)
intel_power_domains_enable(dev_priv);
intel_runtime_pm_enable(dev_priv);
+
+ intel_audio_init(dev_priv);
}
/**
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/7] drm/i915/perf: only append status when data is available
Hi Lionel, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on drm-intel/for-linux-next] [also build test WARNING on v5.0-rc2 next-20190116] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Lionel-Landwerlin/drm-i915-perf-rework-aging-tail-workaround/20190117-000149 base: git://anongit.freedesktop.org/drm-intel for-linux-next reproduce: make htmldocs All warnings (new ones prefixed by >>): include/linux/dma-buf.h:304: warning: Function parameter or member 'cb_excl.cb' not described in 'dma_buf' include/linux/dma-buf.h:304: warning: Function parameter or member 'cb_excl.poll' not described in 'dma_buf' include/linux/dma-buf.h:304: warning: Function parameter or member 'cb_excl.active' not described in 'dma_buf' include/linux/dma-buf.h:304: warning: Function parameter or member 'cb_shared.cb' not described in 'dma_buf' include/linux/dma-buf.h:304: warning: Function parameter or member 'cb_shared.poll' not described in 'dma_buf' include/linux/dma-buf.h:304: warning: Function parameter or member 'cb_shared.active' not described in 'dma_buf' include/linux/dma-fence-array.h:54: warning: Function parameter or member 'work' not described in 'dma_fence_array' include/linux/firmware/intel/stratix10-svc-client.h:1: warning: no structured comments found include/linux/gpio/driver.h:371: warning: Function parameter or member 'init_valid_mask' not described in 'gpio_chip' include/linux/iio/hw-consumer.h:1: warning: no structured comments found include/linux/input/sparse-keymap.h:46: warning: Function parameter or member 'sw' not described in 'key_entry' drivers/mtd/nand/raw/nand_base.c:420: warning: Function parameter or member 'chip' not described in 'nand_fill_oob' drivers/mtd/nand/raw/nand_bbt.c:173: warning: Function parameter or member 'this' not described in 'read_bbt' drivers/mtd/nand/raw/nand_bbt.c:173: warning: Excess function parameter 'chip' description in 'read_bbt' include/linux/regulator/machine.h:199: warning: Function parameter or member 'max_uV_step' not described in 'regulation_constraints' include/linux/regulator/driver.h:228: warning: Function parameter or member 'resume' not described in 'regulator_ops' arch/s390/include/asm/cio.h:245: warning: Function parameter or member 'esw.esw0' not described in 'irb' arch/s390/include/asm/cio.h:245: warning: Function parameter or member 'esw.esw1' not described in 'irb' arch/s390/include/asm/cio.h:245: warning: Function parameter or member 'esw.esw2' not described in 'irb' arch/s390/include/asm/cio.h:245: warning: Function parameter or member 'esw.esw3' not described in 'irb' arch/s390/include/asm/cio.h:245: warning: Function parameter or member 'esw.eadm' not described in 'irb' drivers/slimbus/stream.c:1: warning: no structured comments found include/linux/spi/spi.h:180: warning: Function parameter or member 'driver_override' not described in 'spi_device' drivers/target/target_core_device.c:1: warning: no structured comments found drivers/usb/typec/bus.c:1: warning: no structured comments found drivers/usb/typec/class.c:1: warning: no structured comments found include/linux/w1.h:281: warning: Function parameter or member 'of_match_table' not described in 'w1_family' fs/direct-io.c:257: warning: Excess function parameter 'offset' description in 'dio_complete' fs/file_table.c:1: warning: no structured comments found fs/libfs.c:477: warning: Excess function parameter 'available' description in 'simple_write_end' fs/posix_acl.c:646: warning: Function parameter or member 'inode' not described in 'posix_acl_update_mode' fs/posix_acl.c:646: warning: Function parameter or member 'mode_p' not described in 'posix_acl_update_mode' fs/posix_acl.c:646: warning: Function parameter or member 'acl' not described in 'posix_acl_update_mode' drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:294: warning: Excess function parameter 'mm' description in 'amdgpu_mn_invalidate_range_start_hsa' drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:294: warning: Excess function parameter 'start' description in 'amdgpu_mn_invalidate_range_start_hsa' drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:294: warning: Excess function parameter 'end' description in 'amdgpu_mn_invalidate_range_start_hsa' drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:343: warning: Excess function parameter 'mm' description in 'amdgpu_mn_invalidate_range_end' drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:343: warning: Excess function parameter 'start' description in 'amdgpu_mn_invalidate_range_end' drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:343: warning: Excess function parameter 'end' description in 'amdgpu_mn_invalidate_range_end' drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:183: warning: Function parameter or member 'blockable' not described in 'amdgpu_mn_read_lock' drive
Re: [Intel-gfx] [PATCH v3 4/4] drm/i915/debugfs: Print PSR selective update status register values
On Fri, 2019-01-11 at 12:44 -0800, José Roberto de Souza wrote:
> The value of this registers will be used to test if PSR2 is doing
> selective update and if the number of blocks match with the expected.
>
> v2:
> - Using new macros
> - Changed the string output
>
> v3:
> - reading PSR2_SU_STATUS registers together(Dhinakaran)
> - printing SU blocks of frames with 0 updates(Dhinakaran)
>
> Cc: Rodrigo Vivi
> Cc: Dhinakaran Pandiyan
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 23 +++
> 1 file changed, 23 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index f8668cb05d64..5817ae0fb5f8 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2600,6 +2600,29 @@ static int i915_edp_psr_status(struct seq_file
> *m, void *data)
> seq_printf(m, "Last exit at: %lld\n", psr->last_exit);
> }
>
> + if (psr->psr2_enabled) {
> + u32 su_frames_val[3];
> + u8 frame;
'int' seems like a more appropriate choice here. With that changed,
Reviewed-by: Dhinakaran Pandiyan
Also, patch 2/4 needs rebase.
-DK
> +
> + /*
> + * Reading all 3 registers before hand to minimize
> crossing a
> + * frame boundary between register reads
> + */
> + for (frame = 0; frame < PSR2_SU_STATUS_FRAMES; frame +=
> 3)
> + su_frames_val[frame / 3] =
> I915_READ(PSR2_SU_STATUS(frame));
> +
> + seq_puts(m, "Frame:\tPSR2 SU blocks:\n");
> +
> + for (frame = 0; frame < PSR2_SU_STATUS_FRAMES; frame++)
> {
> + u32 su_blocks;
> +
> + su_blocks = su_frames_val[frame / 3] &
> + PSR2_SU_STATUS_MASK(frame);
> + su_blocks = su_blocks >>
> PSR2_SU_STATUS_SHIFT(frame);
> + seq_printf(m, "%d\t%d\n", frame, su_blocks);
> + }
> + }
> +
> unlock:
> mutex_unlock(>lock);
> intel_runtime_pm_put(dev_priv);
___
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: Pull all the reset functionality together into i915_reset.c
== Series Details ==
Series: drm/i915: Pull all the reset functionality together into i915_reset.c
URL : https://patchwork.freedesktop.org/series/55308/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5435 -> Patchwork_11307
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/55308/revisions/1/mbox/
Known issues
Here are the changes found in Patchwork_11307 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_execlists:
- fi-apl-guc: PASS -> INCOMPLETE [fdo#103927]
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: PASS -> DMESG-WARN [fdo#102614]
Possible fixes
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS
* igt@i915_selftest@live_hangcheck:
- fi-bwr-2160:DMESG-FAIL [fdo#108735] -> PASS
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: FAIL [fdo#108767] -> PASS
Warnings
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u: DMESG-FAIL [fdo#105079] -> DMESG-WARN [fdo#103558] /
[fdo#105079] / [fdo#105602]
{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#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#105079]: https://bugs.freedesktop.org/show_bug.cgi?id=105079
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108735]: https://bugs.freedesktop.org/show_bug.cgi?id=108735
[fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
Participating hosts (47 -> 42)
--
Missing(5): fi-kbl-soraka fi-ilk-m540 fi-bsw-cyan fi-icl-y fi-byt-clapper
Build changes
-
* Linux: CI_DRM_5435 -> Patchwork_11307
CI_DRM_5435: 74343418cada21ca522b3bc59b77b7699833f6ef @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4776: a76fa4d02cc806e30ed72ba1b8233c694ab1727b @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11307: 01c7b5cb9d1a6075930f1c103746b9bdcdd0a4fb @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
01c7b5cb9d1a drm/i915: Pull all the reset functionality together into
i915_reset.c
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11307/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: Fixes tag needs some work in the drm-misc tree
Hi all.
> Commit
>
> 94520db52fc0 ("drm: fix alpha build after drm_util.h change")
>
> has a malformed Fixes tag:
>
> Fixes: 733748ac37b45 ("drm: move drm_can_sleep() to drm_util.h")
>
> The SHA1 does not reference a commit currently in the tree. Maybe it
> was meant to be e9eafcb58921.
I can confirm that Stephen is right and that e9eafcb58921 is the proper SHA-1.
I guess the SHA-1 I used was from a rebased tree.
The mails from 0-DAY used the correct SHA-1 - which should have been a hint to
me.
Sigh
Sam
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 43/46] drm/i915: Allocate a status page for each timeline
Quoting John Harrison (2019-01-16 21:06:36)
> On 1/15/2019 10:43, Chris Wilson wrote:
> > Quoting John Harrison (2019-01-15 18:17:21)
> >> On 1/15/2019 01:50, Chris Wilson wrote:
> >>> Quoting John Harrison (2019-01-15 00:56:13)
> On 1/7/2019 03:55, Chris Wilson wrote:
> > +static int alloc_hwsp(struct i915_timeline *timeline)
> > +{
> > + struct drm_i915_private *i915 = timeline->i915;
> > + struct i915_vma *vma;
> > + int offset;
> > +
> > + mutex_lock(>gt.timeline_lock);
> > +
> > +restart:
> > + offset = find_first_cacheline(i915);
> > + if (offset == NBITS && i915->gt.timeline_hwsp) {
> > + i915_vma_put(i915->gt.timeline_hwsp);
> > + i915->gt.timeline_hwsp = NULL;
> > + }
> > +
> > + vma = i915->gt.timeline_hwsp;
> > + if (!vma) {
> > + struct drm_i915_gem_object *bo;
> > +
> > + /* Drop the lock before allocations */
> > + mutex_unlock(>gt.timeline_lock);
> > +
> > + BUILD_BUG_ON(NBITS * CACHELINE_BYTES > PAGE_SIZE);
> > + bo = i915_gem_object_create_internal(i915, PAGE_SIZE);
> > + if (IS_ERR(bo))
> > + return PTR_ERR(bo);
> > +
> > + i915_gem_object_set_cache_level(bo, I915_CACHE_LLC);
> > +
> > + vma = i915_vma_instance(bo, >ggtt.vm, NULL);
> > + if (IS_ERR(vma))
> > + return PTR_ERR(vma);
> > +
> > + mutex_lock(>gt.timeline_lock);
> > + if (i915->gt.timeline_hwsp) {
> > + i915_gem_object_put(bo);
> > + goto restart;
> > + }
> > +
> > + i915->gt.timeline_hwsp = vma;
> > + i915->gt.timeline_free = ~0ull;
> > + offset = 0;
> > + }
> > +
> > + i915->gt.timeline_free &= ~BIT_ULL(offset);
> > +
> > + timeline->hwsp_ggtt = i915_vma_get(vma);
> > + timeline->hwsp_offset = offset * CACHELINE_BYTES;
> > +
> > + mutex_unlock(>gt.timeline_lock);
> > +
> > + return 0;
> > +}
> If I'm reading this correctly then gt.timeline_hwsp/free is the a cached
> copy of the most recently allocated but not yet filled bank of seqno
> locations. When it gets full, the i915->gt reference gets dropped and a
> new page is allocated and used up line by line. Meanwhile, each timeline
> has it's own private reference to the page so dropping the i915->gt
> reference is safe. And once the last timeline using a given page is
> freed, the last reference to that page will be dropped and so the page
> itself will also be freed. If a timeline is freed before the currently
> cached page is filled, then that timeline's slot will be released and
> re-used by the next timeline to be created.
>
> But what about the scenario of a long running system with a small but
> growing number of persistent tasks interspersed with many short lived
> tasks? In that case, you would end up with many sparsely populated pages
> that whose free slots will not get re-used. You could have a linked list
> of cached pages. When a page is filled, move it to a 'full' list. When a
> timeline is freed, if it's page was on the 'full' list, clear the slot
> and move it back to the 'available' list.
> >>> Yes. My thinking was a plain slab cache was a quick-and-dirty
> >>> improvement over a page-per-timeline. And a freelist would be the next
> >>> step.
> >>>
> Or is the idea that a worst case of a single page vma allocation per
> timeline is the least of our worries if there is an ever growing number
> of timelines/contexts/users in the system?
> >>> Nah, it was just an attempt to quickly reduce the number of allocations,
> >>> where the worst case of one page+vma per timeline was the starting
> >>> point.
> >>>
> >>> We should break this patch down into 1) one-page-per-timeline, 2) slab
> >>> cache, 3) free list 4) profit.
> >>>
> >>> At other times we have been wanting to be able to suballocate pages,
> >>> something to keep in mind would be extending this to arbitrary cacheline
> >>> allocations.
> >> The multi-stage approach sounds good. Keep things simple in this patch
> >> and then improve the situation later. One thing to be careful of with a
> >> cacheline allocator would be make sure whatever is being converted
> >> wasn't using full pages for security reasons. I.e. a page can be private
> >> to a process, a cacheline will be shared by many. I guess that would
> >> only really apply to allocations being passed to user land as the kernel
> >> is considered secure? Or can a user batch buffer write to arbitrary
> >> locations within the ppHWSP and thereby splat someone else's seqno?
> > ppHWSP, yes. But for
[Intel-gfx] linux-next: Fixes tag needs some work in the drm-misc tree
[I am experimenting with checking the Fixes tags in commits in linux-next.
Please let me know if you think I am being too strict.]
Hi all,
Commit
94520db52fc0 ("drm: fix alpha build after drm_util.h change")
has a malformed Fixes tag:
Fixes: 733748ac37b45 ("drm: move drm_can_sleep() to drm_util.h")
The SHA1 does not reference a commit currently in the tree. Maybe it
was meant to be e9eafcb58921.
--
Cheers,
Stephen Rothwell
pgp7QjOgcd_CR.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 43/46] drm/i915: Allocate a status page for each timeline
On 1/15/2019 10:43, Chris Wilson wrote:
Quoting John Harrison (2019-01-15 18:17:21)
On 1/15/2019 01:50, Chris Wilson wrote:
Quoting John Harrison (2019-01-15 00:56:13)
On 1/7/2019 03:55, Chris Wilson wrote:
+static int alloc_hwsp(struct i915_timeline *timeline)
+{
+ struct drm_i915_private *i915 = timeline->i915;
+ struct i915_vma *vma;
+ int offset;
+
+ mutex_lock(>gt.timeline_lock);
+
+restart:
+ offset = find_first_cacheline(i915);
+ if (offset == NBITS && i915->gt.timeline_hwsp) {
+ i915_vma_put(i915->gt.timeline_hwsp);
+ i915->gt.timeline_hwsp = NULL;
+ }
+
+ vma = i915->gt.timeline_hwsp;
+ if (!vma) {
+ struct drm_i915_gem_object *bo;
+
+ /* Drop the lock before allocations */
+ mutex_unlock(>gt.timeline_lock);
+
+ BUILD_BUG_ON(NBITS * CACHELINE_BYTES > PAGE_SIZE);
+ bo = i915_gem_object_create_internal(i915, PAGE_SIZE);
+ if (IS_ERR(bo))
+ return PTR_ERR(bo);
+
+ i915_gem_object_set_cache_level(bo, I915_CACHE_LLC);
+
+ vma = i915_vma_instance(bo, >ggtt.vm, NULL);
+ if (IS_ERR(vma))
+ return PTR_ERR(vma);
+
+ mutex_lock(>gt.timeline_lock);
+ if (i915->gt.timeline_hwsp) {
+ i915_gem_object_put(bo);
+ goto restart;
+ }
+
+ i915->gt.timeline_hwsp = vma;
+ i915->gt.timeline_free = ~0ull;
+ offset = 0;
+ }
+
+ i915->gt.timeline_free &= ~BIT_ULL(offset);
+
+ timeline->hwsp_ggtt = i915_vma_get(vma);
+ timeline->hwsp_offset = offset * CACHELINE_BYTES;
+
+ mutex_unlock(>gt.timeline_lock);
+
+ return 0;
+}
If I'm reading this correctly then gt.timeline_hwsp/free is the a cached
copy of the most recently allocated but not yet filled bank of seqno
locations. When it gets full, the i915->gt reference gets dropped and a
new page is allocated and used up line by line. Meanwhile, each timeline
has it's own private reference to the page so dropping the i915->gt
reference is safe. And once the last timeline using a given page is
freed, the last reference to that page will be dropped and so the page
itself will also be freed. If a timeline is freed before the currently
cached page is filled, then that timeline's slot will be released and
re-used by the next timeline to be created.
But what about the scenario of a long running system with a small but
growing number of persistent tasks interspersed with many short lived
tasks? In that case, you would end up with many sparsely populated pages
that whose free slots will not get re-used. You could have a linked list
of cached pages. When a page is filled, move it to a 'full' list. When a
timeline is freed, if it's page was on the 'full' list, clear the slot
and move it back to the 'available' list.
Yes. My thinking was a plain slab cache was a quick-and-dirty
improvement over a page-per-timeline. And a freelist would be the next
step.
Or is the idea that a worst case of a single page vma allocation per
timeline is the least of our worries if there is an ever growing number
of timelines/contexts/users in the system?
Nah, it was just an attempt to quickly reduce the number of allocations,
where the worst case of one page+vma per timeline was the starting
point.
We should break this patch down into 1) one-page-per-timeline, 2) slab
cache, 3) free list 4) profit.
At other times we have been wanting to be able to suballocate pages,
something to keep in mind would be extending this to arbitrary cacheline
allocations.
The multi-stage approach sounds good. Keep things simple in this patch
and then improve the situation later. One thing to be careful of with a
cacheline allocator would be make sure whatever is being converted
wasn't using full pages for security reasons. I.e. a page can be private
to a process, a cacheline will be shared by many. I guess that would
only really apply to allocations being passed to user land as the kernel
is considered secure? Or can a user batch buffer write to arbitrary
locations within the ppHWSP and thereby splat someone else's seqno?
ppHWSP, yes. But for internal allocations, only accessible via the ring
+ GGTT, should be no problem. I agree that we definitely don't want to
expose subpage sharing across the userspace boundary (all isolation
controls are only on pages and above).
If userspace wants suballocations, it can (and does) do them for itself
and should regulate its own sharing.
I'm a little confused. Are you saying that a rogue batch buffer could
splat some other context's ppHWSP seqno or that it can't? It would be
bad if one dodgy user could cause hangchecks in another user's batch by
splatting their seqnos.
+ if (global_hwsp) {
+ timeline->hwsp_ggtt = i915_vma_get(global_hwsp);
+ timeline->hwsp_offset = I915_GEM_HWS_SEQNO_ADDR;
+ } else {
+
[Intel-gfx] [PULL] drm-misc-next
Hi Daniel, Dave,
Here is a re-run of the previous drm-misc-next as asked by Daniel.
Thanks!
Maxime
drm-misc-next-2019-01-16:
drm-misc-next for 5.1:
UAPI Changes:
- New fourcc identifier for ARM Framebuffer Compression v1.3
Cross-subsystem Changes:
Core Changes:
- Reorganisation of drm_device and drm_framebuffer headers
- Cleanup of the drmP inclusion
- Fix leaks in the fb-helpers
- Allow for depth different from bpp in fb-helper fbdev emulation
- Remove drm_mode_object from drm_display_mode
Driver Changes:
- Add reflection properties to rockchip
- a bunch of fixes for virtio
- a bunch of fixes for dp_mst and drivers using it, and introduction of a
new refcounting scheme
- Convertion of bochs to atomic and generic fbdev emulation
- Allow meson to remove the firmware framebuffers
The following changes since commit e3d093070eb0b5e3df668d3eb04100ea79343c65:
Merge tag 'tilcdc-4.22' of https://github.com/jsarha/linux into drm-next
(2019-01-11 06:29:31 +1000)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2019-01-16
for you to fetch changes up to 94520db52fc0e931327bb77fe79a952a0e9dd2b0:
drm: fix alpha build after drm_util.h change (2019-01-16 11:16:17 +0100)
drm-misc-next for 5.1:
UAPI Changes:
- New fourcc identifier for ARM Framebuffer Compression v1.3
Cross-subsystem Changes:
Core Changes:
- Reorganisation of drm_device and drm_framebuffer headers
- Cleanup of the drmP inclusion
- Fix leaks in the fb-helpers
- Allow for depth different from bpp in fb-helper fbdev emulation
- Remove drm_mode_object from drm_display_mode
Driver Changes:
- Add reflection properties to rockchip
- a bunch of fixes for virtio
- a bunch of fixes for dp_mst and drivers using it, and introduction of a
new refcounting scheme
- Convertion of bochs to atomic and generic fbdev emulation
- Allow meson to remove the firmware framebuffers
Daniel Vetter (15):
drm/todo: Better defio support in the generic fbdev emulation
drm/crtc-helpers: WARN when used with atomic drivers
drm/ch7006: Stop using drm_crtc_force_disable
drm/nouveau: Stop using drm_crtc_force_disable
drm: Unexport drm_crtc_force_disable
drm/atomic: Add missing () to function ref in kerneldoc
drm: Move the legacy kms disable_all helper to crtc helpers
drm/arc: Don't set the dpms hook
drm/tda998x: Don't set dpms hook
drm/doc: Polish kerneldoc for drm_device.h
drm/docs: improve docs for drm_drv.c
drm/of: Fix kerneldoc
drm/panel: Small documentation polish
drm/doc: Move bridge link target to the right place
staging/vboxvideo: Don't set FBINFO_MISC_ALWAYS_SETPAR
Daniele Castagna (2):
drm/rockchip: Fix YUV buffers color rendering
drm/rockchip: Add reflection properties
Enric Balletbo i Serra (1):
drm/rockchip: update cursors asynchronously through atomic.
Ezequiel Garcia (5):
drm/virtio: Remove incorrect kfree()
drm/virtio: Add missing virtqueue reset
drm/virtio: Drop deprecated load/unload initialization
drm/rockchip: Fix typo in VOP macros argument
drm/rockchip: Separate RK3288 from RK3368 win01 registers
Gerd Hoffmann (19):
drm/virtio: log error responses
drm/virtio: fix pageflip flush
drm/virtio: drop virtio_gpu_fence_cleanup()
drm/bochs: encoder cleanup
drm/bochs: split bochs_hw_setmode
drm/bochs: atomic: add atomic_flush+atomic_enable callbacks.
drm/bochs: atomic: add mode_set_nofb callback.
drm/bochs: atomic: switch planes to atomic, wire up helpers.
drm/bochs: atomic: use atomic set_config helper
drm/bochs: atomic: use atomic page_flip helper
drm/bochs: atomic: use suspend/resume helpers
drm/bochs: atomic: set DRIVER_ATOMIC
drm/bochs: remove old bochs_crtc_* functions
drm/bochs: drop unused gpu_addr arg from bochs_bo_pin()
drm/bochs: move ttm_bo_(un)reserve calls into bochs_bo_{pin, unpin}
drm/bochs: add basic prime support
drm/bochs: switch to generic drm fbdev emulation
drm/bochs: drop old fbdev emulation code
drm/bochs: move remaining fb bits to kms
Gustavo A. R. Silva (1):
qxl: Use struct_size() in kzalloc()
Kuo-Hsin Yang (1):
drm/gem: Mark pinned pages as unevictable
Linus Walleij (2):
drm/fb-helper: Scale back depth to supported maximum
drm/panel: Add a driver for the TPO TPG110
Lyude Paul (21):
drm/dp_mst: Fix some formatting in drm_dp_add_port()
drm/dp_mst: Fix some formatting in drm_dp_payload_send_msg()
drm/dp_mst: Fix some formatting in drm_dp_mst_allocate_vcpi()
drm/dp_mst: Fix some formatting in drm_dp_mst_deallocate_vcpi()
drm/dp_mst: Rename drm_dp_mst_get_validated_(port|mstb)_ref and friends
drm/dp_mst: Introduce
Re: [Intel-gfx] [PATCH 08/13] drm/i915: Populate gamma_mode for all platforms
On Wed, Jan 16, 2019 at 08:58:04PM +0200, Ville Syrjälä wrote:
> On Wed, Jan 16, 2019 at 10:31:56AM -0800, Matt Roper wrote:
> > On Fri, Jan 11, 2019 at 07:08:18PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > On pre-HSW gamma mode is configured via PIPECONF. The bits are
> > > the same except shifted up, so we can reuse just store them in
> > > crtc_state->gamma_mode in the HSW+ way, allowing us to share
> > > some code later.
> > >
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/i915/i915_reg.h | 10 -
> > > drivers/gpu/drm/i915/intel_color.c | 60 +---
> > > drivers/gpu/drm/i915/intel_display.c | 14 ++-
> > > 3 files changed, 66 insertions(+), 18 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index 44958d994bfa..9d17ba199be4 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -5578,9 +5578,15 @@ enum {
> > > #define PIPECONF_SINGLE_WIDE 0
> > > #define PIPECONF_PIPE_UNLOCKED 0
> > > #define PIPECONF_PIPE_LOCKED (1 << 25)
> > > -#define PIPECONF_PALETTE 0
> > > -#define PIPECONF_GAMMA (1 << 24)
> > > #define PIPECONF_FORCE_BORDER (1 << 25)
> > > +#define PIPECONF_GAMMA_MODE_MASK_I9XX (1 << 24) /* gmch */
> > > +#define PIPECONF_GAMMA_MODE_MASK_ILK (3 << 24) /* ilk-ivb */
> > > +#define PIPECONF_GAMMA_MODE_8BIT (0 << 24) /* gmch,ilk-ivb */
> > > +#define PIPECONF_GAMMA_MODE_10BIT (1 << 24) /* gmch,ilk-ivb */
> > > +#define PIPECONF_GAMMA_MODE_12BIT (2 << 24) /* ilk-ivb */
> > > +#define PIPECONF_GAMMA_MODE_SPLIT (3 << 24) /* ivb */
> > > +#define PIPECONF_GAMMA_MODE(x) ((x)<<24) /* pass in GAMMA_MODE_MODE_*
> > > */
> > > +#define PIPECONF_GAMMA_MODE_SHIFT 24
> > > #define PIPECONF_INTERLACE_MASK(7 << 21)
> > > #define PIPECONF_INTERLACE_MASK_HSW(3 << 21)
> > > /* Note that pre-gen3 does not support interlaced display directly. Panel
> > > diff --git a/drivers/gpu/drm/i915/intel_color.c
> > > b/drivers/gpu/drm/i915/intel_color.c
> > > index 0c0da7ed0fd7..6fdbfa8c4008 100644
> > > --- a/drivers/gpu/drm/i915/intel_color.c
> > > +++ b/drivers/gpu/drm/i915/intel_color.c
> > > @@ -351,6 +351,32 @@ static void i9xx_load_luts(const struct
> > > intel_crtc_state *crtc_state)
> > > i9xx_load_luts_internal(crtc_state, crtc_state->base.gamma_lut);
> > > }
> > >
> > > +static void i9xx_color_commit(const struct intel_crtc_state *crtc_state)
> > > +{
> > > + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> > > + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > > + enum pipe pipe = crtc->pipe;
> > > + u32 val;
> > > +
> > > + val = I915_READ(PIPECONF(pipe));
> > > + val &= ~PIPECONF_GAMMA_MODE_MASK_I9XX;
> > > + val |= PIPECONF_GAMMA_MODE(crtc_state->gamma_mode);
> > > + I915_WRITE(PIPECONF(pipe), val);
> > > +}
> > > +
> > > +static void ilk_color_commit(const struct intel_crtc_state *crtc_state)
> > > +{
> > > + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> > > + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > > + enum pipe pipe = crtc->pipe;
> > > + u32 val;
> > > +
> > > + val = I915_READ(PIPECONF(pipe));
> > > + val &= ~PIPECONF_GAMMA_MODE_MASK_ILK;
> > > + val |= PIPECONF_GAMMA_MODE(crtc_state->gamma_mode);
> > > + I915_WRITE(PIPECONF(pipe), val);
> > > +}
> >
> > Could we just set color_commit to i9xx_set_pipeconf and
> > ironlake_set_pipeconf to handle these without the r-m-w?
>
> Perhaps. But not quite sure if we have any magic restrictions
> in the crtc enable sequence that would prevent that.
I guess we could always keep the double set_pipeconf() in the
crtc enable path so that we won't have to think whether to move the
color_commit() earlier or the set_pipeconf() later.
>
> >
> >
> > Matt
> >
> > > +
> > > static void hsw_color_commit(const struct intel_crtc_state *crtc_state)
> > > {
> > > struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> > > @@ -585,8 +611,7 @@ void intel_color_commit(const struct intel_crtc_state
> > > *crtc_state)
> > > {
> > > struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
> > >
> > > - if (dev_priv->display.color_commit)
> > > - dev_priv->display.color_commit(crtc_state);
> > > + dev_priv->display.color_commit(crtc_state);
> > > }
> > >
> > > int intel_color_check(struct intel_crtc_state *crtc_state)
> > > @@ -634,20 +659,25 @@ void intel_color_init(struct intel_crtc *crtc)
> > >
> > > drm_mode_crtc_set_gamma_size(>base, 256);
> > >
> > > - if (IS_CHERRYVIEW(dev_priv)) {
> > > - dev_priv->display.load_luts = cherryview_load_luts;
> > > - } else if (IS_HASWELL(dev_priv)) {
> > > - dev_priv->display.load_luts = i9xx_load_luts;
> > > - dev_priv->display.color_commit = hsw_color_commit;
> > > - } else if
Re: [Intel-gfx] [PATCH 10/13] drm/i915: Track pipe csc enable in crtc state
On Fri, Jan 11, 2019 at 07:08:20PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Just like we did for pipe gamma, let's also track the pipe csc
> state. The hardware only exists on ILK+, and currently we always
> enable it on hsw+ and never on any other platforms. Just like
> with pipe gamma, the primary plane control register is used
> for the readout on pre-SKL, and the pipe bottom color register
> on SKL+.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/i915_reg.h | 4 ++--
> drivers/gpu/drm/i915/intel_color.c | 7 ++-
> drivers/gpu/drm/i915/intel_display.c | 18 ++
> drivers/gpu/drm/i915/intel_drv.h | 3 +++
> drivers/gpu/drm/i915/intel_sprite.c | 6 --
> 5 files changed, 29 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 7f0913bc1b47..8848721dd691 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6120,7 +6120,7 @@ enum {
> #define MCURSOR_PIPE_SELECT_SHIFT 28
> #define MCURSOR_PIPE_SELECT(pipe) ((pipe) << 28)
> #define MCURSOR_GAMMA_ENABLE (1 << 26)
> -#define MCURSOR_PIPE_CSC_ENABLE (1 << 24)
> +#define MCURSOR_PIPE_CSC_ENABLE (1 << 24) /* ilk+ */
> #define MCURSOR_ROTATE_180 (1 << 15)
> #define MCURSOR_TRICKLE_FEED_DISABLE (1 << 14)
> #define _CURABASE0x70084
> @@ -6175,7 +6175,7 @@ enum {
> #define DISPPLANE_RGBA888 (0xf << 26)
> #define DISPPLANE_STEREO_ENABLE(1 << 25)
> #define DISPPLANE_STEREO_DISABLE 0
> -#define DISPPLANE_PIPE_CSC_ENABLE (1 << 24)
> +#define DISPPLANE_PIPE_CSC_ENABLE (1 << 24) /* ilk+ */
> #define DISPPLANE_SEL_PIPE_SHIFT 24
> #define DISPPLANE_SEL_PIPE_MASK(3 << DISPPLANE_SEL_PIPE_SHIFT)
> #define DISPPLANE_SEL_PIPE(pipe) ((pipe) <<
> DISPPLANE_SEL_PIPE_SHIFT)
> diff --git a/drivers/gpu/drm/i915/intel_color.c
> b/drivers/gpu/drm/i915/intel_color.c
> index 313b281204fa..8d7ea902a34b 100644
> --- a/drivers/gpu/drm/i915/intel_color.c
> +++ b/drivers/gpu/drm/i915/intel_color.c
> @@ -397,7 +397,8 @@ static void skl_color_commit(const struct
> intel_crtc_state *crtc_state)
> val = 0;
> if (crtc_state->gamma_enable)
> val |= PIPE_BOTTOM_GAMMA_ENABLE;
> - val |= PIPE_BOTTOM_CSC_ENABLE;
> + if (crtc_state->csc_enable)
> + val |= PIPE_BOTTOM_CSC_ENABLE;
> I915_WRITE(PIPE_BOTTOM_COLOR(pipe), val);
>
> I915_WRITE(GAMMA_MODE(crtc->pipe), crtc_state->gamma_mode);
> @@ -644,6 +645,10 @@ int intel_color_check(struct intel_crtc_state
> *crtc_state)
>
> crtc_state->gamma_enable = true;
>
> + if (INTEL_GEN(dev_priv) >= 9 ||
> + IS_BROADWELL(dev_priv) || IS_HASWELL(dev_priv))
> + crtc_state->csc_enable = true;
> +
> /*
>* We also allow no degamma lut/ctm and a gamma lut at the legacy
>* size (256 entries).
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 896ce95790cb..2e66b398167e 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3189,7 +3189,7 @@ static u32 i9xx_plane_ctl_crtc(const struct
> intel_crtc_state *crtc_state)
> if (crtc_state->gamma_enable)
> dspcntr |= DISPPLANE_GAMMA_ENABLE;
>
> - if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
> + if (crtc_state->csc_enable)
> dspcntr |= DISPPLANE_PIPE_CSC_ENABLE;
>
> if (INTEL_GEN(dev_priv) < 5)
> @@ -3668,7 +3668,8 @@ u32 skl_plane_ctl_crtc(const struct intel_crtc_state
> *crtc_state)
> if (crtc_state->gamma_enable)
> plane_ctl |= PLANE_CTL_PIPE_GAMMA_ENABLE;
>
> - plane_ctl |= PLANE_CTL_PIPE_CSC_ENABLE;
> + if (crtc_state->csc_enable)
> + plane_ctl |= PLANE_CTL_PIPE_CSC_ENABLE;
>
> return plane_ctl;
> }
> @@ -3723,7 +3724,8 @@ u32 glk_plane_color_ctl_crtc(const struct
> intel_crtc_state *crtc_state)
> if (crtc_state->gamma_enable)
> plane_color_ctl |= PLANE_COLOR_PIPE_GAMMA_ENABLE;
>
> - plane_color_ctl |= PLANE_COLOR_PIPE_CSC_ENABLE;
> + if (crtc_state->csc_enable)
> + plane_color_ctl |= PLANE_COLOR_PIPE_CSC_ENABLE;
>
> return plane_color_ctl;
> }
> @@ -8052,6 +8054,10 @@ static void i9xx_get_pipe_color_config(struct
> intel_crtc_state *crtc_state)
>
> if (tmp & DISPPLANE_GAMMA_ENABLE)
> crtc_state->gamma_enable = true;
> +
> + if (!HAS_GMCH_DISPLAY(dev_priv) &&
> + tmp & DISPPLANE_PIPE_CSC_ENABLE)
> + crtc_state->csc_enable = true;
> }
>
> static bool i9xx_get_pipe_config(struct intel_crtc *crtc,
> @@ -9812,6 +9818,9 @@ static bool haswell_get_pipe_config(struct intel_crtc
> *crtc,
>
> if (tmp & PIPE_BOTTOM_GAMMA_ENABLE)
>
Re: [Intel-gfx] [PATCH 09/13] drm/i915: Track pipe gamma enable/disable in crtc state
On Fri, Jan 11, 2019 at 07:08:19PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Track whether pipe gamma is enabled or disabled. For now we
> stick to the current behaviour of always enabling gamma. But
> we do get working state readout for this now. On SKL+ we use
> the pipe bottom color as our hardware state. On pre-SKL we
> read the state back from the primary plane control register.
> That only really correct for g4x+, as older platforms never
> gamma correct pipe bottom color. But doing the readout the
> same way on all platforms is fine, and there is no other way
> to do it really.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/i915_reg.h | 8
> drivers/gpu/drm/i915/intel_color.c | 24 +++-
> drivers/gpu/drm/i915/intel_display.c | 56 ++--
> drivers/gpu/drm/i915/intel_drv.h | 3 ++
> drivers/gpu/drm/i915/intel_sprite.c | 17 +++--
> 5 files changed, 92 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 9d17ba199be4..7f0913bc1b47 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -5707,6 +5707,14 @@ enum {
> #define PIPEMISC_DITHER_TYPE_SP(0 << 2)
> #define PIPEMISC(pipe) _MMIO_PIPE2(pipe, _PIPE_MISC_A)
>
> +/* SKL+ pipe bottom color */
> +#define _PIPE_BOTTOM_COLOR_A 0x70034
> +#define _PIPE_BOTTOM_COLOR_B 0x71034
> +#define PIPE_BOTTOM_GAMMA_ENABLE (1 << 31)
> +#define PIPE_BOTTOM_CSC_ENABLE (1 << 30)
> +#define PIPE_BOTTOM_COLOR_MASK 0x3FFF
> +#define PIPE_BOTTOM_COLOR(pipe) _MMIO_PIPE2(pipe,
> _PIPE_BOTTOM_COLOR_A)
> +
> #define VLV_DPFLIPSTAT _MMIO(VLV_DISPLAY_BASE
> + 0x70028)
> #define PIPEB_LINE_COMPARE_INT_EN (1 << 29)
> #define PIPEB_HLINE_INT_EN (1 << 28)
> diff --git a/drivers/gpu/drm/i915/intel_color.c
> b/drivers/gpu/drm/i915/intel_color.c
> index 6fdbfa8c4008..313b281204fa 100644
> --- a/drivers/gpu/drm/i915/intel_color.c
> +++ b/drivers/gpu/drm/i915/intel_color.c
> @@ -387,6 +387,24 @@ static void hsw_color_commit(const struct
> intel_crtc_state *crtc_state)
> ilk_load_csc_matrix(crtc_state);
> }
>
> +static void skl_color_commit(const struct intel_crtc_state *crtc_state)
> +{
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + enum pipe pipe = crtc->pipe;
> + u32 val;
> +
> + val = 0;
> + if (crtc_state->gamma_enable)
> + val |= PIPE_BOTTOM_GAMMA_ENABLE;
> + val |= PIPE_BOTTOM_CSC_ENABLE;
> + I915_WRITE(PIPE_BOTTOM_COLOR(pipe), val);
> +
> + I915_WRITE(GAMMA_MODE(crtc->pipe), crtc_state->gamma_mode);
> +
> + ilk_load_csc_matrix(crtc_state);
> +}
> +
> static void bdw_load_degamma_lut(const struct intel_crtc_state *crtc_state)
> {
> struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> @@ -624,6 +642,8 @@ int intel_color_check(struct intel_crtc_state *crtc_state)
> degamma_length = INTEL_INFO(dev_priv)->color.degamma_lut_size;
> gamma_length = INTEL_INFO(dev_priv)->color.gamma_lut_size;
>
> + crtc_state->gamma_enable = true;
> +
> /*
>* We also allow no degamma lut/ctm and a gamma lut at the legacy
>* size (256 entries).
> @@ -674,7 +694,9 @@ void intel_color_init(struct intel_crtc *crtc)
> else
> dev_priv->display.load_luts = i9xx_load_luts;
>
> - if (INTEL_GEN(dev_priv) >= 8 || IS_HASWELL(dev_priv))
> + if (INTEL_GEN(dev_priv) >= 9)
> + dev_priv->display.color_commit = skl_color_commit;
> + else if (IS_BROADWELL(dev_priv) || IS_HASWELL(dev_priv))
> dev_priv->display.color_commit = hsw_color_commit;
> else
> dev_priv->display.color_commit = ilk_color_commit;
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 90afcae91b30..896ce95790cb 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3186,7 +3186,8 @@ static u32 i9xx_plane_ctl_crtc(const struct
> intel_crtc_state *crtc_state)
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> u32 dspcntr = 0;
>
> - dspcntr |= DISPPLANE_GAMMA_ENABLE;
> + if (crtc_state->gamma_enable)
> + dspcntr |= DISPPLANE_GAMMA_ENABLE;
>
> if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
> dspcntr |= DISPPLANE_PIPE_CSC_ENABLE;
> @@ -3664,7 +3665,9 @@ u32 skl_plane_ctl_crtc(const struct intel_crtc_state
> *crtc_state)
> if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> return plane_ctl;
>
> - plane_ctl |= PLANE_CTL_PIPE_GAMMA_ENABLE;
> +
Re: [Intel-gfx] Timing issues between ALSA and i915 drivers
On Wed, 16 Jan 2019 18:48:25 +0100,
Pierre-Louis Bossart wrote:
>
> Hi,
>
> I could use some feedback on HDMI audio issues exposed during the 4.21
> merge window. By accident (misleading documentation) we ended up
> enabling the Skylake driver instead of the HDaudio legacy, and broke
> audio on a number of Skylake and ApolloLake devices where the
> HDMI/iDISP codec was not detected (bit 2 not set in the
> codec_mask). Linus' Dell XPS13 9350 was the first to be impacted of
> course...
>
> After debugging a bit, this issue can be resolved by either
>
> a) compiling both SOUND and DRM as built-ins (y instead of m)
>
> b) moving the calls snd_hdac_i915_init() to the probe function instead
> of the worker queue (code at
> https://github.com/plbossart/sound/commits/fix/skl-hdmi)
This isn't guaranteed to work, as request_module() might be involved,
I'm afraid.
> Both solutions point to timing issues.
>
> During internal reviews I was alerted to the fact that the suggested
> fix essentially reverts patch ab1b732d53c18 ('ASoC: Intel: Skylake:
> Move i915 registration to worker thread') which was introduced to
> solve DRM lockup issues.
>
> In other words, we are at a point where we either have DRM lockups or
> can't detect the HDMI audio codec, none of which are too good.
>
> I don't have the background for the DRM lockup stuff, nor do I
> understand why snd_hdac_i915_init has to be called from a thread
> context. Is this really a requirement?
>
> I also don't get what sort of timing issues would come from an
> initialization. What happens on the i915 side and is there some sort
> of mandatory delay between the completion of the i915_init and issuing
> a snd_hdac_chip_readw(bus, STATESTS) to get the codec masks on the
> HDaudio links?
snd_hdac_i915_init() waits for the binding with the i915 audio
component, so a possible solution would be just to delay the audio
component registration at the really last stage, like the change
below.
If this still doesn't work, it'll be more deeply inside, and I have
little clue for now...
thanks,
Takashi
---
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1577,8 +1577,6 @@ static void i915_driver_register(struct drm_i915_private
*dev_priv)
if (IS_GEN5(dev_priv))
intel_gpu_ips_init(dev_priv);
- intel_audio_init(dev_priv);
-
/*
* Some ports require correctly set-up hpd registers for detection to
* work properly (leading to ghost connected connector status), e.g. VGA
@@ -1597,6 +1595,8 @@ static void i915_driver_register(struct drm_i915_private
*dev_priv)
intel_power_domains_enable(dev_priv);
intel_runtime_pm_enable(dev_priv);
+
+ intel_audio_init(dev_priv);
}
/**
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/13] drm/i915: Populate gamma_mode for all platforms
On Wed, Jan 16, 2019 at 10:31:56AM -0800, Matt Roper wrote:
> On Fri, Jan 11, 2019 at 07:08:18PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > On pre-HSW gamma mode is configured via PIPECONF. The bits are
> > the same except shifted up, so we can reuse just store them in
> > crtc_state->gamma_mode in the HSW+ way, allowing us to share
> > some code later.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/i915_reg.h | 10 -
> > drivers/gpu/drm/i915/intel_color.c | 60 +---
> > drivers/gpu/drm/i915/intel_display.c | 14 ++-
> > 3 files changed, 66 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 44958d994bfa..9d17ba199be4 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -5578,9 +5578,15 @@ enum {
> > #define PIPECONF_SINGLE_WIDE 0
> > #define PIPECONF_PIPE_UNLOCKED 0
> > #define PIPECONF_PIPE_LOCKED (1 << 25)
> > -#define PIPECONF_PALETTE 0
> > -#define PIPECONF_GAMMA (1 << 24)
> > #define PIPECONF_FORCE_BORDER(1 << 25)
> > +#define PIPECONF_GAMMA_MODE_MASK_I9XX(1 << 24) /* gmch */
> > +#define PIPECONF_GAMMA_MODE_MASK_ILK (3 << 24) /* ilk-ivb */
> > +#define PIPECONF_GAMMA_MODE_8BIT (0 << 24) /* gmch,ilk-ivb */
> > +#define PIPECONF_GAMMA_MODE_10BIT(1 << 24) /* gmch,ilk-ivb */
> > +#define PIPECONF_GAMMA_MODE_12BIT(2 << 24) /* ilk-ivb */
> > +#define PIPECONF_GAMMA_MODE_SPLIT(3 << 24) /* ivb */
> > +#define PIPECONF_GAMMA_MODE(x) ((x)<<24) /* pass in GAMMA_MODE_MODE_*
> > */
> > +#define PIPECONF_GAMMA_MODE_SHIFT24
> > #define PIPECONF_INTERLACE_MASK (7 << 21)
> > #define PIPECONF_INTERLACE_MASK_HSW (3 << 21)
> > /* Note that pre-gen3 does not support interlaced display directly. Panel
> > diff --git a/drivers/gpu/drm/i915/intel_color.c
> > b/drivers/gpu/drm/i915/intel_color.c
> > index 0c0da7ed0fd7..6fdbfa8c4008 100644
> > --- a/drivers/gpu/drm/i915/intel_color.c
> > +++ b/drivers/gpu/drm/i915/intel_color.c
> > @@ -351,6 +351,32 @@ static void i9xx_load_luts(const struct
> > intel_crtc_state *crtc_state)
> > i9xx_load_luts_internal(crtc_state, crtc_state->base.gamma_lut);
> > }
> >
> > +static void i9xx_color_commit(const struct intel_crtc_state *crtc_state)
> > +{
> > + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> > + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > + enum pipe pipe = crtc->pipe;
> > + u32 val;
> > +
> > + val = I915_READ(PIPECONF(pipe));
> > + val &= ~PIPECONF_GAMMA_MODE_MASK_I9XX;
> > + val |= PIPECONF_GAMMA_MODE(crtc_state->gamma_mode);
> > + I915_WRITE(PIPECONF(pipe), val);
> > +}
> > +
> > +static void ilk_color_commit(const struct intel_crtc_state *crtc_state)
> > +{
> > + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> > + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > + enum pipe pipe = crtc->pipe;
> > + u32 val;
> > +
> > + val = I915_READ(PIPECONF(pipe));
> > + val &= ~PIPECONF_GAMMA_MODE_MASK_ILK;
> > + val |= PIPECONF_GAMMA_MODE(crtc_state->gamma_mode);
> > + I915_WRITE(PIPECONF(pipe), val);
> > +}
>
> Could we just set color_commit to i9xx_set_pipeconf and
> ironlake_set_pipeconf to handle these without the r-m-w?
Perhaps. But not quite sure if we have any magic restrictions
in the crtc enable sequence that would prevent that.
>
>
> Matt
>
> > +
> > static void hsw_color_commit(const struct intel_crtc_state *crtc_state)
> > {
> > struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> > @@ -585,8 +611,7 @@ void intel_color_commit(const struct intel_crtc_state
> > *crtc_state)
> > {
> > struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
> >
> > - if (dev_priv->display.color_commit)
> > - dev_priv->display.color_commit(crtc_state);
> > + dev_priv->display.color_commit(crtc_state);
> > }
> >
> > int intel_color_check(struct intel_crtc_state *crtc_state)
> > @@ -634,20 +659,25 @@ void intel_color_init(struct intel_crtc *crtc)
> >
> > drm_mode_crtc_set_gamma_size(>base, 256);
> >
> > - if (IS_CHERRYVIEW(dev_priv)) {
> > - dev_priv->display.load_luts = cherryview_load_luts;
> > - } else if (IS_HASWELL(dev_priv)) {
> > - dev_priv->display.load_luts = i9xx_load_luts;
> > - dev_priv->display.color_commit = hsw_color_commit;
> > - } else if (IS_BROADWELL(dev_priv) || IS_GEN9_BC(dev_priv) ||
> > - IS_BROXTON(dev_priv)) {
> > - dev_priv->display.load_luts = broadwell_load_luts;
> > - dev_priv->display.color_commit = hsw_color_commit;
> > - } else if (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) {
> > - dev_priv->display.load_luts = glk_load_luts;
> > - dev_priv->display.color_commit =
Re: [Intel-gfx] [PATCH 08/13] drm/i915: Populate gamma_mode for all platforms
On Fri, Jan 11, 2019 at 07:08:18PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> On pre-HSW gamma mode is configured via PIPECONF. The bits are
> the same except shifted up, so we can reuse just store them in
> crtc_state->gamma_mode in the HSW+ way, allowing us to share
> some code later.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_reg.h | 10 -
> drivers/gpu/drm/i915/intel_color.c | 60 +---
> drivers/gpu/drm/i915/intel_display.c | 14 ++-
> 3 files changed, 66 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 44958d994bfa..9d17ba199be4 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -5578,9 +5578,15 @@ enum {
> #define PIPECONF_SINGLE_WIDE 0
> #define PIPECONF_PIPE_UNLOCKED 0
> #define PIPECONF_PIPE_LOCKED (1 << 25)
> -#define PIPECONF_PALETTE 0
> -#define PIPECONF_GAMMA (1 << 24)
> #define PIPECONF_FORCE_BORDER (1 << 25)
> +#define PIPECONF_GAMMA_MODE_MASK_I9XX (1 << 24) /* gmch */
> +#define PIPECONF_GAMMA_MODE_MASK_ILK (3 << 24) /* ilk-ivb */
> +#define PIPECONF_GAMMA_MODE_8BIT (0 << 24) /* gmch,ilk-ivb */
> +#define PIPECONF_GAMMA_MODE_10BIT (1 << 24) /* gmch,ilk-ivb */
> +#define PIPECONF_GAMMA_MODE_12BIT (2 << 24) /* ilk-ivb */
> +#define PIPECONF_GAMMA_MODE_SPLIT (3 << 24) /* ivb */
> +#define PIPECONF_GAMMA_MODE(x) ((x)<<24) /* pass in GAMMA_MODE_MODE_*
> */
> +#define PIPECONF_GAMMA_MODE_SHIFT 24
> #define PIPECONF_INTERLACE_MASK(7 << 21)
> #define PIPECONF_INTERLACE_MASK_HSW(3 << 21)
> /* Note that pre-gen3 does not support interlaced display directly. Panel
> diff --git a/drivers/gpu/drm/i915/intel_color.c
> b/drivers/gpu/drm/i915/intel_color.c
> index 0c0da7ed0fd7..6fdbfa8c4008 100644
> --- a/drivers/gpu/drm/i915/intel_color.c
> +++ b/drivers/gpu/drm/i915/intel_color.c
> @@ -351,6 +351,32 @@ static void i9xx_load_luts(const struct intel_crtc_state
> *crtc_state)
> i9xx_load_luts_internal(crtc_state, crtc_state->base.gamma_lut);
> }
>
> +static void i9xx_color_commit(const struct intel_crtc_state *crtc_state)
> +{
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + enum pipe pipe = crtc->pipe;
> + u32 val;
> +
> + val = I915_READ(PIPECONF(pipe));
> + val &= ~PIPECONF_GAMMA_MODE_MASK_I9XX;
> + val |= PIPECONF_GAMMA_MODE(crtc_state->gamma_mode);
> + I915_WRITE(PIPECONF(pipe), val);
> +}
> +
> +static void ilk_color_commit(const struct intel_crtc_state *crtc_state)
> +{
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + enum pipe pipe = crtc->pipe;
> + u32 val;
> +
> + val = I915_READ(PIPECONF(pipe));
> + val &= ~PIPECONF_GAMMA_MODE_MASK_ILK;
> + val |= PIPECONF_GAMMA_MODE(crtc_state->gamma_mode);
> + I915_WRITE(PIPECONF(pipe), val);
> +}
Could we just set color_commit to i9xx_set_pipeconf and
ironlake_set_pipeconf to handle these without the r-m-w?
Matt
> +
> static void hsw_color_commit(const struct intel_crtc_state *crtc_state)
> {
> struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> @@ -585,8 +611,7 @@ void intel_color_commit(const struct intel_crtc_state
> *crtc_state)
> {
> struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
>
> - if (dev_priv->display.color_commit)
> - dev_priv->display.color_commit(crtc_state);
> + dev_priv->display.color_commit(crtc_state);
> }
>
> int intel_color_check(struct intel_crtc_state *crtc_state)
> @@ -634,20 +659,25 @@ void intel_color_init(struct intel_crtc *crtc)
>
> drm_mode_crtc_set_gamma_size(>base, 256);
>
> - if (IS_CHERRYVIEW(dev_priv)) {
> - dev_priv->display.load_luts = cherryview_load_luts;
> - } else if (IS_HASWELL(dev_priv)) {
> - dev_priv->display.load_luts = i9xx_load_luts;
> - dev_priv->display.color_commit = hsw_color_commit;
> - } else if (IS_BROADWELL(dev_priv) || IS_GEN9_BC(dev_priv) ||
> -IS_BROXTON(dev_priv)) {
> - dev_priv->display.load_luts = broadwell_load_luts;
> - dev_priv->display.color_commit = hsw_color_commit;
> - } else if (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) {
> - dev_priv->display.load_luts = glk_load_luts;
> - dev_priv->display.color_commit = hsw_color_commit;
> + if (HAS_GMCH_DISPLAY(dev_priv)) {
> + if (IS_CHERRYVIEW(dev_priv))
> + dev_priv->display.load_luts = cherryview_load_luts;
> + else
> + dev_priv->display.load_luts = i9xx_load_luts;
> +
> + dev_priv->display.color_commit =
Re: [Intel-gfx] [PATCH 06/13] drm/i915: Split color mgmt based on single vs. double buffered registers
>-Original Message-
>From: Roper, Matthew D
>Sent: Tuesday, January 15, 2019 6:27 AM
>To: Ville Syrjala
>Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma
>Subject: Re: [PATCH 06/13] drm/i915: Split color mgmt based on single vs.
>double
>buffered registers
>
>On Fri, Jan 11, 2019 at 07:08:16PM +0200, Ville Syrjala wrote:
>> From: Ville Syrjälä
>>
>> Split the color managemnt hooks along the single vs. double buffered
Typo in management.
>> registers line. Of the currently progammed registers GAMMA_MODE and
Typo in programmed.
>> the ilk+ pipe CSC are double buffered, the LUTS and CHV CGM block are
>> single buffered.
>>
>> The double buffered register will be programmed during the normal pipe
>> update with evasion, and also during pipe enable so that the settings
>> will already be correct when the pipe starts up before the planes are
>> enabled.
>>
>> The single buffered registers are currently programmed before the
>> vblank evade. Which is totally wrong, but we'll correct that later.
>>
>> Signed-off-by: Ville Syrjälä
>> ---
>> drivers/gpu/drm/i915/i915_drv.h | 2 +-
>> drivers/gpu/drm/i915/intel_color.c | 49 +---
>> drivers/gpu/drm/i915/intel_display.c | 16 +
>> drivers/gpu/drm/i915/intel_drv.h | 2 +-
>> 4 files changed, 34 insertions(+), 35 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h
>> b/drivers/gpu/drm/i915/i915_drv.h index 7182a580002c..354858b2019b
>> 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -320,7 +320,7 @@ struct drm_i915_display_funcs {
>> /* display clock increase/decrease */
>> /* pll clock increase/decrease */
>>
>> -void (*load_csc_matrix)(const struct intel_crtc_state *crtc_state);
>> +void (*color_commit)(const struct intel_crtc_state *crtc_state);
>> void (*load_luts)(const struct intel_crtc_state *crtc_state);
>
>Logic-wise this patch looks good, but we should probably add some kerneldoc to
>these to make it clear that color_commit() is programming anything that's
>expected to take effect at the vblank, and load_luts() takes effect immediately
>when called.
This documentation or some comments in the function description in code will
definitely help.
>
>> };
>>
>> diff --git a/drivers/gpu/drm/i915/intel_color.c
>> b/drivers/gpu/drm/i915/intel_color.c
>> index df3567686c45..f9e0855162f3 100644
>> --- a/drivers/gpu/drm/i915/intel_color.c
>> +++ b/drivers/gpu/drm/i915/intel_color.c
>> @@ -304,14 +304,6 @@ static void cherryview_load_csc_matrix(const struct
>intel_crtc_state *crtc_state
>> I915_WRITE(CGM_PIPE_MODE(pipe), mode); }
>>
>> -void intel_color_set_csc(const struct intel_crtc_state *crtc_state)
>> -{
>> -struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
>> -
>> -if (dev_priv->display.load_csc_matrix)
>> -dev_priv->display.load_csc_matrix(crtc_state);
>> -}
>> -
>> /* Loads the legacy palette/gamma unit for the CRTC. */ static void
>> i9xx_load_luts_internal(const struct intel_crtc_state *crtc_state,
>> const struct drm_property_blob *blob) @@ -
>359,6 +351,16 @@
>> static void i9xx_load_luts(const struct intel_crtc_state *crtc_state)
>> i9xx_load_luts_internal(crtc_state, crtc_state->base.gamma_lut); }
>>
>> +static void hsw_color_commit(const struct intel_crtc_state
>> +*crtc_state) {
>> +struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
>> +struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>> +
>> +I915_WRITE(GAMMA_MODE(crtc->pipe), crtc_state->gamma_mode);
>> +
>> +ilk_load_csc_matrix(crtc_state);
One issue which I see here is that we are mixing programming of csc and gamma
mode
in a common function. There may be situations where we don't want either a csc
or
gamma to be enabled. Also more so since the respective blocks are implemented as
separate properties. Not sure if this will cause any real issue though.
>> +}
>> +
>> /* Loads the legacy palette/gamma unit for the CRTC on Haswell. */
>> static void haswell_load_luts(const struct intel_crtc_state
>> *crtc_state) { @@ -376,8 +378,6 @@ static void
>> haswell_load_luts(const struct intel_crtc_state *crtc_state)
>> reenable_ips = true;
>> }
>>
>> -I915_WRITE(GAMMA_MODE(crtc->pipe), crtc_state->gamma_mode);
>> -
>> i9xx_load_luts(crtc_state);
>>
>> if (reenable_ips)
>> @@ -485,8 +485,6 @@ static void broadwell_load_luts(const struct
>intel_crtc_state *crtc_state)
>> */
>> I915_WRITE(PREC_PAL_INDEX(pipe), 0);
>> }
>> -
>> -I915_WRITE(GAMMA_MODE(pipe), crtc_state->gamma_mode);
>> }
>>
>> static void glk_load_degamma_lut(const struct intel_crtc_state
>> *crtc_state) @@ -539,8 +537,6 @@ static void glk_load_luts(const struct
>intel_crtc_state *crtc_state)
>> */
>> I915_WRITE(PREC_PAL_INDEX(pipe), 0);
>> }
>> -
>> -
Re: [Intel-gfx] [PATCH 2/7] drm/i915/perf: reset pollin when perf stream is enabled
On 16/01/2019 17:13, Matthew Auld wrote:
On Wed, 16 Jan 2019 at 15:36, Lionel Landwerlin
wrote:
No issues have been raised about this yet, but this should be reset
every time we enable the stream, otherwise we might have a stale value
from the previous round of enable/disable.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 575701e2aabc..4c5d2ee4d6e3 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1876,6 +1876,8 @@ static void i915_oa_stream_enable(struct i915_perf_stream
*stream)
{
struct drm_i915_private *dev_priv = stream->dev_priv;
+ dev_priv->perf.oa.pollin = false;
+
dev_priv->perf.oa.ops.oa_enable(stream);
Don't we fumigate oa.polling way down in ops.oa_enable() ?
Duh! You're right... It's the last step for gen7/8_init_oa_buffer().
I think I would like to move it into the generic setup if that's okay
and leave the specific stuff to register manipulations.
Will update.
-
Lionel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Split out drm_probe_helper.h
Hi Daniel. > v5: Actually try to sort them, and while at it, sort all the ones I > touch. Applied this variant on top of drm-misc and did a build test. Looked good for ia64, x86 and alpha. Took a closer look at the changes to atmel_hlcd - and they looked OK. But I noticed that atmel_hlcdc uses only drm_kms_helper_poll_init() and drm_kms_helper_poll_fini(). But there are no hits on DRM_CONNECTOR_POLL - so I think we maybe have a driver here where we have plugged the drm_poll infrastructure, but it is not in use. > include/drm/drm_crtc_helper.h | 16 --- The list of include files in this file could be dropped and replaced by: struct drm_connector; struct drm_device; struct drm_display_mode; struct drm_encoder; struct drm_framebuffer; struct drm_mode_set; struct drm_modeset_acquire_ctx; I tried to do so on top of your patch. But there were too many build errros and I somehow lost the motivation. > include/drm/drm_probe_helper.h| 27 +++ This on the other hand is fine - as expected as this is a new file. But the above is just some random comments so: Acked-by: Sam Ravnborg ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/7] drm/i915: handle interrupts from the OA unit
On 16/01/2019 16:31, Chris Wilson wrote:
Quoting Lionel Landwerlin (2019-01-16 16:25:26)
On 16/01/2019 16:05, Chris Wilson wrote:
Quoting Lionel Landwerlin (2019-01-16 15:58:00)
On 16/01/2019 15:52, Chris Wilson wrote:
Quoting Lionel Landwerlin (2019-01-16 15:36:20)
@@ -1877,6 +1883,21 @@ struct drm_i915_private {
wait_queue_head_t poll_wq;
bool pollin;
+ /**
+* Atomic counter incremented by the interrupt
+* handling code for each OA half full interrupt
+* received.
+*/
+ atomic64_t half_full_count;
+
+ /**
+* Copy of the atomic half_full_count that was last
+* processed in the i915-perf driver. If both counters
+* differ, there is data available to read in the OA
+* buffer.
+*/
+ u64 half_full_count_last;
Eh? But why a relatively expensive atomic64. You only need one bit, and
reading the tail pointer from WB memory should just be cheap. You should
be able to sample the perf ringbuffer pointers very cheaply... What am I
missing?
-Chris
Fair comment.
The thing is with this series there are 2 mechanism that notify the poll_wq.
One is the hrtimer that kicks in at regular interval and polls the
register with the workaround.
The other is the interrupt which doesn't read the registers and workaround.
What's the complication with the workaround?
It's a bit more than just looking at registers, we actually have to look
at the content of the buffer to figure out what landed in memory.
The register values are not synchronized with the memory writes...
I don't want to look at registers at all for polling, and you shouldn't
need to since communication is via a ringbuf.
There is a comment in the code (i915_perf_poll_locked) about not
checking the register after each wakeup because that may be a very hot path.
The atomic64 sounded like a lesser evil.
I'm clearly not understanding something here...
Does the hardware not do:
update ringbuf data;
wmb() (or post to global observation point in their parlance)
update ringbuf tail
As far as I understand, the OA unit :
sends its memory write requests to the memory controller
immediately updates the ringbuf tail, without waiting for the
previous requests to complete
Then we just need to sample the ringbuf tail and compare against how far
we read last time?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/13] drm/i915: Move LUT programming to happen after vblank waits
On Wed, Jan 16, 2019 at 09:38:59AM -0800, Matt Roper wrote:
> On Fri, Jan 11, 2019 at 07:08:17PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > The LUTs are single buffered so we should program them after
> > the double buffered pipe updates have been latched by the
> > hardware.
> >
> > We'll also fix up the IPS vs. split gamma w/a to do the IPS
> > disable like everyone else. Note that this is currently dead
> > code as we don't use the split gamma mode on HSW, but that
> > will be fixed up shortly.
>
> I don't think this is quite dead code...we don't use split gamma
> ourselves, but we could potentially inherit that setup from the BIOS
> (which will stick around until it eventually gets clobbered by the first
> modeset/fastset).
>
> Uma's series added some logic to sanitize the LUT's immediately on boot,
> but that hasn't landed yet.
>
>
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_color.c | 25 +--
> > drivers/gpu/drm/i915/intel_display.c | 47
> > 2 files changed, 42 insertions(+), 30 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_color.c
> > b/drivers/gpu/drm/i915/intel_color.c
> > index f9e0855162f3..0c0da7ed0fd7 100644
> > --- a/drivers/gpu/drm/i915/intel_color.c
> > +++ b/drivers/gpu/drm/i915/intel_color.c
> > @@ -361,29 +361,6 @@ static void hsw_color_commit(const struct
> > intel_crtc_state *crtc_state)
> > ilk_load_csc_matrix(crtc_state);
> > }
> >
> > -/* Loads the legacy palette/gamma unit for the CRTC on Haswell. */
> > -static void haswell_load_luts(const struct intel_crtc_state *crtc_state)
> > -{
> > - struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> > - struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > - bool reenable_ips = false;
> > -
> > - /*
> > -* Workaround : Do not read or write the pipe palette/gamma data while
> > -* GAMMA_MODE is configured for split gamma and IPS_CTL has IPS enabled.
> > -*/
> > - if (IS_HASWELL(dev_priv) && crtc_state->ips_enabled &&
> > - (crtc_state->gamma_mode == GAMMA_MODE_MODE_SPLIT)) {
> > - hsw_disable_ips(crtc_state);
> > - reenable_ips = true;
> > - }
> > -
> > - i9xx_load_luts(crtc_state);
> > -
> > - if (reenable_ips)
> > - hsw_enable_ips(crtc_state);
> > -}
> > -
> > static void bdw_load_degamma_lut(const struct intel_crtc_state *crtc_state)
> > {
> > struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> > @@ -660,7 +637,7 @@ void intel_color_init(struct intel_crtc *crtc)
> > if (IS_CHERRYVIEW(dev_priv)) {
> > dev_priv->display.load_luts = cherryview_load_luts;
> > } else if (IS_HASWELL(dev_priv)) {
> > - dev_priv->display.load_luts = haswell_load_luts;
> > + dev_priv->display.load_luts = i9xx_load_luts;
> > dev_priv->display.color_commit = hsw_color_commit;
> > } else if (IS_BROADWELL(dev_priv) || IS_GEN9_BC(dev_priv) ||
> >IS_BROXTON(dev_priv)) {
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 96c78566b8e6..1caee4128974 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -5299,24 +5299,54 @@ intel_pre_disable_primary_noatomic(struct drm_crtc
> > *crtc)
> > static bool hsw_pre_update_disable_ips(const struct intel_crtc_state
> > *old_crtc_state,
> >const struct intel_crtc_state
> > *new_crtc_state)
> > {
> > + struct intel_crtc *crtc = to_intel_crtc(new_crtc_state->base.crtc);
> > + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > +
> > if (!old_crtc_state->ips_enabled)
> > return false;
> >
> > if (needs_modeset(_crtc_state->base))
> > return true;
> >
> > + /*
> > +* Workaround : Do not read or write the pipe palette/gamma data while
> > +* GAMMA_MODE is configured for split gamma and IPS_CTL has IPS enabled.
> > +*
> > +* Disable IPS before we program the LUT.
> > +*/
> > + if (IS_HASWELL(dev_priv) &&
> > + (new_crtc_state->base.color_mgmt_changed ||
> > +new_crtc_state->update_pipe) &&
> > + new_crtc_state->gamma_mode == GAMMA_MODE_MODE_SPLIT)
>
> Wouldn't we want old_crtc_state for the gamma_mode test? We need to
> disable IPS if we're already in split gamma mode (inherited from BIOS),
> regardless of whether we're moving to non-split gamma.
We're going to update the gamma mode before programming the LUT.
But I think I'll probably change this to disable IPS around all LUT
updates to prevent IPS from using the old LUT during the vblank. That's
assuming IPS does actually prefill during vblank (which would make sense
to me).
>
>
> Matt
>
> > + return true;
> > +
> > return !new_crtc_state->ips_enabled;
> > }
> >
> > static bool hsw_post_update_enable_ips(const
Re: [Intel-gfx] drm/i915: Watchdog timeout: IRQ handler for gen8+
On 16/01/19 09:42, Antonio Argenziano wrote: On 16/01/19 08:15, Tvrtko Ursulin wrote: On 11/01/2019 21:28, John Harrison wrote: On 1/11/2019 09:31, Antonio Argenziano wrote: On 11/01/19 00:22, Tvrtko Ursulin wrote: On 11/01/2019 00:47, Antonio Argenziano wrote: On 07/01/19 08:58, Tvrtko Ursulin wrote: On 07/01/2019 13:57, Chris Wilson wrote: Quoting Tvrtko Ursulin (2019-01-07 13:43:29) On 07/01/2019 11:58, Tvrtko Ursulin wrote: [snip] Note about future interaction with preemption: Preemption could happen in a command sequence prior to watchdog counter getting disabled, resulting in watchdog being triggered following preemption (e.g. when watchdog had been enabled in the low priority batch). The driver will need to explicitly disable the watchdog counter as part of the preemption sequence. Does the series take care of preemption? I did not find that it does. Oh. I hoped that the watchdog was saved as part of the context... Then despite preemption, the timeout would resume from where we left off as soon as it was back on the gpu. If the timeout remaining was context saved it would be much simpler (at least on first glance), please say it is. I made my comments going only by the text from the commit message and the absence of any preemption special handling. Having read the spec, the situation seems like this: * Watchdog control and threshold register are context saved and restored. * On a context switch watchdog counter is reset to zero and automatically disabled until enabled by a context restore or explicitly. So it sounds the commit message could be wrong that special handling is needed from this direction. But read till the end on the restriction listed. * Watchdog counter is reset to zero and is not accumulated across multiple submission of the same context (due preemption). I read this as - after preemption contexts gets a new full timeout allocation. Or in other words, if a context is preempted N times, it's cumulative watchdog timeout will be N * set value. This could be theoretically exploitable to bypass the timeout. If a client sets up two contexts with prio -1 and -2, and keeps submitting periodical no-op batches against prio -1 context, while prio -2 is it's own hog, then prio -2 context defeats the watchdog timer. I think.. would appreciate is someone challenged this conclusion. I think you are right that is a possibility but, is that a problem? The client can just not set the threshold to bypass the timeout. Also because you need the hanging batch to be simply preemptible, you cannot disrupt any work from another client that is higher priority. This is But I think higher priority client can have the same effect on the lower priority purely by accident, no? As a real world example, user kicks off an background transcoding job, which happens to use prio -2, and uses the watchdog timer. At the same time user watches a video from a player of normal priority. This causes periodic, say 24Hz, preemption events, due frame decoding activity on the same engine as the transcoding client. Does this defeat the watchdog timer for the former is the question? Then the questions of can we do something about it and whether it really isn't a problem? I guess it depends if you consider that timeout as the maximum lifespan a workload can have or max contiguous active time. I believe the intended purpose of the watchdog is to prevent broken bitstreams hanging the transcoder/player. That is, it is a form of error detection used by the media driver to handle bad user input. So if there is a way for the watchdog to be extended indefinitely under normal situations, that would be a problem. It means the transcoder will not detect the broken input data in a timely manner and effectively hang rather than skip over to the next packet. And note that broken input data can be caused by something as innocent as a dropped packet due to high network contention. No need for any malicious activity at all. My understanding of the intended purpose is the same. And it would be a very useful feature. I'm not familiar enough with the application but, in the scenario above, what if the batch that is being preempted is not stuck but just nice enough to be preempted enough times so that it wouldn't complete in the given wall clock time but would be fast enough by itself. Ignore me, re-reading this I now get you are trying to advocate for an active-time timeout not pure wall clock time. Chris mentioned the other day that until hardware is fixed to context save/restore the watchdog counter this could simply be implemented using timers. And I have to say I agree. Shouldn't be too hard to prototype it using hrtimers - start on context in, stop on context out and kick forward on user interrupts. More or less. Would this implement the feature on the driver side just like it would for the HW? I mean have the same
[Intel-gfx] Timing issues between ALSA and i915 drivers
Hi,
I could use some feedback on HDMI audio issues exposed during the 4.21
merge window. By accident (misleading documentation) we ended up
enabling the Skylake driver instead of the HDaudio legacy, and broke
audio on a number of Skylake and ApolloLake devices where the HDMI/iDISP
codec was not detected (bit 2 not set in the codec_mask). Linus' Dell
XPS13 9350 was the first to be impacted of course...
After debugging a bit, this issue can be resolved by either
a) compiling both SOUND and DRM as built-ins (y instead of m)
b) moving the calls snd_hdac_i915_init() to the probe function instead
of the worker queue (code at
https://github.com/plbossart/sound/commits/fix/skl-hdmi)
Both solutions point to timing issues.
During internal reviews I was alerted to the fact that the suggested fix
essentially reverts patch ab1b732d53c18 ('ASoC: Intel: Skylake: Move
i915 registration to worker thread') which was introduced to solve DRM
lockup issues.
In other words, we are at a point where we either have DRM lockups or
can't detect the HDMI audio codec, none of which are too good.
I don't have the background for the DRM lockup stuff, nor do I
understand why snd_hdac_i915_init has to be called from a thread
context. Is this really a requirement?
I also don't get what sort of timing issues would come from an
initialization. What happens on the i915 side and is there some sort of
mandatory delay between the completion of the i915_init and issuing a
snd_hdac_chip_readw(bus, STATESTS) to get the codec masks on the HDaudio
links?
Thanks for any pointers or comments.
-Pierre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915: Watchdog timeout: IRQ handler for gen8+
On 16/01/19 08:15, Tvrtko Ursulin wrote: On 11/01/2019 21:28, John Harrison wrote: On 1/11/2019 09:31, Antonio Argenziano wrote: On 11/01/19 00:22, Tvrtko Ursulin wrote: On 11/01/2019 00:47, Antonio Argenziano wrote: On 07/01/19 08:58, Tvrtko Ursulin wrote: On 07/01/2019 13:57, Chris Wilson wrote: Quoting Tvrtko Ursulin (2019-01-07 13:43:29) On 07/01/2019 11:58, Tvrtko Ursulin wrote: [snip] Note about future interaction with preemption: Preemption could happen in a command sequence prior to watchdog counter getting disabled, resulting in watchdog being triggered following preemption (e.g. when watchdog had been enabled in the low priority batch). The driver will need to explicitly disable the watchdog counter as part of the preemption sequence. Does the series take care of preemption? I did not find that it does. Oh. I hoped that the watchdog was saved as part of the context... Then despite preemption, the timeout would resume from where we left off as soon as it was back on the gpu. If the timeout remaining was context saved it would be much simpler (at least on first glance), please say it is. I made my comments going only by the text from the commit message and the absence of any preemption special handling. Having read the spec, the situation seems like this: * Watchdog control and threshold register are context saved and restored. * On a context switch watchdog counter is reset to zero and automatically disabled until enabled by a context restore or explicitly. So it sounds the commit message could be wrong that special handling is needed from this direction. But read till the end on the restriction listed. * Watchdog counter is reset to zero and is not accumulated across multiple submission of the same context (due preemption). I read this as - after preemption contexts gets a new full timeout allocation. Or in other words, if a context is preempted N times, it's cumulative watchdog timeout will be N * set value. This could be theoretically exploitable to bypass the timeout. If a client sets up two contexts with prio -1 and -2, and keeps submitting periodical no-op batches against prio -1 context, while prio -2 is it's own hog, then prio -2 context defeats the watchdog timer. I think.. would appreciate is someone challenged this conclusion. I think you are right that is a possibility but, is that a problem? The client can just not set the threshold to bypass the timeout. Also because you need the hanging batch to be simply preemptible, you cannot disrupt any work from another client that is higher priority. This is But I think higher priority client can have the same effect on the lower priority purely by accident, no? As a real world example, user kicks off an background transcoding job, which happens to use prio -2, and uses the watchdog timer. At the same time user watches a video from a player of normal priority. This causes periodic, say 24Hz, preemption events, due frame decoding activity on the same engine as the transcoding client. Does this defeat the watchdog timer for the former is the question? Then the questions of can we do something about it and whether it really isn't a problem? I guess it depends if you consider that timeout as the maximum lifespan a workload can have or max contiguous active time. I believe the intended purpose of the watchdog is to prevent broken bitstreams hanging the transcoder/player. That is, it is a form of error detection used by the media driver to handle bad user input. So if there is a way for the watchdog to be extended indefinitely under normal situations, that would be a problem. It means the transcoder will not detect the broken input data in a timely manner and effectively hang rather than skip over to the next packet. And note that broken input data can be caused by something as innocent as a dropped packet due to high network contention. No need for any malicious activity at all. My understanding of the intended purpose is the same. And it would be a very useful feature. I'm not familiar enough with the application but, in the scenario above, what if the batch that is being preempted is not stuck but just nice enough to be preempted enough times so that it wouldn't complete in the given wall clock time but would be fast enough by itself. Chris mentioned the other day that until hardware is fixed to context save/restore the watchdog counter this could simply be implemented using timers. And I have to say I agree. Shouldn't be too hard to prototype it using hrtimers - start on context in, stop on context out and kick forward on user interrupts. More or less. Would this implement the feature on the driver side just like it would for the HW? I mean have the same IOCTL and silently discard workload that hit the timeout. Also, would it discard batches while they are in the queue (not active)? Antonio Then if the cost of
Re: [Intel-gfx] [PATCH 07/13] drm/i915: Move LUT programming to happen after vblank waits
On Fri, Jan 11, 2019 at 07:08:17PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The LUTs are single buffered so we should program them after
> the double buffered pipe updates have been latched by the
> hardware.
>
> We'll also fix up the IPS vs. split gamma w/a to do the IPS
> disable like everyone else. Note that this is currently dead
> code as we don't use the split gamma mode on HSW, but that
> will be fixed up shortly.
I don't think this is quite dead code...we don't use split gamma
ourselves, but we could potentially inherit that setup from the BIOS
(which will stick around until it eventually gets clobbered by the first
modeset/fastset).
Uma's series added some logic to sanitize the LUT's immediately on boot,
but that hasn't landed yet.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_color.c | 25 +--
> drivers/gpu/drm/i915/intel_display.c | 47
> 2 files changed, 42 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_color.c
> b/drivers/gpu/drm/i915/intel_color.c
> index f9e0855162f3..0c0da7ed0fd7 100644
> --- a/drivers/gpu/drm/i915/intel_color.c
> +++ b/drivers/gpu/drm/i915/intel_color.c
> @@ -361,29 +361,6 @@ static void hsw_color_commit(const struct
> intel_crtc_state *crtc_state)
> ilk_load_csc_matrix(crtc_state);
> }
>
> -/* Loads the legacy palette/gamma unit for the CRTC on Haswell. */
> -static void haswell_load_luts(const struct intel_crtc_state *crtc_state)
> -{
> - struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> - struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> - bool reenable_ips = false;
> -
> - /*
> - * Workaround : Do not read or write the pipe palette/gamma data while
> - * GAMMA_MODE is configured for split gamma and IPS_CTL has IPS enabled.
> - */
> - if (IS_HASWELL(dev_priv) && crtc_state->ips_enabled &&
> - (crtc_state->gamma_mode == GAMMA_MODE_MODE_SPLIT)) {
> - hsw_disable_ips(crtc_state);
> - reenable_ips = true;
> - }
> -
> - i9xx_load_luts(crtc_state);
> -
> - if (reenable_ips)
> - hsw_enable_ips(crtc_state);
> -}
> -
> static void bdw_load_degamma_lut(const struct intel_crtc_state *crtc_state)
> {
> struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> @@ -660,7 +637,7 @@ void intel_color_init(struct intel_crtc *crtc)
> if (IS_CHERRYVIEW(dev_priv)) {
> dev_priv->display.load_luts = cherryview_load_luts;
> } else if (IS_HASWELL(dev_priv)) {
> - dev_priv->display.load_luts = haswell_load_luts;
> + dev_priv->display.load_luts = i9xx_load_luts;
> dev_priv->display.color_commit = hsw_color_commit;
> } else if (IS_BROADWELL(dev_priv) || IS_GEN9_BC(dev_priv) ||
> IS_BROXTON(dev_priv)) {
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 96c78566b8e6..1caee4128974 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5299,24 +5299,54 @@ intel_pre_disable_primary_noatomic(struct drm_crtc
> *crtc)
> static bool hsw_pre_update_disable_ips(const struct intel_crtc_state
> *old_crtc_state,
> const struct intel_crtc_state
> *new_crtc_state)
> {
> + struct intel_crtc *crtc = to_intel_crtc(new_crtc_state->base.crtc);
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> +
> if (!old_crtc_state->ips_enabled)
> return false;
>
> if (needs_modeset(_crtc_state->base))
> return true;
>
> + /*
> + * Workaround : Do not read or write the pipe palette/gamma data while
> + * GAMMA_MODE is configured for split gamma and IPS_CTL has IPS enabled.
> + *
> + * Disable IPS before we program the LUT.
> + */
> + if (IS_HASWELL(dev_priv) &&
> + (new_crtc_state->base.color_mgmt_changed ||
> + new_crtc_state->update_pipe) &&
> + new_crtc_state->gamma_mode == GAMMA_MODE_MODE_SPLIT)
Wouldn't we want old_crtc_state for the gamma_mode test? We need to
disable IPS if we're already in split gamma mode (inherited from BIOS),
regardless of whether we're moving to non-split gamma.
Matt
> + return true;
> +
> return !new_crtc_state->ips_enabled;
> }
>
> static bool hsw_post_update_enable_ips(const struct intel_crtc_state
> *old_crtc_state,
> const struct intel_crtc_state
> *new_crtc_state)
> {
> + struct intel_crtc *crtc = to_intel_crtc(new_crtc_state->base.crtc);
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> +
> if (!new_crtc_state->ips_enabled)
> return false;
>
> if (needs_modeset(_crtc_state->base))
> return true;
>
> + /*
> + * Workaround : Do not read or write the
Re: [Intel-gfx] [PATCH 05/13] drm/i915: Pull GAMMA_MODE write out from haswell_load_luts()
>-Original Message-
>From: Roper, Matthew D
>Sent: Saturday, January 12, 2019 6:27 AM
>To: Ville Syrjala
>Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma
>Subject: Re: [PATCH 05/13] drm/i915: Pull GAMMA_MODE write out from
>haswell_load_luts()
>
>On Fri, Jan 11, 2019 at 07:08:15PM +0200, Ville Syrjala wrote:
>> From: Ville Syrjälä
>>
>> For bdw+ let's move the GAMMA_MODE write for the legacy LUT mode into
>> the .load_luts() funciton directly, rather than relying on
>> haswell_load_luts(). We'll be getting rid of
>> haswell_load_luts() entirely soon, and it's anyway cleaner to have the
>> GAMMA_MODE write in a single place.
>>
>> Signed-off-by: Ville Syrjälä
>
>Reviewed-by: Matt Roper
Looks ok to me.
Reviewed-by: Uma Shankar
>> ---
>> drivers/gpu/drm/i915/intel_color.c | 36
>> +-
>> 1 file changed, 20 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_color.c
>> b/drivers/gpu/drm/i915/intel_color.c
>> index 0dfd104b89d7..df3567686c45 100644
>> --- a/drivers/gpu/drm/i915/intel_color.c
>> +++ b/drivers/gpu/drm/i915/intel_color.c
>> @@ -473,21 +473,20 @@ static void broadwell_load_luts(const struct
>intel_crtc_state *crtc_state)
>> enum pipe pipe = crtc->pipe;
>>
>> if (crtc_state_is_legacy_gamma(crtc_state)) {
>> -haswell_load_luts(crtc_state);
>> -return;
>> -}
>> +i9xx_load_luts(crtc_state);
>> +} else {
>> +bdw_load_degamma_lut(crtc_state);
>> +bdw_load_gamma_lut(crtc_state,
>> + INTEL_INFO(dev_priv)-
>>color.degamma_lut_size);
>>
>> -bdw_load_degamma_lut(crtc_state);
>> -bdw_load_gamma_lut(crtc_state,
>> - INTEL_INFO(dev_priv)->color.degamma_lut_size);
>> +/*
>> + * Reset the index, otherwise it prevents the legacy palette to
>> be
>> + * written properly.
>> + */
>> +I915_WRITE(PREC_PAL_INDEX(pipe), 0);
>> +}
>>
>> I915_WRITE(GAMMA_MODE(pipe), crtc_state->gamma_mode);
>> -
>> -/*
>> - * Reset the index, otherwise it prevents the legacy palette to be
>> - * written properly.
>> - */
>> -I915_WRITE(PREC_PAL_INDEX(pipe), 0);
>> }
>>
>> static void glk_load_degamma_lut(const struct intel_crtc_state
>> *crtc_state) @@ -530,11 +529,16 @@ static void glk_load_luts(const struct
>intel_crtc_state *crtc_state)
>> glk_load_degamma_lut(crtc_state);
>>
>> if (crtc_state_is_legacy_gamma(crtc_state)) {
>> -haswell_load_luts(crtc_state);
>> -return;
>> -}
>> +i9xx_load_luts(crtc_state);
>> +} else {
>> +bdw_load_gamma_lut(crtc_state, 0);
>>
>> -bdw_load_gamma_lut(crtc_state, 0);
>> +/*
>> + * Reset the index, otherwise it prevents the legacy palette to
>> be
>> + * written properly.
>> + */
>> +I915_WRITE(PREC_PAL_INDEX(pipe), 0);
>> +}
>>
>> I915_WRITE(GAMMA_MODE(pipe), crtc_state->gamma_mode); }
>> --
>> 2.19.2
>>
>
>--
>Matt Roper
>Graphics Software Engineer
>IoTG Platform Enabling & Development
>Intel Corporation
>(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/13] drm/i915: Constify the state arguments to the color management stuff
>-Original Message-
>From: Roper, Matthew D
>Sent: Saturday, January 12, 2019 6:12 AM
>To: Ville Syrjala
>Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma
>Subject: Re: [PATCH 04/13] drm/i915: Constify the state arguments to the color
>management stuff
>
>On Fri, Jan 11, 2019 at 07:08:14PM +0200, Ville Syrjala wrote:
>> From: Ville Syrjälä
>>
>> Pass the crtc state etc. as const to the color management commit
>> functions. And while at it polish some of the local variables.
>>
>> Signed-off-by: Ville Syrjälä
>
>Reviewed-by: Matt Roper
Looks ok to me.
Reviewed-by: Uma Shankar
>> ---
>> drivers/gpu/drm/i915/i915_drv.h| 4 +-
>> drivers/gpu/drm/i915/intel_color.c | 128 -
>> drivers/gpu/drm/i915/intel_drv.h | 4 +-
>> 3 files changed, 73 insertions(+), 63 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h
>> b/drivers/gpu/drm/i915/i915_drv.h index 5df26ccda8a4..7182a580002c
>> 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -320,8 +320,8 @@ struct drm_i915_display_funcs {
>> /* display clock increase/decrease */
>> /* pll clock increase/decrease */
>>
>> -void (*load_csc_matrix)(struct intel_crtc_state *crtc_state);
>> -void (*load_luts)(struct intel_crtc_state *crtc_state);
>> +void (*load_csc_matrix)(const struct intel_crtc_state *crtc_state);
>> +void (*load_luts)(const struct intel_crtc_state *crtc_state);
>> };
>>
>> #define CSR_VERSION(major, minor) ((major) << 16 | (minor))
>> diff --git a/drivers/gpu/drm/i915/intel_color.c
>> b/drivers/gpu/drm/i915/intel_color.c
>> index b10e66ce3970..0dfd104b89d7 100644
>> --- a/drivers/gpu/drm/i915/intel_color.c
>> +++ b/drivers/gpu/drm/i915/intel_color.c
>> @@ -74,12 +74,12 @@
>> #define ILK_CSC_COEFF_1_0 \
>> ((7 << 12) | ILK_CSC_COEFF_FP(CTM_COEFF_1_0, 8))
>>
>> -static bool lut_is_legacy(struct drm_property_blob *lut)
>> +static bool lut_is_legacy(const struct drm_property_blob *lut)
>> {
>> return drm_color_lut_size(lut) == LEGACY_LUT_LENGTH; }
>>
>> -static bool crtc_state_is_legacy_gamma(struct intel_crtc_state
>> *crtc_state)
>> +static bool crtc_state_is_legacy_gamma(const struct intel_crtc_state
>> +*crtc_state)
>> {
>> return !crtc_state->base.degamma_lut &&
>> !crtc_state->base.ctm &&
>> @@ -115,8 +115,8 @@ static u64 *ctm_mult_by_limited(u64 *result, const
>> u64 *input)
>>
>> static void ilk_load_ycbcr_conversion_matrix(struct intel_crtc *crtc)
>> {
>> -int pipe = crtc->pipe;
>> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>> +enum pipe pipe = crtc->pipe;
>>
>> I915_WRITE(PIPE_CSC_PREOFF_HI(pipe), 0);
>> I915_WRITE(PIPE_CSC_PREOFF_ME(pipe), 0); @@ -137,13 +137,14 @@
>> static void ilk_load_ycbcr_conversion_matrix(struct intel_crtc *crtc)
>> I915_WRITE(PIPE_CSC_MODE(pipe), 0);
>> }
>>
>> -static void ilk_load_csc_matrix(struct intel_crtc_state *crtc_state)
>> +static void ilk_load_csc_matrix(const struct intel_crtc_state
>> +*crtc_state)
>> {
>> struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
>> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>> -int i, pipe = crtc->pipe;
>> -uint16_t coeffs[9] = { 0, };
>> bool limited_color_range = false;
>> +enum pipe pipe = crtc->pipe;
>> +u16 coeffs[9] = {};
>> +int i;
>>
>> /*
>> * FIXME if there's a gamma LUT after the CSC, we should @@ -256,15
>> +257,15 @@ static void ilk_load_csc_matrix(struct intel_crtc_state
>> *crtc_state)
>> /*
>> * Set up the pipe CSC unit on CherryView.
>> */
>> -static void cherryview_load_csc_matrix(struct intel_crtc_state
>> *crtc_state)
>> +static void cherryview_load_csc_matrix(const struct intel_crtc_state
>> +*crtc_state)
>> {
>> -struct drm_device *dev = crtc_state->base.crtc->dev;
>> -struct drm_i915_private *dev_priv = to_i915(dev);
>> -int pipe = to_intel_crtc(crtc_state->base.crtc)->pipe;
>> +struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
>> +struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>> +enum pipe pipe = crtc->pipe;
>> uint32_t mode;
>>
>> if (crtc_state->base.ctm) {
>> -struct drm_color_ctm *ctm = crtc_state->base.ctm->data;
>> +const struct drm_color_ctm *ctm = crtc_state->base.ctm->data;
>> uint16_t coeffs[9] = { 0, };
>> int i;
>>
>> @@ -303,18 +304,17 @@ static void cherryview_load_csc_matrix(struct
>intel_crtc_state *crtc_state)
>> I915_WRITE(CGM_PIPE_MODE(pipe), mode); }
>>
>> -void intel_color_set_csc(struct intel_crtc_state *crtc_state)
>> +void intel_color_set_csc(const struct intel_crtc_state *crtc_state)
>> {
>> -struct drm_device *dev = crtc_state->base.crtc->dev;
>> -struct drm_i915_private *dev_priv = to_i915(dev);
>> +struct drm_i915_private *dev_priv =
>> +to_i915(crtc_state->base.crtc->dev);
>>
>> if
Re: [Intel-gfx] [PATCH 03/13] drm/i915: Precompute gamma_mode
>-Original Message-
>From: Roper, Matthew D
>Sent: Saturday, January 12, 2019 6:12 AM
>To: Ville Syrjala
>Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma
>Subject: Re: [PATCH 03/13] drm/i915: Precompute gamma_mode
>
>On Fri, Jan 11, 2019 at 07:08:13PM +0200, Ville Syrjala wrote:
>> From: Ville Syrjälä
>>
>> We shouldn't be computing gamma mode during the commit phase.
>> Move it to the check phase.
>>
>> Signed-off-by: Ville Syrjälä
>
>Looks like this also drops the posting reads, but I don't see anything in the
>bspec
>that indicates those were necessary in the first place.
>
>> ---
>> drivers/gpu/drm/i915/intel_color.c | 44
>> +-
>> 1 file changed, 25 insertions(+), 19 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_color.c
>> b/drivers/gpu/drm/i915/intel_color.c
>> index 37fd9ddf762e..b10e66ce3970 100644
>> --- a/drivers/gpu/drm/i915/intel_color.c
>> +++ b/drivers/gpu/drm/i915/intel_color.c
>> @@ -375,8 +375,7 @@ static void haswell_load_luts(struct intel_crtc_state
>*crtc_state)
>> reenable_ips = true;
>> }
>>
>> -crtc_state->gamma_mode = GAMMA_MODE_MODE_8BIT;
>> -I915_WRITE(GAMMA_MODE(crtc->pipe), GAMMA_MODE_MODE_8BIT);
>> +I915_WRITE(GAMMA_MODE(crtc->pipe), crtc_state->gamma_mode);
>>
>> i9xx_load_luts(crtc_state);
>>
>> @@ -476,9 +475,7 @@ static void broadwell_load_luts(struct intel_crtc_state
>*crtc_state)
>> bdw_load_gamma_lut(crtc_state,
>> INTEL_INFO(dev_priv)->color.degamma_lut_size);
>>
>> -crtc_state->gamma_mode = GAMMA_MODE_MODE_SPLIT;
>> -I915_WRITE(GAMMA_MODE(pipe), GAMMA_MODE_MODE_SPLIT);
>> -POSTING_READ(GAMMA_MODE(pipe));
>> +I915_WRITE(GAMMA_MODE(pipe), crtc_state->gamma_mode);
>>
>> /*
>> * Reset the index, otherwise it prevents the legacy palette to be
>> @@ -532,9 +529,7 @@ static void glk_load_luts(struct intel_crtc_state
>> *crtc_state)
>>
>> bdw_load_gamma_lut(crtc_state, 0);
>>
>> -crtc_state->gamma_mode = GAMMA_MODE_MODE_10BIT;
>> -I915_WRITE(GAMMA_MODE(pipe), GAMMA_MODE_MODE_10BIT);
>> -POSTING_READ(GAMMA_MODE(pipe));
>> +I915_WRITE(GAMMA_MODE(pipe), crtc_state->gamma_mode);
>> }
>>
>> /* Loads the palette/gamma unit for the CRTC on CherryView. */ @@
>> -608,29 +603,40 @@ void intel_color_load_luts(struct intel_crtc_state
>> *crtc_state) int intel_color_check(struct intel_crtc_state
>> *crtc_state) {
>> struct drm_i915_private *dev_priv =
>> to_i915(crtc_state->base.crtc->dev);
>> +const struct drm_property_blob *gamma_lut = crtc_state-
>>base.gamma_lut;
>> +const struct drm_property_blob *degamma_lut =
>> +crtc_state->base.degamma_lut;
>> size_t gamma_length, degamma_length;
>>
>> degamma_length = INTEL_INFO(dev_priv)->color.degamma_lut_size;
>> gamma_length = INTEL_INFO(dev_priv)->color.gamma_lut_size;
>>
>> /*
>> - * We allow both degamma & gamma luts at the right size or
>> - * NULL.
>> + * We also allow no degamma lut/ctm and a gamma lut at the legacy
>> + * size (256 entries).
>> */
>
>Minor nit: now that the order of tests is swapped, you probably want to move
>the "also" from this comment down to the one below.
>
>Otherwise,
>
>Reviewed-by: Matt Roper
Looks ok to me as well.
Reviewed-by: Uma Shankar
>
>> -if ((!crtc_state->base.degamma_lut ||
>> - drm_color_lut_size(crtc_state->base.degamma_lut) ==
>degamma_length) &&
>> -(!crtc_state->base.gamma_lut ||
>> - drm_color_lut_size(crtc_state->base.gamma_lut) == gamma_length))
>> +if (crtc_state_is_legacy_gamma(crtc_state)) {
>> +crtc_state->gamma_mode = GAMMA_MODE_MODE_8BIT;
>> return 0;
>> +}
>>
>> /*
>> - * We also allow no degamma lut/ctm and a gamma lut at the legacy
>> - * size (256 entries).
>> + * We allow both degamma & gamma luts at the right size or
>> + * NULL.
>> */
>> -if (crtc_state_is_legacy_gamma(crtc_state))
>> -return 0;
>> +if (degamma_lut && drm_color_lut_size(degamma_lut) !=
>degamma_length)
>> +return -EINVAL;
>> +
>> +if (gamma_lut && drm_color_lut_size(gamma_lut) != gamma_length)
>> +return -EINVAL;
>> +
>> +if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
>> +crtc_state->gamma_mode = GAMMA_MODE_MODE_10BIT;
>> +else if (INTEL_GEN(dev_priv) >= 9 || IS_BROADWELL(dev_priv))
>> +crtc_state->gamma_mode = GAMMA_MODE_MODE_SPLIT;
>> +else
>> +crtc_state->gamma_mode = GAMMA_MODE_MODE_8BIT;
>>
>> -return -EINVAL;
>> +return 0;
>> }
>>
>> void intel_color_init(struct intel_crtc *crtc)
>> --
>> 2.19.2
>>
>
>--
>Matt Roper
>Graphics Software Engineer
>IoTG Platform Enabling & Development
>Intel Corporation
>(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/7] drm/i915/perf: reset pollin when perf stream is enabled
On Wed, 16 Jan 2019 at 15:36, Lionel Landwerlin
wrote:
>
> No issues have been raised about this yet, but this should be reset
> every time we enable the stream, otherwise we might have a stale value
> from the previous round of enable/disable.
>
> Signed-off-by: Lionel Landwerlin
> ---
> drivers/gpu/drm/i915/i915_perf.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_perf.c
> b/drivers/gpu/drm/i915/i915_perf.c
> index 575701e2aabc..4c5d2ee4d6e3 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -1876,6 +1876,8 @@ static void i915_oa_stream_enable(struct
> i915_perf_stream *stream)
> {
> struct drm_i915_private *dev_priv = stream->dev_priv;
>
> + dev_priv->perf.oa.pollin = false;
> +
> dev_priv->perf.oa.ops.oa_enable(stream);
Don't we fumigate oa.polling way down in ops.oa_enable() ?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/13] drm/i915: Split the gamma/csc enable bits from the plane_ctl() function
>-Original Message- >From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of >Ville Syrjälä >Sent: Tuesday, January 15, 2019 12:42 AM >To: Roper, Matthew D >Cc: intel-gfx@lists.freedesktop.org >Subject: Re: [Intel-gfx] [PATCH 02/13] drm/i915: Split the gamma/csc enable >bits >from the plane_ctl() function > >On Mon, Jan 14, 2019 at 07:11:10PM +0200, Ville Syrjälä wrote: >> On Fri, Jan 11, 2019 at 04:41:37PM -0800, Matt Roper wrote: >> > On Fri, Jan 11, 2019 at 07:08:12PM +0200, Ville Syrjala wrote: >> > > From: Ville Syrjälä >> > > >> > > On g4x+ the pipe gamma enable bit for the primary plane affects >> > > the pipe bottom color as well. The same for the pipe csc enable >> > > bit on ilk+. Thus we must configure those bits correctly even when >> > > the primary plane is disabled. >> > >> > This is only true for > > dedicated bits that control this, so I don't think the primay >> > plane's settings should have any impact when disabled. I.e., we >> > also need the bits set in this patch: >> > >> > https://patchwork.freedesktop.org/patch/271109/ >> >> Yes. I had the same bits (or something similar in a later patch in the >> series). But we should probably just land your stuff first. >> >> > >> > > To make the feasible let's split those settings from the >> > > plane_ctl() function into a seprate funciton that we can call from Typo here. >> > > the ->disable_plane() hook as well. >> > >> > Is calling it from ->disable_plane() enough? If we just disable the >> > primary plane, then those bits will remain set while the crtc >> > remains active. But if you then disable the whole crtc and >> > re-enable it again later, won't we have lost the bits at that point? Just curious, once crtc is re-enabled plane enable will eventually happen where this can again be enabled. So is this the corner case where crtc gets enabled and primary plane is not enabled and it works with just overlays ? If this is the case, why not just explicitly enable these separately in crtc enable sequence and not rely on primary plane enabling path to set this for us. What could be the potential problem if we do this ? >> >> Hmm. Yes, probably. >> >> Just adding a needs_modeset() check into >> intel_color_add_affected_planes() (introduced in a later patch) could >> be one way. But that means the plane control reg won't be updated >> before the pipe is already active. So we might need a special case for >> that too. >> >> That said, I kinda hate the pipe enable special cases for the color >> management stuff. So I'm wondering if we could eliminate it all and >> just rely on the normal pipe+plane update to do things correctly. But >> to make that consistent we might have to have another special case to >> disable gamma/etc. prior to enabling the pipe so that it can all be >> enabled atomically later. Hmm. I suppose that could be achieved by >> clearing all relevant control bits in disable_plane() (or in >> crtc_disable() for skl+) if the crtc is no longer active. >> >> And I guess we could still keep the .load_luts() special case since >> guaranteeing the atomicity for that isn't as easy. >> >> It would mean the pipe alwasy comes up with gamma and csc disabled. >> But since it's all some shade of black anyway I guess it shouldn't be >> a big deal. > >Bah. That won't actually work without more hacks for the case where the crtc >was enabled already. I guess I'll just have to stick an explicit primary- >>disable_plane() call into the crtc_enable() path :( >> >> > >> > >> > Matt >> > >> > > >> > > For consistency we'll do that on all the plane types. While that >> > > has no real benefits at this time, it'll become useful when we >> > > start to control the pipe gamma/csc enable bits dynamically when >> > > we overhaul the color management code. >> > > >> > > On pre-g4x there doesn't appear to be any way to gamma correct the >> > > pipe bottom color, but sticking to the same pattern doesn't hurt. >> > > And it'll still help us to do crtc state readout correctly for the >> > > pipe gamma enable bit for the color management overhaul. >> > > >> > > An alternative apporach would be to still precompute these bits Typo in approach. >> > > into plane_state->ctl, but that would require that we run through >> > > the plane check even when the plane isn't logically enabled on any >> > > crtc. Currently that condition causes us to short circuit the >> > > entire thing and not call ->check_plane(). >> > > There would also be some chicken and egg problems with >> > > ->check_plane() vs. crtc color state check that would >> > > requite splitting certain things into multiple steps. >> > > So all in all this seems like the easier route. >> > > >> > > Signed-off-by: Ville Syrjälä >> > > --- >> > > drivers/gpu/drm/i915/intel_display.c | 128 --- >> > > drivers/gpu/drm/i915/intel_drv.h | 3 +- >> > > drivers/gpu/drm/i915/intel_sprite.c | 54 --- >> > > 3 files changed, 139
Re: [Intel-gfx] [PATCH 00/17] drm/i915: switch to kernel fixed size types
On Wed, Jan 16, 2019 at 11:15:18AM +0200, Jani Nikula wrote: > Hi all - > > I haven't cared all that much about using C99 fixed size types (uint32_t > etc.) in the driver in addition to kernel types, as long as only one or > the other is used in the same struct/function/file. But the increasing > mixed use crossed some OCD threshold the other day. It gets ugly, and > sets a precedent that mixed use is fine. > > Let's switch to kernel types exclusively, shall we? > > Each path in the series is independent of the others, and it's mostly > one patch per file, apart from the first patch which gathers all the > isolated uses into one patch. I've tried to order the series from least > to most likely to cause conflicts with in-flight work per gut feeling. > > Please holler if you think some of these patches need to wait for some > other, more important stuff to land first. This was mostly scripted, > with a few manual edits on top, so pretty quick to redo on top later. > > After most of these have landed, I intend to drop PREFER_KERNEL_TYPES > from the checkpatch ignore list, and enforce. Did a really quick scan through and the pattern matcher in the brain didn't complain, so seems good enough to me. Reviewed-by: Ville Syrjälä > > BR, > Jani. > > > Jani Nikula (17): > drm/i915: small isolated c99 types to kernel types switch > drm/i915/crt: switch to kernel types > drm/i915/sdvo: switch to kernel types > drm/i915/lspcon: switch to kernel types > drm/i915/debugfs: switch to kernel types > drm/i915/irq: switch to kernel types > drm/i915/cdclk: switch to kernel types > drm/i915/dpll_mgr: switch to kernel types > drm/i915/dp: switch to kernel types > drm/i915/sprite: switch to kernel types > drm/i915/color: switch to kernel types > drm/i915/pm: switch to kernel types > drm/i915/ddi: switch to kernel types > drm/i915/csr: switch to kernel types > drm/i915/display: switch to kernel types > drm/i915/i915_drv.h: switch to kernel types > drm/i915/intel_drv.h: switch to kernel types > > drivers/gpu/drm/i915/i915_debugfs.c | 22 +- > drivers/gpu/drm/i915/i915_drv.h | 158 ++--- > drivers/gpu/drm/i915/i915_gem.c | 14 +- > drivers/gpu/drm/i915/i915_gem_fence_reg.c | 8 +- > drivers/gpu/drm/i915/i915_gpu_error.c | 10 +- > drivers/gpu/drm/i915/i915_irq.c | 82 +++ > drivers/gpu/drm/i915/i915_perf.c | 2 +- > drivers/gpu/drm/i915/i915_reg.h | 4 +- > drivers/gpu/drm/i915/intel_atomic.c | 4 +- > drivers/gpu/drm/i915/intel_atomic_plane.c | 4 +- > drivers/gpu/drm/i915/intel_cdclk.c| 40 ++-- > drivers/gpu/drm/i915/intel_color.c| 40 ++-- > drivers/gpu/drm/i915/intel_crt.c | 22 +- > drivers/gpu/drm/i915/intel_csr.c | 68 +++--- > drivers/gpu/drm/i915/intel_ddi.c | 52 ++--- > drivers/gpu/drm/i915/intel_display.c | 104 - > drivers/gpu/drm/i915/intel_dp.c | 142 ++-- > drivers/gpu/drm/i915/intel_dp_link_training.c | 32 +-- > drivers/gpu/drm/i915/intel_dp_mst.c | 2 +- > drivers/gpu/drm/i915/intel_dpio_phy.c | 18 +- > drivers/gpu/drm/i915/intel_dpll_mgr.c | 145 ++-- > drivers/gpu/drm/i915/intel_dpll_mgr.h | 53 +++-- > drivers/gpu/drm/i915/intel_drv.h | 94 > drivers/gpu/drm/i915/intel_engine_cs.c| 12 +- > drivers/gpu/drm/i915/intel_fbc.c | 2 +- > drivers/gpu/drm/i915/intel_fifo_underrun.c| 12 +- > drivers/gpu/drm/i915/intel_hdcp.c | 4 +- > drivers/gpu/drm/i915/intel_lrc.c | 2 +- > drivers/gpu/drm/i915/intel_lspcon.c | 20 +- > drivers/gpu/drm/i915/intel_pipe_crc.c | 18 +- > drivers/gpu/drm/i915/intel_pm.c | 213 +- > drivers/gpu/drm/i915/intel_psr.c | 6 +- > drivers/gpu/drm/i915/intel_ringbuffer.h | 2 +- > drivers/gpu/drm/i915/intel_runtime_pm.c | 20 +- > drivers/gpu/drm/i915/intel_sdvo.c | 78 +++ > drivers/gpu/drm/i915/intel_sprite.c | 60 ++--- > 36 files changed, 782 insertions(+), 787 deletions(-) > > -- > 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 14/17] drm/i915/csr: switch to kernel types
On Wed, Jan 16, 2019 at 11:15:32AM +0200, Jani Nikula wrote:
> Mixed C99 and kernel types use is getting ugly. Prefer kernel types.
>
> sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g'
>
> Minor checkpatch fixes sprinkled on top of the changed lines.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_csr.c | 68
> 1 file changed, 34 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_csr.c
> b/drivers/gpu/drm/i915/intel_csr.c
> index ea5fb64d33dd..2b25cccdae16 100644
> --- a/drivers/gpu/drm/i915/intel_csr.c
> +++ b/drivers/gpu/drm/i915/intel_csr.c
> @@ -70,50 +70,50 @@ MODULE_FIRMWARE(BXT_CSR_PATH);
>
> struct intel_css_header {
> /* 0x09 for DMC */
> - uint32_t module_type;
> + u32 module_type;
>
> /* Includes the DMC specific header in dwords */
> - uint32_t header_len;
> + u32 header_len;
>
> /* always value would be 0x1 */
> - uint32_t header_ver;
> + u32 header_ver;
>
> /* Not used */
> - uint32_t module_id;
> + u32 module_id;
>
> /* Not used */
> - uint32_t module_vendor;
> + u32 module_vendor;
>
> /* in MMDD format */
> - uint32_t date;
> + u32 date;
>
> /* Size in dwords (CSS_Headerlen + PackageHeaderLen + dmc FWsLen)/4 */
> - uint32_t size;
> + u32 size;
>
> /* Not used */
> - uint32_t key_size;
> + u32 key_size;
>
> /* Not used */
> - uint32_t modulus_size;
> + u32 modulus_size;
>
> /* Not used */
> - uint32_t exponent_size;
> + u32 exponent_size;
>
> /* Not used */
> - uint32_t reserved1[12];
> + u32 reserved1[12];
>
> /* Major Minor */
> - uint32_t version;
> + u32 version;
>
> /* Not used */
> - uint32_t reserved2[8];
> + u32 reserved2[8];
>
> /* Not used */
> - uint32_t kernel_header_info;
> + u32 kernel_header_info;
> } __packed;
>
> struct intel_fw_info {
> - uint16_t reserved1;
> + u16 reserved1;
>
> /* Stepping (A, B, C, ..., *). * is a wildcard */
> char stepping;
> @@ -121,8 +121,8 @@ struct intel_fw_info {
> /* Sub-stepping (0, 1, ..., *). * is a wildcard */
> char substepping;
>
> - uint32_t offset;
> - uint32_t reserved2;
> + u32 offset;
> + u32 reserved2;
> } __packed;
>
> struct intel_package_header {
> @@ -135,14 +135,14 @@ struct intel_package_header {
> unsigned char reserved[10];
>
> /* Number of valid entries in the FWInfo array below */
> - uint32_t num_entries;
> + u32 num_entries;
>
> struct intel_fw_info fw_info[20];
> } __packed;
>
> struct intel_dmc_header {
> /* always value would be 0x40403E3E */
> - uint32_t signature;
> + u32 signature;
>
> /* DMC binary header length */
> unsigned char header_len;
> @@ -151,30 +151,30 @@ struct intel_dmc_header {
> unsigned char header_ver;
>
> /* Reserved */
> - uint16_t dmcc_ver;
> + u16 dmcc_ver;
>
> /* Major, Minor */
> - uint32_tproject;
> + u32 project;
>
> /* Firmware program size (excluding header) in dwords */
> - uint32_tfw_size;
> + u32 fw_size;
Some odd looking tabs here.
--
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.SPARSE: warning for drm/i915: Pull all the reset functionality together into i915_reset.c
== Series Details == Series: drm/i915: Pull all the reset functionality together into i915_reset.c URL : https://patchwork.freedesktop.org/series/55308/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Pull all the reset functionality together into i915_reset.c -drivers/gpu/drm/i915/selftests/../i915_drv.h:3577:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3546:16: warning: expression using sizeof(void) +./include/uapi/linux/perf_event.h:147:56: warning: cast truncates bits from constant value (8000 becomes 0) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 32/46] drm/i915: Pull VM lists under the VM mutex.
Quoting Tvrtko Ursulin (2019-01-16 16:47:43)
>
> On 07/01/2019 11:54, Chris Wilson wrote:
> > @@ -1530,20 +1531,21 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void
> > *data,
> >
> > static void i915_gem_object_bump_inactive_ggtt(struct drm_i915_gem_object
> > *obj)
> > {
> > - struct drm_i915_private *i915;
> > + struct drm_i915_private *i915 = to_i915(obj->base.dev);
> > struct list_head *list;
> > struct i915_vma *vma;
> >
> > GEM_BUG_ON(!i915_gem_object_has_pinned_pages(obj));
> >
> > + mutex_lock(>ggtt.vm.mutex);
> > for_each_ggtt_vma(vma, obj) {
> > if (!drm_mm_node_allocated(>node))
> > continue;
> >
> > list_move_tail(>vm_link, >vm->bound_list);
> > }
> > + mutex_unlock(>ggtt.vm.mutex);
>
> This is now struct_mutex -> vm->mutex nesting, which we would preferably
> want to avoid? There only two callers for the function.
>
> It looks we could remove nesting from i915_gem_set_domain_ioctl by just
> moving the call to after mutex unlock.
>
> i915_gem_object_unpin_from_display_plane callers are not as easy so
> maybe at least do the one above?
unpin_from_display_plane is the goal here tbh.
> > - i915 = to_i915(obj->base.dev);
> > spin_lock(>mm.obj_lock);
> > list = obj->bind_count ? >mm.bound_list :
> > >mm.unbound_list;
> > list_move_tail(>mm.link, list);
> > diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c
> > b/drivers/gpu/drm/i915/i915_gem_evict.c
> > index a76f65fe86be..4a0c6830659d 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_evict.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_evict.c
> > @@ -433,6 +433,7 @@ int i915_gem_evict_vm(struct i915_address_space *vm)
> > }
> >
> > INIT_LIST_HEAD(_list);
> > + mutex_lock(>mutex);
> > list_for_each_entry(vma, >bound_list, vm_link) {
> > if (i915_vma_is_pinned(vma))
> > continue;
> > @@ -440,6 +441,7 @@ int i915_gem_evict_vm(struct i915_address_space *vm)
> > __i915_vma_pin(vma);
> > list_add(>evict_link, _list);
> > }
> > + mutex_unlock(>mutex);
>
> This is another nesting so I suppose you leave all this fun for later?
Yes, the intent was to put the locks in place (gradually) then peel back
struct_mutex (gradually).
> > @@ -689,8 +694,10 @@ i915_vma_remove(struct i915_vma *vma)
> >
> > vma->ops->clear_pages(vma);
> >
> > + mutex_lock(>vm->mutex);
> > drm_mm_remove_node(>node);
>
> This is by design also protected by the vm->mutex? But insertion is not
> AFAICT.
Not yet. Can you guess which bit proved tricky? ;) Getting the right
point to lock for execbuf, and eviction. At the same time over there is
the fuss with ww_mutex, as well as contexts et al, and it all gets
confusing quickly.
...(tries to remember why this patch is actually here; this set was
picked so that I could do obj->vma_list without struct_mutex (which
was used for timeline allocation) and I pulled in anything required to
resolve conflicts, but why this one)...
-Chris
___
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/i915: Pull all the reset functionality together into i915_reset.c
== Series Details ==
Series: drm/i915: Pull all the reset functionality together into i915_reset.c
URL : https://patchwork.freedesktop.org/series/55308/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
01c7b5cb9d1a drm/i915: Pull all the reset functionality together into
i915_reset.c
-:1090: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#1090:
new file mode 100644
-:1095: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier
tag in line 1
#1095: FILE: drivers/gpu/drm/i915/i915_reset.c:1:
+/*
-:1239: WARNING:TYPO_SPELLING: 'acknowledgement' may be misspelled - perhaps
'acknowledgment'?
#1239: FILE: drivers/gpu/drm/i915/i915_reset.c:145:
+ /* Assert reset for at least 20 usec, and wait for acknowledgement. */
-:1964: WARNING:MEMORY_BARRIER: memory barrier without comment
#1964: FILE: drivers/gpu/drm/i915/i915_reset.c:870:
+ smp_mb__before_atomic();
-:2263: WARNING:STATIC_CONST_CHAR_ARRAY: char * array declaration might be
better as static const
#2263: FILE: drivers/gpu/drm/i915/i915_reset.c:1169:
+ char *error_event[] = { I915_ERROR_UEVENT "=1", NULL };
-:2264: WARNING:STATIC_CONST_CHAR_ARRAY: char * array declaration might be
better as static const
#2264: FILE: drivers/gpu/drm/i915/i915_reset.c:1170:
+ char *reset_event[] = { I915_RESET_UEVENT "=1", NULL };
-:2265: WARNING:STATIC_CONST_CHAR_ARRAY: char * array declaration might be
better as static const
#2265: FILE: drivers/gpu/drm/i915/i915_reset.c:1171:
+ char *reset_done_event[] = { I915_ERROR_UEVENT "=0", NULL };
-:2490: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier
tag in line 1
#2490: FILE: drivers/gpu/drm/i915/i915_reset.h:1:
+/*
-:2540: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'W' - possible side-effects?
#2540: FILE: drivers/gpu/drm/i915/i915_reset.h:51:
+#define i915_wedge_on_timeout(W, DEV, TIMEOUT) \
+ for (__i915_init_wedge((W), (DEV), (TIMEOUT), __func__);\
+(W)->i915; \
+__i915_fini_wedge((W)))
total: 0 errors, 8 warnings, 1 checks, 3113 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 32/46] drm/i915: Pull VM lists under the VM mutex.
On 07/01/2019 11:54, Chris Wilson wrote:
A starting point to counter the pervasive struct_mutex. For the goal of
avoiding (or at least blocking under them!) global locks during user
request submission, a simple but important step is being able to manage
each clients GTT separately. For which, we want to replace using the
struct_mutex as the guard for all things GTT/VM and switch instead to a
specific mutex inside i915_address_space.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 14 --
drivers/gpu/drm/i915/i915_gem_evict.c | 2 ++
drivers/gpu/drm/i915/i915_gem_gtt.c | 15 +--
drivers/gpu/drm/i915/i915_gem_shrinker.c| 4
drivers/gpu/drm/i915/i915_gem_stolen.c | 2 ++
drivers/gpu/drm/i915/i915_vma.c | 11 +++
drivers/gpu/drm/i915/selftests/i915_gem_evict.c | 3 +++
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 3 +++
8 files changed, 46 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 6ed44aeee583..5141a8ba4836 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -246,18 +246,19 @@ int
i915_gem_get_aperture_ioctl(struct drm_device *dev, void *data,
struct drm_file *file)
{
- struct drm_i915_private *dev_priv = to_i915(dev);
- struct i915_ggtt *ggtt = _priv->ggtt;
+ struct i915_ggtt *ggtt = _i915(dev)->ggtt;
struct drm_i915_gem_get_aperture *args = data;
struct i915_vma *vma;
u64 pinned;
+ mutex_lock(>vm.mutex);
+
pinned = ggtt->vm.reserved;
- mutex_lock(>struct_mutex);
list_for_each_entry(vma, >vm.bound_list, vm_link)
if (i915_vma_is_pinned(vma))
pinned += vma->node.size;
- mutex_unlock(>struct_mutex);
+
+ mutex_unlock(>vm.mutex);
args->aper_size = ggtt->vm.total;
args->aper_available_size = args->aper_size - pinned;
@@ -1530,20 +1531,21 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void
*data,
static void i915_gem_object_bump_inactive_ggtt(struct drm_i915_gem_object *obj)
{
- struct drm_i915_private *i915;
+ struct drm_i915_private *i915 = to_i915(obj->base.dev);
struct list_head *list;
struct i915_vma *vma;
GEM_BUG_ON(!i915_gem_object_has_pinned_pages(obj));
+ mutex_lock(>ggtt.vm.mutex);
for_each_ggtt_vma(vma, obj) {
if (!drm_mm_node_allocated(>node))
continue;
list_move_tail(>vm_link, >vm->bound_list);
}
+ mutex_unlock(>ggtt.vm.mutex);
This is now struct_mutex -> vm->mutex nesting, which we would preferably
want to avoid? There only two callers for the function.
It looks we could remove nesting from i915_gem_set_domain_ioctl by just
moving the call to after mutex unlock.
i915_gem_object_unpin_from_display_plane callers are not as easy so
maybe at least do the one above?
- i915 = to_i915(obj->base.dev);
spin_lock(>mm.obj_lock);
list = obj->bind_count ? >mm.bound_list : >mm.unbound_list;
list_move_tail(>mm.link, list);
diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c
b/drivers/gpu/drm/i915/i915_gem_evict.c
index a76f65fe86be..4a0c6830659d 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/i915_gem_evict.c
@@ -433,6 +433,7 @@ int i915_gem_evict_vm(struct i915_address_space *vm)
}
INIT_LIST_HEAD(_list);
+ mutex_lock(>mutex);
list_for_each_entry(vma, >bound_list, vm_link) {
if (i915_vma_is_pinned(vma))
continue;
@@ -440,6 +441,7 @@ int i915_gem_evict_vm(struct i915_address_space *vm)
__i915_vma_pin(vma);
list_add(>evict_link, _list);
}
+ mutex_unlock(>mutex);
This is another nesting so I suppose you leave all this fun for later?
ret = 0;
list_for_each_entry_safe(vma, next, _list, evict_link) {
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index ad4ef8980b97..c3363a9b586b 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1932,7 +1932,10 @@ static struct i915_vma *pd_vma_create(struct
gen6_hw_ppgtt *ppgtt, int size)
vma->ggtt_view.type = I915_GGTT_VIEW_ROTATED; /* prevent fencing */
INIT_LIST_HEAD(>obj_link);
+
+ mutex_lock(>vm->mutex);
list_add(>vm_link, >vm->unbound_list);
+ mutex_unlock(>vm->mutex);
return vma;
}
@@ -3504,9 +3507,10 @@ void i915_gem_restore_gtt_mappings(struct
drm_i915_private *dev_priv)
i915_check_and_clear_faults(dev_priv);
+ mutex_lock(>vm.mutex);
+
/* First fill our portion of the GTT with scratch pages */
ggtt->vm.clear_range(>vm, 0, ggtt->vm.total);
-
ggtt->vm.closed = true; /* skip rewriting PTE
Re: [Intel-gfx] [PATCH 31/46] drm/i915: Stop tracking MRU activity on VMA
Quoting Tvrtko Ursulin (2019-01-16 16:27:16)
>
> On 07/01/2019 11:54, Chris Wilson wrote:
> > Our goal is to remove struct_mutex and replace it with fine grained
> > locking. One of the thorny issues is our eviction logic for reclaiming
> > space for an execbuffer (or GTT mmaping, among a few other examples).
> > While eviction itself is easy to move under a per-VM mutex, performing
> > the activity tracking is less agreeable. One solution is not to do any
> > MRU tracking and do a simple coarse evaluation during eviction of
> > active/inactive, with a loose temporal ordering of last
> > insertion/evaluation. That keeps all the locking constrained to when we
> > are manipulating the VM itself, neatly avoiding the tricky handling of
> > possible recursive locking during execbuf and elsewhere.
> >
> > Note that discarding the MRU is unlikely to impact upon our efficiency
> > to reclaim VM space (where we think a LRU model is best) as our
> > current strategy is to use random idle replacement first before doing
> > a search, and over time the use of softpinned 48b per-ppGTT is growing
> > (thereby eliminating any need to perform any eviction searches, in
> > theory at least).
>
> I've noticed you did some changes since I last reviewed it, but there is
> not change log so I have to find them manually. Also, the ones you did
> not do I suppose means you disagree with?
I updated the commit msg wrt to the changes
> On the commit message my comment was that I think you should mention the
> removal of active/inactive lists in favour of a single list.
I did, did I not?
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/i915_gem.c | 10 +--
> > drivers/gpu/drm/i915/i915_gem_evict.c | 71 ---
> > drivers/gpu/drm/i915/i915_gem_gtt.c | 15 ++--
> > drivers/gpu/drm/i915/i915_gem_gtt.h | 26 +--
> > drivers/gpu/drm/i915/i915_gem_shrinker.c | 8 ++-
> > drivers/gpu/drm/i915/i915_gem_stolen.c| 3 +-
> > drivers/gpu/drm/i915/i915_gpu_error.c | 37 +-
> > drivers/gpu/drm/i915/i915_vma.c | 9 +--
> > .../gpu/drm/i915/selftests/i915_gem_evict.c | 4 +-
> > drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 2 +-
> > 10 files changed, 84 insertions(+), 101 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 83fb02dab18c..6ed44aeee583 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -254,10 +254,7 @@ i915_gem_get_aperture_ioctl(struct drm_device *dev,
> > void *data,
> >
> > pinned = ggtt->vm.reserved;
> > mutex_lock(>struct_mutex);
> > - list_for_each_entry(vma, >vm.active_list, vm_link)
> > - if (i915_vma_is_pinned(vma))
> > - pinned += vma->node.size;
> > - list_for_each_entry(vma, >vm.inactive_list, vm_link)
> > + list_for_each_entry(vma, >vm.bound_list, vm_link)
> > if (i915_vma_is_pinned(vma))
> > pinned += vma->node.size;
> > mutex_unlock(>struct_mutex);
> > @@ -1540,13 +1537,10 @@ static void
> > i915_gem_object_bump_inactive_ggtt(struct drm_i915_gem_object *obj)
> > GEM_BUG_ON(!i915_gem_object_has_pinned_pages(obj));
> >
> > for_each_ggtt_vma(vma, obj) {
> > - if (i915_vma_is_active(vma))
> > - continue;
> > -
> > if (!drm_mm_node_allocated(>node))
> > continue;
> >
> > - list_move_tail(>vm_link, >vm->inactive_list);
> > + list_move_tail(>vm_link, >vm->bound_list);
> > }
> >
> > i915 = to_i915(obj->base.dev);
> > diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c
> > b/drivers/gpu/drm/i915/i915_gem_evict.c
> > index 02b83a5ed96c..a76f65fe86be 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_evict.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_evict.c
> > @@ -127,14 +127,10 @@ i915_gem_evict_something(struct i915_address_space
> > *vm,
> > struct drm_i915_private *dev_priv = vm->i915;
> > struct drm_mm_scan scan;
> > struct list_head eviction_list;
> > - struct list_head *phases[] = {
> > - >inactive_list,
> > - >active_list,
> > - NULL,
> > - }, **phase;
> > struct i915_vma *vma, *next;
> > struct drm_mm_node *node;
> > enum drm_mm_insert_mode mode;
> > + struct i915_vma *active;
> > int ret;
> >
> > lockdep_assert_held(>i915->drm.struct_mutex);
>
> There is this a comment around here not shown in the diff which talks
> about active and inactive lists. Plus it is misleading on the lists
> ordering now.
The sequence is still in tact. Just a minor mental adjustment that we
scan both in the same list, with softer ordering. Par for the course as
comments go.
> > @@ -170,17 +166,46 @@ i915_gem_evict_something(struct i915_address_space
> > *vm,
> >
Re: [Intel-gfx] [PATCH 5/7] drm/i915: handle interrupts from the OA unit
Quoting Lionel Landwerlin (2019-01-16 16:25:26)
> On 16/01/2019 16:05, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2019-01-16 15:58:00)
> >> On 16/01/2019 15:52, Chris Wilson wrote:
> >>> Quoting Lionel Landwerlin (2019-01-16 15:36:20)
> @@ -1877,6 +1883,21 @@ struct drm_i915_private {
> wait_queue_head_t poll_wq;
> bool pollin;
>
> + /**
> +* Atomic counter incremented by the interrupt
> +* handling code for each OA half full interrupt
> +* received.
> +*/
> + atomic64_t half_full_count;
> +
> + /**
> +* Copy of the atomic half_full_count that was
> last
> +* processed in the i915-perf driver. If both
> counters
> +* differ, there is data available to read in
> the OA
> +* buffer.
> +*/
> + u64 half_full_count_last;
> >>> Eh? But why a relatively expensive atomic64. You only need one bit, and
> >>> reading the tail pointer from WB memory should just be cheap. You should
> >>> be able to sample the perf ringbuffer pointers very cheaply... What am I
> >>> missing?
> >>> -Chris
> >>>
> >> Fair comment.
> >>
> >> The thing is with this series there are 2 mechanism that notify the
> >> poll_wq.
> >>
> >> One is the hrtimer that kicks in at regular interval and polls the
> >> register with the workaround.
> >>
> >> The other is the interrupt which doesn't read the registers and workaround.
> > What's the complication with the workaround?
>
>
> It's a bit more than just looking at registers, we actually have to look
> at the content of the buffer to figure out what landed in memory.
>
> The register values are not synchronized with the memory writes...
I don't want to look at registers at all for polling, and you shouldn't
need to since communication is via a ringbuf.
> There is a comment in the code (i915_perf_poll_locked) about not
> checking the register after each wakeup because that may be a very hot path.
>
> The atomic64 sounded like a lesser evil.
I'm clearly not understanding something here...
Does the hardware not do:
update ringbuf data;
wmb() (or post to global observation point in their parlance)
update ringbuf tail
Then we just need to sample the ringbuf tail and compare against how far
we read last time?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 31/46] drm/i915: Stop tracking MRU activity on VMA
On 07/01/2019 11:54, Chris Wilson wrote:
Our goal is to remove struct_mutex and replace it with fine grained
locking. One of the thorny issues is our eviction logic for reclaiming
space for an execbuffer (or GTT mmaping, among a few other examples).
While eviction itself is easy to move under a per-VM mutex, performing
the activity tracking is less agreeable. One solution is not to do any
MRU tracking and do a simple coarse evaluation during eviction of
active/inactive, with a loose temporal ordering of last
insertion/evaluation. That keeps all the locking constrained to when we
are manipulating the VM itself, neatly avoiding the tricky handling of
possible recursive locking during execbuf and elsewhere.
Note that discarding the MRU is unlikely to impact upon our efficiency
to reclaim VM space (where we think a LRU model is best) as our
current strategy is to use random idle replacement first before doing
a search, and over time the use of softpinned 48b per-ppGTT is growing
(thereby eliminating any need to perform any eviction searches, in
theory at least).
I've noticed you did some changes since I last reviewed it, but there is
not change log so I have to find them manually. Also, the ones you did
not do I suppose means you disagree with?
On the commit message my comment was that I think you should mention the
removal of active/inactive lists in favour of a single list.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 10 +--
drivers/gpu/drm/i915/i915_gem_evict.c | 71 ---
drivers/gpu/drm/i915/i915_gem_gtt.c | 15 ++--
drivers/gpu/drm/i915/i915_gem_gtt.h | 26 +--
drivers/gpu/drm/i915/i915_gem_shrinker.c | 8 ++-
drivers/gpu/drm/i915/i915_gem_stolen.c| 3 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 37 +-
drivers/gpu/drm/i915/i915_vma.c | 9 +--
.../gpu/drm/i915/selftests/i915_gem_evict.c | 4 +-
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 2 +-
10 files changed, 84 insertions(+), 101 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 83fb02dab18c..6ed44aeee583 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -254,10 +254,7 @@ i915_gem_get_aperture_ioctl(struct drm_device *dev, void
*data,
pinned = ggtt->vm.reserved;
mutex_lock(>struct_mutex);
- list_for_each_entry(vma, >vm.active_list, vm_link)
- if (i915_vma_is_pinned(vma))
- pinned += vma->node.size;
- list_for_each_entry(vma, >vm.inactive_list, vm_link)
+ list_for_each_entry(vma, >vm.bound_list, vm_link)
if (i915_vma_is_pinned(vma))
pinned += vma->node.size;
mutex_unlock(>struct_mutex);
@@ -1540,13 +1537,10 @@ static void i915_gem_object_bump_inactive_ggtt(struct
drm_i915_gem_object *obj)
GEM_BUG_ON(!i915_gem_object_has_pinned_pages(obj));
for_each_ggtt_vma(vma, obj) {
- if (i915_vma_is_active(vma))
- continue;
-
if (!drm_mm_node_allocated(>node))
continue;
- list_move_tail(>vm_link, >vm->inactive_list);
+ list_move_tail(>vm_link, >vm->bound_list);
}
i915 = to_i915(obj->base.dev);
diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c
b/drivers/gpu/drm/i915/i915_gem_evict.c
index 02b83a5ed96c..a76f65fe86be 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/i915_gem_evict.c
@@ -127,14 +127,10 @@ i915_gem_evict_something(struct i915_address_space *vm,
struct drm_i915_private *dev_priv = vm->i915;
struct drm_mm_scan scan;
struct list_head eviction_list;
- struct list_head *phases[] = {
- >inactive_list,
- >active_list,
- NULL,
- }, **phase;
struct i915_vma *vma, *next;
struct drm_mm_node *node;
enum drm_mm_insert_mode mode;
+ struct i915_vma *active;
int ret;
lockdep_assert_held(>i915->drm.struct_mutex);
There is this a comment around here not shown in the diff which talks
about active and inactive lists. Plus it is misleading on the lists
ordering now.
@@ -170,17 +166,46 @@ i915_gem_evict_something(struct i915_address_space *vm,
*/
if (!(flags & PIN_NONBLOCK))
i915_retire_requests(dev_priv);
- else
- phases[1] = NULL;
search_again:
+ active = NULL;
INIT_LIST_HEAD(_list);
- phase = phases;
- do {
- list_for_each_entry(vma, *phase, vm_link)
- if (mark_free(, vma, flags, _list))
- goto found;
- } while (*++phase);
+ list_for_each_entry_safe(vma, next, >bound_list, vm_link) {
+ /*
+* We keep this list in a rough least-recently scanned
Re: [Intel-gfx] [PATCH 5/7] drm/i915: handle interrupts from the OA unit
On 16/01/2019 16:05, Chris Wilson wrote:
Quoting Lionel Landwerlin (2019-01-16 15:58:00)
On 16/01/2019 15:52, Chris Wilson wrote:
Quoting Lionel Landwerlin (2019-01-16 15:36:20)
@@ -1877,6 +1883,21 @@ struct drm_i915_private {
wait_queue_head_t poll_wq;
bool pollin;
+ /**
+* Atomic counter incremented by the interrupt
+* handling code for each OA half full interrupt
+* received.
+*/
+ atomic64_t half_full_count;
+
+ /**
+* Copy of the atomic half_full_count that was last
+* processed in the i915-perf driver. If both counters
+* differ, there is data available to read in the OA
+* buffer.
+*/
+ u64 half_full_count_last;
Eh? But why a relatively expensive atomic64. You only need one bit, and
reading the tail pointer from WB memory should just be cheap. You should
be able to sample the perf ringbuffer pointers very cheaply... What am I
missing?
-Chris
Fair comment.
The thing is with this series there are 2 mechanism that notify the poll_wq.
One is the hrtimer that kicks in at regular interval and polls the
register with the workaround.
The other is the interrupt which doesn't read the registers and workaround.
What's the complication with the workaround?
It's a bit more than just looking at registers, we actually have to look
at the content of the buffer to figure out what landed in memory.
The register values are not synchronized with the memory writes...
There is a comment in the code (i915_perf_poll_locked) about not
checking the register after each wakeup because that may be a very hot path.
The atomic64 sounded like a lesser evil.
Maybe a better way to do it would be to have 2 wait queues, one triggers
a workqueue for the oa_buffer_check after the interrupt, the other
notifies the existing poll_wq.
Ok, I was expecting that both the hrtimer, interrupt and general signal
handling (spurious wakeups) fed into the same mechanism to sample the
ringbuffer and notify the client if ready. (And I presume that we sample
from the client's process context anyway to save on the context switch.)
Correct, the client only deals with the output of oa_buffer_check().
The interrupt is just missing the oa_buffer_check() step which maybe we
can do with a 2 stage thing.
Either timer+buffer_check -> wakeup
Or interrupt-> workqueue+buffer_check -> wakeup
-
Lionel
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915: Watchdog timeout: IRQ handler for gen8+
On 11/01/2019 21:28, John Harrison wrote: On 1/11/2019 09:31, Antonio Argenziano wrote: On 11/01/19 00:22, Tvrtko Ursulin wrote: On 11/01/2019 00:47, Antonio Argenziano wrote: On 07/01/19 08:58, Tvrtko Ursulin wrote: On 07/01/2019 13:57, Chris Wilson wrote: Quoting Tvrtko Ursulin (2019-01-07 13:43:29) On 07/01/2019 11:58, Tvrtko Ursulin wrote: [snip] Note about future interaction with preemption: Preemption could happen in a command sequence prior to watchdog counter getting disabled, resulting in watchdog being triggered following preemption (e.g. when watchdog had been enabled in the low priority batch). The driver will need to explicitly disable the watchdog counter as part of the preemption sequence. Does the series take care of preemption? I did not find that it does. Oh. I hoped that the watchdog was saved as part of the context... Then despite preemption, the timeout would resume from where we left off as soon as it was back on the gpu. If the timeout remaining was context saved it would be much simpler (at least on first glance), please say it is. I made my comments going only by the text from the commit message and the absence of any preemption special handling. Having read the spec, the situation seems like this: * Watchdog control and threshold register are context saved and restored. * On a context switch watchdog counter is reset to zero and automatically disabled until enabled by a context restore or explicitly. So it sounds the commit message could be wrong that special handling is needed from this direction. But read till the end on the restriction listed. * Watchdog counter is reset to zero and is not accumulated across multiple submission of the same context (due preemption). I read this as - after preemption contexts gets a new full timeout allocation. Or in other words, if a context is preempted N times, it's cumulative watchdog timeout will be N * set value. This could be theoretically exploitable to bypass the timeout. If a client sets up two contexts with prio -1 and -2, and keeps submitting periodical no-op batches against prio -1 context, while prio -2 is it's own hog, then prio -2 context defeats the watchdog timer. I think.. would appreciate is someone challenged this conclusion. I think you are right that is a possibility but, is that a problem? The client can just not set the threshold to bypass the timeout. Also because you need the hanging batch to be simply preemptible, you cannot disrupt any work from another client that is higher priority. This is But I think higher priority client can have the same effect on the lower priority purely by accident, no? As a real world example, user kicks off an background transcoding job, which happens to use prio -2, and uses the watchdog timer. At the same time user watches a video from a player of normal priority. This causes periodic, say 24Hz, preemption events, due frame decoding activity on the same engine as the transcoding client. Does this defeat the watchdog timer for the former is the question? Then the questions of can we do something about it and whether it really isn't a problem? I guess it depends if you consider that timeout as the maximum lifespan a workload can have or max contiguous active time. I believe the intended purpose of the watchdog is to prevent broken bitstreams hanging the transcoder/player. That is, it is a form of error detection used by the media driver to handle bad user input. So if there is a way for the watchdog to be extended indefinitely under normal situations, that would be a problem. It means the transcoder will not detect the broken input data in a timely manner and effectively hang rather than skip over to the next packet. And note that broken input data can be caused by something as innocent as a dropped packet due to high network contention. No need for any malicious activity at all. My understanding of the intended purpose is the same. And it would be a very useful feature. Chris mentioned the other day that until hardware is fixed to context save/restore the watchdog counter this could simply be implemented using timers. And I have to say I agree. Shouldn't be too hard to prototype it using hrtimers - start on context in, stop on context out and kick forward on user interrupts. More or less. Then if the cost of these hrtimer manipulations wouldn't show in profiles significantly we would have a solution. At least in execlists mode. :) But in parallel we could file a feature request to fix the hardware implementation and then could just switch the timer "backend" from hrtimers to GPU. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/7] drm/i915: handle interrupts from the OA unit
Quoting Lionel Landwerlin (2019-01-16 16:02:51)
> On 16/01/2019 15:58, Lionel Landwerlin wrote:
> > On 16/01/2019 15:52, Chris Wilson wrote:
> >> Quoting Lionel Landwerlin (2019-01-16 15:36:20)
> >>> @@ -1877,6 +1883,21 @@ struct drm_i915_private {
> >>> wait_queue_head_t poll_wq;
> >>> bool pollin;
> >>> + /**
> >>> + * Atomic counter incremented by the interrupt
> >>> + * handling code for each OA half full
> >>> interrupt
> >>> + * received.
> >>> + */
> >>> + atomic64_t half_full_count;
> >>> +
> >>> + /**
> >>> + * Copy of the atomic half_full_count that
> >>> was last
> >>> + * processed in the i915-perf driver. If
> >>> both counters
> >>> + * differ, there is data available to read
> >>> in the OA
> >>> + * buffer.
> >>> + */
> >>> + u64 half_full_count_last;
> >> Eh? But why a relatively expensive atomic64. You only need one bit, and
> >> reading the tail pointer from WB memory should just be cheap. You should
> >> be able to sample the perf ringbuffer pointers very cheaply... What am I
> >> missing?
> >> -Chris
> >>
> > Fair comment.
> >
> > The thing is with this series there are 2 mechanism that notify the
> > poll_wq.
> >
> > One is the hrtimer that kicks in at regular interval and polls the
> > register with the workaround.
> >
> > The other is the interrupt which doesn't read the registers and
> > workaround.
>
>
> What I meant is that I need a way to know which one did the wake up so I
> can call oa_check_buffer() in the interrupt case, that's wait the
> atomic64 is there for.
I thought oa_check_buffer() was just "is there any data for me?"
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/13] drm/i915: Clean up intel_plane_atomic_check_with_state()
>-Original Message-
>From: Ville Syrjala [mailto:ville.syrj...@linux.intel.com]
>Sent: Friday, January 11, 2019 10:38 PM
>To: intel-gfx@lists.freedesktop.org
>Cc: Shankar, Uma ; Roper, Matthew D
>
>Subject: [PATCH 01/13] drm/i915: Clean up
>intel_plane_atomic_check_with_state()
>
>From: Ville Syrjälä
>
>Rename some of the state variables in
>intel_plane_atomic_check_with_state() to make it less confusing.
Looks ok to me.
Reviewed-by: Uma Shankar
>Signed-off-by: Ville Syrjälä
>---
> drivers/gpu/drm/i915/intel_atomic_plane.c | 36 +++
> 1 file changed, 17 insertions(+), 19 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
>b/drivers/gpu/drm/i915/intel_atomic_plane.c
>index 683a75dad4fb..50be2c5dd76e 100644
>--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
>+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
>@@ -110,41 +110,39 @@ intel_plane_destroy_state(struct drm_plane *plane, }
>
> int intel_plane_atomic_check_with_state(const struct intel_crtc_state
>*old_crtc_state,
>- struct intel_crtc_state *crtc_state,
>+ struct intel_crtc_state *new_crtc_state,
> const struct intel_plane_state
>*old_plane_state,
>- struct intel_plane_state *intel_state)
>+ struct intel_plane_state
>*new_plane_state)
> {
>- struct drm_plane *plane = intel_state->base.plane;
>- struct drm_plane_state *state = _state->base;
>- struct intel_plane *intel_plane = to_intel_plane(plane);
>+ struct intel_plane *plane =
>+to_intel_plane(new_plane_state->base.plane);
> int ret;
>
>- crtc_state->active_planes &= ~BIT(intel_plane->id);
>- crtc_state->nv12_planes &= ~BIT(intel_plane->id);
>- intel_state->base.visible = false;
>+ new_crtc_state->active_planes &= ~BIT(plane->id);
>+ new_crtc_state->nv12_planes &= ~BIT(plane->id);
>+ new_plane_state->base.visible = false;
>
>- /* If this is a cursor plane, no further checks are needed. */
>- if (!intel_state->base.crtc && !old_plane_state->base.crtc)
>+ if (!new_plane_state->base.crtc && !old_plane_state->base.crtc)
> return 0;
>
>- ret = intel_plane->check_plane(crtc_state, intel_state);
>+ ret = plane->check_plane(new_crtc_state, new_plane_state);
> if (ret)
> return ret;
>
> /* FIXME pre-g4x don't work like this */
>- if (state->visible)
>- crtc_state->active_planes |= BIT(intel_plane->id);
>+ if (new_plane_state->base.visible)
>+ new_crtc_state->active_planes |= BIT(plane->id);
>
>- if (state->visible && state->fb->format->format == DRM_FORMAT_NV12)
>- crtc_state->nv12_planes |= BIT(intel_plane->id);
>+ if (new_plane_state->base.visible &&
>+ new_plane_state->base.fb->format->format == DRM_FORMAT_NV12)
>+ new_crtc_state->nv12_planes |= BIT(plane->id);
>
>- if (state->visible || old_plane_state->base.visible)
>- crtc_state->update_planes |= BIT(intel_plane->id);
>+ if (new_plane_state->base.visible || old_plane_state->base.visible)
>+ new_crtc_state->update_planes |= BIT(plane->id);
>
> return intel_plane_atomic_calc_changes(old_crtc_state,
>- _state->base,
>+ _crtc_state->base,
> old_plane_state,
>- state);
>+ _plane_state->base);
> }
>
> static int intel_plane_atomic_check(struct drm_plane *plane,
>--
>2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/7] drm/i915: handle interrupts from the OA unit
Quoting Lionel Landwerlin (2019-01-16 15:58:00)
> On 16/01/2019 15:52, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2019-01-16 15:36:20)
> >> @@ -1877,6 +1883,21 @@ struct drm_i915_private {
> >> wait_queue_head_t poll_wq;
> >> bool pollin;
> >>
> >> + /**
> >> +* Atomic counter incremented by the interrupt
> >> +* handling code for each OA half full interrupt
> >> +* received.
> >> +*/
> >> + atomic64_t half_full_count;
> >> +
> >> + /**
> >> +* Copy of the atomic half_full_count that was last
> >> +* processed in the i915-perf driver. If both
> >> counters
> >> +* differ, there is data available to read in the
> >> OA
> >> +* buffer.
> >> +*/
> >> + u64 half_full_count_last;
> > Eh? But why a relatively expensive atomic64. You only need one bit, and
> > reading the tail pointer from WB memory should just be cheap. You should
> > be able to sample the perf ringbuffer pointers very cheaply... What am I
> > missing?
> > -Chris
> >
> Fair comment.
>
> The thing is with this series there are 2 mechanism that notify the poll_wq.
>
> One is the hrtimer that kicks in at regular interval and polls the
> register with the workaround.
>
> The other is the interrupt which doesn't read the registers and workaround.
What's the complication with the workaround?
> Maybe a better way to do it would be to have 2 wait queues, one triggers
> a workqueue for the oa_buffer_check after the interrupt, the other
> notifies the existing poll_wq.
Ok, I was expecting that both the hrtimer, interrupt and general signal
handling (spurious wakeups) fed into the same mechanism to sample the
ringbuffer and notify the client if ready. (And I presume that we sample
from the client's process context anyway to save on the context switch.)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/7] drm/i915: handle interrupts from the OA unit
On 16/01/2019 15:58, Lionel Landwerlin wrote:
On 16/01/2019 15:52, Chris Wilson wrote:
Quoting Lionel Landwerlin (2019-01-16 15:36:20)
@@ -1877,6 +1883,21 @@ struct drm_i915_private {
wait_queue_head_t poll_wq;
bool pollin;
+ /**
+ * Atomic counter incremented by the interrupt
+ * handling code for each OA half full
interrupt
+ * received.
+ */
+ atomic64_t half_full_count;
+
+ /**
+ * Copy of the atomic half_full_count that
was last
+ * processed in the i915-perf driver. If
both counters
+ * differ, there is data available to read
in the OA
+ * buffer.
+ */
+ u64 half_full_count_last;
Eh? But why a relatively expensive atomic64. You only need one bit, and
reading the tail pointer from WB memory should just be cheap. You should
be able to sample the perf ringbuffer pointers very cheaply... What am I
missing?
-Chris
Fair comment.
The thing is with this series there are 2 mechanism that notify the
poll_wq.
One is the hrtimer that kicks in at regular interval and polls the
register with the workaround.
The other is the interrupt which doesn't read the registers and
workaround.
What I meant is that I need a way to know which one did the wake up so I
can call oa_check_buffer() in the interrupt case, that's wait the
atomic64 is there for.
Maybe a better way to do it would be to have 2 wait queues, one
triggers a workqueue for the oa_buffer_check after the interrupt, the
other notifies the existing poll_wq.
-
Lionel
___
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] [v6 5/6] drm/i915/icl: Enable pipe output csc
GEN11+ onwards an output csc hardware block has been added.
This is after the pipe gamma block and is in addition to the
legacy pipe CSC block. Primary use case for this block is to
convert RGB to YUV in case sink supports YUV.
This patch adds supports for the same.
v2: This is added after splitting the existing ICL pipe CSC
handling. As per Matt's suggestion, made this to co-exist
with existing pipe CSC, wherein both can be enabled if a
certain usecase arises.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_reg.h| 41 +
drivers/gpu/drm/i915/intel_color.c | 75 --
drivers/gpu/drm/i915/intel_drv.h | 3 ++
3 files changed, 99 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 3c3a902..edd6b4d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9864,6 +9864,7 @@ enum skl_power_gate {
#define _PIPE_A_CSC_MODE 0x49028
#define ICL_CSC_ENABLE(1 << 31)
+#define ICL_OUTPUT_CSC_ENABLE (1 << 30)
#define CSC_BLACK_SCREEN_OFFSET (1 << 2)
#define CSC_POSITION_BEFORE_GAMMA (1 << 1)
#define CSC_MODE_YUV_TO_RGB (1 << 0)
@@ -9903,6 +9904,46 @@ enum skl_power_gate {
#define PIPE_CSC_POSTOFF_ME(pipe) _MMIO_PIPE(pipe,
_PIPE_A_CSC_POSTOFF_ME, _PIPE_B_CSC_POSTOFF_ME)
#define PIPE_CSC_POSTOFF_LO(pipe) _MMIO_PIPE(pipe,
_PIPE_A_CSC_POSTOFF_LO, _PIPE_B_CSC_POSTOFF_LO)
+/* Pipe Output CSC */
+#define _PIPE_A_OUTPUT_CSC_COEFF_RY_GY 0x49050
+#define _PIPE_A_OUTPUT_CSC_COEFF_BY0x49054
+#define _PIPE_A_OUTPUT_CSC_COEFF_RU_GU 0x49058
+#define _PIPE_A_OUTPUT_CSC_COEFF_BU0x4905c
+#define _PIPE_A_OUTPUT_CSC_COEFF_RV_GV 0x49060
+#define _PIPE_A_OUTPUT_CSC_COEFF_BV0x49064
+#define _PIPE_A_OUTPUT_CSC_PREOFF_HI 0x49068
+#define _PIPE_A_OUTPUT_CSC_PREOFF_ME 0x4906c
+#define _PIPE_A_OUTPUT_CSC_PREOFF_LO 0x49070
+#define _PIPE_A_OUTPUT_CSC_POSTOFF_HI 0x49074
+#define _PIPE_A_OUTPUT_CSC_POSTOFF_ME 0x49078
+#define _PIPE_A_OUTPUT_CSC_POSTOFF_LO 0x4907c
+
+#define _PIPE_B_OUTPUT_CSC_COEFF_RY_GY 0x49150
+#define _PIPE_B_OUTPUT_CSC_COEFF_BY0x49154
+#define _PIPE_B_OUTPUT_CSC_COEFF_RU_GU 0x49158
+#define _PIPE_B_OUTPUT_CSC_COEFF_BU0x4915c
+#define _PIPE_B_OUTPUT_CSC_COEFF_RV_GV 0x49160
+#define _PIPE_B_OUTPUT_CSC_COEFF_BV0x49164
+#define _PIPE_B_OUTPUT_CSC_PREOFF_HI 0x49168
+#define _PIPE_B_OUTPUT_CSC_PREOFF_ME 0x4916c
+#define _PIPE_B_OUTPUT_CSC_PREOFF_LO 0x49170
+#define _PIPE_B_OUTPUT_CSC_POSTOFF_HI 0x49174
+#define _PIPE_B_OUTPUT_CSC_POSTOFF_ME 0x49178
+#define _PIPE_B_OUTPUT_CSC_POSTOFF_LO 0x4917c
+
+#define PIPE_CSC_OUTPUT_COEFF_RY_GY(pipe) _MMIO_PIPE(pipe,
_PIPE_A_OUTPUT_CSC_COEFF_RY_GY, _PIPE_B_OUTPUT_CSC_COEFF_RY_GY)
+#define PIPE_CSC_OUTPUT_COEFF_BY(pipe) _MMIO_PIPE(pipe,
_PIPE_A_OUTPUT_CSC_COEFF_BY, _PIPE_B_OUTPUT_CSC_COEFF_BY)
+#define PIPE_CSC_OUTPUT_COEFF_RU_GU(pipe) _MMIO_PIPE(pipe,
_PIPE_A_OUTPUT_CSC_COEFF_RU_GU, _PIPE_B_OUTPUT_CSC_COEFF_RU_GU)
+#define PIPE_CSC_OUTPUT_COEFF_BU(pipe) _MMIO_PIPE(pipe,
_PIPE_A_OUTPUT_CSC_COEFF_BU, _PIPE_B_OUTPUT_CSC_COEFF_BU)
+#define PIPE_CSC_OUTPUT_COEFF_RV_GV(pipe) _MMIO_PIPE(pipe,
_PIPE_A_OUTPUT_CSC_COEFF_RV_GV, _PIPE_B_OUTPUT_CSC_COEFF_RV_GV)
+#define PIPE_CSC_OUTPUT_COEFF_BV(pipe) _MMIO_PIPE(pipe,
_PIPE_A_OUTPUT_CSC_COEFF_BV, _PIPE_B_OUTPUT_CSC_COEFF_BV)
+#define PIPE_CSC_OUTPUT_PREOFF_HI(pipe)_MMIO_PIPE(pipe,
_PIPE_A_OUTPUT_CSC_PREOFF_HI, _PIPE_B_OUTPUT_CSC_PREOFF_HI)
+#define PIPE_CSC_OUTPUT_PREOFF_ME(pipe)_MMIO_PIPE(pipe,
_PIPE_A_OUTPUT_CSC_PREOFF_ME, _PIPE_B_OUTPUT_CSC_PREOFF_ME)
+#define PIPE_CSC_OUTPUT_PREOFF_LO(pipe)_MMIO_PIPE(pipe,
_PIPE_A_OUTPUT_CSC_PREOFF_LO, _PIPE_B_OUTPUT_CSC_PREOFF_LO)
+#define PIPE_CSC_OUTPUT_POSTOFF_HI(pipe) _MMIO_PIPE(pipe,
_PIPE_A_OUTPUT_CSC_POSTOFF_HI, _PIPE_B_OUTPUT_CSC_POSTOFF_HI)
+#define PIPE_CSC_OUTPUT_POSTOFF_ME(pipe) _MMIO_PIPE(pipe,
_PIPE_A_OUTPUT_CSC_POSTOFF_ME, _PIPE_B_OUTPUT_CSC_POSTOFF_ME)
+#define PIPE_CSC_OUTPUT_POSTOFF_LO(pipe) _MMIO_PIPE(pipe,
_PIPE_A_OUTPUT_CSC_POSTOFF_LO, _PIPE_B_OUTPUT_CSC_POSTOFF_LO)
+
/* pipe degamma/gamma LUTs on IVB+ */
#define _PAL_PREC_INDEX_A 0x4A400
#define _PAL_PREC_INDEX_B 0x4AC00
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index 9b8d2de..c95adb9 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -113,29 +113,58 @@ static u64 *ctm_mult_by_limited(u64 *result, const u64
*input)
return result;
}
-static void ilk_load_ycbcr_conversion_matrix(struct intel_crtc *crtc)
+static void ilk_load_ycbcr_conversion_matrix(struct intel_crtc_state
+*crtc_state)
{
- int pipe = crtc->pipe;
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
[Intel-gfx] [v6 4/6] drm/i915/icl: Enable ICL Pipe CSC block
Enable ICL pipe csc hardware. CSC block is enabled
in CSC_MODE register instead of PLANE_COLOR_CTL.
ToDO: Extend the ABI to accept 32 bit coefficient values
instead of 16bit for future platforms.
v2: Addressed Maarten's review comments.
v3: Addressed Matt's review comments. Removed rmw patterns
as suggested by Matt.
v4: Addressed Matt's review comments.
v5: Addressed Ville's review comments.
v6: Separated pipe output csc programming from regular csc.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_reg.h| 9 ++---
drivers/gpu/drm/i915/intel_color.c | 7 ++-
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index a84200f..3c3a902 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9861,10 +9861,13 @@ enum skl_power_gate {
#define _PIPE_A_CSC_COEFF_BU 0x4901c
#define _PIPE_A_CSC_COEFF_RV_GV0x49020
#define _PIPE_A_CSC_COEFF_BV 0x49024
+
#define _PIPE_A_CSC_MODE 0x49028
-#define CSC_BLACK_SCREEN_OFFSET (1 << 2)
-#define CSC_POSITION_BEFORE_GAMMA(1 << 1)
-#define CSC_MODE_YUV_TO_RGB (1 << 0)
+#define ICL_CSC_ENABLE(1 << 31)
+#define CSC_BLACK_SCREEN_OFFSET (1 << 2)
+#define CSC_POSITION_BEFORE_GAMMA (1 << 1)
+#define CSC_MODE_YUV_TO_RGB (1 << 0)
+
#define _PIPE_A_CSC_PREOFF_HI 0x49030
#define _PIPE_A_CSC_PREOFF_ME 0x49034
#define _PIPE_A_CSC_PREOFF_LO 0x49038
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index 494891c..9b8d2de 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -134,6 +134,7 @@ static void ilk_load_ycbcr_conversion_matrix(struct
intel_crtc *crtc)
I915_WRITE(PIPE_CSC_POSTOFF_HI(pipe), POSTOFF_RGB_TO_YUV_HI);
I915_WRITE(PIPE_CSC_POSTOFF_ME(pipe), POSTOFF_RGB_TO_YUV_ME);
I915_WRITE(PIPE_CSC_POSTOFF_LO(pipe), POSTOFF_RGB_TO_YUV_LO);
+
I915_WRITE(PIPE_CSC_MODE(pipe), 0);
}
@@ -242,7 +243,10 @@ static void ilk_load_csc_matrix(struct intel_crtc_state
*crtc_state)
I915_WRITE(PIPE_CSC_POSTOFF_ME(pipe), postoff);
I915_WRITE(PIPE_CSC_POSTOFF_LO(pipe), postoff);
- I915_WRITE(PIPE_CSC_MODE(pipe), 0);
+ if (INTEL_GEN(dev_priv) >= 11)
+ I915_WRITE(PIPE_CSC_MODE(pipe), ICL_CSC_ENABLE);
+ else
+ I915_WRITE(PIPE_CSC_MODE(pipe), 0);
} else {
uint32_t mode = CSC_MODE_YUV_TO_RGB;
@@ -692,6 +696,7 @@ void intel_color_init(struct intel_crtc *crtc)
dev_priv->display.load_csc_matrix = ilk_load_csc_matrix;
dev_priv->display.load_luts = glk_load_luts;
} else if (IS_ICELAKE(dev_priv)) {
+ dev_priv->display.load_csc_matrix = ilk_load_csc_matrix;
dev_priv->display.load_luts = icl_load_luts;
} else {
dev_priv->display.load_luts = i9xx_load_luts;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v6 3/6] drm/i915/icl: Add icl pipe degamma and gamma support
Add support for icl pipe degamma and gamma.
v2: Removed a POSTING_READ and corrected the Bit
Definition as per Maarten's comments.
v3: Addressed Matt's review comments. Removed rmw patterns
as suggested by Matt.
v4: Fixed Matt's review comments.
v5: Corrected macro alignment as per Jani Nikula's comments.
Addressed Ville and Matt's review comments.
v6: Merged ICL degamma handling with GLK and dropped ICL
degamma function as per Ville and Matt's comments.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_reg.h| 12 +++-
drivers/gpu/drm/i915/intel_color.c | 21 +
2 files changed, 28 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index fad5a9e..a84200f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7088,11 +7088,13 @@ enum {
#define _GAMMA_MODE_A 0x4a480
#define _GAMMA_MODE_B 0x4ac80
#define GAMMA_MODE(pipe) _MMIO_PIPE(pipe, _GAMMA_MODE_A, _GAMMA_MODE_B)
-#define GAMMA_MODE_MODE_MASK (3 << 0)
-#define GAMMA_MODE_MODE_8BIT (0 << 0)
-#define GAMMA_MODE_MODE_10BIT (1 << 0)
-#define GAMMA_MODE_MODE_12BIT (2 << 0)
-#define GAMMA_MODE_MODE_SPLIT (3 << 0)
+#define PRE_CSC_GAMMA_ENABLE (1 << 31)
+#define POST_CSC_GAMMA_ENABLE (1 << 30)
+#define GAMMA_MODE_MODE_MASK (3 << 0)
+#define GAMMA_MODE_MODE_8BIT (0 << 0)
+#define GAMMA_MODE_MODE_10BIT (1 << 0)
+#define GAMMA_MODE_MODE_12BIT (2 << 0)
+#define GAMMA_MODE_MODE_SPLIT (3 << 0)
/* DMC/CSR */
#define CSR_PROGRAM(i) _MMIO(0x8 + (i) * 4)
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index 3712bd0..494891c 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -557,6 +557,25 @@ static void glk_load_luts(struct intel_crtc_state
*crtc_state)
POSTING_READ(GAMMA_MODE(pipe));
}
+static void icl_load_luts(struct intel_crtc_state *crtc_state)
+{
+ struct drm_crtc *crtc = crtc_state->base.crtc;
+ struct drm_device *dev = crtc_state->base.crtc->dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ enum pipe pipe = to_intel_crtc(crtc)->pipe;
+
+ if (crtc_state_is_legacy_gamma(crtc_state)) {
+ haswell_load_luts(crtc_state);
+ return;
+ }
+
+ glk_load_degamma_lut(crtc_state);
+ bdw_load_gamma_lut(crtc_state, 0);
+
+ I915_WRITE(GAMMA_MODE(pipe), GAMMA_MODE_MODE_10BIT |
+ PRE_CSC_GAMMA_ENABLE | POST_CSC_GAMMA_ENABLE);
+}
+
/* Loads the palette/gamma unit for the CRTC on CherryView. */
static void cherryview_load_luts(struct intel_crtc_state *crtc_state)
{
@@ -672,6 +691,8 @@ void intel_color_init(struct intel_crtc *crtc)
} else if (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) {
dev_priv->display.load_csc_matrix = ilk_load_csc_matrix;
dev_priv->display.load_luts = glk_load_luts;
+ } else if (IS_ICELAKE(dev_priv)) {
+ dev_priv->display.load_luts = icl_load_luts;
} else {
dev_priv->display.load_luts = i9xx_load_luts;
}
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v6 6/6] drm/i915/icl: Add degamma and gamma lut size to gen11 caps
Add the degamma and gamma lut sizes to gen11 capability
structure.
Note: Currently this doesn't account for the extended range gamma
entries and this will be addressed with new segmented gamma ABI
in a future patch.
v2: Reorder the patch as per Maarten's suggestion.
v3: Rebase
v4: Updated commit message with a note as per Matt's suggestion.
v5: No Change.
Signed-off-by: Uma Shankar
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/i915_pci.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 24248d0..92eb38d 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -639,7 +639,8 @@
}, \
GEN(11), \
.ddb_size = 2048, \
- .has_logical_ring_elsq = 1
+ .has_logical_ring_elsq = 1, \
+ .color = { .degamma_lut_size = 33, .gamma_lut_size = 1024 }
static const struct intel_device_info intel_icelake_11_info = {
GEN11_FEATURES,
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v6 0/6] Add support for Gen 11 pipe color features
This patch series adds support for Gen11 pipe degamma, CSC and gamma hardware blocks. CRC checks are not working for 10bit gamma but works for 8bit pallete modes which seems to be due to some rounding errors in pipe. Also there is a corner case where Lut precision is increased to 3.16, hence its not possible to accurately represent 1.0 which will require 17 bits. Support for extending the ABI is already in discussion in below series: https://patchwork.freedesktop.org/patch/249771/ ToDo: Support for Multi Segmented Gamma will be added later. v2: Addressed Maarten's review comments and re-ordered the patch series. v3: Addressed Matt's review comments. Removed rmw patterns as suggested by Matt. v4: Addressed Matt's review comments. v5: Addressed Matt's, Ville and Jani Nikula's review comments. v6: Addressed Matt and Ville's review comments. Extended GLK degamma function and merged ICL degamma support to that. Handled pipe output csc separately along with regular pipe csc. Dropped gamma_mode removal patch as Ville is using that to refactor the gamma handling. This series may need a rebase on top of Ville's below series: https://patchwork.freedesktop.org/series/55081/. Uma Shankar (6): drm/i915: Sanitize crtc gamma and csc mode drm/i915/glk: Fix degamma lut programming drm/i915/icl: Add icl pipe degamma and gamma support drm/i915/icl: Enable ICL Pipe CSC block drm/i915/icl: Enable pipe output csc drm/i915/icl: Add degamma and gamma lut size to gen11 caps drivers/gpu/drm/i915/i915_pci.c | 5 +- drivers/gpu/drm/i915/i915_reg.h | 62 +--- drivers/gpu/drm/i915/intel_color.c | 133 --- drivers/gpu/drm/i915/intel_display.c | 21 ++ drivers/gpu/drm/i915/intel_drv.h | 3 + 5 files changed, 188 insertions(+), 36 deletions(-) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v6 2/6] drm/i915/glk: Fix degamma lut programming
Fixed the glk degamma lut programming which currently
was hard coding a linear lut all the time, making degamma
block of glk basically a pass through.
Currently degamma lut for glk is assigned as 0 in platform
configuration. Updated the same to 33 as per the hardware
capability. IGT tests for degamma were getting skipped due to
this, spotted by Swati.
ToDo: The current gamma/degamm lut ABI has just 16bit for each
color component. This is not enough for GLK+, since input
precision is increased to 3.16 which will need 19bit entries.
Credits-to: Swati Sharma
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_pci.c| 2 +-
drivers/gpu/drm/i915/intel_color.c | 36
2 files changed, 29 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index dd4aff2..24248d0 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -69,7 +69,7 @@
#define CHV_COLORS \
.color = { .degamma_lut_size = 65, .gamma_lut_size = 257 }
#define GLK_COLORS \
- .color = { .degamma_lut_size = 0, .gamma_lut_size = 1024 }
+ .color = { .degamma_lut_size = 33, .gamma_lut_size = 1024 }
/* Keep in gen based order, and chronological order within a gen */
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index 37fd9dd..3712bd0 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -491,7 +491,7 @@ static void glk_load_degamma_lut(struct intel_crtc_state
*crtc_state)
{
struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
enum pipe pipe = to_intel_crtc(crtc_state->base.crtc)->pipe;
- const uint32_t lut_size = 33;
+ const uint32_t lut_size = INTEL_INFO(dev_priv)->color.degamma_lut_size;
uint32_t i;
/*
@@ -502,14 +502,34 @@ static void glk_load_degamma_lut(struct intel_crtc_state
*crtc_state)
I915_WRITE(PRE_CSC_GAMC_INDEX(pipe), 0);
I915_WRITE(PRE_CSC_GAMC_INDEX(pipe), PRE_CSC_GAMC_AUTO_INCREMENT);
- /*
-* FIXME: The pipe degamma table in geminilake doesn't support
-* different values per channel, so this just loads a linear table.
-*/
- for (i = 0; i < lut_size; i++) {
- uint32_t v = (i * (1 << 16)) / (lut_size - 1);
- I915_WRITE(PRE_CSC_GAMC_DATA(pipe), v);
+ if (crtc_state->base.degamma_lut) {
+ struct drm_color_lut *lut = crtc_state->base.degamma_lut->data;
+
+ for (i = 0; i < lut_size; i++) {
+ /*
+* First 33 entries represent range from 0 to 1.0
+* 34th and 35th entry will represent extended range
+* inputs 3.0 and 7.0 respectively, currently clamped
+* at 1.0. Since the precision is 16bit, the user
+* value can be directly filled to register.
+* The pipe degamma table in GLK+ onwards doesn't
+* support different values per channel, so this just
+* programs green value which will be equal to Red and
+* Blue into the lut registers.
+* ToDo: Extend to max 7.0. Enable 32 bit input value
+* as compared to just 16 to achieve this.
+*/
+ I915_WRITE(PRE_CSC_GAMC_DATA(pipe), lut[i].green);
+ I915_WRITE(PRE_CSC_GAMC_DATA(pipe), lut[i].green);
+ }
+ } else {
+ /* load a linear table. */
+ for (i = 0; i < lut_size; i++) {
+ uint32_t v = (i * (1 << 16)) / (lut_size - 1);
+
+ I915_WRITE(PRE_CSC_GAMC_DATA(pipe), v);
+ }
}
/* Clamp values > 1.0. */
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v6 1/6] drm/i915: Sanitize crtc gamma and csc mode
Sanitize crtc gamma and csc mode and update the mode in driver
in case BIOS has setup a different mode or gamma luts, csc with
any other unexpected values than desired. There is restriction on
HSW platform not to read/write color LUT's if ips is enabled.
Handled the same accordingly.
We don't read out the LUT's and CTM that the BIOS setup, so at the
moment they stick around for a while until they get unexpectedly
clobbered by a subsequent modeset or fastset. The change here will
basically force them to be reset to standard/linear values at startup.
Maybe in the future we'll try to actually read out and preserve the
contents of the actual LUT's and CTM that the BIOS had setup, but we
don't do that yet today, so the change here at least makes the behavior
a little bit more consistent than what it has been.
v2: Addressed Matt's review comments.
Credits-to: Matt Roper
Signed-off-by: Uma Shankar
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/intel_display.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index af164d7..56fa469 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15434,6 +15434,27 @@ static void intel_sanitize_crtc(struct intel_crtc
*crtc,
}
}
+ /*
+* Sanitize gamma mode incase BIOS leaves it in SPLIT GAMMA MODE
+* or gamma luts, csc with any other unexpected values than desired.
+* We don't read out the LUT's and CTM that the BIOS setup, so at the
+* moment they stick around for a while until they get unexpectedly
+* clobbered by a subsequent modeset or fastset.
+* The change here will basically force them to be reset to
+* standard/linear values at startup.
+* Workaround HSW : Do not read or write the pipe palette/gamma data
+* while GAMMA_MODE is configured for split gamma and IPS_CTL has IPS
+* enabled.
+*/
+ if (IS_HASWELL(dev_priv)) {
+ hsw_disable_ips(crtc_state);
+
+ intel_color_set_csc(crtc_state);
+ intel_color_load_luts(crtc_state);
+
+ hsw_enable_ips(crtc_state);
+ }
+
/* Adjust the state of the output pipe according to whether we
* have active connectors/encoders. */
if (crtc_state->base.active && !intel_crtc_has_encoders(crtc))
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v5 6/6] drm/i915/icl: Add degamma and gamma lut size to gen11 caps
>-Original Message-
>From: Roper, Matthew D
>Sent: Saturday, January 12, 2019 4:35 AM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; Lankhorst, Maarten
>; Syrjala, Ville ;
>Sharma,
>Shashank
>Subject: Re: [v5 6/6] drm/i915/icl: Add degamma and gamma lut size to gen11
>caps
>
>On Tue, Jan 08, 2019 at 01:07:33PM +0530, Uma Shankar wrote:
>> Add the degamma and gamma lut sizes to gen11 capability structure.
>>
>> Note: Currently this doesn't account for the extended range gamma
>> entries and this will be addressed with new segmented gamma ABI in a
>> future patch.
>>
>> v2: Reorder the patch as per Maarten's suggestion.
>>
>> v3: Rebase
>>
>> v4: Updated commit message with a note as per Matt's suggestion.
>>
>> v5: No Change.
>>
>> Signed-off-by: Uma Shankar
>
>On one of the earlier patches, we suggested using the new degamma loading
>function for glk/cnl as well. If you do that, you'll also probably want to
>update
>the degamma_lut_size for GLK as well, although that can be done as a separate
>patch if you like.
I have updated GLK degamma to handle this correctly and ICL to re-use that.
>
>The values here look correct for ICL, so
>
>Reviewed-by: Matt Roper
Thanks Matt for the review and all the valuable corrections and inputs.
Regards,
Uma Shankar
>> ---
>> drivers/gpu/drm/i915/i915_pci.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_pci.c
>> b/drivers/gpu/drm/i915/i915_pci.c index dd4aff2..14e5bb4 100644
>> --- a/drivers/gpu/drm/i915/i915_pci.c
>> +++ b/drivers/gpu/drm/i915/i915_pci.c
>> @@ -639,7 +639,8 @@
>> }, \
>> GEN(11), \
>> .ddb_size = 2048, \
>> -.has_logical_ring_elsq = 1
>> +.has_logical_ring_elsq = 1, \
>> +.color = { .degamma_lut_size = 33, .gamma_lut_size = 1024 }
>>
>> static const struct intel_device_info intel_icelake_11_info = {
>> GEN11_FEATURES,
>> --
>> 1.9.1
>>
>
>--
>Matt Roper
>Graphics Software Engineer
>IoTG Platform Enabling & Development
>Intel Corporation
>(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/7] drm/i915: handle interrupts from the OA unit
On 16/01/2019 15:52, Chris Wilson wrote:
Quoting Lionel Landwerlin (2019-01-16 15:36:20)
@@ -1877,6 +1883,21 @@ struct drm_i915_private {
wait_queue_head_t poll_wq;
bool pollin;
+ /**
+* Atomic counter incremented by the interrupt
+* handling code for each OA half full interrupt
+* received.
+*/
+ atomic64_t half_full_count;
+
+ /**
+* Copy of the atomic half_full_count that was last
+* processed in the i915-perf driver. If both counters
+* differ, there is data available to read in the OA
+* buffer.
+*/
+ u64 half_full_count_last;
Eh? But why a relatively expensive atomic64. You only need one bit, and
reading the tail pointer from WB memory should just be cheap. You should
be able to sample the perf ringbuffer pointers very cheaply... What am I
missing?
-Chris
Fair comment.
The thing is with this series there are 2 mechanism that notify the poll_wq.
One is the hrtimer that kicks in at regular interval and polls the
register with the workaround.
The other is the interrupt which doesn't read the registers and workaround.
Maybe a better way to do it would be to have 2 wait queues, one triggers
a workqueue for the oa_buffer_check after the interrupt, the other
notifies the existing poll_wq.
-
Lionel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v5 5/6] drm/i915/icl: Enable ICL Pipe CSC block
>-Original Message-
>From: Roper, Matthew D
>Sent: Saturday, January 12, 2019 4:30 AM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; Lankhorst, Maarten
>; Syrjala, Ville ;
>Sharma,
>Shashank
>Subject: Re: [v5 5/6] drm/i915/icl: Enable ICL Pipe CSC block
>
>On Tue, Jan 08, 2019 at 01:07:32PM +0530, Uma Shankar wrote:
>> Enable ICL pipe csc hardware. CSC block is enabled in CSC_MODE
>> register instead of PLANE_COLOR_CTL.
>>
>> ToDO: Extend the ABI to accept 32 bit coefficient values instead of
>> 16bit for future platforms.
>>
>> v2: Addressed Maarten's review comments.
>>
>> v3: Addressed Matt's review comments. Removed rmw patterns as
>> suggested by Matt.
>>
>> v4: Addressed Matt's review comments.
>>
>> v5: Addressed Ville's review comments.
>>
>> Signed-off-by: Uma Shankar
>> ---
>> drivers/gpu/drm/i915/i915_reg.h| 10 +++---
>> drivers/gpu/drm/i915/intel_color.c | 12 ++--
>> 2 files changed, 17 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> b/drivers/gpu/drm/i915/i915_reg.h index f29eef7..5a262c0 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -9861,10 +9861,14 @@ enum skl_power_gate {
>> #define _PIPE_A_CSC_COEFF_BU0x4901c
>> #define _PIPE_A_CSC_COEFF_RV_GV 0x49020
>> #define _PIPE_A_CSC_COEFF_BV0x49024
>> +
>> #define _PIPE_A_CSC_MODE0x49028
>> -#define CSC_BLACK_SCREEN_OFFSET (1 << 2)
>> -#define CSC_POSITION_BEFORE_GAMMA (1 << 1)
>> -#define CSC_MODE_YUV_TO_RGB (1 << 0)
>> +#define ICL_CSC_ENABLE (1 << 31)
>> +#define ICL_OUTPUT_CSC_ENABLE (1 << 30)
>> +#define CSC_BLACK_SCREEN_OFFSET(1 << 2)
>> +#define CSC_POSITION_BEFORE_GAMMA (1 << 1)
>> +#define CSC_MODE_YUV_TO_RGB(1 << 0)
>> +
>> #define _PIPE_A_CSC_PREOFF_HI 0x49030
>> #define _PIPE_A_CSC_PREOFF_ME 0x49034
>> #define _PIPE_A_CSC_PREOFF_LO 0x49038
>> diff --git a/drivers/gpu/drm/i915/intel_color.c
>> b/drivers/gpu/drm/i915/intel_color.c
>> index 9cd4646..c3e4ff6 100644
>> --- a/drivers/gpu/drm/i915/intel_color.c
>> +++ b/drivers/gpu/drm/i915/intel_color.c
>> @@ -134,7 +134,11 @@ static void ilk_load_ycbcr_conversion_matrix(struct
>intel_crtc *crtc)
>> I915_WRITE(PIPE_CSC_POSTOFF_HI(pipe), POSTOFF_RGB_TO_YUV_HI);
>> I915_WRITE(PIPE_CSC_POSTOFF_ME(pipe),
>POSTOFF_RGB_TO_YUV_ME);
>> I915_WRITE(PIPE_CSC_POSTOFF_LO(pipe), POSTOFF_RGB_TO_YUV_LO);
>> -I915_WRITE(PIPE_CSC_MODE(pipe), 0);
>> +
>> +if (INTEL_GEN(dev_priv) >= 11)
>> +I915_WRITE(PIPE_CSC_MODE(pipe),
>ICL_OUTPUT_CSC_ENABLE);
>
>For gen11+, shouldn't we be programming OUTPUT_CSC_COEFF instead of
>CSC_COEFF if we set this bit?
Yeah you are right, ideally output CSC coeff should be programmed to utilize
this.
Will add that support.
>> +else
>> +I915_WRITE(PIPE_CSC_MODE(pipe), 0);
>> }
>>
>> static void ilk_load_csc_matrix(struct intel_crtc_state *crtc_state)
>> @@ -242,7 +246,10 @@ static void ilk_load_csc_matrix(struct intel_crtc_state
>*crtc_state)
>> I915_WRITE(PIPE_CSC_POSTOFF_ME(pipe), postoff);
>> I915_WRITE(PIPE_CSC_POSTOFF_LO(pipe), postoff);
>>
>> -I915_WRITE(PIPE_CSC_MODE(pipe), 0);
>> +if (INTEL_GEN(dev_priv) >= 11)
>> +I915_WRITE(PIPE_CSC_MODE(pipe), ICL_CSC_ENABLE);
>> +else
>> +I915_WRITE(PIPE_CSC_MODE(pipe), 0);
>
>I might be misinterpreting how the hardware works, but my impression was that
>we had two distinct CSC units now on gen11+. So we could use the traditional
>CSC registers to hold the userspace-provided CTM and the new output CSC
>registers to hold the fixed RGB->YUV matrix, and they could both be used at the
>same time if necessary. It looks like this function is still assuming that
>the two are
>mutually exclusive and that if we need RGB->YUV we never bother programming
>the userspace matrix. Is that intentional or an oversight? Aside from the
>register
>definitions themselves, the bspec seems to be pretty sparse on how the whole
>pipeline goes together...
Ideally both CSC blocks can co-exist, current design is indeed limiting this.
Will modify
to handle this properly.
Regards,
Uma Shankar
>
>Matt
>
>> } else {
>> uint32_t mode = CSC_MODE_YUV_TO_RGB;
>>
>> @@ -700,6 +707,7 @@ void intel_color_init(struct intel_crtc *crtc)
>> dev_priv->display.load_csc_matrix = ilk_load_csc_matrix;
>> dev_priv->display.load_luts = glk_load_luts;
>> } else if (IS_ICELAKE(dev_priv)) {
>> +dev_priv->display.load_csc_matrix = ilk_load_csc_matrix;
>> dev_priv->display.load_luts = icl_load_luts;
>> } else {
>> dev_priv->display.load_luts = i9xx_load_luts;
>> --
>> 1.9.1
>>
>
>--
>Matt Roper
>Graphics Software Engineer
>IoTG Platform Enabling & Development
>Intel Corporation
>(916)
[Intel-gfx] [PATCH] drm/i915: Limit the for_each_set_bit() to the valid range
Let static analyzers (smatch) know that we are not going to wander off
the end of the array by providing a tight upper bound:
drivers/gpu/drm/i915/intel_display.c:9532 hsw_get_transcoder_state() error:
buffer overflow 'dev_priv->__info.trans_offsets' 6 <= 31
References: 0716931a82b4 ("drm/i915/icl: fix transcoder state readout")
Signed-off-by: Chris Wilson
Cc: Jani Nikula
Cc: Ville Syrjala
Cc: Imre Deak
Cc: Madhav Chauhan
---
drivers/gpu/drm/i915/intel_display.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 62d61fcad89c..b087ed285cc1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9526,7 +9526,9 @@ static bool hsw_get_transcoder_state(struct intel_crtc
*crtc,
* XXX: Do intel_display_power_get_if_enabled before reading this (for
* consistency and less surprising code; it's in always on power).
*/
- for_each_set_bit(panel_transcoder, _transcoder_mask, 32) {
+ for_each_set_bit(panel_transcoder,
+_transcoder_mask,
+ARRAY_SIZE(INTEL_INFO(dev_priv)->trans_offsets)) {
enum pipe trans_pipe;
tmp = I915_READ(TRANS_DDI_FUNC_CTL(panel_transcoder));
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/7] drm/i915: handle interrupts from the OA unit
Quoting Lionel Landwerlin (2019-01-16 15:36:20)
> @@ -1877,6 +1883,21 @@ struct drm_i915_private {
> wait_queue_head_t poll_wq;
> bool pollin;
>
> + /**
> +* Atomic counter incremented by the interrupt
> +* handling code for each OA half full interrupt
> +* received.
> +*/
> + atomic64_t half_full_count;
> +
> + /**
> +* Copy of the atomic half_full_count that was last
> +* processed in the i915-perf driver. If both counters
> +* differ, there is data available to read in the OA
> +* buffer.
> +*/
> + u64 half_full_count_last;
Eh? But why a relatively expensive atomic64. You only need one bit, and
reading the tail pointer from WB memory should just be cheap. You should
be able to sample the perf ringbuffer pointers very cheaply... What am I
missing?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v5 4/6] drm/i915/icl: Add icl pipe degamma and gamma support
>-Original Message-
>From: Roper, Matthew D
>Sent: Saturday, January 12, 2019 3:49 AM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; Lankhorst, Maarten
>; Syrjala, Ville ;
>Sharma,
>Shashank
>Subject: Re: [v5 4/6] drm/i915/icl: Add icl pipe degamma and gamma support
>
>On Tue, Jan 08, 2019 at 01:07:31PM +0530, Uma Shankar wrote:
>> Add support for icl pipe degamma and gamma.
>>
>> v2: Removed a POSTING_READ and corrected the Bit Definition as per
>> Maarten's comments.
>>
>> v3: Addressed Matt's review comments. Removed rmw patterns as
>> suggested by Matt.
>>
>> v4: Fixed Matt's review comments.
>>
>> v5: Corrected macro alignment as per Jani Nikula's comments.
>> Addressed Ville and Matt's review comments.
>>
>> Signed-off-by: Uma Shankar
>> ---
>> drivers/gpu/drm/i915/i915_reg.h| 12 ---
>> drivers/gpu/drm/i915/intel_color.c | 65
>> ++
>> 2 files changed, 72 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> b/drivers/gpu/drm/i915/i915_reg.h index 44958d9..f29eef7 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -7088,11 +7088,13 @@ enum {
>> #define _GAMMA_MODE_A 0x4a480
>> #define _GAMMA_MODE_B 0x4ac80
>> #define GAMMA_MODE(pipe) _MMIO_PIPE(pipe, _GAMMA_MODE_A,
>_GAMMA_MODE_B)
>> -#define GAMMA_MODE_MODE_MASK(3 << 0)
>> -#define GAMMA_MODE_MODE_8BIT(0 << 0)
>> -#define GAMMA_MODE_MODE_10BIT (1 << 0)
>> -#define GAMMA_MODE_MODE_12BIT (2 << 0)
>> -#define GAMMA_MODE_MODE_SPLIT (3 << 0)
>> +#define PRE_CSC_GAMMA_ENABLE (1 << 31)
>> +#define POST_CSC_GAMMA_ENABLE (1 << 30)
>> +#define GAMMA_MODE_MODE_MASK (3 << 0)
>> +#define GAMMA_MODE_MODE_8BIT (0 << 0)
>> +#define GAMMA_MODE_MODE_10BIT (1 << 0)
>> +#define GAMMA_MODE_MODE_12BIT (2 << 0)
>> +#define GAMMA_MODE_MODE_SPLIT (3 << 0)
>>
>> /* DMC/CSR */
>> #define CSR_PROGRAM(i) _MMIO(0x8 + (i) * 4)
>> diff --git a/drivers/gpu/drm/i915/intel_color.c
>> b/drivers/gpu/drm/i915/intel_color.c
>> index 9a72e64..9cd4646 100644
>> --- a/drivers/gpu/drm/i915/intel_color.c
>> +++ b/drivers/gpu/drm/i915/intel_color.c
>> @@ -520,6 +520,69 @@ static void glk_load_luts(struct intel_crtc_state
>*crtc_state)
>> POSTING_READ(GAMMA_MODE(pipe));
>> }
>>
>> +static void icl_load_degamma_lut(struct intel_crtc_state *crtc_state)
>
>As Ville noted, I think the degamma LUT works the same way on GLK-ICL; the
>gamma part may be different (and there's extra stuff like the extra output CSC
>on
>ICL), but for degamma specifically I think the code you wrote below could just
>be
>used to replace the current body of glk_load_degamma_lut rather than adding it
>as a separate function.
Ok, will merge that to one function and extend GLK to handle this instead of the
current pass through.
>Since GLK-ICL only support equal r/g/b values, we also need to land the LUT
>validation patches I wrote in December. Those are fully reviewed so I'll do
>that as
>soon as I get an ack from Dave/Daniel to merge the drm core patch through the
>Intel tree.
Yes, this would be needed. Thanks Matt for taking this up.
Regards,
Uma Shankar
>
>Matt
>
>> +{
>> +struct drm_device *dev = crtc_state->base.crtc->dev;
>> +struct drm_i915_private *dev_priv = to_i915(dev);
>> +enum pipe pipe = to_intel_crtc(crtc_state->base.crtc)->pipe;
>> +const uint32_t lut_size = INTEL_INFO(dev_priv)-
>>color.degamma_lut_size;
>> +uint32_t i;
>> +
>> +/*
>> + * When setting the auto-increment bit, the hardware seems to
>> + * ignore the index bits, so we need to reset it to index 0
>> + * separately.
>> + */
>> +I915_WRITE(PRE_CSC_GAMC_INDEX(pipe), 0);
>> +I915_WRITE(PRE_CSC_GAMC_INDEX(pipe),
>PRE_CSC_GAMC_AUTO_INCREMENT);
>> +
>> +if (crtc_state->base.degamma_lut) {
>> +struct drm_color_lut *lut = crtc_state->base.degamma_lut-
>>data;
>> +
>> +for (i = 0; i < lut_size; i++) {
>> +/*
>> + * First 33 entries represent range from 0 to 1.0
>> + * 34th and 35th entry will represent extended range
>> + * inputs 3.0 and 7.0 respectively, currently clamped
>> + * at 1.0. Since the precision is 16bit, the user value
>> + * can be directly filled to register.
>> + * ToDo: Extend to max 7.0.
>> + */
>> +I915_WRITE(PRE_CSC_GAMC_DATA(pipe), lut[i].green);
>> +}
>> +} else {
>> +/* load a linear table. */
>> +for (i = 0; i < lut_size; i++) {
>> +uint32_t v = (i * (1 << 16)) / (lut_size - 1);
>> +
>> +I915_WRITE(PRE_CSC_GAMC_DATA(pipe), v);
>> +}
>> +}
>> +
>> +/* Clamp values > 1.0. */
>> +while (i++ < 35)
>>
[Intel-gfx] [PATCH 6/7] drm/i915/perf: add interrupt enabling parameter
This let's the application choose to be driven by the interrupt
mechanism of the HW. In conjuction with long periods for checks for
the availability of data on the CPU, this can reduce the CPU load when
doing capture of OA data.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 54 +++-
include/uapi/drm/i915_drm.h | 8 +
2 files changed, 48 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 82c4e0c08859..da721fce2543 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -243,7 +243,7 @@
* oa_buffer_check().
*
* Most of the implementation details for this workaround are in
- * oa_buffer_check_unlocked() and _append_oa_reports()
+ * oa_buffer_check() and _append_oa_reports()
*
* Note for posterity: previously the driver used to define an effective tail
* pointer that lagged the real pointer by a 'tail margin' measured in bytes
@@ -418,9 +418,11 @@ static u32 gen7_oa_hw_tail_read(struct drm_i915_private
*dev_priv)
return oastatus1 & GEN7_OASTATUS1_TAIL_MASK;
}
+
/**
- * oa_buffer_check_unlocked - check for data and update tail ptr state
+ * oa_buffer_check - check for data and update tail ptr state
* @dev_priv: i915 device instance
+ * @lock: whether to take the oa_buffer spin lock
*
* This is either called via fops (for blocking reads in user ctx) or the poll
* check hrtimer (atomic ctx) to check the OA buffer tail pointer and check
@@ -442,8 +444,9 @@ static u32 gen7_oa_hw_tail_read(struct drm_i915_private
*dev_priv)
*
* Returns: %true if the OA buffer contains data, else %false
*/
-static bool oa_buffer_check_unlocked(struct drm_i915_private *dev_priv)
+static bool oa_buffer_check(struct drm_i915_private *dev_priv, bool lock)
{
+ u64 half_full_count = atomic64_read(_priv->perf.oa.half_full_count);
u32 gtt_offset = i915_ggtt_offset(dev_priv->perf.oa.oa_buffer.vma);
int report_size = dev_priv->perf.oa.oa_buffer.format_size;
unsigned long flags;
@@ -454,7 +457,8 @@ static bool oa_buffer_check_unlocked(struct
drm_i915_private *dev_priv)
* could result in an OA buffer reset which might reset the head,
* tails[] and aged_tail state.
*/
- spin_lock_irqsave(_priv->perf.oa.oa_buffer.ptr_lock, flags);
+ if (lock)
+ spin_lock_irqsave(_priv->perf.oa.oa_buffer.ptr_lock, flags);
hw_tail = dev_priv->perf.oa.ops.oa_hw_tail_read(dev_priv);
@@ -530,7 +534,10 @@ static bool oa_buffer_check_unlocked(struct
drm_i915_private *dev_priv)
dev_priv->perf.oa.oa_buffer.aging_timestamp = now;
}
- spin_unlock_irqrestore(_priv->perf.oa.oa_buffer.ptr_lock, flags);
+ dev_priv->perf.oa.half_full_count_last = half_full_count;
+
+ if (lock)
+ spin_unlock_irqrestore(_priv->perf.oa.oa_buffer.ptr_lock,
flags);
return OA_TAKEN(dev_priv->perf.oa.oa_buffer.tail - gtt_offset,
dev_priv->perf.oa.oa_buffer.head - gtt_offset) >=
report_size;
@@ -1124,9 +1131,9 @@ static int gen7_oa_read(struct i915_perf_stream *stream,
* i915_oa_wait_unlocked - handles blocking IO until OA data available
* @stream: An i915-perf stream opened for OA metrics
*
- * Called when userspace tries to read() from a blocking stream FD opened
- * for OA metrics. It waits until the hrtimer callback finds a non-empty
- * OA buffer and wakes us.
+ * Called when userspace tries to read() from a blocking stream FD opened for
+ * OA metrics. It waits until either the hrtimer callback finds a non-empty OA
+ * buffer or the OA interrupt kicks in and wakes us.
*
* Note: it's acceptable to have this return with some false positives
* since any subsequent read handling will return -EAGAIN if there isn't
@@ -1143,7 +1150,7 @@ static int i915_oa_wait_unlocked(struct i915_perf_stream
*stream)
return -EIO;
return wait_event_interruptible(dev_priv->perf.oa.poll_wq,
- oa_buffer_check_unlocked(dev_priv));
+ oa_buffer_check(dev_priv, true));
}
/**
@@ -1964,6 +1971,10 @@ static void i915_oa_stream_disable(struct
i915_perf_stream *stream)
dev_priv->perf.oa.ops.oa_disable(stream);
+ dev_priv->perf.oa.half_full_count_last = 0;
+ atomic64_set(_priv->perf.oa.half_full_count,
+dev_priv->perf.oa.half_full_count_last);
+
if (dev_priv->perf.oa.periodic)
hrtimer_cancel(_priv->perf.oa.poll_check_timer);
}
@@ -2290,7 +2301,7 @@ static enum hrtimer_restart oa_poll_check_timer_cb(struct
hrtimer *hrtimer)
perf.oa.poll_check_timer);
struct i915_perf_stream *stream = dev_priv->perf.oa.exclusive_stream;
- if (oa_buffer_check_unlocked(dev_priv)) {
+ if (oa_buffer_check(dev_priv, true)) {
[Intel-gfx] [PATCH 0/7] drm/i915/perf: add OA interrupt support
Taking the RFC off this series. To quite the vTune team that tried the previous version : "It reduces data collection overhead in VTune by 11x. It is great!" The GPA team's report on the previous version was a drop in CPU consumption from 17~20% down to 2~3%. This version includes : - a fix for an issue reported by Chris on the IMR register access on Haswell - the ability to completely disable the i915 OA head/tail polling - a new ioctl on the perf stream file descript (not the i915 drm master/render node) to force i915 to look at the OA head/tail register (see explanation in last patch). Cheers, Lionel Landwerlin (7): drm/i915/perf: rework aging tail workaround drm/i915/perf: reset pollin when perf stream is enabled drm/i915/perf: only append status when data is available drm/i915/perf: add new open param to configure polling of OA buffer drm/i915: handle interrupts from the OA unit drm/i915/perf: add interrupt enabling parameter drm/i915/perf: add flushing ioctl drivers/gpu/drm/i915/i915_drv.h | 59 +++- drivers/gpu/drm/i915/i915_irq.c | 39 ++- drivers/gpu/drm/i915/i915_perf.c| 388 +++- drivers/gpu/drm/i915/i915_reg.h | 7 + drivers/gpu/drm/i915/intel_ringbuffer.c | 2 + include/uapi/drm/i915_drm.h | 35 +++ 6 files changed, 357 insertions(+), 173 deletions(-) -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/7] drm/i915/perf: add flushing ioctl
With the currently available parameters for the i915-perf stream,
there are still situations that are not well covered :
If an application opens the stream with polling disable or at very low
frequency and OA interrupt enabled, no data will be available even
though somewhere between nothing and half of the OA buffer worth of
data might have landed in memory.
To solve this issue we have a new flush ioctl on the perf stream that
forces the i915-perf driver to look at the state of the buffer when
called and makes any data available through both poll() & read() type
syscalls.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 17 +
include/uapi/drm/i915_drm.h | 19 +++
2 files changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index da721fce2543..6c98ffa2135e 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -2433,6 +2433,20 @@ static void i915_perf_disable_locked(struct
i915_perf_stream *stream)
stream->ops->disable(stream);
}
+/**
+ * i915_perf_flush_data - handle `I915_PERF_IOCTL_FLUSH_DATA` ioctl
+ * @stream: An enabled i915 perf stream
+ *
+ * The intention is to flush all the data available for reading from the OA
+ * buffer
+ */
+static void i915_perf_flush_data(struct i915_perf_stream *stream)
+{
+ struct drm_i915_private *dev_priv = stream->dev_priv;
+
+ dev_priv->perf.oa.pollin = oa_buffer_check(stream->dev_priv, true);
+}
+
/**
* i915_perf_ioctl - support ioctl() usage with i915 perf stream FDs
* @stream: An i915 perf stream
@@ -2456,6 +2470,9 @@ static long i915_perf_ioctl_locked(struct
i915_perf_stream *stream,
case I915_PERF_IOCTL_DISABLE:
i915_perf_disable_locked(stream);
return 0;
+ case I915_PERF_IOCTL_FLUSH_DATA:
+ i915_perf_flush_data(stream);
+ return 0;
}
return -EINVAL;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index b6db5e544a35..0f0d20080572 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1594,6 +1594,25 @@ struct drm_i915_perf_open_param {
*/
#define I915_PERF_IOCTL_DISABLE_IO('i', 0x1)
+/**
+ * Actively check the availability of data from a stream.
+ *
+ * A stream data availability can be driven by two types of events :
+ *
+ * - if enabled, the kernel's hrtimer checking the amount of available data
+ * in the OA buffer through head/tail registers.
+ *
+ * - if enabled, the OA unit's interrupt mechanism
+ *
+ * The kernel hrtimer incur a cost of running callback at fixed time
+ * intervals, while the OA interrupt might only happen rarely. In the
+ * situation where the application has disabled the kernel's hrtimer and only
+ * uses the OA interrupt to know about available data, the application can
+ * request an active check of the available OA data through this ioctl. This
+ * will make any data in the OA buffer available with either poll() or read().
+ */
+#define I915_PERF_IOCTL_FLUSH_DATA _IO('i', 0x2)
+
/**
* Common to all i915 perf records
*/
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/7] drm/i915/perf: reset pollin when perf stream is enabled
No issues have been raised about this yet, but this should be reset
every time we enable the stream, otherwise we might have a stale value
from the previous round of enable/disable.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 575701e2aabc..4c5d2ee4d6e3 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1876,6 +1876,8 @@ static void i915_oa_stream_enable(struct i915_perf_stream
*stream)
{
struct drm_i915_private *dev_priv = stream->dev_priv;
+ dev_priv->perf.oa.pollin = false;
+
dev_priv->perf.oa.ops.oa_enable(stream);
if (dev_priv->perf.oa.periodic)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/7] drm/i915/perf: rework aging tail workaround
We're about to introduce an options to open the perf stream, giving
the user ability to configure how often it wants the kernel to poll
the OA registers for available data.
Right now the workaround against the OA tail pointer race condition
requires at least twice the internal kernel polling timer to make any
data available.
This changes introduce checks on the OA data written into the circular
buffer to make as much data as possible available on the first
iteration of the polling timer.
v2: Use OA_TAKEN macro without the gtt_offset (Lionel)
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 32 ++---
drivers/gpu/drm/i915/i915_perf.c | 200 ++-
2 files changed, 103 insertions(+), 129 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index da055a86db4d..8cb93718224f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1877,6 +1877,12 @@ struct drm_i915_private {
*/
struct ratelimit_state spurious_report_rs;
+ /**
+* For rate limiting any notifications of tail pointer
+* race.
+*/
+ struct ratelimit_state tail_pointer_race;
+
bool periodic;
int period_exponent;
@@ -1917,23 +1923,11 @@ struct drm_i915_private {
spinlock_t ptr_lock;
/**
-* One 'aging' tail pointer and one 'aged'
-* tail pointer ready to used for reading.
-*
-* Initial values of 0x are invalid
-* and imply that an update is required
-* (and should be ignored by an attempted
-* read)
-*/
- struct {
- u32 offset;
- } tails[2];
-
- /**
-* Index for the aged tail ready to read()
-* data up to.
+* The last HW tail reported by HW. The data
+* might not have made it to memory yet
+* though.
*/
- unsigned int aged_tail_idx;
+ u32 aging_tail;
/**
* A monotonic timestamp for when the current
@@ -1952,6 +1946,12 @@ struct drm_i915_private {
* data to userspace.
*/
u32 head;
+
+ /**
+* The last tail verified tail that can be
+* read by userspace.
+*/
+ u32 tail;
} oa_buffer;
u32 gen7_latched_oastatus1;
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index faff6cf1aaa1..575701e2aabc 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -233,23 +233,14 @@
* for this earlier, as part of the oa_buffer_check to avoid lots of redundant
* read() attempts.
*
- * In effect we define a tail pointer for reading that lags the real tail
- * pointer by at least %OA_TAIL_MARGIN_NSEC nanoseconds, which gives enough
- * time for the corresponding reports to become visible to the CPU.
- *
- * To manage this we actually track two tail pointers:
- * 1) An 'aging' tail with an associated timestamp that is tracked until we
- * can trust the corresponding data is visible to the CPU; at which point
- * it is considered 'aged'.
- * 2) An 'aged' tail that can be used for read()ing.
- *
- * The two separate pointers let us decouple read()s from tail pointer aging.
- *
- * The tail pointers are checked and updated at a limited rate within a hrtimer
- * callback (the same callback that is used for delivering EPOLLIN events)
- *
- * Initially the tails are marked invalid with %INVALID_TAIL_PTR which
- * indicates that an updated tail pointer is needed.
+ * We workaround this issue in oa_buffer_check() by reading the reports in the
+ * OA buffer, starting from the tail reported by the HW until we find 2
+ * consecutive reports with their first 2 dwords of not at 0. Those dwords are
+ * also set to 0 once read and the whole buffer is cleared upon OA buffer
+ * initialization. The first dword is the reason for this report while the
+ * second is the timestamp, making the chances of having those 2
[Intel-gfx] [PATCH 3/7] drm/i915/perf: only append status when data is available
The only bit of the status register we currently report in the
i915-perf stream is the "report loss" bit. Only report this when we
have some data to report with it. There was a kind of inconsistency
here in that we could report report loss without appending the reports
associated with the loss.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 54
1 file changed, 34 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 4c5d2ee4d6e3..b37c7ad0cde6 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -636,6 +636,7 @@ static int append_oa_sample(struct i915_perf_stream *stream,
* Returns: 0 on success, negative error code on failure.
*/
static int gen8_append_oa_reports(struct i915_perf_stream *stream,
+ u32 oastatus,
char __user *buf,
size_t count,
size_t *offset)
@@ -681,6 +682,21 @@ static int gen8_append_oa_reports(struct i915_perf_stream
*stream,
head, tail))
return -EIO;
+ /*
+* If there is nothing to read, don't append the status report yet,
+* wait until we have some data available.
+*/
+ if (!OA_TAKEN(tail, head))
+ return 0;
+
+ if (oastatus & GEN8_OASTATUS_REPORT_LOST) {
+ ret = append_oa_status(stream, buf, count, offset,
+ DRM_I915_PERF_RECORD_OA_REPORT_LOST);
+ if (ret)
+ return ret;
+ I915_WRITE(GEN8_OASTATUS,
+ oastatus & ~GEN8_OASTATUS_REPORT_LOST);
+ }
for (/* none */;
(taken = OA_TAKEN(tail, head));
@@ -880,16 +896,7 @@ static int gen8_oa_read(struct i915_perf_stream *stream,
oastatus = I915_READ(GEN8_OASTATUS);
}
- if (oastatus & GEN8_OASTATUS_REPORT_LOST) {
- ret = append_oa_status(stream, buf, count, offset,
- DRM_I915_PERF_RECORD_OA_REPORT_LOST);
- if (ret)
- return ret;
- I915_WRITE(GEN8_OASTATUS,
- oastatus & ~GEN8_OASTATUS_REPORT_LOST);
- }
-
- return gen8_append_oa_reports(stream, buf, count, offset);
+ return gen8_append_oa_reports(stream, oastatus, buf, count, offset);
}
/**
@@ -913,6 +920,7 @@ static int gen8_oa_read(struct i915_perf_stream *stream,
* Returns: 0 on success, negative error code on failure.
*/
static int gen7_append_oa_reports(struct i915_perf_stream *stream,
+ u32 oastatus1,
char __user *buf,
size_t count,
size_t *offset)
@@ -956,6 +964,21 @@ static int gen7_append_oa_reports(struct i915_perf_stream
*stream,
head, tail))
return -EIO;
+ /*
+* If there is nothing to read, don't append the status report yet,
+* wait until we have some data available.
+*/
+ if (!OA_TAKEN(tail, head))
+ return 0;
+
+ if (unlikely(oastatus1 & GEN7_OASTATUS1_REPORT_LOST)) {
+ ret = append_oa_status(stream, buf, count, offset,
+ DRM_I915_PERF_RECORD_OA_REPORT_LOST);
+ if (ret)
+ return ret;
+ dev_priv->perf.oa.gen7_latched_oastatus1 |=
+ GEN7_OASTATUS1_REPORT_LOST;
+ }
for (/* none */;
(taken = OA_TAKEN(tail, head));
@@ -1089,16 +1112,7 @@ static int gen7_oa_read(struct i915_perf_stream *stream,
oastatus1 = I915_READ(GEN7_OASTATUS1);
}
- if (unlikely(oastatus1 & GEN7_OASTATUS1_REPORT_LOST)) {
- ret = append_oa_status(stream, buf, count, offset,
- DRM_I915_PERF_RECORD_OA_REPORT_LOST);
- if (ret)
- return ret;
- dev_priv->perf.oa.gen7_latched_oastatus1 |=
- GEN7_OASTATUS1_REPORT_LOST;
- }
-
- return gen7_append_oa_reports(stream, buf, count, offset);
+ return gen7_append_oa_reports(stream, oastatus1, buf, count, offset);
}
/**
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/7] drm/i915: handle interrupts from the OA unit
The OA unit can notify that its circular buffer is half full through
an interrupt and we would like to give the application the ability to
make use of this interrupt to get rid of CPU checks on the OA buffer.
This change wires up the interrupt to the i915-perf stream and leaves
it ignored for now.
v2: Use spin_lock_irq() to access the IMR register on Haswell (Chris)
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 21 +
drivers/gpu/drm/i915/i915_irq.c | 39 -
drivers/gpu/drm/i915/i915_perf.c| 26 +
drivers/gpu/drm/i915/i915_reg.h | 7 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 2 ++
5 files changed, 88 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d535df8f7d0a..850cf35e6163 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1385,6 +1385,12 @@ struct i915_perf_stream {
* buffer should be checked for available data.
*/
u64 poll_oa_period;
+
+ /**
+* @oa_interrupt_monitor: Whether the stream will be notified by OA
+* interrupts.
+*/
+ bool oa_interrupt_monitor;
};
/**
@@ -1877,6 +1883,21 @@ struct drm_i915_private {
wait_queue_head_t poll_wq;
bool pollin;
+ /**
+* Atomic counter incremented by the interrupt
+* handling code for each OA half full interrupt
+* received.
+*/
+ atomic64_t half_full_count;
+
+ /**
+* Copy of the atomic half_full_count that was last
+* processed in the i915-perf driver. If both counters
+* differ, there is data available to read in the OA
+* buffer.
+*/
+ u64 half_full_count_last;
+
/**
* For rate limiting any notifications of spurious
* invalid OA reports
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 94187e68d39a..7996048565a7 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1214,6 +1214,12 @@ static void notify_ring(struct intel_engine_cs *engine)
trace_intel_engine_notify(engine, wait);
}
+static void notify_perfmon_buffer_half_full(struct drm_i915_private *i915)
+{
+ atomic64_inc(>perf.oa.half_full_count);
+ wake_up_all(>perf.oa.poll_wq);
+}
+
static void vlv_c0_read(struct drm_i915_private *dev_priv,
struct intel_rps_ei *ei)
{
@@ -1478,6 +1484,9 @@ static void snb_gt_irq_handler(struct drm_i915_private
*dev_priv,
GT_RENDER_CS_MASTER_ERROR_INTERRUPT))
DRM_DEBUG("Command parser error, gt_iir 0x%08x\n", gt_iir);
+ if (gt_iir & GT_PERFMON_BUFFER_HALF_FULL_INTERRUPT)
+ notify_perfmon_buffer_half_full(dev_priv);
+
if (gt_iir & GT_PARITY_ERROR(dev_priv))
ivybridge_parity_error_irq_handler(dev_priv, gt_iir);
}
@@ -1499,6 +1508,12 @@ gen8_cs_irq_handler(struct intel_engine_cs *engine, u32
iir)
tasklet_hi_schedule(>execlists.tasklet);
}
+static void gen8_perfmon_handler(struct drm_i915_private *i915, u32 iir)
+{
+ if (iir & GEN8_GT_PERFMON_BUFFER_HALF_FULL_INTERRUPT)
+ notify_perfmon_buffer_half_full(i915);
+}
+
static void gen8_gt_irq_ack(struct drm_i915_private *i915,
u32 master_ctl, u32 gt_iir[4])
{
@@ -1508,6 +1523,7 @@ static void gen8_gt_irq_ack(struct drm_i915_private *i915,
GEN8_GT_BCS_IRQ | \
GEN8_GT_VCS1_IRQ | \
GEN8_GT_VCS2_IRQ | \
+ GEN8_GT_WDBOX_OACS_IRQ | \
GEN8_GT_VECS_IRQ | \
GEN8_GT_PM_IRQ | \
GEN8_GT_GUC_IRQ)
@@ -1530,7 +1546,7 @@ static void gen8_gt_irq_ack(struct drm_i915_private *i915,
raw_reg_write(regs, GEN8_GT_IIR(2), gt_iir[2]);
}
- if (master_ctl & GEN8_GT_VECS_IRQ) {
+ if (master_ctl & (GEN8_GT_VECS_IRQ | GEN8_GT_WDBOX_OACS_IRQ)) {
gt_iir[3] = raw_reg_read(regs, GEN8_GT_IIR(3));
if (likely(gt_iir[3]))
raw_reg_write(regs, GEN8_GT_IIR(3), gt_iir[3]);
@@ -1554,9 +1570,11 @@ static void gen8_gt_irq_handler(struct drm_i915_private
*i915,
gt_iir[1] >> GEN8_VCS2_IRQ_SHIFT);
}
- if (master_ctl & GEN8_GT_VECS_IRQ) {
+ if (master_ctl & (GEN8_GT_VECS_IRQ | GEN8_GT_WDBOX_OACS_IRQ)) {
gen8_cs_irq_handler(i915->engine[VECS],
gt_iir[3]
[Intel-gfx] [PATCH 4/7] drm/i915/perf: add new open param to configure polling of OA buffer
This new parameter let's the application choose how often the OA
buffer should be checked on the CPU side for data availability. Longer
polling period tend to reduce CPU overhead if the application does not
care about somewhat real time data collection.
v2: Allow disabling polling completely with 0 value (Lionel)
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 6 +
drivers/gpu/drm/i915/i915_perf.c | 43 ++--
include/uapi/drm/i915_drm.h | 8 ++
3 files changed, 50 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8cb93718224f..d535df8f7d0a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1379,6 +1379,12 @@ struct i915_perf_stream {
* @oa_config: The OA configuration used by the stream.
*/
struct i915_oa_config *oa_config;
+
+ /**
+* @poll_oa_period: The period in nanoseconds at which the OA
+* buffer should be checked for available data.
+*/
+ u64 poll_oa_period;
};
/**
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index b37c7ad0cde6..9ad45ad31b43 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -254,11 +254,11 @@
*/
#define OA_TAIL_MARGIN_NSEC10ULL
-/* frequency for checking whether the OA unit has written new reports to the
- * circular OA buffer...
+/* The default frequency for checking whether the OA unit has written new
+ * reports to the circular OA buffer...
*/
-#define POLL_FREQUENCY 200
-#define POLL_PERIOD (NSEC_PER_SEC / POLL_FREQUENCY)
+#define DEFAULT_POLL_FREQUENCY 200
+#define DEFAULT_POLL_PERIOD (NSEC_PER_SEC / DEFAULT_POLL_FREQUENCY)
/* for sysctl proc_dointvec_minmax of dev.i915.perf_stream_paranoid */
static int zero;
@@ -335,6 +335,8 @@ static const struct i915_oa_format
gen8_plus_oa_formats[I915_OA_FORMAT_MAX] = {
* @oa_format: An OA unit HW report format
* @oa_periodic: Whether to enable periodic OA unit sampling
* @oa_period_exponent: The OA unit sampling period is derived from this
+ * @poll_oa_period: The period at which the CPU will check for OA data
+ * availability
*
* As read_properties_unlocked() enumerates and validates the properties given
* to open a stream of metrics the configuration is built up in the structure
@@ -351,6 +353,7 @@ struct perf_open_properties {
int oa_format;
bool oa_periodic;
int oa_period_exponent;
+ u64 poll_oa_period;
};
static void free_oa_config(struct drm_i915_private *dev_priv,
@@ -1894,9 +1897,9 @@ static void i915_oa_stream_enable(struct i915_perf_stream
*stream)
dev_priv->perf.oa.ops.oa_enable(stream);
- if (dev_priv->perf.oa.periodic)
+ if (dev_priv->perf.oa.periodic && stream->poll_oa_period)
hrtimer_start(_priv->perf.oa.poll_check_timer,
- ns_to_ktime(POLL_PERIOD),
+ ns_to_ktime(stream->poll_oa_period),
HRTIMER_MODE_REL_PINNED);
}
@@ -2260,13 +2263,15 @@ static enum hrtimer_restart
oa_poll_check_timer_cb(struct hrtimer *hrtimer)
struct drm_i915_private *dev_priv =
container_of(hrtimer, typeof(*dev_priv),
perf.oa.poll_check_timer);
+ struct i915_perf_stream *stream = dev_priv->perf.oa.exclusive_stream;
if (oa_buffer_check_unlocked(dev_priv)) {
dev_priv->perf.oa.pollin = true;
wake_up(_priv->perf.oa.poll_wq);
}
- hrtimer_forward_now(hrtimer, ns_to_ktime(POLL_PERIOD));
+ hrtimer_forward_now(hrtimer,
+ ns_to_ktime(stream->poll_oa_period));
return HRTIMER_RESTART;
}
@@ -2587,6 +2592,7 @@ i915_perf_open_ioctl_locked(struct drm_i915_private
*dev_priv,
stream->dev_priv = dev_priv;
stream->ctx = specific_ctx;
+ stream->poll_oa_period = props->poll_oa_period;
ret = i915_oa_stream_init(stream, param, props);
if (ret)
@@ -2642,6 +2648,7 @@ static u64 oa_exponent_to_ns(struct drm_i915_private
*dev_priv, int exponent)
/**
* read_properties_unlocked - validate + copy userspace stream open properties
* @dev_priv: i915 device instance
+ * @open_flags: Flags set by userspace for the opening of the stream
* @uprops: The array of u64 key value pairs given by userspace
* @n_props: The number of key value pairs expected in @uprops
* @props: The stream configuration built up while validating properties
@@ -2655,6 +2662,7 @@ static u64 oa_exponent_to_ns(struct drm_i915_private
*dev_priv, int exponent)
* rule out defining new properties with ordering requirements in the future.
*/
static int read_properties_unlocked(struct drm_i915_private *dev_priv,
+ u32 open_flags,
u64 __user
[Intel-gfx] [CI] drm/i915: Pull all the reset functionality together into i915_reset.c
Currently the code to reset the GPU and our state is spread widely
across a few files. Pull the logic together into a common file.
Signed-off-by: Chris Wilson
Acked-by: Mika Kuoppala
---
drivers/gpu/drm/i915/Makefile |3 +-
drivers/gpu/drm/i915/i915_debugfs.c |2 +
drivers/gpu/drm/i915/i915_drv.c | 206 +--
drivers/gpu/drm/i915/i915_drv.h | 33 +-
drivers/gpu/drm/i915/i915_gem.c | 446 +-
drivers/gpu/drm/i915/i915_gem_gtt.c |1 +
drivers/gpu/drm/i915/i915_irq.c | 238 ---
drivers/gpu/drm/i915/i915_request.c |1 +
drivers/gpu/drm/i915/i915_reset.c | 1389 +
drivers/gpu/drm/i915/i915_reset.h | 56 +
drivers/gpu/drm/i915/intel_display.c | 15 +-
drivers/gpu/drm/i915/intel_engine_cs.c|1 +
drivers/gpu/drm/i915/intel_guc.h |3 +
drivers/gpu/drm/i915/intel_hangcheck.c|1 +
drivers/gpu/drm/i915/intel_uc.c |1 +
drivers/gpu/drm/i915/intel_uncore.c | 556 ---
drivers/gpu/drm/i915/selftests/intel_lrc.c|2 +
.../drm/i915/selftests/intel_workarounds.c|1 +
18 files changed, 1483 insertions(+), 1472 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_reset.c
create mode 100644 drivers/gpu/drm/i915/i915_reset.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index c34bee16730d..65ed00db 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -40,9 +40,10 @@ i915-y := i915_drv.o \
i915_mm.o \
i915_params.o \
i915_pci.o \
+ i915_reset.o \
i915_suspend.o \
- i915_syncmap.o \
i915_sw_fence.o \
+ i915_syncmap.o \
i915_sysfs.o \
intel_csr.o \
intel_device_info.o \
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 8d738e6ca7b5..7f149622d1ff 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -32,6 +32,8 @@
#include "intel_drv.h"
#include "intel_guc_submission.h"
+#include "i915_reset.h"
+
static inline struct drm_i915_private *node_to_i915(struct drm_info_node *node)
{
return to_i915(node->minor->dev);
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index dafbbfadd1ad..f462a4d28af4 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -48,6 +48,7 @@
#include "i915_drv.h"
#include "i915_trace.h"
#include "i915_pmu.h"
+#include "i915_reset.h"
#include "i915_query.h"
#include "i915_vgpu.h"
#include "intel_drv.h"
@@ -2205,211 +2206,6 @@ static int i915_resume_switcheroo(struct drm_device
*dev)
return i915_drm_resume(dev);
}
-/**
- * i915_reset - reset chip after a hang
- * @i915: #drm_i915_private to reset
- * @stalled_mask: mask of the stalled engines with the guilty requests
- * @reason: user error message for why we are resetting
- *
- * Reset the chip. Useful if a hang is detected. Marks the device as wedged
- * on failure.
- *
- * Caller must hold the struct_mutex.
- *
- * Procedure is fairly simple:
- * - reset the chip using the reset reg
- * - re-init context state
- * - re-init hardware status page
- * - re-init ring buffer
- * - re-init interrupt state
- * - re-init display
- */
-void i915_reset(struct drm_i915_private *i915,
- unsigned int stalled_mask,
- const char *reason)
-{
- struct i915_gpu_error *error = >gpu_error;
- int ret;
- int i;
-
- GEM_TRACE("flags=%lx\n", error->flags);
-
- might_sleep();
- lockdep_assert_held(>drm.struct_mutex);
- assert_rpm_wakelock_held(i915);
- GEM_BUG_ON(!test_bit(I915_RESET_BACKOFF, >flags));
-
- if (!test_bit(I915_RESET_HANDOFF, >flags))
- return;
-
- /* Clear any previous failed attempts at recovery. Time to try again. */
- if (!i915_gem_unset_wedged(i915))
- goto wakeup;
-
- if (reason)
- dev_notice(i915->drm.dev, "Resetting chip for %s\n", reason);
- error->reset_count++;
-
- ret = i915_gem_reset_prepare(i915);
- if (ret) {
- dev_err(i915->drm.dev, "GPU recovery failed\n");
- goto taint;
- }
-
- if (!intel_has_gpu_reset(i915)) {
- if (i915_modparams.reset)
- dev_err(i915->drm.dev, "GPU reset not supported\n");
- else
- DRM_DEBUG_DRIVER("GPU reset disabled\n");
- goto error;
- }
-
- for (i = 0; i < 3; i++) {
- ret = intel_gpu_reset(i915, ALL_ENGINES);
- if (ret == 0)
- break;
-
- msleep(100);
- }
- if (ret) {
- dev_err(i915->drm.dev, "Failed to reset chip\n");
-
Re: [Intel-gfx] [PATCH 3/8] drm/i915: Pull all the reset functionality together into i915_reset.c
Quoting Mika Kuoppala (2019-01-16 15:06:37) > Chris Wilson writes: > > > Currently the code to reset the GPU and our state is spread widely > > across a few files. Pull the logic together into a common file. > > > > Signed-off-by: Chris Wilson > > Dunno how it goes but gut feeling that this would have > been better at the end of series after the dust has settled. Or perhaps if we applied it last June... :) -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: Pull all the reset functionality together into i915_reset.c
Chris Wilson writes:
> Currently the code to reset the GPU and our state is spread widely
> across a few files. Pull the logic together into a common file.
>
> Signed-off-by: Chris Wilson
Dunno how it goes but gut feeling that this would have
been better at the end of series after the dust has settled.
Regardless,
Acked-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/Makefile |3 +-
> drivers/gpu/drm/i915/i915_debugfs.c |2 +
> drivers/gpu/drm/i915/i915_drv.c | 206 +--
> drivers/gpu/drm/i915/i915_drv.h | 33 +-
> drivers/gpu/drm/i915/i915_gem.c | 446 +-
> drivers/gpu/drm/i915/i915_gem_gtt.c |1 +
> drivers/gpu/drm/i915/i915_irq.c | 238 ---
> drivers/gpu/drm/i915/i915_request.c |1 +
> drivers/gpu/drm/i915/i915_reset.c | 1389 +
> drivers/gpu/drm/i915/i915_reset.h | 56 +
> drivers/gpu/drm/i915/intel_display.c | 15 +-
> drivers/gpu/drm/i915/intel_engine_cs.c|1 +
> drivers/gpu/drm/i915/intel_guc.h |3 +
> drivers/gpu/drm/i915/intel_hangcheck.c|1 +
> drivers/gpu/drm/i915/intel_uc.c |1 +
> drivers/gpu/drm/i915/intel_uncore.c | 556 ---
> drivers/gpu/drm/i915/selftests/intel_lrc.c|2 +
> .../drm/i915/selftests/intel_workarounds.c|1 +
> 18 files changed, 1483 insertions(+), 1472 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/i915_reset.c
> create mode 100644 drivers/gpu/drm/i915/i915_reset.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index c34bee16730d..65ed00db 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -40,9 +40,10 @@ i915-y := i915_drv.o \
> i915_mm.o \
> i915_params.o \
> i915_pci.o \
> + i915_reset.o \
> i915_suspend.o \
> - i915_syncmap.o \
> i915_sw_fence.o \
> + i915_syncmap.o \
> i915_sysfs.o \
> intel_csr.o \
> intel_device_info.o \
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index da6d2581cb0e..a93abb2274e6 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -32,6 +32,8 @@
> #include "intel_drv.h"
> #include "intel_guc_submission.h"
>
> +#include "i915_reset.h"
> +
> static inline struct drm_i915_private *node_to_i915(struct drm_info_node
> *node)
> {
> return to_i915(node->minor->dev);
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index dafbbfadd1ad..f462a4d28af4 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -48,6 +48,7 @@
> #include "i915_drv.h"
> #include "i915_trace.h"
> #include "i915_pmu.h"
> +#include "i915_reset.h"
> #include "i915_query.h"
> #include "i915_vgpu.h"
> #include "intel_drv.h"
> @@ -2205,211 +2206,6 @@ static int i915_resume_switcheroo(struct drm_device
> *dev)
> return i915_drm_resume(dev);
> }
>
> -/**
> - * i915_reset - reset chip after a hang
> - * @i915: #drm_i915_private to reset
> - * @stalled_mask: mask of the stalled engines with the guilty requests
> - * @reason: user error message for why we are resetting
> - *
> - * Reset the chip. Useful if a hang is detected. Marks the device as wedged
> - * on failure.
> - *
> - * Caller must hold the struct_mutex.
> - *
> - * Procedure is fairly simple:
> - * - reset the chip using the reset reg
> - * - re-init context state
> - * - re-init hardware status page
> - * - re-init ring buffer
> - * - re-init interrupt state
> - * - re-init display
> - */
> -void i915_reset(struct drm_i915_private *i915,
> - unsigned int stalled_mask,
> - const char *reason)
> -{
> - struct i915_gpu_error *error = >gpu_error;
> - int ret;
> - int i;
> -
> - GEM_TRACE("flags=%lx\n", error->flags);
> -
> - might_sleep();
> - lockdep_assert_held(>drm.struct_mutex);
> - assert_rpm_wakelock_held(i915);
> - GEM_BUG_ON(!test_bit(I915_RESET_BACKOFF, >flags));
> -
> - if (!test_bit(I915_RESET_HANDOFF, >flags))
> - return;
> -
> - /* Clear any previous failed attempts at recovery. Time to try again. */
> - if (!i915_gem_unset_wedged(i915))
> - goto wakeup;
> -
> - if (reason)
> - dev_notice(i915->drm.dev, "Resetting chip for %s\n", reason);
> - error->reset_count++;
> -
> - ret = i915_gem_reset_prepare(i915);
> - if (ret) {
> - dev_err(i915->drm.dev, "GPU recovery failed\n");
> - goto taint;
> - }
> -
> - if (!intel_has_gpu_reset(i915)) {
> - if (i915_modparams.reset)
> - dev_err(i915->drm.dev, "GPU reset not supported\n");
> - else
> - DRM_DEBUG_DRIVER("GPU reset
