Re: [Intel-gfx] [PATCH 1/2] drm/i915: Update virtual PCH in single function
On Thu, 31 May 2018, "Xu, Colin" wrote: > Hi Jani, any comments? Without correct PCH type, BXT in virtualization > will fail to boot due to display initialization fail. If any more > input required, please kindly let me know. See [1] and please provide your Tested-by and/or Reviewed-by on the relevant patches. Thanks, Jani. [1] https://patchwork.freedesktop.org/series/43986/ -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/5] drm/i915/gem: be more strict about HAS_PCH_NOP() usage
HAS_PCH_NOP() implies a PCH platform without south display, not generic
disabled display. Prefer num_pipes == 0 for PCH independent checks.
Cc: Ville Syrjala
Cc: Chris Wilson
Signed-off-by: Jani Nikula
---
I'm actually not sure about this. What should VLV, CHV, BXT and GLK do
in this branch if display gets disabled? See next patch.
---
drivers/gpu/drm/i915/i915_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 530d6d0109b4..d6be1a08848d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5137,7 +5137,7 @@ int i915_gem_init_hw(struct drm_i915_private *dev_priv)
I915_WRITE(MI_PREDICATE_RESULT_2, IS_HSW_GT3(dev_priv) ?
LOWER_SLICE_ENABLED : LOWER_SLICE_DISABLED);
- if (HAS_PCH_NOP(dev_priv)) {
+ if (INTEL_INFO(dev_priv)->num_pipes == 0) {
if (IS_IVYBRIDGE(dev_priv)) {
u32 temp = I915_READ(GEN7_MSG_CTL);
temp &= ~(WAIT_FOR_PCH_FLR_ACK |
WAIT_FOR_PCH_RESET_ACK);
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/5] drm/i915: clean up virtual PCH special case handling
Use intel_pch_type() also for mapping the no PCH case (PCH id 0) to
PCH_NONE to simplify code.
Also make sure that intel_pch_type() knows all the PCH ids returned by
intel_virt_detect_pch(). Loudly fail if this isn't the case; this
shouldn't happen anyway.
Cc: Colin Xu
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index c42e389a27f3..1842a067a604 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -282,13 +282,12 @@ static void intel_detect_pch(struct drm_i915_private
*dev_priv)
} else if (intel_is_virt_pch(id, pch->subsystem_vendor,
pch->subsystem_device)) {
id = intel_virt_detect_pch(dev_priv);
- if (id) {
- pch_type = intel_pch_type(dev_priv, id);
- if (WARN_ON(pch_type == PCH_NONE))
- pch_type = PCH_NOP;
- } else {
- pch_type = PCH_NONE;
- }
+ pch_type = intel_pch_type(dev_priv, id);
+
+ /* Sanity check virtual PCH id */
+ if (WARN_ON(id && pch_type == PCH_NONE))
+ id = 0;
+
dev_priv->pch_type = pch_type;
dev_priv->pch_id = id;
break;
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/5] drm/i915: fix guest virtual PCH detection on non-PCH systems
Virtualized non-PCH systems such as Broxton or Geminilake should use
PCH_NONE to indicate no PCH rather than PCH_NOP. The latter is a
specific case to indicate a PCH system without south display.
Reported-by: Colin Xu
Cc: Colin Xu
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 8f002ae22e62..c42e389a27f3 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -287,7 +287,7 @@ static void intel_detect_pch(struct drm_i915_private
*dev_priv)
if (WARN_ON(pch_type == PCH_NONE))
pch_type = PCH_NOP;
} else {
- pch_type = PCH_NOP;
+ pch_type = PCH_NONE;
}
dev_priv->pch_type = pch_type;
dev_priv->pch_id = id;
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/5] drm/i915: be more strict about HAS_PCH_NOP() usage
HAS_PCH_NOP() implies a PCH platform without south display, not generic
disabled display. Prefer num_pipes == 0 for PCH independent checks.
Cc: Ville Syrjala
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_bios.c | 2 +-
drivers/gpu/drm/i915/intel_i2c.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 1cf073b6ac8a..94428633a9d3 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1700,7 +1700,7 @@ void intel_bios_init(struct drm_i915_private *dev_priv)
const struct bdb_header *bdb;
u8 __iomem *bios = NULL;
- if (HAS_PCH_NOP(dev_priv)) {
+ if (INTEL_INFO(dev_priv)->num_pipes == 0) {
DRM_DEBUG_KMS("Skipping VBT init due to disabled display.\n");
return;
}
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index e6875509bcd9..61729bf84e08 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -771,7 +771,7 @@ int intel_setup_gmbus(struct drm_i915_private *dev_priv)
unsigned int pin;
int ret;
- if (HAS_PCH_NOP(dev_priv))
+ if (INTEL_INFO(dev_priv)->num_pipes == 0)
return 0;
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/5] drm/i915: fix PCH_NOP setting for non-PCH platforms
Setting PCH type to PCH_NOP before checking whether we actually have a
PCH ends up returning true for HAS_PCH_SPLIT() on all non-PCH split
platforms. Fix this by using PCH_NOP only for platforms that actually
have a PCH.
Cc: Ville Syrjala
Signed-off-by: Jani Nikula
---
Should we log this with "Found No Point PCH"? ;)
---
drivers/gpu/drm/i915/i915_drv.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 1842a067a604..5deee698881b 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -246,14 +246,6 @@ static void intel_detect_pch(struct drm_i915_private
*dev_priv)
{
struct pci_dev *pch = NULL;
- /* In all current cases, num_pipes is equivalent to the PCH_NOP setting
-* (which really amounts to a PCH but no South Display).
-*/
- if (INTEL_INFO(dev_priv)->num_pipes == 0) {
- dev_priv->pch_type = PCH_NOP;
- return;
- }
-
/*
* The reason to probe ISA bridge instead of Dev31:Fun0 is to
* make graphics device passthrough work easy for VMM, that only
@@ -293,6 +285,17 @@ static void intel_detect_pch(struct drm_i915_private
*dev_priv)
break;
}
}
+
+ /*
+* Use PCH_NOP (PCH but no South Display) for PCH platforms without
+* display.
+*/
+ if (pch && INTEL_INFO(dev_priv)->num_pipes == 0) {
+ DRM_DEBUG_KMS("Display disabled, reverting to NOP PCH\n");
+ dev_priv->pch_type = PCH_NOP;
+ dev_priv->pch_id = 0;
+ }
+
if (!pch)
DRM_DEBUG_KMS("No PCH found.\n");
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] gpu: drm: i915: Change return type to vm_fault_t
On Thu, 31 May 2018, Souptick Joarder wrote:
> On Mon, May 21, 2018 at 4:48 PM, Souptick Joarder
> wrote:
>> On Thu, May 17, 2018 at 10:40 AM, Souptick Joarder
>> wrote:
>>> On Thu, May 17, 2018 at 12:48 AM, Chris Wilson
>>> wrote:
Quoting Souptick Joarder (2018-05-16 20:12:20)
> Use new return type vm_fault_t for fault handler. For
> now, this is just documenting that the function returns
> a VM_FAULT value rather than an errno. Once all instances
> are converted, vm_fault_t will become a distinct type.
>
> commit 1c8f422059ae ("mm: change return type to vm_fault_t")
>
> Fixed one checkpatch.pl warning inside WARN_ONCE.
>
> Signed-off-by: Souptick Joarder
> ---
> diff --git a/drivers/gpu/drm/i915/i915_gem.c
> b/drivers/gpu/drm/i915/i915_gem.c
> index dd89abd..732abdf 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1882,7 +1882,7 @@ int i915_gem_mmap_gtt_version(void)
> * The current feature set supported by i915_gem_fault() and thus GTT
> mmaps
> * is exposed via I915_PARAM_MMAP_GTT_VERSION (see
> i915_gem_mmap_gtt_version).
> */
> -int i915_gem_fault(struct vm_fault *vmf)
> +vm_fault_t i915_gem_fault(struct vm_fault *vmf)
> {
> #define MIN_CHUNK_PAGES ((1 << 20) >> PAGE_SHIFT) /* 1 MiB */
> struct vm_area_struct *area = vmf->vma;
> @@ -1894,7 +1894,8 @@ int i915_gem_fault(struct vm_fault *vmf)
> struct i915_vma *vma;
> pgoff_t page_offset;
> unsigned int flags;
> - int ret;
> + int err;
> + vm_fault_t ret = VM_FAULT_SIGBUS;
>
> /* We don't use vmf->pgoff since that has the fake offset */
> page_offset = (vmf->address - area->vm_start) >> PAGE_SHIFT;
> @@ -2027,8 +2028,7 @@ int i915_gem_fault(struct vm_fault *vmf)
> ret = VM_FAULT_SIGBUS;
> break;
> default:
> - WARN_ONCE(ret, "unhandled error in i915_gem_fault: %i\n",
> ret);
> - ret = VM_FAULT_SIGBUS;
> + WARN_ONCE(ret, "unhandled error in %s: %x\n", __func__,
> err);
> break;
Even simpler would be to use e.g. return VM_FAULT_SIGBUS for each case
above. No early initialisation of use-once variables allowing the
compiler to do it's job. For a smaller patch, you can even skip the
s/ret/err/
-Chris
>>>
>>> Chris,
>>> I prefer to use return once at the end of the function rather than
>>> writing multiple return statement (Current code is doing similar).
>>> But if you think other way, I can make that change :)
>>
>> If no further comment, we would like to get this patch
>> in queue for 4.18
For gpu drivers, that ship had sailed before you sent the patch. It'll
be v4.19.
I'll let Chris comment if changes are needed or not.
BR,
Jani.
>
> We need to get this patch in queue for 4.18.
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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 v4] gpu: drm: i915: Change return type to vm_fault_t
On Mon, May 21, 2018 at 4:48 PM, Souptick Joarder wrote:
> On Thu, May 17, 2018 at 10:40 AM, Souptick Joarder
> wrote:
>> On Thu, May 17, 2018 at 12:48 AM, Chris Wilson
>> wrote:
>>> Quoting Souptick Joarder (2018-05-16 20:12:20)
Use new return type vm_fault_t for fault handler. For
now, this is just documenting that the function returns
a VM_FAULT value rather than an errno. Once all instances
are converted, vm_fault_t will become a distinct type.
commit 1c8f422059ae ("mm: change return type to vm_fault_t")
Fixed one checkpatch.pl warning inside WARN_ONCE.
Signed-off-by: Souptick Joarder
---
>>>
diff --git a/drivers/gpu/drm/i915/i915_gem.c
b/drivers/gpu/drm/i915/i915_gem.c
index dd89abd..732abdf 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1882,7 +1882,7 @@ int i915_gem_mmap_gtt_version(void)
* The current feature set supported by i915_gem_fault() and thus GTT
mmaps
* is exposed via I915_PARAM_MMAP_GTT_VERSION (see
i915_gem_mmap_gtt_version).
*/
-int i915_gem_fault(struct vm_fault *vmf)
+vm_fault_t i915_gem_fault(struct vm_fault *vmf)
{
#define MIN_CHUNK_PAGES ((1 << 20) >> PAGE_SHIFT) /* 1 MiB */
struct vm_area_struct *area = vmf->vma;
@@ -1894,7 +1894,8 @@ int i915_gem_fault(struct vm_fault *vmf)
struct i915_vma *vma;
pgoff_t page_offset;
unsigned int flags;
- int ret;
+ int err;
+ vm_fault_t ret = VM_FAULT_SIGBUS;
/* We don't use vmf->pgoff since that has the fake offset */
page_offset = (vmf->address - area->vm_start) >> PAGE_SHIFT;
@@ -2027,8 +2028,7 @@ int i915_gem_fault(struct vm_fault *vmf)
ret = VM_FAULT_SIGBUS;
break;
default:
- WARN_ONCE(ret, "unhandled error in i915_gem_fault: %i\n",
ret);
- ret = VM_FAULT_SIGBUS;
+ WARN_ONCE(ret, "unhandled error in %s: %x\n", __func__,
err);
break;
>>>
>>> Even simpler would be to use e.g. return VM_FAULT_SIGBUS for each case
>>> above. No early initialisation of use-once variables allowing the
>>> compiler to do it's job. For a smaller patch, you can even skip the
>>> s/ret/err/
>>> -Chris
>>
>> Chris,
>> I prefer to use return once at the end of the function rather than
>> writing multiple return statement (Current code is doing similar).
>> But if you think other way, I can make that change :)
>
> If no further comment, we would like to get this patch
> in queue for 4.18
We need to get this patch in queue for 4.18.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Configure SKL+ scaler initial phase correctly
Thank you.
Reviewed-By: Vidya Srinivas
> -Original Message-
> From: Ville Syrjala [mailto:ville.syrj...@linux.intel.com]
> Sent: Tuesday, May 22, 2018 12:26 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Srinivas, Vidya ; Maarten Lankhorst
>
> Subject: [PATCH 2/2] drm/i915: Configure SKL+ scaler initial phase correctly
>
> From: Ville Syrjälä
>
> Set up the SKL+ scaler initial phase registers correctly. Otherwise we start
> fetching the data from the center of the first pixel instead of the top-left
> corner, which obviously then leads to right/bottom edges replicating data
> excessively as the data runs out half a pixel too soon.
>
> Cc: Vidya Srinivas
> Cc: Maarten Lankhorst
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_reg.h | 4
> drivers/gpu/drm/i915/intel_display.c | 41
>
> drivers/gpu/drm/i915/intel_drv.h | 1 +
> drivers/gpu/drm/i915/intel_sprite.c | 26 +--
> 4 files changed, 70 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h index 196a0eb79272..094527403ede
> 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6774,6 +6774,10 @@ enum {
> #define _PS_VPHASE_1B 0x68988
> #define _PS_VPHASE_2B 0x68A88
> #define _PS_VPHASE_1C 0x69188
> +#define PS_Y_PHASE(x) ((x) << 16)
> +#define PS_UV_RGB_PHASE(x) ((x) << 0)
> +#define PS_PHASE_MASK (0x7fff << 1) /* u2.13 */
> +#define PS_PHASE_TRIP (1 << 0)
>
> #define _PS_HPHASE_1A 0x68194
> #define _PS_HPHASE_2A 0x68294
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 42c1f4a56556..07185644a88a 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4729,6 +4729,39 @@ static void cpt_verify_modeset(struct
> drm_device *dev, int pipe)
> }
> }
>
> +/*
> + * The hardware phase 0.0 refers to the center of the pixel.
> + * We want to start from the top/left edge which is phase
> + * -0.5. That matches how the hardware calculates the scaling
> + * factors (from top-left of the first pixel to bottom-right
> + * of the last pixel, as opposed to the pixel centers).
> + *
> + * For 4:2:0 subsampled chroma planes we obviously have to
> + * adjust that so that the chroma sample position lands in
> + * the right spot.
> + *
> + * Note that for packed YCbCr 4:2:2 formats there is no way to
> + * control chroma siting. The hardware simply replicates the
> + * chroma samples for both of the luma samples, and thus we don't
> + * actually get the expected MPEG2 chroma siting convention :(
> + * The same behaviour is observed on pre-SKL platforms as well.
> + */
> +u16 skl_scaler_calc_phase(int sub, bool chroma_cosited) {
> + int phase = -0x8000;
> + u16 trip = 0;
> +
> + if (chroma_cosited)
> + phase += (sub - 1) * 0x8000 / sub;
> +
> + if (phase < 0)
> + phase = 0x1 + phase;
> + else
> + trip = PS_PHASE_TRIP;
> +
> + return ((phase >> 2) & PS_PHASE_MASK) | trip; }
> +
> static int
> skl_update_scaler(struct intel_crtc_state *crtc_state, bool force_detach,
> unsigned int scaler_user, int *scaler_id, @@ -4928,14
> +4961,22 @@ static void skylake_pfit_enable(struct intel_crtc *crtc)
> >config->scaler_state;
>
> if (crtc->config->pch_pfit.enabled) {
> + u16 uv_rgb_hphase, uv_rgb_vphase;
> int id;
>
> if (WARN_ON(crtc->config->scaler_state.scaler_id < 0))
> return;
>
> + uv_rgb_hphase = skl_scaler_calc_phase(1, false);
> + uv_rgb_vphase = skl_scaler_calc_phase(1, false);
> +
> id = scaler_state->scaler_id;
> I915_WRITE(SKL_PS_CTRL(pipe, id), PS_SCALER_EN |
> PS_FILTER_MEDIUM | scaler_state-
> >scalers[id].mode);
> + I915_WRITE_FW(SKL_PS_VPHASE(pipe, id),
> + PS_Y_PHASE(0) |
> PS_UV_RGB_PHASE(uv_rgb_vphase));
> + I915_WRITE_FW(SKL_PS_HPHASE(pipe, id),
> + PS_Y_PHASE(0) |
> PS_UV_RGB_PHASE(uv_rgb_hphase));
> I915_WRITE(SKL_PS_WIN_POS(pipe, id), crtc->config-
> >pch_pfit.pos);
> I915_WRITE(SKL_PS_WIN_SZ(pipe, id), crtc->config-
> >pch_pfit.size);
> }
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 42a59b7fd736..0f1dbfcf8538 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1621,6 +1621,7 @@ void intel_mode_from_pipe_config(struct
> drm_display_mode *mode, void intel_crtc_arm_fifo_underrun(struct
> intel_crtc *crtc,
> struct intel_crtc_state *crtc_state);
>
> +u16 skl_scaler_calc_phase(int sub, bool chroma_center);
> int
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Remove bogus NV12 PLANE_COLOR_CTL setup
Thank you.
Reviewed-By: Vidya Srinivas
> -Original Message-
> From: Ville Syrjala [mailto:ville.syrj...@linux.intel.com]
> Sent: Tuesday, May 22, 2018 12:26 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Srinivas, Vidya ; Maarten Lankhorst
>
> Subject: [PATCH 1/2] drm/i915: Remove bogus NV12 PLANE_COLOR_CTL
> setup
>
> From: Ville Syrjälä
>
> We already handle the color encoding mode properly. Remove the broken
> NV12 special case.
>
> Cc: Vidya Srinivas
> Cc: Maarten Lankhorst
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index f5c078c9d0d2..42c1f4a56556 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3643,11 +3643,6 @@ u32 glk_plane_color_ctl(const struct
> intel_crtc_state *crtc_state,
> plane_color_ctl |= glk_plane_color_ctl_alpha(fb->format->format);
>
> if (intel_format_is_yuv(fb->format->format)) {
> - if (fb->format->format == DRM_FORMAT_NV12) {
> - plane_color_ctl |=
> -
> PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
> - goto out;
> - }
> if (plane_state->base.color_encoding ==
> DRM_COLOR_YCBCR_BT709)
> plane_color_ctl |=
> PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
> else
> @@ -3656,7 +3651,7 @@ u32 glk_plane_color_ctl(const struct
> intel_crtc_state *crtc_state,
> if (plane_state->base.color_range ==
> DRM_COLOR_YCBCR_FULL_RANGE)
> plane_color_ctl |=
> PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE;
> }
> -out:
> +
> return plane_color_ctl;
> }
>
> --
> 2.16.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Update virtual PCH in single function
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Colin Xu
>Sent: Wednesday, May 30, 2018 14:26
>To: Nikula, Jani ; intel-gfx@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [PATCH 1/2] drm/i915: Update virtual PCH in single
>function
>
>On 05/29/2018 01:45 PM, Jani Nikula wrote:
>
>> On Wed, 30 May 2018, Colin Xu wrote:
>>> On 05/28/2018 09:42 PM, Jani Nikula wrote:
On Mon, 28 May 2018, Jani Nikula wrote:
> On Mon, 28 May 2018, Jani Nikula wrote:
>> On Tue, 29 May 2018, colin...@intel.com wrote:
>>> From: Colin Xu
>>>
>>> The existing way to update virtual PCH will return wrong PCH type
>>> in case the host doesn't have PCH:
>>> - intel_virt_detect_pch returns guessed PCH id 0
>>> - id 0 maps to PCH_NOP. >> should be PCH_NONE.
>>> Since PCH_NONE and PCH_NOP are different types, mixing them up
>>> will break vbt initialization logic.
>>>
>>> In addition, to add new none/nop PCH override for a specific
>>> platform, branching need to be added to intel_virt_detect_pch(),
>>> intel_pch_type() and the caller since none/nop PCH is not always
>>> mapping to the same predefined PCH id.
>>>
>>> This patch merges the virtual PCH update/sanity check logic into
>>> single function intel_virt_update_pch(), which still keeps using
>>> existing intel_pch_type() to do the sanity check, while making it
>>> clean to override virtual PCH id for a specific platform for future
>>> platform enablement.
>> Please keep the assignment out of intel_virt_{detect,update}_pch like. I
>> think the patch here is unnecessarily complicated.
> To elaborate, intel_pch_type() should *always* be able to map pch id to
> pch type. There should not be combinations that aren't covered by
> that. If the sanity checks there need to accept Broxton as well, perhaps
> pass a parameter to indicate virtualization, and accept certain pch ids
> for Broxton as well.
>
> If you're faking a pch for Broxton, I don't think there's a case where
> pch id should be 0 and pch type should be something else. Either both
> are zero, or both are non-zero.
-ENOCOFFEE in the morning. Is the fix you're looking for simply:
>>> Yes this is the most simply way.
>>> The reason I didn't craft the patch like this in the beginning is that
>>> I'm not sure after your refactoring patch, if the case exists that pch
>>> id 0 maps to type either nop or none.
>>> As you said there is no such case, the simply change should work well.
>>> Will you made the change sometime or I need update my patch set?
>> I was trying to look at which part of my refactoring broke this, but it
>> seems to me it was already setting pch_type to PCH_NOP before that.
>>
>> Do you have a bisect result?
>
>It doesnt' seem being broken by the refactoring. Since Broxton isn't supported
>in virtualization environemtn before, the issue is covered up.
>In native case, intel_pch_type() returns none since there is no PCH hardware
>and it works correctly. In virutalization, we expect the same.
>--
Hi Jani, any comments? Without correct PCH type, BXT in virtualization
will fail to boot due to display initialization fail. If any more input
required,
please kindly let me know.
BR,
Colin Xu
>
>>
>> BR,
>> Jani.
>>
>>
>>
>
>___
>Intel-gfx mailing list
>Intel-gfx@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 2/6] drm/i915: hdmi: add CEC notifier to intel_hdmi
On Wed, May 30, 2018 at 06:29:36PM +0300, Ville Syrjälä wrote:
> On Thu, May 24, 2018 at 11:57:17AM +0200, Neil Armstrong wrote:
> > This patchs adds the cec_notifier feature to the intel_hdmi part
> > of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate
> > between each HDMI ports.
> > The changes will allow the i915 HDMI code to notify EDID and HPD changes
> > to an eventual CEC adapter.
> >
> > Signed-off-by: Neil Armstrong
> > Reviewed-by: Hans Verkuil
> > ---
> > drivers/gpu/drm/i915/Kconfig | 1 +
> > drivers/gpu/drm/i915/intel_display.h | 20
> > drivers/gpu/drm/i915/intel_drv.h | 2 ++
> > drivers/gpu/drm/i915/intel_hdmi.c| 13 +
> > 4 files changed, 36 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> > index dfd9588..2d65d56 100644
> > --- a/drivers/gpu/drm/i915/Kconfig
> > +++ b/drivers/gpu/drm/i915/Kconfig
> > @@ -23,6 +23,7 @@ config DRM_I915
> > select SYNC_FILE
> > select IOSF_MBI
> > select CRC32
> > + select CEC_CORE if CEC_NOTIFIER
> > help
> > Choose this option if you have a system that has "Intel Graphics
> > Media Accelerator" or "HD Graphics" integrated graphics,
> > diff --git a/drivers/gpu/drm/i915/intel_display.h
> > b/drivers/gpu/drm/i915/intel_display.h
> > index 4e7418b..c68d1c8 100644
> > --- a/drivers/gpu/drm/i915/intel_display.h
> > +++ b/drivers/gpu/drm/i915/intel_display.h
> > @@ -126,6 +126,26 @@ enum port {
> >
> > #define port_name(p) ((p) + 'A')
> >
> > +static inline const char *port_identifier(enum port port)
> > +{
> > + switch (port) {
> > + case PORT_A:
> > + return "Port A";
> > + case PORT_B:
> > + return "Port B";
> > + case PORT_C:
> > + return "Port C";
> > + case PORT_D:
> > + return "Port D";
> > + case PORT_E:
> > + return "Port E";
> > + case PORT_F:
> > + return "Port F";
> > + default:
> > + return "";
> > + }
> > +}
>
> Could use a comment to make it clear that this identifier is
> expected to remain stable since it's referenced from other drivers.
>
> > +
> > enum dpio_channel {
> > DPIO_CH0,
> > DPIO_CH1
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index d436858..b50e51b 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -39,6 +39,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > /**
> > * __wait_for - magic wait macro
> > @@ -1001,6 +1002,7 @@ struct intel_hdmi {
> > bool has_audio;
> > bool rgb_quant_range_selectable;
> > struct intel_connector *attached_connector;
> > + struct cec_notifier *notifier;
>
> "notifier" seems a bit too generic a name. "cec_notifier" would be
> better.
>
> Apart from that this seems OK to me
> Reviewed-by: Ville Syrjälä
It seems that you will need to push this to other trees right?
Feel free to use:
Acked-by: Rodrigo Vivi
>
> > };
> >
> > struct intel_dp_mst_encoder;
> > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> > b/drivers/gpu/drm/i915/intel_hdmi.c
> > index 1baef4a..d522b5b 100644
> > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> > @@ -1868,6 +1868,8 @@ intel_hdmi_set_edid(struct drm_connector *connector)
> > connected = true;
> > }
> >
> > + cec_notifier_set_phys_addr_from_edid(intel_hdmi->notifier, edid);
> > +
> > return connected;
> > }
> >
> > @@ -1876,6 +1878,7 @@ intel_hdmi_detect(struct drm_connector *connector,
> > bool force)
> > {
> > enum drm_connector_status status;
> > struct drm_i915_private *dev_priv = to_i915(connector->dev);
> > + struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
> >
> > DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
> > connector->base.id, connector->name);
> > @@ -1891,6 +1894,9 @@ intel_hdmi_detect(struct drm_connector *connector,
> > bool force)
> >
> > intel_display_power_put(dev_priv, POWER_DOMAIN_GMBUS);
> >
> > + if (status != connector_status_connected)
> > + cec_notifier_phys_addr_invalidate(intel_hdmi->notifier);
> > +
> > return status;
> > }
> >
> > @@ -2031,6 +2037,8 @@ static void chv_hdmi_pre_enable(struct intel_encoder
> > *encoder,
> >
> > static void intel_hdmi_destroy(struct drm_connector *connector)
> > {
> > + if (intel_attached_hdmi(connector)->notifier)
> > + cec_notifier_put(intel_attached_hdmi(connector)->notifier);
> > kfree(to_intel_connector(connector)->detect_edid);
> > drm_connector_cleanup(connector);
> > kfree(connector);
> > @@ -2358,6 +2366,11 @@ void intel_hdmi_init_connector(struct
> > intel_digital_port *intel_dig_port,
> > u32 temp = I915_READ(PEG_BAND_GAP_DATA);
> > I915_WRITE(PEG_BAND_GAP_DATA, (temp & ~0xf) | 0xd);
> > }
> > +
> > +
[Intel-gfx] [PATCH i-g-t 2/2] igt/gem_userptr: Check read-only mappings
Setup a userptr object that only has a read-only mapping back to a file
store (memfd). Then attempt to write into that mapping using the GPU and
assert that those writes do not land (while also writing via a writable
userptr mapping into the same memfd to verify that the GPU is working!)
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
configure.ac | 1 +
lib/ioctl_wrappers.c | 4 +-
lib/ioctl_wrappers.h | 4 +-
tests/Makefile.am | 4 +-
tests/gem_userptr_blits.c | 191 ++
5 files changed, 198 insertions(+), 6 deletions(-)
diff --git a/configure.ac b/configure.ac
index 2f6bc70ee..f5a059d6a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -125,6 +125,7 @@ PKG_CHECK_MODULES(PCIACCESS, [pciaccess >= 0.10])
PKG_CHECK_MODULES(KMOD, [libkmod])
PKG_CHECK_MODULES(PROCPS, [libprocps])
PKG_CHECK_MODULES(LIBUNWIND, [libunwind])
+PKG_CHECK_MODULES(SSL, [openssl])
PKG_CHECK_MODULES(VALGRIND, [valgrind], [have_valgrind=yes],
[have_valgrind=no])
if test x$have_valgrind = xyes; then
diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
index 79db44a8c..d5d2a4e4c 100644
--- a/lib/ioctl_wrappers.c
+++ b/lib/ioctl_wrappers.c
@@ -869,7 +869,7 @@ int gem_madvise(int fd, uint32_t handle, int state)
return madv.retained;
}
-int __gem_userptr(int fd, void *ptr, int size, int read_only, uint32_t flags,
uint32_t *handle)
+int __gem_userptr(int fd, void *ptr, uint64_t size, int read_only, uint32_t
flags, uint32_t *handle)
{
struct drm_i915_gem_userptr userptr;
@@ -898,7 +898,7 @@ int __gem_userptr(int fd, void *ptr, int size, int
read_only, uint32_t flags, ui
*
* Returns userptr handle for the GEM object.
*/
-void gem_userptr(int fd, void *ptr, int size, int read_only, uint32_t flags,
uint32_t *handle)
+void gem_userptr(int fd, void *ptr, uint64_t size, int read_only, uint32_t
flags, uint32_t *handle)
{
igt_assert_eq(__gem_userptr(fd, ptr, size, read_only, flags, handle),
0);
}
diff --git a/lib/ioctl_wrappers.h b/lib/ioctl_wrappers.h
index b966f72c9..8e2cd380b 100644
--- a/lib/ioctl_wrappers.h
+++ b/lib/ioctl_wrappers.h
@@ -133,8 +133,8 @@ struct local_i915_gem_userptr {
#define LOCAL_I915_USERPTR_UNSYNCHRONIZED (1<<31)
uint32_t handle;
};
-void gem_userptr(int fd, void *ptr, int size, int read_only, uint32_t flags,
uint32_t *handle);
-int __gem_userptr(int fd, void *ptr, int size, int read_only, uint32_t flags,
uint32_t *handle);
+void gem_userptr(int fd, void *ptr, uint64_t size, int read_only, uint32_t
flags, uint32_t *handle);
+int __gem_userptr(int fd, void *ptr, uint64_t size, int read_only, uint32_t
flags, uint32_t *handle);
void gem_sw_finish(int fd, uint32_t handle);
diff --git a/tests/Makefile.am b/tests/Makefile.am
index f41ad5096..ba307b220 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -126,8 +126,8 @@ gem_tiled_swapping_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
gem_tiled_swapping_LDADD = $(LDADD) -lpthread
prime_self_import_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
prime_self_import_LDADD = $(LDADD) -lpthread
-gem_userptr_blits_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
-gem_userptr_blits_LDADD = $(LDADD) -lpthread
+gem_userptr_blits_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS) $(SSL_CFLAGS)
+gem_userptr_blits_LDADD = $(LDADD) $(SSL_LIBS) -lpthread
perf_pmu_LDADD = $(LDADD) $(top_builddir)/lib/libigt_perf.la
gem_eio_LDADD = $(LDADD) -lrt
diff --git a/tests/gem_userptr_blits.c b/tests/gem_userptr_blits.c
index 0c2bdf5b2..2bfba4f04 100644
--- a/tests/gem_userptr_blits.c
+++ b/tests/gem_userptr_blits.c
@@ -46,10 +46,13 @@
#include
#include
#include
+#include
#include
#include
#include
+#include
+
#include "drm.h"
#include "i915_drm.h"
@@ -1075,6 +1078,191 @@ static int test_dmabuf(void)
return 0;
}
+static int test_readonly(int i915)
+{
+ unsigned char orig[SHA_DIGEST_LENGTH];
+ uint64_t aperture_size;
+ uint32_t whandle, rhandle;
+ uint32_t sz, total;
+ void *pages, *space;
+ int memfd;
+
+ /*
+* A small batch of pages; small enough to cheaply check for stray
+* writes but large enough that we don't create too many VMA pointing
+* back to this set from the large arena. The limit on total number
+* of VMA for a process is 65,536 (at least on this kernel).
+*/
+ sz = 16 << 12;
+ memfd = memfd_create("pages", 0);
+ igt_require(memfd != -1);
+ igt_require(ftruncate(memfd, sz) == 0);
+
+ pages = mmap(NULL, sz, PROT_WRITE, MAP_SHARED, memfd, 0);
+ igt_assert(pages != MAP_FAILED);
+
+ igt_require(__gem_userptr(i915, pages, sz, true, userptr_flags,
) == 0);
+ gem_close(i915, rhandle);
+
+ gem_userptr(i915, pages, sz, false, userptr_flags, );
+
+ total = 2048ull << 20;
+ aperture_size = gem_aperture_size(i915) / 2;
+ if (aperture_size > total)
+
[Intel-gfx] [PATCH i-g-t 1/2] igt/gem_userptr: Exercise new PROBE | POPULATE flags
Exercise new API to probe that the userptr range is valid (backed by
struct pages and not pfn) or to populate the userptr upon creation (by
calling get_user_pages() on the range).
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Michał Winiarski
---
tests/gem_userptr_blits.c | 140 ++
1 file changed, 140 insertions(+)
diff --git a/tests/gem_userptr_blits.c b/tests/gem_userptr_blits.c
index 7e3b6ef38..0c2bdf5b2 100644
--- a/tests/gem_userptr_blits.c
+++ b/tests/gem_userptr_blits.c
@@ -557,6 +557,140 @@ static int test_invalid_gtt_mapping(int fd)
return 0;
}
+static void store_dword(int fd, uint32_t target,
+ uint32_t offset, uint32_t value)
+{
+ const int gen = intel_gen(intel_get_drm_devid(fd));
+ struct drm_i915_gem_exec_object2 obj[2];
+ struct drm_i915_gem_relocation_entry reloc;
+ struct drm_i915_gem_execbuffer2 execbuf;
+ uint32_t batch[16];
+ int i;
+
+ memset(, 0, sizeof(execbuf));
+ execbuf.buffers_ptr = to_user_pointer(obj);
+ execbuf.buffer_count = ARRAY_SIZE(obj);
+ execbuf.flags = 0;
+ if (gen < 6)
+ execbuf.flags |= I915_EXEC_SECURE;
+
+ memset(obj, 0, sizeof(obj));
+ obj[0].handle = target;
+ obj[1].handle = gem_create(fd, 4096);
+
+ memset(, 0, sizeof(reloc));
+ reloc.target_handle = obj[0].handle;
+ reloc.presumed_offset = 0;
+ reloc.offset = sizeof(uint32_t);
+ reloc.delta = offset;
+ reloc.read_domains = I915_GEM_DOMAIN_RENDER;
+ reloc.write_domain = I915_GEM_DOMAIN_RENDER;
+ obj[1].relocs_ptr = to_user_pointer();
+ obj[1].relocation_count = 1;
+
+ i = 0;
+ batch[i] = MI_STORE_DWORD_IMM | (gen < 6 ? 1 << 22 : 0);
+ if (gen >= 8) {
+ batch[++i] = offset;
+ batch[++i] = 0;
+ } else if (gen >= 4) {
+ batch[++i] = 0;
+ batch[++i] = offset;
+ reloc.offset += sizeof(uint32_t);
+ } else {
+ batch[i]--;
+ batch[++i] = offset;
+ }
+ batch[++i] = value;
+ batch[++i] = MI_BATCH_BUFFER_END;
+ gem_write(fd, obj[1].handle, 0, batch, sizeof(batch));
+ gem_execbuf(fd, );
+ gem_close(fd, obj[1].handle);
+}
+
+#define LOCAL_USERPTR_PROBE 0x2
+#define LOCAL_USERPTR_POPULATE 0x4
+static void test_probe(int fd, unsigned int flags)
+{
+#define N_PAGES 5
+ struct drm_i915_gem_mmap_gtt mmap_gtt;
+ uint32_t handle;
+
+ igt_require(__gem_userptr(fd,
+ (void *)-PAGE_SIZE, 2*PAGE_SIZE, 0,
+ flags, ) == -EFAULT);
+
+ /*
+* We allocate 5 pages, and apply various combinations
+* of unmap, remap-gtt to the pages. Then we try to
+* create a userptr from the middle 3 pages and check
+* if unexpectedly succeeds or fails.
+*/
+ memset(_gtt, 0, sizeof(mmap_gtt));
+ mmap_gtt.handle = gem_create(fd, PAGE_SIZE);
+ drmIoctl(fd, DRM_IOCTL_I915_GEM_MMAP_GTT, _gtt);
+
+ for (unsigned long pass = 0; pass < 4 * 4 * 4 * 4 *4; pass++) {
+ int expected = 0;
+ void *ptr;
+
+ ptr = mmap(NULL, N_PAGES * PAGE_SIZE,
+ PROT_READ | PROT_WRITE,
+ MAP_SHARED | MAP_ANONYMOUS,
+ -1, 0);
+
+ for (int page = 0; page < N_PAGES; page++) {
+ int mode = (pass >> (2 * page)) & 3;
+ void *fixed = ptr + page * PAGE_SIZE;
+
+ switch (mode) {
+ default:
+ case 0:
+ break;
+
+ case 1:
+ munmap(fixed, PAGE_SIZE);
+ if (page >= 1 && page <= 3)
+ expected = -EFAULT;
+ break;
+
+ case 2:
+ fixed = mmap(fixed, PAGE_SIZE,
+PROT_READ | PROT_WRITE,
+MAP_SHARED | MAP_FIXED,
+fd, mmap_gtt.offset);
+ igt_assert(fixed != MAP_FAILED);
+ if (page >= 1 && page <= 3)
+ expected = -EFAULT;
+ break;
+ }
+ }
+
+ errno = 0;
+ handle = 0;
+ igt_assert_eq(__gem_userptr(fd, ptr + PAGE_SIZE, 3*PAGE_SIZE,
+ 0, flags, ),
+ expected);
+ if (handle) {
+ for (int page = 0; page < 3; page++)
+ store_dword(fd, handle,
Re: [Intel-gfx] [PATCH v2 01/13] drm/i915: Constify intel_plane_funcs
On Wed, May 30, 2018 at 10:00 AM Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> intel_plane funcs can be cosnt. Make it so.
s/cosnt/const
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 8d4c9e249c44..daca04b39eef 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13252,7 +13252,7 @@ static bool
> intel_cursor_plane_format_mod_supported(struct drm_plane *plane,
> return modifier == DRM_FORMAT_MOD_LINEAR && format ==
> DRM_FORMAT_ARGB;
> }
>
> -static struct drm_plane_funcs intel_plane_funcs = {
> +static const struct drm_plane_funcs intel_plane_funcs = {
> .update_plane = drm_atomic_helper_update_plane,
> .disable_plane = drm_atomic_helper_disable_plane,
> .destroy = intel_plane_destroy,
> --
> 2.16.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 02/13] drm/vmwgfx: Stop using plane->fb in vmw_kms_helper_dirty()
On Fri, May 25, 2018 at 09:50:34PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Instead of plane->fb (which we're going to deprecate for atomic drivers)
> we need to look at plane->state->fb. The maze of code leading to
> vmw_kms_helper_dirty() wasn't particularly clear, but my analysis
> concluded that the calls originating from vmw_*_primary_plane_atomic_update()
> all pass in the crtc which means we'll never end up in this branch
> of the function. All other callers use drm_modeset_lock_all() somewhere
> higher up, which means accessing plane->state is safe. We'll toss in
> a lockdep assert to catch wrongdoers.
>
> v2: Drop the comment and make the code do what it did before (Thomas)
>
> Cc: Deepak Rawat
> Cc: Thomas Hellstrom
> Cc: Sinclair Yeh
> Cc: VMware Graphics
> Cc: Daniel Vetter
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> index 2e4c38bb846d..5417eb1b486e 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> @@ -2326,9 +2326,12 @@ int vmw_kms_helper_dirty(struct vmw_private *dev_priv,
> } else {
> list_for_each_entry(crtc, _priv->dev->mode_config.crtc_list,
> head) {
> - if (crtc->primary->fb != >base)
> - continue;
> - units[num_units++] = vmw_crtc_to_du(crtc);
> + struct drm_plane *plane = crtc->primary;
> +
> + lockdep_assert_held(>mutex);
kbuild test robot told me
>> include/linux/lockdep.h:347:52: error: 'struct drm_modeset_lock' has
>> no member named 'dep_map'
#define lockdep_is_held(lock) lock_is_held(&(lock)->dep_map)
Maybe I'll just drop the asserts? Or do people really want them
(in which case I gues I need to dig out the underlying mutex)?
> +
> + if (plane->state->fb == >base)
> + units[num_units++] = vmw_crtc_to_du(crtc);
> }
> }
>
> --
> 2.16.1
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Promote .format_mod_supported() to the lead role
On Wed, May 30, 2018 at 11:30:26AM -0700, Eric Anholt wrote: > Ville Syrjälä writes: > > > On Mon, May 21, 2018 at 12:21:01PM -0700, Eric Anholt wrote: > >> Ville Syrjala writes: > >> > >> > From: Ville Syrjälä > >> > > >> > Up to now we've used the plane's modifier list as the primary > >> > source of information for which modifiers are supported by a > >> > given plane. In order to allow auxiliary metadata to be embedded > >> > within the bits of the modifier we need to stop doing that. > >> > > >> > Thus we have to make .format_mod_supported() aware of the plane's > >> > capabilities and gracefully deal with any modifier being passed > >> > in directly from userspace. > >> > >> This seems like it would be a lot shorter if you just had a helper to > >> check if your format and modifier was in drm_plane->format_types and > >> drm_plane->modifiers, since then you wouldn't be duplicating your tables > >> and you wouldn't need has_ccs either. > > > > I suppose. And I guess that's where I started originally :/ > > > > But I'm not sure if it's better go that route or the other route of > > reducing the arrays to some simple supersets and also utilize > > .format_mod_supported() in plane init to filter out the unsupported > > formats when populating the plane's format list. Probably best not > > dwell on this too much for now so that we can at least make some > > progress :) > > > >> > >> However, it's not my driver and it unblocks vc4's patch, so: > >> > >> Reviewed-by: Eric Anholt > > > > Thanks. I'm guessing we should push this into drm-misc-next so > > that you can pile your core/sand bits on top? > > That would be wonderful. Now pushed. Had to resolve a few nv12 conflicts each way. I guess someone else will get to deal with that same fun at some point -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Add WaKBLVECSSemaphoreWaitPoll
Quoting Mika Kuoppala (2018-05-30 16:02:06) > There is a problem with kbl up to rev E0 where a heavy > memory traffic from adjacent engine(s) can cause an engine > reset to fail. This traffic can be from normal memory accesses > or it can be from heavy polling on a semaphore wait. > > To combat the normal traffic, we do our best to idle the adjacent > engines, before we ask the engine to prepare for reset. For per > engine reset, this will add an unwanted extra latency as we > do blanket approach before every reset. In past already have > noticed that idling an engine before reset, improves our chances > of resetting it, but this only idles the engines we are about to > reset, not the adjancent ones. Unfortunately we don't have a lock on the other engines, so can't prevent two resets running in parallel clobbering state on the other. So what's stopping the failure mode of falling back to resetting all engines at once if resetting one fails? Is it a catastrophic failure? > We could only take the approach of idling adjacent engines, > if the first reset fails. But in this area, it is usually best > to get it right off the bat. > > For the second issue where unlimited semaphore wait poll loop > is generating the heavy memory traffic and preventing a reset, > we add one microsecond poll interval to semaphore wait to > guarantee bandwidth for the reset preration. The side effect > is that we make semaphore completion latencies also 1us longer. You know the rule: second issue, second patch. That's odd, I would have expected a MI_SEMA op to be an arbitration point (even inside the busy wait loop), so would have expected it to behave nicely with STOP_RING. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 12/13] drm/vc4: Stop updating plane->fb/crtc
Ville Syrjala writes: > From: Ville Syrjälä > > We want to get rid of plane->fb/crtc on atomic drivers. Stop setting > them. > > Cc: Eric Anholt > Signed-off-by: Ville Syrjälä > Reviewed-by: Maarten Lankhorst > Reviewed-by: Daniel Vetter Reviewed-by: Eric Anholt 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 i-g-t 2/3] lib: Align ring measurement to timer
Quoting Antonio Argenziano (2018-05-30 18:30:36) > > > On 30/05/18 03:33, Chris Wilson wrote: > > After hitting the SIGINT from execbuf, wait until the next timer signal > > before trying again. This aligns the start of the ioctl to the timer, > > hopefully maximising the amount of time we have for processing before > > the next signal -- trying to prevent the case where we are scheduled out > > in the middle of processing and so hit the timer signal too early. > > > > References: https://bugs.freedesktop.org/show_bug.cgi?id=106695 > > Signed-off-by: Chris Wilson > > Not sure I understand what is the sequence of events, is the problem we > get a signal in the middle of a 'good' execbuf and exit the while loop > prematurely? If so maybe we can also think of making the timer 'VIRTUAL' > so that it would decrement only when the process is executing. If it's VIRTUAL it'll never fire when we wait for space (as being asleep no user/sys time is consumed). The only way I can explain 106695 would be with some very strange scheduler behaviour, but even then it requires us to hit a path where we actually check for a pending signal -- which should only happen when we run out of ring space for this setup. Not even the device being wedged (which it wasn't) would cause the ring to drain. Possibly going over 10s and the cork being unplugged? Very stange. > > --- > > lib/i915/gem_ring.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/lib/i915/gem_ring.c b/lib/i915/gem_ring.c > > index 7d64165eb..0c061000c 100644 > > --- a/lib/i915/gem_ring.c > > +++ b/lib/i915/gem_ring.c > > @@ -96,6 +96,8 @@ __gem_measure_ring_inflight(int fd, unsigned int engine, > > enum measure_ring_flags > > if (last == count) > > break; > > > > + /* sleep until the next timer interrupt (woken on signal) */ > > + pause(); > > Does it cause any (sensible) slowdown? Adds at most one timer interval, 10us. Ok, at a push 2 timer intervals if it takes longer than first to setup the sleep. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/9] drm/pl111: Set .gem_prime_vmap and .gem_prime_mmap
Noralf Trønnes writes: > These are needed for pl111 to use the generic fbdev emulation. Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: Cancel reset preparations on failed resets
== Series Details == Series: series starting with [1/2] drm/i915: Cancel reset preparations on failed resets URL : https://patchwork.freedesktop.org/series/43957/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4257_full -> Patchwork_9152_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9152_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9152_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/43957/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9152_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-bsd1: shard-kbl: PASS -> SKIP igt@pm_rc6_residency@rc6-accuracy: shard-snb: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_9152_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_gtt: shard-glk: PASS -> INCOMPLETE (k.org#198133, fdo#103359) igt@kms_flip@basic-flip-vs-wf_vblank: shard-hsw: PASS -> FAIL (fdo#103928) igt@kms_flip@plain-flip-ts-check-interruptible: shard-hsw: PASS -> FAIL (fdo#100368) igt@kms_frontbuffer_tracking@fbc-suspend: shard-glk: PASS -> DMESG-WARN (fdo#106728) igt@kms_rotation_crc@cursor-rotation-180: shard-hsw: PASS -> FAIL (fdo#103925, fdo#104724) igt@pm_rpm@drm-resources-equal: shard-glk: PASS -> FAIL (fdo#106539) +1 Possible fixes igt@drv_selftest@live_hangcheck: shard-kbl: DMESG-FAIL (fdo#106560) -> PASS igt@gem_exec_parallel@render-fds: shard-snb: INCOMPLETE (fdo#105411) -> PASS igt@kms_flip@flip-vs-expired-vblank-interruptible: shard-glk: FAIL (fdo#105363) -> PASS igt@kms_flip@plain-flip-ts-check: shard-glk: FAIL (fdo#100368) -> PASS igt@kms_flip_tiling@flip-to-x-tiled: shard-glk: FAIL (fdo#104724) -> PASS igt@perf@blocking: shard-hsw: FAIL (fdo#102252) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925 fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411 fdo#106539 https://bugs.freedesktop.org/show_bug.cgi?id=106539 fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560 fdo#106728 https://bugs.freedesktop.org/show_bug.cgi?id=106728 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4257 -> Patchwork_9152 CI_DRM_4257: 8aac35d26057479982a346c0e9cd57c2e930b7e1 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4501: 6796a604bab6df9c84af149e799902360afdd157 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9152: 9ab18769303bacc835b8a6973e04ea77880e0cca @ git://anongit.freedesktop.org/gfx-ci/linux == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9152/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Promote .format_mod_supported() to the lead role
Ville Syrjälä writes: > On Mon, May 21, 2018 at 12:21:01PM -0700, Eric Anholt wrote: >> Ville Syrjala writes: >> >> > From: Ville Syrjälä >> > >> > Up to now we've used the plane's modifier list as the primary >> > source of information for which modifiers are supported by a >> > given plane. In order to allow auxiliary metadata to be embedded >> > within the bits of the modifier we need to stop doing that. >> > >> > Thus we have to make .format_mod_supported() aware of the plane's >> > capabilities and gracefully deal with any modifier being passed >> > in directly from userspace. >> >> This seems like it would be a lot shorter if you just had a helper to >> check if your format and modifier was in drm_plane->format_types and >> drm_plane->modifiers, since then you wouldn't be duplicating your tables >> and you wouldn't need has_ccs either. > > I suppose. And I guess that's where I started originally :/ > > But I'm not sure if it's better go that route or the other route of > reducing the arrays to some simple supersets and also utilize > .format_mod_supported() in plane init to filter out the unsupported > formats when populating the plane's format list. Probably best not > dwell on this too much for now so that we can at least make some > progress :) > >> >> However, it's not my driver and it unblocks vc4's patch, so: >> >> Reviewed-by: Eric Anholt > > Thanks. I'm guessing we should push this into drm-misc-next so > that you can pile your core/sand bits on top? That would be wonderful. signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-misc-fixes for 4.17
Hi Dave, One more fix that came in today. It's fixing a regression introduced during the merge window, so it'd be nice to get it in. drm-misc-fixes-2018-05-30: dw-hdmi: Fix Oops regression from rc1 (Neil) Cc: Neil Armstrong Cheers, Sean The following changes since commit 2bc5ff0bdc00d81d719dad74589317a260d583ed: drm/omap: fix NULL deref crash with SDI displays (2018-05-24 19:14:46 +0300) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2018-05-30 for you to fetch changes up to c32048d9e93a5ab925d745396c63e7b912147f0a: drm/bridge/synopsys: dw-hdmi: fix dw_hdmi_setup_rx_sense (2018-05-30 13:42:39 -0400) dw-hdmi: Fix Oops regression from rc1 (Neil) Cc: Neil Armstrong Neil Armstrong (1): drm/bridge/synopsys: dw-hdmi: fix dw_hdmi_setup_rx_sense drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 15 --- drivers/gpu/drm/meson/meson_dw_hdmi.c | 2 +- include/drm/bridge/dw_hdmi.h | 2 +- 3 files changed, 6 insertions(+), 13 deletions(-) -- Sean Paul, Software Engineer, Google / Chromium OS ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Cancel reset preparations on failed resets
== Series Details == Series: series starting with [1/2] drm/i915: Cancel reset preparations on failed resets URL : https://patchwork.freedesktop.org/series/43957/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4257 -> Patchwork_9152 = == Summary - WARNING == Minor unknown changes coming with Patchwork_9152 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9152, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/43957/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9152: === IGT changes === Warnings igt@kms_flip@basic-flip-vs-dpms: fi-glk-j4005: PASS -> SKIP == Known issues == Here are the changes found in Patchwork_9152 that come from known issues: === IGT changes === Issues hit igt@kms_flip@basic-flip-vs-modeset: fi-glk-j4005: PASS -> DMESG-WARN (fdo#106000) igt@kms_flip@basic-flip-vs-wf_vblank: fi-glk-j4005: PASS -> FAIL (fdo#100368) igt@kms_frontbuffer_tracking@basic: fi-hsw-4200u: PASS -> DMESG-FAIL (fdo#102614, fdo#106103) fi-hsw-peppy: PASS -> DMESG-FAIL (fdo#102614, fdo#106103) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: fi-cnl-psr: PASS -> DMESG-WARN (fdo#104951) igt@prime_vgem@basic-fence-flip: fi-glk-j4005: PASS -> FAIL (fdo#104008) Possible fixes igt@gem_mmap_gtt@basic-small-bo-tiledx: fi-gdg-551: FAIL (fdo#102575) -> PASS igt@kms_flip@basic-flip-vs-wf_vblank: fi-cnl-psr: FAIL (fdo#100368) -> PASS igt@kms_frontbuffer_tracking@basic: fi-bsw-n3050: INCOMPLETE (fdo#106729) -> PASS igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c: fi-skl-guc: FAIL (fdo#104724, fdo#103191) -> PASS igt@kms_pipe_crc_basic@read-crc-pipe-c: fi-glk-j4005: DMESG-WARN (fdo#106097, fdo#106000) -> PASS igt@prime_vgem@basic-fence-flip: fi-ilk-650: FAIL (fdo#104008) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951 fdo#106000 https://bugs.freedesktop.org/show_bug.cgi?id=106000 fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097 fdo#106103 https://bugs.freedesktop.org/show_bug.cgi?id=106103 fdo#106729 https://bugs.freedesktop.org/show_bug.cgi?id=106729 == Participating hosts (45 -> 39) == Missing(6): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-cfl-u2 fi-skl-6700hq == Build changes == * Linux: CI_DRM_4257 -> Patchwork_9152 CI_DRM_4257: 8aac35d26057479982a346c0e9cd57c2e930b7e1 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4501: 6796a604bab6df9c84af149e799902360afdd157 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9152: 9ab18769303bacc835b8a6973e04ea77880e0cca @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 9ab18769303b drm/i915: Add WaKBLVECSSemaphoreWaitPoll 7d9f9247a4bb drm/i915: Cancel reset preparations on failed resets == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9152/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 00/13] drm: Eliminate plane->fb/crtc usage for atomic drivers
Thanks Ville. This series: Reviewed-by: Sinclair Yeh On Fri, May 25, 2018 at 09:50:32PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > Here are again the last (?) bits of eliminating the plane->fb/crtc > usage for atomic drivers. I've pushed everything else (thanks to > everyone who reviewed them). > > Deepak said he'd tested the vmwgfx stuff, so I think it should be > safe to land. Just missing a bit of review... > > Cc: Alex Deucher > Cc: amd-...@lists.freedesktop.org > Cc: "Christian König" > Cc: Daniel Vetter > Cc: David Airlie > Cc: "David (ChunMing) Zhou" > Cc: Deepak Rawat > Cc: Eric Anholt > Cc: freedr...@lists.freedesktop.org > Cc: Gerd Hoffmann > Cc: Harry Wentland > Cc: Inki Dae > Cc: Joonyoung Shim > Cc: Kyungmin Park > Cc: linux-arm-...@vger.kernel.org > Cc: Rob Clark > Cc: Seung-Woo Kim > Cc: Sinclair Yeh > Cc: Thomas Hellstrom > Cc: virtualizat...@lists.linux-foundation.org > Cc: VMware Graphics > > Ville Syrjälä (13): > drm/vmwgfx: Stop using plane->fb in vmw_kms_atomic_check_modeset() > drm/vmwgfx: Stop using plane->fb in vmw_kms_helper_dirty() > drm/vmwgfx: Stop using plane->fb in vmw_kms_update_implicit_fb() > drm/vmwgfx: Stop updating plane->fb > drm/vmwgfx: Stop using plane->fb in atomic_enable() > drm/vmwgfx: Stop messing about with plane->fb/old_fb/crtc > drm/amdgpu/dc: Stop updating plane->fb > drm/i915: Stop updating plane->fb/crtc > drm/exynos: Stop updating plane->crtc > drm/msm: Stop updating plane->fb/crtc > drm/virtio: Stop updating plane->crtc > drm/vc4: Stop updating plane->fb/crtc > drm: Stop updating plane->crtc/fb/old_fb on atomic drivers > > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 - > drivers/gpu/drm/drm_atomic.c | 55 > +++ > drivers/gpu/drm/drm_atomic_helper.c | 15 +-- > drivers/gpu/drm/drm_crtc.c| 8 +++- > drivers/gpu/drm/drm_fb_helper.c | 7 --- > drivers/gpu/drm/drm_framebuffer.c | 5 --- > drivers/gpu/drm/drm_plane.c | 14 +++--- > drivers/gpu/drm/drm_plane_helper.c| 4 +- > drivers/gpu/drm/exynos/exynos_drm_plane.c | 2 - > drivers/gpu/drm/i915/intel_atomic_plane.c | 12 - > drivers/gpu/drm/i915/intel_display.c | 7 ++- > drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c | 1 - > drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c| 2 - > drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 1 - > drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c| 2 - > drivers/gpu/drm/vc4/vc4_crtc.c| 3 -- > drivers/gpu/drm/virtio/virtgpu_display.c | 2 - > drivers/gpu/drm/vmwgfx/vmwgfx_fb.c| 24 -- > drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 24 +++--- > drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 2 - > drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 5 +-- > include/drm/drm_atomic.h | 3 -- > 22 files changed, 46 insertions(+), 154 deletions(-) > > -- > 2.16.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 3/3] lib: Double check ring measurement
On 30/05/18 03:33, Chris Wilson wrote: Check twice for the signal interrupting the execbuf, because the real world is messy. References: https://bugs.freedesktop.org/show_bug.cgi?id=106695 Signed-off-by: Chris Wilson Cc: Antonio Argenziano LGTM. Reviewed-by: Antonio Argenziano ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 2/3] lib: Align ring measurement to timer
On 30/05/18 03:33, Chris Wilson wrote: After hitting the SIGINT from execbuf, wait until the next timer signal before trying again. This aligns the start of the ioctl to the timer, hopefully maximising the amount of time we have for processing before the next signal -- trying to prevent the case where we are scheduled out in the middle of processing and so hit the timer signal too early. References: https://bugs.freedesktop.org/show_bug.cgi?id=106695 Signed-off-by: Chris Wilson Not sure I understand what is the sequence of events, is the problem we get a signal in the middle of a 'good' execbuf and exit the while loop prematurely? If so maybe we can also think of making the timer 'VIRTUAL' so that it would decrement only when the process is executing. Thanks, Antonio --- lib/i915/gem_ring.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lib/i915/gem_ring.c b/lib/i915/gem_ring.c index 7d64165eb..0c061000c 100644 --- a/lib/i915/gem_ring.c +++ b/lib/i915/gem_ring.c @@ -96,6 +96,8 @@ __gem_measure_ring_inflight(int fd, unsigned int engine, enum measure_ring_flags if (last == count) break; + /* sleep until the next timer interrupt (woken on signal) */ + pause(); Does it cause any (sensible) slowdown? Thanks, Antonio last = count; } while (1); ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: per context slice/subslice powergating (rev8)
== Series Details == Series: drm/i915: per context slice/subslice powergating (rev8) URL : https://patchwork.freedesktop.org/series/42285/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4257_full -> Patchwork_9151_full = == Summary - FAILURE == Serious unknown changes coming with Patchwork_9151_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9151_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/42285/revisions/8/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9151_full: === IGT changes === Possible regressions igt@gem_ctx_param@invalid-param-get: shard-apl: PASS -> FAIL shard-glk: PASS -> FAIL shard-snb: PASS -> FAIL shard-hsw: PASS -> FAIL shard-kbl: PASS -> FAIL igt@gem_ctx_param@invalid-param-set: shard-kbl: PASS -> DMESG-FAIL shard-hsw: PASS -> DMESG-FAIL shard-snb: PASS -> DMESG-FAIL +1 shard-glk: PASS -> DMESG-FAIL shard-apl: PASS -> DMESG-FAIL == Known issues == Here are the changes found in Patchwork_9151_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_gtt: shard-kbl: PASS -> INCOMPLETE (fdo#103665) igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-glk: PASS -> FAIL (fdo#105363) igt@kms_flip@flip-vs-panning-vs-hang-interruptible: shard-snb: PASS -> DMESG-WARN (fdo#103821) igt@kms_flip@flip-vs-wf_vblank-interruptible: shard-hsw: PASS -> FAIL (fdo#100368) igt@kms_flip@modeset-vs-vblank-race: shard-glk: PASS -> FAIL (fdo#103060) igt@kms_flip_tiling@flip-x-tiled: shard-glk: PASS -> FAIL (fdo#103822, fdo#104724) igt@perf_pmu@render-node-busy-idle-vcs0: shard-snb: PASS -> FAIL (fdo#105286) Possible fixes igt@kms_flip@flip-vs-expired-vblank-interruptible: shard-glk: FAIL (fdo#105363) -> PASS igt@kms_flip@plain-flip-ts-check: shard-glk: FAIL (fdo#100368) -> PASS igt@perf@blocking: shard-hsw: FAIL (fdo#102252) -> PASS igt@perf_pmu@rc6-runtime-pm: shard-kbl: FAIL (fdo#105010) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103821 https://bugs.freedesktop.org/show_bug.cgi?id=103821 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105010 https://bugs.freedesktop.org/show_bug.cgi?id=105010 fdo#105286 https://bugs.freedesktop.org/show_bug.cgi?id=105286 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4257 -> Patchwork_9151 CI_DRM_4257: 8aac35d26057479982a346c0e9cd57c2e930b7e1 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4501: 6796a604bab6df9c84af149e799902360afdd157 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9151: ab350a0f9e28cf98c5c305fc7dd273bb35e68c5b @ git://anongit.freedesktop.org/gfx-ci/linux == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9151/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915: Cancel reset preparations on failed resets
== Series Details == Series: series starting with [1/2] drm/i915: Cancel reset preparations on failed resets URL : https://patchwork.freedesktop.org/series/43957/ State : warning == Summary == $ dim checkpatch origin/drm-tip 7d9f9247a4bb drm/i915: Cancel reset preparations on failed resets 9ab18769303b drm/i915: Add WaKBLVECSSemaphoreWaitPoll -:40: CHECK:SPACING: spaces preferred around that '+' (ctx:VxV) #40: FILE: drivers/gpu/drm/i915/i915_reg.h:2240: +#define RING_SEMA_WAIT_POLL(base) _MMIO((base)+0x24c) ^ total: 0 errors, 0 warnings, 1 checks, 108 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/pmu: Measure sampler intervals
On 30/05/2018 16:37, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-05-30 16:27:02)
On 30/05/2018 15:55, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-05-30 15:37:18)
On 30/05/2018 12:55, Chris Wilson wrote:
hrtimer is not reliable enough to assume fixed intervals, and so even
coarse accuracy (in the face of kasan and similar heavy debugging) we
need to measure the actual interval between sample.
While using a single timestamp to compute the interval does not allow
very fine accuracy (consider the impact of a slow forcewake between
different samples after the timestamp is read) is much better than
assuming the interval.
v2: Make use of the sample period for estimating the GPU clock cycles,
leaving the frequency calculation (the averaging) to the caller.
Introduce new samplers for reporting cycles instead of Hz.
Testcase: igt/perf_pmu #ivb
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_pmu.c | 44 ++---
drivers/gpu/drm/i915/i915_pmu.h | 6 +
include/uapi/drm/i915_drm.h | 2 ++
3 files changed, 43 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index dc87797db500..12033e47e3b4 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -86,6 +86,8 @@ static bool pmu_needs_timer(struct drm_i915_private *i915,
bool gpu_active)
*/
enable &= config_enabled_mask(I915_PMU_ACTUAL_FREQUENCY) |
config_enabled_mask(I915_PMU_REQUESTED_FREQUENCY) |
+ config_enabled_mask(I915_PMU_ACTUAL_CLOCK) |
+ config_enabled_mask(I915_PMU_REQUESTED_CLOCK) |
ENGINE_SAMPLE_MASK;
/*
@@ -127,6 +129,7 @@ static void __i915_pmu_maybe_start_timer(struct
drm_i915_private *i915)
{
if (!i915->pmu.timer_enabled && pmu_needs_timer(i915, true)) {
i915->pmu.timer_enabled = true;
+ i915->pmu.timestamp = ktime_get();
hrtimer_start_range_ns(>pmu.timer,
ns_to_ktime(PERIOD), 0,
HRTIMER_MODE_REL_PINNED);
@@ -160,7 +163,7 @@ update_sample(struct i915_pmu_sample *sample, u32 unit, u32
val)
sample->cur += mul_u32_u32(val, unit);
}
-static void engines_sample(struct drm_i915_private *dev_priv)
+static void engines_sample(struct drm_i915_private *dev_priv, u64 period)
{
struct intel_engine_cs *engine;
enum intel_engine_id id;
@@ -183,7 +186,7 @@ static void engines_sample(struct drm_i915_private
*dev_priv)
val = !i915_seqno_passed(current_seqno, last_seqno);
update_sample(>pmu.sample[I915_SAMPLE_BUSY],
- PERIOD, val);
+ period, val);
if (val && (engine->pmu.enable &
(BIT(I915_SAMPLE_WAIT) | BIT(I915_SAMPLE_SEMA {
@@ -195,10 +198,10 @@ static void engines_sample(struct drm_i915_private
*dev_priv)
}
update_sample(>pmu.sample[I915_SAMPLE_WAIT],
- PERIOD, !!(val & RING_WAIT));
+ period, !!(val & RING_WAIT));
update_sample(>pmu.sample[I915_SAMPLE_SEMA],
- PERIOD, !!(val & RING_WAIT_SEMAPHORE));
+ period, !!(val & RING_WAIT_SEMAPHORE));
}
if (fw)
@@ -207,10 +210,11 @@ static void engines_sample(struct drm_i915_private
*dev_priv)
intel_runtime_pm_put(dev_priv);
}
-static void frequency_sample(struct drm_i915_private *dev_priv)
+static void frequency_sample(struct drm_i915_private *dev_priv, u64 period)
{
if (dev_priv->pmu.enable &
- config_enabled_mask(I915_PMU_ACTUAL_FREQUENCY)) {
+ (config_enabled_mask(I915_PMU_ACTUAL_CLOCK) |
+ config_enabled_mask(I915_PMU_ACTUAL_FREQUENCY))) {
u32 val;
val = dev_priv->gt_pm.rps.cur_freq;
@@ -223,13 +227,20 @@ static void frequency_sample(struct drm_i915_private
*dev_priv)
update_sample(_priv->pmu.sample[__I915_SAMPLE_FREQ_ACT],
1, intel_gpu_freq(dev_priv, val));
+ update_sample(_priv->pmu.sample[__I915_SAMPLE_CLOCK_ACT],
+ period, intel_gpu_freq(dev_priv, val));
Cache intel_gpu_freq in a local.
}
if (dev_priv->pmu.enable &
- config_enabled_mask(I915_PMU_REQUESTED_FREQUENCY)) {
+ (config_enabled_mask(I915_PMU_REQUESTED_CLOCK) |
+ config_enabled_mask(I915_PMU_REQUESTED_FREQUENCY))) {
update_sample(_priv->pmu.sample[__I915_SAMPLE_FREQ_REQ], 1,
intel_gpu_freq(dev_priv,
dev_priv->gt_pm.rps.cur_freq));
+
[Intel-gfx] [PATCH v2 13/13] drm/i915: Rename variables in intel_primary_plane_create()
From: Ville Syrjälä
Let's try to stick a common naming pattern in all the plane init funcs.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 86 ++--
1 file changed, 42 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 684514c3fb5c..d2264c0559dd 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13324,88 +13324,86 @@ static bool i9xx_plane_has_fbc(struct
drm_i915_private *dev_priv,
static struct intel_plane *
intel_primary_plane_create(struct drm_i915_private *dev_priv, enum pipe pipe)
{
- struct intel_plane *primary;
- const uint32_t *intel_primary_formats;
+ struct intel_plane *plane;
unsigned int supported_rotations;
unsigned int possible_crtcs;
- unsigned int num_formats;
- const uint64_t *modifiers;
+ const u64 *modifiers;
+ const u32 *formats;
+ int num_formats;
int ret;
if (INTEL_GEN(dev_priv) >= 9) {
- primary = skl_universal_plane_create(dev_priv, pipe,
-PLANE_PRIMARY);
- if (IS_ERR(primary))
- return primary;
+ plane = skl_universal_plane_create(dev_priv, pipe,
+ PLANE_PRIMARY);
+ if (IS_ERR(plane))
+ return plane;
/* FIXME unify */
- primary->check_plane = intel_check_primary_plane;
+ plane->check_plane = intel_check_primary_plane;
- return primary;
+ return plane;
}
- primary = intel_plane_alloc();
- if (IS_ERR(primary))
- return primary;
+ plane = intel_plane_alloc();
+ if (IS_ERR(plane))
+ return plane;
- primary->can_scale = false;
- primary->max_downscale = 1;
- primary->pipe = pipe;
+ plane->can_scale = false;
+ plane->max_downscale = 1;
+ plane->pipe = pipe;
/*
* On gen2/3 only plane A can do FBC, but the panel fitter and LVDS
* port is hooked to pipe B. Hence we want plane A feeding pipe B.
*/
if (HAS_FBC(dev_priv) && INTEL_GEN(dev_priv) < 4)
- primary->i9xx_plane = (enum i9xx_plane_id) !pipe;
+ plane->i9xx_plane = (enum i9xx_plane_id) !pipe;
else
- primary->i9xx_plane = (enum i9xx_plane_id) pipe;
- primary->id = PLANE_PRIMARY;
- primary->frontbuffer_bit = INTEL_FRONTBUFFER(pipe, primary->id);
+ plane->i9xx_plane = (enum i9xx_plane_id) pipe;
+ plane->id = PLANE_PRIMARY;
+ plane->frontbuffer_bit = INTEL_FRONTBUFFER(pipe, plane->id);
- primary->has_fbc = i9xx_plane_has_fbc(dev_priv, primary->i9xx_plane);
- if (primary->has_fbc) {
+ plane->has_fbc = i9xx_plane_has_fbc(dev_priv, plane->i9xx_plane);
+ if (plane->has_fbc) {
struct intel_fbc *fbc = _priv->fbc;
- fbc->possible_framebuffer_bits |= primary->frontbuffer_bit;
+ fbc->possible_framebuffer_bits |= plane->frontbuffer_bit;
}
- primary->check_plane = intel_check_primary_plane;
+ plane->check_plane = intel_check_primary_plane;
if (INTEL_GEN(dev_priv) >= 4) {
- intel_primary_formats = i965_primary_formats;
+ formats = i965_primary_formats;
num_formats = ARRAY_SIZE(i965_primary_formats);
modifiers = i9xx_format_modifiers;
- primary->update_plane = i9xx_update_plane;
- primary->disable_plane = i9xx_disable_plane;
- primary->get_hw_state = i9xx_plane_get_hw_state;
+ plane->update_plane = i9xx_update_plane;
+ plane->disable_plane = i9xx_disable_plane;
+ plane->get_hw_state = i9xx_plane_get_hw_state;
} else {
- intel_primary_formats = i8xx_primary_formats;
+ formats = i8xx_primary_formats;
num_formats = ARRAY_SIZE(i8xx_primary_formats);
modifiers = i9xx_format_modifiers;
- primary->update_plane = i9xx_update_plane;
- primary->disable_plane = i9xx_disable_plane;
- primary->get_hw_state = i9xx_plane_get_hw_state;
+ plane->update_plane = i9xx_update_plane;
+ plane->disable_plane = i9xx_disable_plane;
+ plane->get_hw_state = i9xx_plane_get_hw_state;
}
possible_crtcs = BIT(pipe);
if (INTEL_GEN(dev_priv) >= 5 || IS_G4X(dev_priv))
- ret = drm_universal_plane_init(_priv->drm, >base,
+ ret = drm_universal_plane_init(_priv->drm, >base,
possible_crtcs,
_plane_funcs,
-
[Intel-gfx] [PATCH v2 12/13] drm/i915: s/intel_plane/plane/ in sprite init
From: Ville Syrjälä
Use a more familiar naming pattern for our variables in the sprite plane
init function.
v2: Drop the redundant 'plane' from plane_formats and num_planes_formats
too
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_sprite.c | 103 ++--
1 file changed, 51 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index e84755c9557a..7bc79e0c7eb8 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1515,74 +1515,74 @@ skl_universal_plane_create(struct drm_i915_private
*dev_priv,
struct intel_plane *
intel_sprite_plane_create(struct drm_i915_private *dev_priv,
- enum pipe pipe, int plane)
+ enum pipe pipe, int sprite)
{
- struct intel_plane *intel_plane;
+ struct intel_plane *plane;
unsigned long possible_crtcs;
- const uint32_t *plane_formats;
- const uint64_t *modifiers;
unsigned int supported_rotations;
- int num_plane_formats;
+ const u64 *modifiers;
+ const u32 *formats;
+ int num_formats;
int ret;
if (INTEL_GEN(dev_priv) >= 9) {
- intel_plane = skl_universal_plane_create(dev_priv, pipe,
-PLANE_SPRITE0 + plane);
- if (IS_ERR(intel_plane))
- return intel_plane;
+ plane = skl_universal_plane_create(dev_priv, pipe,
+ PLANE_SPRITE0 + sprite);
+ if (IS_ERR(plane))
+ return plane;
/* FIXME unify */
- intel_plane->check_plane = intel_check_sprite_plane;
+ plane->check_plane = intel_check_sprite_plane;
- return intel_plane;
+ return plane;
}
- intel_plane = intel_plane_alloc();
- if (IS_ERR(intel_plane))
- return intel_plane;
+ plane = intel_plane_alloc();
+ if (IS_ERR(plane))
+ return plane;
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
- intel_plane->can_scale = false;
- intel_plane->max_downscale = 1;
+ plane->can_scale = false;
+ plane->max_downscale = 1;
- intel_plane->update_plane = vlv_update_plane;
- intel_plane->disable_plane = vlv_disable_plane;
- intel_plane->get_hw_state = vlv_plane_get_hw_state;
+ plane->update_plane = vlv_update_plane;
+ plane->disable_plane = vlv_disable_plane;
+ plane->get_hw_state = vlv_plane_get_hw_state;
- plane_formats = vlv_plane_formats;
- num_plane_formats = ARRAY_SIZE(vlv_plane_formats);
+ formats = vlv_plane_formats;
+ num_formats = ARRAY_SIZE(vlv_plane_formats);
modifiers = i9xx_plane_format_modifiers;
} else if (INTEL_GEN(dev_priv) >= 7) {
if (IS_IVYBRIDGE(dev_priv)) {
- intel_plane->can_scale = true;
- intel_plane->max_downscale = 2;
+ plane->can_scale = true;
+ plane->max_downscale = 2;
} else {
- intel_plane->can_scale = false;
- intel_plane->max_downscale = 1;
+ plane->can_scale = false;
+ plane->max_downscale = 1;
}
- intel_plane->update_plane = ivb_update_plane;
- intel_plane->disable_plane = ivb_disable_plane;
- intel_plane->get_hw_state = ivb_plane_get_hw_state;
+ plane->update_plane = ivb_update_plane;
+ plane->disable_plane = ivb_disable_plane;
+ plane->get_hw_state = ivb_plane_get_hw_state;
- plane_formats = snb_plane_formats;
- num_plane_formats = ARRAY_SIZE(snb_plane_formats);
+ formats = snb_plane_formats;
+ num_formats = ARRAY_SIZE(snb_plane_formats);
modifiers = i9xx_plane_format_modifiers;
} else {
- intel_plane->can_scale = true;
- intel_plane->max_downscale = 16;
+ plane->can_scale = true;
+ plane->max_downscale = 16;
- intel_plane->update_plane = g4x_update_plane;
- intel_plane->disable_plane = g4x_disable_plane;
- intel_plane->get_hw_state = g4x_plane_get_hw_state;
+ plane->update_plane = g4x_update_plane;
+ plane->disable_plane = g4x_disable_plane;
+ plane->get_hw_state = g4x_plane_get_hw_state;
modifiers = i9xx_plane_format_modifiers;
if (IS_GEN6(dev_priv)) {
- plane_formats =
[Intel-gfx] [PATCH v2 11/13] drm/i915: Simplify skl_plane_has_planar()
From: Ville Syrjälä
Untangle skl_plane_has_planar() into a more legible form.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_sprite.c | 36 +---
1 file changed, 17 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 0d45453166c5..e84755c9557a 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1364,25 +1364,23 @@ static bool skl_plane_has_fbc(struct drm_i915_private
*dev_priv,
static bool skl_plane_has_planar(struct drm_i915_private *dev_priv,
enum pipe pipe, enum plane_id plane_id)
{
- if (plane_id == PLANE_PRIMARY) {
- if (IS_SKYLAKE(dev_priv) || IS_BROXTON(dev_priv))
- return false;
- else if ((INTEL_GEN(dev_priv) == 9 && pipe == PIPE_C) &&
-!IS_GEMINILAKE(dev_priv))
- return false;
- } else if (plane_id >= PLANE_SPRITE0) {
- if (plane_id == PLANE_CURSOR)
- return false;
- if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) == 10) {
- if (plane_id != PLANE_SPRITE0)
- return false;
- } else {
- if (plane_id != PLANE_SPRITE0 || pipe == PIPE_C ||
- IS_SKYLAKE(dev_priv) || IS_BROXTON(dev_priv))
- return false;
- }
- }
- return true;
+ if (plane_id == PLANE_CURSOR)
+ return false;
+
+ if (IS_SKYLAKE(dev_priv) || IS_BROXTON(dev_priv))
+ return false;
+
+ /* FIXME */
+ if (INTEL_GEN(dev_priv) >= 11)
+ return false;
+
+ if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
+ return plane_id == PLANE_PRIMARY ||
+ plane_id == PLANE_SPRITE0;
+
+ return pipe != PIPE_C &&
+ (plane_id == PLANE_PRIMARY ||
+plane_id == PLANE_SPRITE0);
}
static bool skl_plane_has_ccs(struct drm_i915_private *dev_priv,
--
2.16.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 10/13] drm/i915: Extract skl_universal_plane_init()
From: Ville Syrjälä
There's not much point in following the primary vs. sprite split
for the SKL+ universal plane init code. The only difference is
of our own doing in the form of the .check_plane(). Let's make
a small exception for that little detail and otherwise share
the same code to initialize all the universal planes.
Eventually we should eliminate the mess around .check_plane()
as well, but for now let's be happy with some code reduction.
v2: Remember to set up plane->has_fbc
Make skl_plane_has_ccs() static
v3: Rebase due to NV12, rename some variables
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 195 +--
drivers/gpu/drm/i915/intel_drv.h | 12 +--
drivers/gpu/drm/i915/intel_sprite.c | 192 +-
3 files changed, 169 insertions(+), 230 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index a581118f5c7b..684514c3fb5c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -73,55 +73,6 @@ static const uint64_t i9xx_format_modifiers[] = {
DRM_FORMAT_MOD_INVALID
};
-static const uint32_t skl_primary_formats[] = {
- DRM_FORMAT_C8,
- DRM_FORMAT_RGB565,
- DRM_FORMAT_XRGB,
- DRM_FORMAT_XBGR,
- DRM_FORMAT_ARGB,
- DRM_FORMAT_ABGR,
- DRM_FORMAT_XRGB2101010,
- DRM_FORMAT_XBGR2101010,
- DRM_FORMAT_YUYV,
- DRM_FORMAT_YVYU,
- DRM_FORMAT_UYVY,
- DRM_FORMAT_VYUY,
-};
-
-static const uint32_t skl_pri_planar_formats[] = {
- DRM_FORMAT_C8,
- DRM_FORMAT_RGB565,
- DRM_FORMAT_XRGB,
- DRM_FORMAT_XBGR,
- DRM_FORMAT_ARGB,
- DRM_FORMAT_ABGR,
- DRM_FORMAT_XRGB2101010,
- DRM_FORMAT_XBGR2101010,
- DRM_FORMAT_YUYV,
- DRM_FORMAT_YVYU,
- DRM_FORMAT_UYVY,
- DRM_FORMAT_VYUY,
- DRM_FORMAT_NV12,
-};
-
-static const uint64_t skl_format_modifiers_noccs[] = {
- I915_FORMAT_MOD_Yf_TILED,
- I915_FORMAT_MOD_Y_TILED,
- I915_FORMAT_MOD_X_TILED,
- DRM_FORMAT_MOD_LINEAR,
- DRM_FORMAT_MOD_INVALID
-};
-
-static const uint64_t skl_format_modifiers_ccs[] = {
- I915_FORMAT_MOD_Yf_TILED_CCS,
- I915_FORMAT_MOD_Y_TILED_CCS,
- I915_FORMAT_MOD_Yf_TILED,
- I915_FORMAT_MOD_Y_TILED,
- I915_FORMAT_MOD_X_TILED,
- DRM_FORMAT_MOD_LINEAR,
- DRM_FORMAT_MOD_INVALID
-};
-
/* Cursor formats */
static const uint32_t intel_cursor_formats[] = {
DRM_FORMAT_ARGB,
@@ -13188,42 +13139,9 @@ static bool i965_mod_supported(uint32_t format,
uint64_t modifier)
}
}
-static bool skl_mod_supported(uint32_t format, uint64_t modifier)
-{
- switch (format) {
- case DRM_FORMAT_XRGB:
- case DRM_FORMAT_XBGR:
- case DRM_FORMAT_ARGB:
- case DRM_FORMAT_ABGR:
- if (modifier == I915_FORMAT_MOD_Yf_TILED_CCS ||
- modifier == I915_FORMAT_MOD_Y_TILED_CCS)
- return true;
- /* fall through */
- case DRM_FORMAT_RGB565:
- case DRM_FORMAT_XRGB2101010:
- case DRM_FORMAT_XBGR2101010:
- case DRM_FORMAT_YUYV:
- case DRM_FORMAT_YVYU:
- case DRM_FORMAT_UYVY:
- case DRM_FORMAT_VYUY:
- case DRM_FORMAT_NV12:
- if (modifier == I915_FORMAT_MOD_Yf_TILED)
- return true;
- /* fall through */
- case DRM_FORMAT_C8:
- if (modifier == DRM_FORMAT_MOD_LINEAR ||
- modifier == I915_FORMAT_MOD_X_TILED ||
- modifier == I915_FORMAT_MOD_Y_TILED)
- return true;
- /* fall through */
- default:
- return false;
- }
-}
-
-static bool intel_primary_plane_format_mod_supported(struct drm_plane *plane,
-uint32_t format,
-uint64_t modifier)
+static bool i9xx_plane_format_mod_supported(struct drm_plane *plane,
+ uint32_t format,
+ uint64_t modifier)
{
struct drm_i915_private *dev_priv = to_i915(plane->dev);
@@ -13234,9 +13152,7 @@ static bool
intel_primary_plane_format_mod_supported(struct drm_plane *plane,
modifier != DRM_FORMAT_MOD_LINEAR)
return false;
- if (INTEL_GEN(dev_priv) >= 9)
- return skl_mod_supported(format, modifier);
- else if (INTEL_GEN(dev_priv) >= 4)
+ if (INTEL_GEN(dev_priv) >= 4)
return i965_mod_supported(format, modifier);
else
return i8xx_mod_supported(format, modifier);
@@ -13252,7 +13168,7 @@ static bool
intel_cursor_plane_format_mod_supported(struct drm_plane *plane,
return modifier ==
Re: [Intel-gfx] [PATCH 5/5] drm/i915: Only sanitize GEM from late suspend
Quoting Tvrtko Ursulin (2018-05-30 17:56:20) > > On 29/05/2018 14:29, Chris Wilson wrote: > > During testing we encounter a conflict between SUSPEND_TEST_DEVICES and > > disabling reset (gem_eio/suspend). This results in the device continuing > > on without being reset, but since it has gone through HW sanitization to > > Has some test been failing because of this and since when? gem_eio/suspend? Yes. It will fail in the future because we'll remove all mmio from the process_csb(); it fails right now because we lose track of what interrupts we process across the suspend and may double handle CSB events. E.g. https://bugs.freedesktop.org/show_bug.cgi?id=106702 > > account for the suspend/resume cycle, we have to assume the device has > > been reset to its defaults. A simple way around this is to skip the > > sanitize phase for SUSPEND_TEST_DEVICES by moving it to suspend-late. > > So suspend_late is not called when suspending via SUSPEND_TEST_DEVICES? > Sounds weird to me that core allows a "half-way" suspend mode. But I am > not familiar with that code so don't know. Yes, weird is one way to describe it. > Either way, if we skip it, that only skips the reset which is skipped > anyway in gem_eio/suspend so I did not figure out the difference. We then also skip the call to reset->reset which we need after a real resume (when the device is powered up) and/or after the reset in sanitization. It's fiddly. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 09/13] drm/i915: Introduce intel_plane_alloc()
From: Ville Syrjälä
Pull the common plane+plane_state allocation into a small helper.
Reduces the amount of boilerplate in the plane initialization
functions.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 44 ---
drivers/gpu/drm/i915/intel_drv.h | 3 +++
drivers/gpu/drm/i915/intel_sprite.c | 50
3 files changed, 47 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 2d6147e71aca..a581118f5c7b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13441,8 +13441,7 @@ bool skl_plane_has_planar(struct drm_i915_private
*dev_priv,
static struct intel_plane *
intel_primary_plane_create(struct drm_i915_private *dev_priv, enum pipe pipe)
{
- struct intel_plane *primary = NULL;
- struct intel_plane_state *state = NULL;
+ struct intel_plane *primary;
const uint32_t *intel_primary_formats;
unsigned int supported_rotations;
unsigned int possible_crtcs;
@@ -13450,19 +13449,9 @@ intel_primary_plane_create(struct drm_i915_private
*dev_priv, enum pipe pipe)
const uint64_t *modifiers;
int ret;
- primary = kzalloc(sizeof(*primary), GFP_KERNEL);
- if (!primary) {
- ret = -ENOMEM;
- goto fail;
- }
-
- state = intel_create_plane_state(>base);
- if (!state) {
- ret = -ENOMEM;
- goto fail;
- }
-
- primary->base.state = >base;
+ primary = intel_plane_alloc();
+ if (IS_ERR(primary))
+ return primary;
primary->can_scale = false;
primary->max_downscale = 1;
@@ -13597,8 +13586,7 @@ intel_primary_plane_create(struct drm_i915_private
*dev_priv, enum pipe pipe)
return primary;
fail:
- kfree(state);
- kfree(primary);
+ intel_plane_free(primary);
return ERR_PTR(ret);
}
@@ -13607,24 +13595,13 @@ static struct intel_plane *
intel_cursor_plane_create(struct drm_i915_private *dev_priv,
enum pipe pipe)
{
- struct intel_plane *cursor = NULL;
- struct intel_plane_state *state = NULL;
unsigned int possible_crtcs;
+ struct intel_plane *cursor;
int ret;
- cursor = kzalloc(sizeof(*cursor), GFP_KERNEL);
- if (!cursor) {
- ret = -ENOMEM;
- goto fail;
- }
-
- state = intel_create_plane_state(>base);
- if (!state) {
- ret = -ENOMEM;
- goto fail;
- }
-
- cursor->base.state = >base;
+ cursor = intel_plane_alloc();
+ if (IS_ERR(cursor))
+ return cursor;
cursor->can_scale = false;
cursor->max_downscale = 1;
@@ -13674,8 +13651,7 @@ intel_cursor_plane_create(struct drm_i915_private
*dev_priv,
return cursor;
fail:
- kfree(state);
- kfree(cursor);
+ intel_plane_free(cursor);
return ERR_PTR(ret);
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index e39827b5da5f..b9035432f285 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -2089,6 +2089,9 @@ bool skl_plane_has_ccs(struct drm_i915_private *dev_priv,
bool intel_format_is_yuv(uint32_t format);
bool skl_plane_has_planar(struct drm_i915_private *dev_priv,
enum pipe pipe, enum plane_id plane_id);
+struct intel_plane *intel_plane_alloc(void);
+void intel_plane_free(struct intel_plane *plane);
+
/* intel_tv.c */
void intel_tv_init(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index a87ec18b8828..36b86416f11e 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1369,12 +1369,40 @@ bool skl_plane_has_ccs(struct drm_i915_private
*dev_priv,
plane_id == PLANE_SPRITE0);
}
+struct intel_plane *intel_plane_alloc(void)
+{
+ struct intel_plane_state *plane_state;
+ struct intel_plane *plane;
+
+ plane = kzalloc(sizeof(*plane), GFP_KERNEL);
+ if (!plane)
+ return ERR_PTR(-ENOMEM);
+
+ plane_state = intel_create_plane_state(>base);
+ if (!plane_state) {
+ kfree(plane);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ plane->base.state = _state->base;
+
+ return plane;
+}
+
+void intel_plane_free(struct intel_plane *plane)
+{
+ struct intel_plane_state *plane_state =
+ to_intel_plane_state(plane->base.state);
+
+ kfree(plane_state);
+ kfree(plane);
+}
+
struct intel_plane *
intel_sprite_plane_create(struct drm_i915_private *dev_priv,
enum pipe pipe, int plane)
{
- struct intel_plane *intel_plane = NULL;
- struct intel_plane_state
[Intel-gfx] [PATCH v2 08/13] drm/i915: Move plane_state->scaler_id initialization into intel_create_plane_state()
From: Ville Syrjälä
No point in having each caller of intel_create_plane_state() initialize
the scaler_id to -1. Instead just do it in intel_create_plane_state().
Previously we left scaler_id at 0 for pre-SKL platforms, but I can't
see how initializing it to -1 always would cause any harm.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_atomic_plane.c | 1 +
drivers/gpu/drm/i915/intel_display.c | 7 +--
drivers/gpu/drm/i915/intel_sprite.c | 1 -
3 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index 6d068786eb41..cb9cc0877b36 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -56,6 +56,7 @@ intel_create_plane_state(struct drm_plane *plane)
state->base.plane = plane;
state->base.rotation = DRM_MODE_ROTATE_0;
+ state->scaler_id = -1;
return state;
}
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 453ea548fbd1..2d6147e71aca 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13466,10 +13466,8 @@ intel_primary_plane_create(struct drm_i915_private
*dev_priv, enum pipe pipe)
primary->can_scale = false;
primary->max_downscale = 1;
- if (INTEL_GEN(dev_priv) >= 9) {
+ if (INTEL_GEN(dev_priv) >= 9)
primary->can_scale = true;
- state->scaler_id = -1;
- }
primary->pipe = pipe;
/*
* On gen2/3 only plane A can do FBC, but the panel fitter and LVDS
@@ -13671,9 +13669,6 @@ intel_cursor_plane_create(struct drm_i915_private
*dev_priv,
DRM_MODE_ROTATE_0 |
DRM_MODE_ROTATE_180);
- if (INTEL_GEN(dev_priv) >= 9)
- state->scaler_id = -1;
-
drm_plane_helper_add(>base, _plane_helper_funcs);
return cursor;
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 565ce5259b16..a87ec18b8828 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1397,7 +1397,6 @@ intel_sprite_plane_create(struct drm_i915_private
*dev_priv,
if (INTEL_GEN(dev_priv) >= 9) {
intel_plane->can_scale = true;
- state->scaler_id = -1;
intel_plane->update_plane = skl_update_plane;
intel_plane->disable_plane = skl_disable_plane;
--
2.16.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 06/13] drm/i915: Disallow plane scaling with specific pixel formats
From: Ville Syrjälä
Plane scaling is not supported with specific pixel formats. Disallow
plane scaling when such a format is used. Currently the only such
pixel format we expose is C8, but in case we add more in the future
let's make it easy to deal with them.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_sprite.c | 41
3 files changed, 29 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index c9ed32d7b869..453ea548fbd1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13034,7 +13034,7 @@ intel_check_primary_plane(struct intel_plane *plane,
if (INTEL_GEN(dev_priv) >= 9) {
/* use scaler when colorkey is not required */
- if (!state->ckey.flags) {
+ if (!state->ckey.flags && intel_fb_scalable(state->base.fb)) {
min_scale = 1;
if (state->base.fb)
pixel_format = state->base.fb->format->format;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index fd6256632482..e39827b5da5f 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -2070,6 +2070,7 @@ bool intel_sdvo_init(struct drm_i915_private *dev_priv,
/* intel_sprite.c */
bool intel_format_is_yuv(u32 format);
+bool intel_fb_scalable(const struct drm_framebuffer *fb);
int intel_usecs_to_scanlines(const struct drm_display_mode *adjusted_mode,
int usecs);
struct intel_plane *intel_sprite_plane_create(struct drm_i915_private
*dev_priv,
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 2ce3ffbf8ab1..73a74e6ef847 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -928,6 +928,19 @@ g4x_plane_get_hw_state(struct intel_plane *plane)
return ret;
}
+bool intel_fb_scalable(const struct drm_framebuffer *fb)
+{
+ if (!fb)
+ return false;
+
+ switch (fb->format->format) {
+ case DRM_FORMAT_C8:
+ return false;
+ default:
+ return true;
+ }
+}
+
static int
intel_check_sprite_plane(struct intel_plane *plane,
struct intel_crtc_state *crtc_state,
@@ -940,7 +953,6 @@ intel_check_sprite_plane(struct intel_plane *plane,
int max_scale, min_scale;
bool can_scale;
int ret;
- uint32_t pixel_format = 0;
if (!fb) {
state->base.visible = false;
@@ -960,24 +972,25 @@ intel_check_sprite_plane(struct intel_plane *plane,
}
/* setup can_scale, min_scale, max_scale */
+ can_scale = false;
+ min_scale = DRM_PLANE_HELPER_NO_SCALING;
+ max_scale = DRM_PLANE_HELPER_NO_SCALING;
+
if (INTEL_GEN(dev_priv) >= 9) {
- if (state->base.fb)
- pixel_format = state->base.fb->format->format;
/* use scaler when colorkey is not required */
- if (!state->ckey.flags) {
- can_scale = 1;
+ if (!state->ckey.flags && intel_fb_scalable(fb)) {
+ u32 pixel_format = fb ? fb->format->format : 0;
+
+ can_scale = true;
min_scale = 1;
- max_scale =
- skl_max_scale(crtc, crtc_state, pixel_format);
- } else {
- can_scale = 0;
- min_scale = DRM_PLANE_HELPER_NO_SCALING;
- max_scale = DRM_PLANE_HELPER_NO_SCALING;
+ max_scale = skl_max_scale(crtc, crtc_state,
pixel_format);
}
} else {
- can_scale = plane->can_scale;
- max_scale = plane->max_downscale << 16;
- min_scale = plane->can_scale ? 1 : (1 << 16);
+ if (intel_fb_scalable(fb)) {
+ can_scale = plane->can_scale;
+ max_scale = plane->max_downscale << 16;
+ min_scale = plane->can_scale ? 1 : (1 << 16);
+ }
}
ret = drm_atomic_helper_check_plane_state(>base,
--
2.16.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 07/13] drm/i915: Add missing pixel formats for skl+ "sprites"
From: Ville Syrjälä
All SKL+ universal planes support the same set of formats (with the
exception of NV12 which we don't expose yet). Make the format lists
for primary and sprites the same.
And make the format list const while at it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_sprite.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 73a74e6ef847..565ce5259b16 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1181,12 +1181,15 @@ static const uint32_t vlv_plane_formats[] = {
DRM_FORMAT_VYUY,
};
-static uint32_t skl_plane_formats[] = {
+static const uint32_t skl_plane_formats[] = {
+ DRM_FORMAT_C8,
DRM_FORMAT_RGB565,
- DRM_FORMAT_ABGR,
- DRM_FORMAT_ARGB,
- DRM_FORMAT_XBGR,
DRM_FORMAT_XRGB,
+ DRM_FORMAT_XBGR,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_XRGB2101010,
+ DRM_FORMAT_XBGR2101010,
DRM_FORMAT_YUYV,
DRM_FORMAT_YVYU,
DRM_FORMAT_UYVY,
--
2.16.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 05/13] drm/i915: Allow horizontal mirroring for cnl+ "sprite" planes
From: Ville Syrjälä
All CNL universal planes support horizontal mirroring. Currently
we expose the capability only for the primary plane. Expose it
for the overlay planes as well.
Cc: Joonas Lahtinen
Signed-off-by: Ville Syrjälä
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/intel_sprite.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 45dfc3d972e6..2ce3ffbf8ab1 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1445,7 +1445,12 @@ intel_sprite_plane_create(struct drm_i915_private
*dev_priv,
}
}
- if (INTEL_GEN(dev_priv) >= 9) {
+ if (INTEL_GEN(dev_priv) >= 10) {
+ supported_rotations =
+ DRM_MODE_ROTATE_0 | DRM_MODE_ROTATE_90 |
+ DRM_MODE_ROTATE_180 | DRM_MODE_ROTATE_270 |
+ DRM_MODE_REFLECT_X;
+ } else if (INTEL_GEN(dev_priv) >= 9) {
supported_rotations =
DRM_MODE_ROTATE_0 | DRM_MODE_ROTATE_90 |
DRM_MODE_ROTATE_180 | DRM_MODE_ROTATE_270;
--
2.16.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 04/13] drm/i915: Don't populate plane->i9xx_plane for sprites
From: Ville Syrjälä enum i9xx_plane_id namespace is not valid for any sprite plane, so let's not even populate plane->i9xx_plane. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_sprite.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c index 1c978cccbc17..45dfc3d972e6 100644 --- a/drivers/gpu/drm/i915/intel_sprite.c +++ b/drivers/gpu/drm/i915/intel_sprite.c @@ -1459,7 +1459,6 @@ intel_sprite_plane_create(struct drm_i915_private *dev_priv, } intel_plane->pipe = pipe; - intel_plane->i9xx_plane = plane; intel_plane->id = PLANE_SPRITE0 + plane; intel_plane->frontbuffer_bit = INTEL_FRONTBUFFER(pipe, intel_plane->id); intel_plane->check_plane = intel_check_sprite_plane; -- 2.16.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 02/13] drm/i915: Fix tabs vs. spaces
From: Ville Syrjälä
The sprite code has a bunch of spaces where tabs should be used. Fix it
up.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_sprite.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index ee23613f9fd4..b056a74300c8 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1303,8 +1303,8 @@ static bool skl_mod_supported(uint32_t format, uint64_t
modifier)
}
static bool intel_sprite_plane_format_mod_supported(struct drm_plane *plane,
-uint32_t format,
-uint64_t modifier)
+ uint32_t format,
+ uint64_t modifier)
{
struct drm_i915_private *dev_priv = to_i915(plane->dev);
@@ -1326,14 +1326,14 @@ static bool
intel_sprite_plane_format_mod_supported(struct drm_plane *plane,
}
static const struct drm_plane_funcs intel_sprite_plane_funcs = {
-.update_plane = drm_atomic_helper_update_plane,
-.disable_plane = drm_atomic_helper_disable_plane,
-.destroy = intel_plane_destroy,
-.atomic_get_property = intel_plane_atomic_get_property,
-.atomic_set_property = intel_plane_atomic_set_property,
-.atomic_duplicate_state = intel_plane_duplicate_state,
-.atomic_destroy_state = intel_plane_destroy_state,
-.format_mod_supported = intel_sprite_plane_format_mod_supported,
+ .update_plane = drm_atomic_helper_update_plane,
+ .disable_plane = drm_atomic_helper_disable_plane,
+ .destroy = intel_plane_destroy,
+ .atomic_get_property = intel_plane_atomic_get_property,
+ .atomic_set_property = intel_plane_atomic_set_property,
+ .atomic_duplicate_state = intel_plane_duplicate_state,
+ .atomic_destroy_state = intel_plane_destroy_state,
+ .format_mod_supported = intel_sprite_plane_format_mod_supported,
};
bool skl_plane_has_ccs(struct drm_i915_private *dev_priv,
--
2.16.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 03/13] drm/i915: Populate possible_crtcs for primary/cursor planes
From: Ville Syrjälä
We're currently not providing the possible_crtcs mask to
drm_universal_plane_init() for primary/cursor planes. While that does
work on account of drm_crtc_init_with_planes() filling those up
for us, it's inconsisten with what we're doing for sprite planes.
Let's just always pass the possible_crtcs bitmask to
drm_universal_plane_init(). This does assume that crtc->index
== pipe. But we're already making that assumption elsewhere so
it doesn't seem like a very big sin here.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 14 ++
drivers/gpu/drm/i915/intel_sprite.c | 2 +-
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index daca04b39eef..c9ed32d7b869 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13445,6 +13445,7 @@ intel_primary_plane_create(struct drm_i915_private
*dev_priv, enum pipe pipe)
struct intel_plane_state *state = NULL;
const uint32_t *intel_primary_formats;
unsigned int supported_rotations;
+ unsigned int possible_crtcs;
unsigned int num_formats;
const uint64_t *modifiers;
int ret;
@@ -13532,23 +13533,25 @@ intel_primary_plane_create(struct drm_i915_private
*dev_priv, enum pipe pipe)
primary->get_hw_state = i9xx_plane_get_hw_state;
}
+ possible_crtcs = BIT(pipe);
+
if (INTEL_GEN(dev_priv) >= 9)
ret = drm_universal_plane_init(_priv->drm, >base,
- 0, _plane_funcs,
+ possible_crtcs,
_plane_funcs,
intel_primary_formats,
num_formats,
modifiers,
DRM_PLANE_TYPE_PRIMARY,
"plane 1%c", pipe_name(pipe));
else if (INTEL_GEN(dev_priv) >= 5 || IS_G4X(dev_priv))
ret = drm_universal_plane_init(_priv->drm, >base,
- 0, _plane_funcs,
+ possible_crtcs,
_plane_funcs,
intel_primary_formats,
num_formats,
modifiers,
DRM_PLANE_TYPE_PRIMARY,
"primary %c", pipe_name(pipe));
else
ret = drm_universal_plane_init(_priv->drm, >base,
- 0, _plane_funcs,
+ possible_crtcs,
_plane_funcs,
intel_primary_formats,
num_formats,
modifiers,
DRM_PLANE_TYPE_PRIMARY,
@@ -13608,6 +13611,7 @@ intel_cursor_plane_create(struct drm_i915_private
*dev_priv,
{
struct intel_plane *cursor = NULL;
struct intel_plane_state *state = NULL;
+ unsigned int possible_crtcs;
int ret;
cursor = kzalloc(sizeof(*cursor), GFP_KERNEL);
@@ -13649,8 +13653,10 @@ intel_cursor_plane_create(struct drm_i915_private
*dev_priv,
if (IS_I845G(dev_priv) || IS_I865G(dev_priv) || HAS_CUR_FBC(dev_priv))
cursor->cursor.size = ~0;
+ possible_crtcs = BIT(pipe);
+
ret = drm_universal_plane_init(_priv->drm, >base,
- 0, _cursor_plane_funcs,
+ possible_crtcs,
_cursor_plane_funcs,
intel_cursor_formats,
ARRAY_SIZE(intel_cursor_formats),
cursor_format_modifiers,
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index b056a74300c8..1c978cccbc17 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1464,7 +1464,7 @@ intel_sprite_plane_create(struct drm_i915_private
*dev_priv,
intel_plane->frontbuffer_bit = INTEL_FRONTBUFFER(pipe, intel_plane->id);
intel_plane->check_plane = intel_check_sprite_plane;
- possible_crtcs = (1 << pipe);
+ possible_crtcs = BIT(pipe);
if (INTEL_GEN(dev_priv) >= 9)
ret = drm_universal_plane_init(_priv->drm,
_plane->base,
--
2.16.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 01/13] drm/i915: Constify intel_plane_funcs
From: Ville Syrjälä
intel_plane funcs can be cosnt. Make it so.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 8d4c9e249c44..daca04b39eef 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13252,7 +13252,7 @@ static bool
intel_cursor_plane_format_mod_supported(struct drm_plane *plane,
return modifier == DRM_FORMAT_MOD_LINEAR && format ==
DRM_FORMAT_ARGB;
}
-static struct drm_plane_funcs intel_plane_funcs = {
+static const struct drm_plane_funcs intel_plane_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
.destroy = intel_plane_destroy,
--
2.16.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 00/13] drm/i915: Some plane init cleanups
From: Ville Syrjälä Since NV12 more or less made it in I figured it's time to try and land this plane init cleanup series once again. Ville Syrjälä (13): drm/i915: Constify intel_plane_funcs drm/i915: Fix tabs vs. spaces drm/i915: Populate possible_crtcs for primary/cursor planes drm/i915: Don't populate plane->i9xx_plane for sprites drm/i915: Allow horizontal mirroring for cnl+ "sprite" planes drm/i915: Disallow plane scaling with specific pixel formats drm/i915: Add missing pixel formats for skl+ "sprites" drm/i915: Move plane_state->scaler_id initialization into intel_create_plane_state() drm/i915: Introduce intel_plane_alloc() drm/i915: Extract skl_universal_plane_init() drm/i915: Simplify skl_plane_has_planar() drm/i915: s/intel_plane/plane/ in sprite init drm/i915: Rename variables in intel_primary_plane_create() drivers/gpu/drm/i915/intel_atomic_plane.c | 1 + drivers/gpu/drm/i915/intel_display.c | 310 ++--- drivers/gpu/drm/i915/intel_drv.h | 16 +- drivers/gpu/drm/i915/intel_sprite.c | 374 -- 4 files changed, 327 insertions(+), 374 deletions(-) -- 2.16.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915 : clip yuv primary planes to hw constraints
On Fri, May 25, 2018 at 12:27:40PM -0700, Fritz Koenig wrote:
> YUV planes need to be multiples of 2 to scan out. This was
> handled correctly for planes other than the primary in the
> intel_check_sprite_plane, where the code fixes up the plane
> and makes it compliant. Move this code into a location that
> allows the primary check to access it as well.
intel_check_sprite_plane() is not something we should be spreading.
It's doing way too many platform specific things. I think where I
want to go instead is per-platform plane .check() functions instead.
To that end I think you should just add the relevant checks to eg.
skl_check_plane_surface() for now.
We especially don't want to be moving large chunks of code from
intel_sprite.c to intel_display.c. I'm actually trying to do the
exact opposite and move all the plane code into intel_sprite.c
(or maybe even introduce a new file for the skl+ plane code
entirely).
> Signed-off-by: Fritz Koenig
> ---
> drivers/gpu/drm/i915/intel_display.c | 170 +++
> drivers/gpu/drm/i915/intel_drv.h | 2 +
> drivers/gpu/drm/i915/intel_sprite.c | 154 +---
> 3 files changed, 175 insertions(+), 151 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 5f03af455047..e1eb0fb988a6 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12856,6 +12856,170 @@ skl_max_scale(struct intel_crtc *intel_crtc, struct
> intel_crtc_state *crtc_state
> return max_scale;
> }
>
> +int
> +intel_clip_src_rect(struct intel_plane *plane,
> + struct intel_crtc_state *crtc_state,
> + struct intel_plane_state *state)
> +{
> + struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> + struct drm_framebuffer *fb = state->base.fb;
> + int crtc_x, crtc_y;
> + unsigned int crtc_w, crtc_h;
> + uint32_t src_x, src_y, src_w, src_h;
> + struct drm_rect *src = >base.src;
> + struct drm_rect *dst = >base.dst;
> + struct drm_rect clip = {};
> + int hscale, vscale;
> + int max_scale, min_scale;
> + bool can_scale;
> +
> + *src = drm_plane_state_src(>base);
> + *dst = drm_plane_state_dest(>base);
> +
> + /* setup can_scale, min_scale, max_scale */
> + if (INTEL_GEN(dev_priv) >= 9) {
> + /* use scaler when colorkey is not required */
> + if (!state->ckey.flags) {
> + can_scale = 1;
> + min_scale = 1;
> + max_scale = skl_max_scale(crtc, crtc_state);
> + } else {
> + can_scale = 0;
> + min_scale = DRM_PLANE_HELPER_NO_SCALING;
> + max_scale = DRM_PLANE_HELPER_NO_SCALING;
> + }
> + } else {
> + can_scale = plane->can_scale;
> + max_scale = plane->max_downscale << 16;
> + min_scale = plane->can_scale ? 1 : (1 << 16);
> + }
> +
> + /*
> + * FIXME the following code does a bunch of fuzzy adjustments to the
> + * coordinates and sizes. We probably need some way to decide whether
> + * more strict checking should be done instead.
> + */
> + drm_rect_rotate(src, fb->width << 16, fb->height << 16,
> + state->base.rotation);
> +
> + hscale = drm_rect_calc_hscale_relaxed(src, dst, min_scale, max_scale);
> + BUG_ON(hscale < 0);
> +
> + vscale = drm_rect_calc_vscale_relaxed(src, dst, min_scale, max_scale);
> + BUG_ON(vscale < 0);
> +
> + if (crtc_state->base.enable)
> + drm_mode_get_hv_timing(_state->base.mode,
> +, );
> +
> + state->base.visible = drm_rect_clip_scaled(src, dst, , hscale,
> vscale);
> +
> + crtc_x = dst->x1;
> + crtc_y = dst->y1;
> + crtc_w = drm_rect_width(dst);
> + crtc_h = drm_rect_height(dst);
> +
> + if (state->base.visible) {
> + /* check again in case clipping clamped the results */
> + hscale = drm_rect_calc_hscale(src, dst, min_scale, max_scale);
> + if (hscale < 0) {
> + DRM_DEBUG_KMS("Horizontal scaling factor out of
> limits\n");
> + drm_rect_debug_print("src: ", src, true);
> + drm_rect_debug_print("dst: ", dst, false);
> +
> + return hscale;
> + }
> +
> + vscale = drm_rect_calc_vscale(src, dst, min_scale, max_scale);
> + if (vscale < 0) {
> + DRM_DEBUG_KMS("Vertical scaling factor out of
> limits\n");
> + drm_rect_debug_print("src: ", src, true);
> + drm_rect_debug_print("dst: ", dst, false);
> +
> + return vscale;
> + }
> +
> + /* Make the source viewport
Re: [Intel-gfx] [PATCH 5/5] drm/i915: Only sanitize GEM from late suspend
On 29/05/2018 14:29, Chris Wilson wrote:
During testing we encounter a conflict between SUSPEND_TEST_DEVICES and
disabling reset (gem_eio/suspend). This results in the device continuing
on without being reset, but since it has gone through HW sanitization to
Has some test been failing because of this and since when? gem_eio/suspend?
account for the suspend/resume cycle, we have to assume the device has
been reset to its defaults. A simple way around this is to skip the
sanitize phase for SUSPEND_TEST_DEVICES by moving it to suspend-late.
So suspend_late is not called when suspending via SUSPEND_TEST_DEVICES?
Sounds weird to me that core allows a "half-way" suspend mode. But I am
not familiar with that code so don't know.
Either way, if we skip it, that only skips the reset which is skipped
anyway in gem_eio/suspend so I did not figure out the difference.
Regards,
Tvrtko
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c | 6 +-
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gem.c | 22 +-
3 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 8f002ae22e62..0d9b8cc0436d 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -636,6 +636,8 @@ static const struct vga_switcheroo_client_ops
i915_switcheroo_ops = {
static void i915_gem_fini(struct drm_i915_private *dev_priv)
{
+ i915_gem_suspend_late(dev_priv);
+
/* Flush any outstanding unpin_work. */
i915_gem_drain_workqueue(dev_priv);
@@ -1611,7 +1613,6 @@ static int i915_drm_suspend(struct drm_device *dev)
opregion_target_state = suspend_to_idle(dev_priv) ? PCI_D1 : PCI_D3cold;
intel_opregion_notify_adapter(dev_priv, opregion_target_state);
- intel_uncore_suspend(dev_priv);
intel_opregion_unregister(dev_priv);
intel_fbdev_set_suspend(dev, FBINFO_STATE_SUSPENDED, true);
@@ -1633,7 +1634,10 @@ static int i915_drm_suspend_late(struct drm_device *dev,
bool hibernation)
disable_rpm_wakeref_asserts(dev_priv);
+ i915_gem_suspend_late(dev_priv);
+
intel_display_set_init_power(dev_priv, false);
+ intel_uncore_suspend(dev_priv);
/*
* In case of firmware assisted context save/restore don't manually
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 487922f88b76..4257ffc1bae1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3169,6 +3169,7 @@ void i915_gem_cleanup_engines(struct drm_i915_private
*dev_priv);
int i915_gem_wait_for_idle(struct drm_i915_private *dev_priv,
unsigned int flags);
int __must_check i915_gem_suspend(struct drm_i915_private *dev_priv);
+void i915_gem_suspend_late(struct drm_i915_private *dev_priv);
void i915_gem_resume(struct drm_i915_private *dev_priv);
int i915_gem_fault(struct vm_fault *vmf);
int i915_gem_object_wait(struct drm_i915_gem_object *obj,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 75bdfafc97a2..874ac1a8ec47 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5050,6 +5050,17 @@ int i915_gem_suspend(struct drm_i915_private *dev_priv)
if (WARN_ON(!intel_engines_are_idle(dev_priv)))
i915_gem_set_wedged(dev_priv); /* no hope, discard everything */
+ intel_runtime_pm_put(dev_priv);
+ return 0;
+
+err_unlock:
+ mutex_unlock(>struct_mutex);
+ intel_runtime_pm_put(dev_priv);
+ return ret;
+}
+
+void i915_gem_suspend_late(struct drm_i915_private *i915)
+{
/*
* Neither the BIOS, ourselves or any other kernel
* expects the system to be in execlists mode on startup,
@@ -5069,16 +5080,9 @@ int i915_gem_suspend(struct drm_i915_private *dev_priv)
* machines is a good idea, we don't - just in case it leaves the
* machine in an unusable condition.
*/
- intel_uc_sanitize(dev_priv);
- i915_gem_sanitize(dev_priv);
- intel_runtime_pm_put(dev_priv);
- return 0;
-
-err_unlock:
- mutex_unlock(>struct_mutex);
- intel_runtime_pm_put(dev_priv);
- return ret;
+ intel_uc_sanitize(i915);
+ i915_gem_sanitize(i915);
}
void i915_gem_resume(struct drm_i915_private *i915)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm/i915/guc: Add support for define guc_log_size in megabytes.
On Wed, 30 May 2018 15:53:34 +0200, Piotr Piorkowski wrote: At this moment we can define GuC logs sizes only using pages. But GuC also allows use for this values expressed in megabytes. Lets add support for define guc_log_size in megabytes when we debug of GuC. Signed-off-by: Piotr Piórkowski Cc: Michal Wajdeczko Cc: Michał Winiarski Cc: Joonas Lahtinen Cc: Chris Wilson --- drivers/gpu/drm/i915/intel_guc.c | 12 ++-- drivers/gpu/drm/i915/intel_guc_log.h | 6 ++ 2 files changed, 16 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c index e15047fedb45..5a42db47521b 100644 --- a/drivers/gpu/drm/i915/intel_guc.c +++ b/drivers/gpu/drm/i915/intel_guc.c @@ -263,7 +263,13 @@ static u32 guc_ctl_log_params_flags(struct intel_guc *guc) u32 offset = intel_guc_ggtt_offset(guc, guc->log.vma) >> PAGE_SHIFT; u32 flags; + #if (((CRASH_BUFFER_SIZE) % (1 << 20)) == 0) + #define UNIT (1 << 20) + #define FLAG GUC_LOG_ALLOC_IN_MEGABYTE + #else #define UNIT (4 << 10) + #define FLAG 0 + #endif BUILD_BUG_ON(!CRASH_BUFFER_SIZE); BUILD_BUG_ON(!IS_ALIGNED(CRASH_BUFFER_SIZE, UNIT)); @@ -280,13 +286,15 @@ static u32 guc_ctl_log_params_flags(struct intel_guc *guc) (GUC_LOG_ISR_MASK >> GUC_LOG_ISR_SHIFT)); flags = GUC_LOG_VALID | - GUC_LOG_NOTIFY_ON_HALF_FULL | - ((CRASH_BUFFER_SIZE/UNIT - 1) << GUC_LOG_CRASH_SHIFT) | + GUC_LOG_NOTIFY_ON_HALF_FULL; + flags |= FLAG; I think you can inject FLAG into existing statement without introducing two additional |= + flags |= ((CRASH_BUFFER_SIZE/UNIT - 1) << GUC_LOG_CRASH_SHIFT) | ((DPC_BUFFER_SIZE/UNIT - 1) << GUC_LOG_DPC_SHIFT) | ((ISR_BUFFER_SIZE/UNIT - 1) << GUC_LOG_ISR_SHIFT) | (offset << GUC_LOG_BUF_ADDR_SHIFT); #undef UNIT + #undef FLAG return flags; } diff --git a/drivers/gpu/drm/i915/intel_guc_log.h b/drivers/gpu/drm/i915/intel_guc_log.h index 1b3afdae6d0d..de39b965ae7a 100644 --- a/drivers/gpu/drm/i915/intel_guc_log.h +++ b/drivers/gpu/drm/i915/intel_guc_log.h @@ -34,9 +34,15 @@ struct intel_guc; +#ifdef DRM_I915_DEBUG_GUC +#define CRASH_BUFFER_SIZE 2097152 +#define DPC_BUFFER_SIZE8388608 +#define ISR_BUFFER_SIZE8388608 can we make it more friendly: (8 * 1024 * 1024) +#else #define CRASH_BUFFER_SIZE 8192 #define DPC_BUFFER_SIZE32768 #define ISR_BUFFER_SIZE32768 +#endif btw, are these values just max possible or selected as most valuable ? question for both debug/ndebug Michal /* * While we're using plain log level in i915, GuC controls are much more... ___ 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: per context slice/subslice powergating (rev8)
== Series Details == Series: drm/i915: per context slice/subslice powergating (rev8) URL : https://patchwork.freedesktop.org/series/42285/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4257 -> Patchwork_9151 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/42285/revisions/8/mbox/ == Known issues == Here are the changes found in Patchwork_9151 that come from known issues: === IGT changes === Issues hit igt@kms_flip@basic-flip-vs-dpms: fi-glk-j4005: PASS -> DMESG-WARN (fdo#106000) igt@kms_flip@basic-flip-vs-modeset: fi-glk-j4005: PASS -> DMESG-WARN (fdo#106097, fdo#106000) igt@kms_flip@basic-flip-vs-wf_vblank: fi-glk-j4005: PASS -> FAIL (fdo#100368) Possible fixes igt@kms_flip@basic-flip-vs-wf_vblank: fi-cnl-psr: FAIL (fdo#100368) -> PASS igt@kms_frontbuffer_tracking@basic: fi-bsw-n3050: INCOMPLETE (fdo#106729) -> PASS igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c: fi-skl-guc: FAIL (fdo#104724, fdo#103191) -> PASS igt@kms_pipe_crc_basic@read-crc-pipe-c: fi-glk-j4005: DMESG-WARN (fdo#106097, fdo#106000) -> PASS igt@prime_vgem@basic-fence-flip: fi-ilk-650: FAIL (fdo#104008) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#106000 https://bugs.freedesktop.org/show_bug.cgi?id=106000 fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097 fdo#106729 https://bugs.freedesktop.org/show_bug.cgi?id=106729 == Participating hosts (45 -> 39) == Missing(6): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-cfl-u2 fi-skl-6700hq == Build changes == * Linux: CI_DRM_4257 -> Patchwork_9151 CI_DRM_4257: 8aac35d26057479982a346c0e9cd57c2e930b7e1 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4501: 6796a604bab6df9c84af149e799902360afdd157 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9151: ab350a0f9e28cf98c5c305fc7dd273bb35e68c5b @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == ab350a0f9e28 drm/i915: add a sysfs entry to let users set sseu configs 26456fb5413e drm/i915: Expose RPCS (SSEU) configuration to userspace 211bc25308d6 drm/i915/perf: lock powergating configuration to default when active 4c85932001c4 drm/i915/perf: reuse intel_lrc ctx regs macro 76d7453744fb drm/i915/perf: simplify configure all context function bc248ff938fc drm/i915: Record the sseu configuration per-context & engine 11a6079c0062 drm/i915: Program RPCS for Broadwell == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9151/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 1/3] lib: Assert that we do manage to submit at least one batch when measuring
On 30/05/18 03:33, Chris Wilson wrote: As we measure the ring size, we never expect to find we can not submit no batches at all. Assert against the unexpected. Signed-off-by: Chris Wilson Cc: Antonio Argenziano --- lib/i915/gem_ring.c | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/i915/gem_ring.c b/lib/i915/gem_ring.c index 10d2f2cd4..7d64165eb 100644 --- a/lib/i915/gem_ring.c +++ b/lib/i915/gem_ring.c @@ -100,6 +100,7 @@ __gem_measure_ring_inflight(int fd, unsigned int engine, enum measure_ring_flags } while (1); igt_assert_eq(__execbuf(fd, ), -EINTR); + igt_assert(count); Maybe a courtesy print? With or without, Reviewed-by: Antonio Argenziano memset(, 0, sizeof(itv)); setitimer(ITIMER_REAL, , NULL); ___ 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: per context slice/subslice powergating (rev8)
== Series Details == Series: drm/i915: per context slice/subslice powergating (rev8) URL : https://patchwork.freedesktop.org/series/42285/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Program RPCS for Broadwell Okay! Commit: drm/i915: Record the sseu configuration per-context & engine -drivers/gpu/drm/i915/selftests/../i915_drv.h:3664:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3678:16: warning: expression using sizeof(void) Commit: drm/i915/perf: simplify configure all context function Okay! Commit: drm/i915/perf: reuse intel_lrc ctx regs macro Okay! Commit: drm/i915/perf: lock powergating configuration to default when active Okay! Commit: drm/i915: Expose RPCS (SSEU) configuration to userspace -drivers/gpu/drm/i915/selftests/../i915_drv.h:3678:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3691:16: warning: expression using sizeof(void) Commit: drm/i915: add a sysfs entry to let users set sseu configs -drivers/gpu/drm/i915/selftests/../i915_drv.h:3691:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3697:16: warning: expression using sizeof(void) ___ 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: per context slice/subslice powergating (rev8)
== Series Details == Series: drm/i915: per context slice/subslice powergating (rev8) URL : https://patchwork.freedesktop.org/series/42285/ State : warning == Summary == $ dim checkpatch origin/drm-tip 11a6079c0062 drm/i915: Program RPCS for Broadwell bc248ff938fc drm/i915: Record the sseu configuration per-context & engine 76d7453744fb drm/i915/perf: simplify configure all context function 4c85932001c4 drm/i915/perf: reuse intel_lrc ctx regs macro 211bc25308d6 drm/i915/perf: lock powergating configuration to default when active 26456fb5413e drm/i915: Expose RPCS (SSEU) configuration to userspace -:40: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #40: v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu() (Lionel) total: 0 errors, 1 warnings, 0 checks, 471 lines checked ab350a0f9e28 drm/i915: add a sysfs entry to let users set sseu configs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/7] drm/i915/guc: Move defines with size of GuC logs to intel_guc_log.h
On Wed, 30 May 2018 15:53:33 +0200, Piotr Piorkowski
wrote:
At this moment, we have defined GuC logs sizes in intel_guc_fwif.h, but
as these values are related directly to the GuC logs, and not to API of
GuC parameters, we should move these defines to intel_guc_log.h.
Signed-off-by: Piotr Piórkowski
Cc: Michal Wajdeczko
Cc: Michał Winiarski
Cc: Joonas Lahtinen
Cc: Chris Wilson
---
drivers/gpu/drm/i915/intel_guc.c | 28 +++-
drivers/gpu/drm/i915/intel_guc_fwif.h | 20 +++-
drivers/gpu/drm/i915/intel_guc_log.c | 28 +---
drivers/gpu/drm/i915/intel_guc_log.h | 9 +++--
4 files changed, 54 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc.c
b/drivers/gpu/drm/i915/intel_guc.c
index 3b45f06b1aa2..e15047fedb45 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -263,13 +263,31 @@ static u32 guc_ctl_log_params_flags(struct
intel_guc *guc)
u32 offset = intel_guc_ggtt_offset(guc, guc->log.vma) >> PAGE_SHIFT;
u32 flags;
- /* each allocated unit is a page */
- flags = GUC_LOG_VALID | GUC_LOG_NOTIFY_ON_HALF_FULL |
- (GUC_LOG_CRASH_PAGES << GUC_LOG_CRASH_SHIFT) |
- (GUC_LOG_DPC_PAGES << GUC_LOG_DPC_SHIFT) |
- (GUC_LOG_ISR_PAGES << GUC_LOG_ISR_SHIFT) |
+ #define UNIT (4 << 10)
+
+ BUILD_BUG_ON(!CRASH_BUFFER_SIZE);
+ BUILD_BUG_ON(!IS_ALIGNED(CRASH_BUFFER_SIZE, UNIT));
+ BUILD_BUG_ON(!DPC_BUFFER_SIZE);
+ BUILD_BUG_ON(!IS_ALIGNED(DPC_BUFFER_SIZE, UNIT));
+ BUILD_BUG_ON(!ISR_BUFFER_SIZE);
+ BUILD_BUG_ON(!IS_ALIGNED(ISR_BUFFER_SIZE, UNIT));
+
+ BUILD_BUG_ON((CRASH_BUFFER_SIZE/UNIT - 1) >
+ (GUC_LOG_CRASH_MASK >> GUC_LOG_CRASH_SHIFT));
+ BUILD_BUG_ON((DPC_BUFFER_SIZE/UNIT - 1) >
+ (GUC_LOG_DPC_MASK >> GUC_LOG_DPC_SHIFT));
+ BUILD_BUG_ON((ISR_BUFFER_SIZE/UNIT - 1) >
+ (GUC_LOG_ISR_MASK >> GUC_LOG_ISR_SHIFT));
+
+ flags = GUC_LOG_VALID |
+ GUC_LOG_NOTIFY_ON_HALF_FULL |
+ ((CRASH_BUFFER_SIZE/UNIT - 1) << GUC_LOG_CRASH_SHIFT) |
+ ((DPC_BUFFER_SIZE/UNIT - 1) << GUC_LOG_DPC_SHIFT) |
+ ((ISR_BUFFER_SIZE/UNIT - 1) << GUC_LOG_ISR_SHIFT) |
(offset << GUC_LOG_BUF_ADDR_SHIFT);
+ #undef UNIT
+
return flags;
}
diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index 0867ba76d445..1a0f2a39cef9 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -84,12 +84,12 @@
#define GUC_LOG_VALID(1 << 0)
#define GUC_LOG_NOTIFY_ON_HALF_FULL (1 << 1)
#define GUC_LOG_ALLOC_IN_MEGABYTE(1 << 3)
-#define GUC_LOG_CRASH_PAGES 1
#define GUC_LOG_CRASH_SHIFT 4
-#define GUC_LOG_DPC_PAGES7
+#define GUC_LOG_CRASH_MASK (0x1 << GUC_LOG_CRASH_SHIFT)
#define GUC_LOG_DPC_SHIFT6
-#define GUC_LOG_ISR_PAGES7
+#define GUC_LOG_DPC_MASK (0x7 << GUC_LOG_DPC_SHIFT)
#define GUC_LOG_ISR_SHIFT9
+#define GUC_LOG_ISR_MASK (0x7 << GUC_LOG_ISR_SHIFT)
#define GUC_LOG_BUF_ADDR_SHIFT 12
#define GUC_CTL_PAGE_FAULT_CONTROL 5
@@ -532,20 +532,6 @@ enum guc_log_buffer_type {
};
/**
- * DOC: GuC Log buffer Layout
- *
- * Page0 +---+
- *| ISR state header (32 bytes) |
- *| DPC state header |
- *| Crash dump state header |
- * Page1 +---+
- *| ISR logs|
- * Page9 +---+
- *| DPC logs|
- * Page17 +---+
- *| Crash Dump logs |
- *+---+
- *
* Below state structure is used for coordination of retrieval of GuC
firmware
* logs. Separate state is maintained for each log buffer type.
* read_ptr points to the location where i915 read last in log buffer
and
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c
b/drivers/gpu/drm/i915/intel_guc_log.c
index a751025b6ad7..1c4a8de9c305 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -27,6 +27,28 @@
#include "intel_guc_log.h"
#include "i915_drv.h"
+/*
+ * GuC Log buffer Layout
+ *
+ * +===+ 00B
+ * |Crash dump state header|
+ * +---+ 32B
+ * | DPC state header|
+ * +---+ 64B
+ * | ISR state header|
+ * +---+ 96B
+ * | |
+ * +===+ PAGE_SIZE (4KB)
+ * |Crash Dump logs|
+ * +===+ +
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/5] drm/i915: Remove stale asserts from i915_gem_find_active_request()
== Series Details == Series: series starting with [1/5] drm/i915: Remove stale asserts from i915_gem_find_active_request() URL : https://patchwork.freedesktop.org/series/43892/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4257 -> Patchwork_9150 = == Summary - FAILURE == Serious unknown changes coming with Patchwork_9150 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9150, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/43892/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9150: === IGT changes === Possible regressions igt@gem_exec_suspend@basic-s4-devices: fi-bdw-5557u: PASS -> INCOMPLETE == Known issues == Here are the changes found in Patchwork_9150 that come from known issues: === IGT changes === Issues hit igt@gem_ctx_create@basic-files: fi-glk-j4005: PASS -> DMESG-WARN (fdo#105719) +1 igt@gem_exec_suspend@basic-s4-devices: fi-bdw-gvtdvm: PASS -> INCOMPLETE (fdo#105600) igt@kms_flip@basic-flip-vs-dpms: fi-glk-j4005: PASS -> DMESG-WARN (fdo#106000, fdo#105719) igt@kms_flip@basic-flip-vs-wf_vblank: fi-glk-j4005: PASS -> FAIL (fdo#100368) igt@kms_pipe_crc_basic@read-crc-pipe-c-frame-sequence: fi-skl-6700k2: PASS -> FAIL (fdo#103191, fdo#104724) Possible fixes igt@gem_mmap_gtt@basic-small-bo-tiledx: fi-gdg-551: FAIL (fdo#102575) -> PASS igt@kms_flip@basic-flip-vs-wf_vblank: fi-cnl-psr: FAIL (fdo#100368) -> PASS igt@kms_frontbuffer_tracking@basic: fi-bsw-n3050: INCOMPLETE (fdo#106729) -> PASS igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c: fi-skl-guc: FAIL (fdo#103191, fdo#104724) -> PASS igt@kms_pipe_crc_basic@read-crc-pipe-c: fi-glk-j4005: DMESG-WARN (fdo#106000, fdo#106097) -> SKIP igt@prime_vgem@basic-fence-flip: fi-ilk-650: FAIL (fdo#104008) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105600 https://bugs.freedesktop.org/show_bug.cgi?id=105600 fdo#105719 https://bugs.freedesktop.org/show_bug.cgi?id=105719 fdo#106000 https://bugs.freedesktop.org/show_bug.cgi?id=106000 fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097 fdo#106729 https://bugs.freedesktop.org/show_bug.cgi?id=106729 == Participating hosts (45 -> 38) == Missing(7): fi-ilk-m540 fi-cnl-y3 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-cfl-u2 fi-skl-6700hq == Build changes == * Linux: CI_DRM_4257 -> Patchwork_9150 CI_DRM_4257: 8aac35d26057479982a346c0e9cd57c2e930b7e1 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4501: 6796a604bab6df9c84af149e799902360afdd157 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9150: e40d1490ef1623e7d985bf6f68eb6d0c055566e8 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == e40d1490ef16 drm/i915: Only sanitize GEM from late suspend d161f21ca6dd drm/i915: After reset on sanitization, reset the engine backends 87510967cc30 drm/i915: "Race-to-idle" after switching to the kernel context 047628f19723 drm/i915: Switch to kernel context before idling at runtime == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9150/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Cancel reset preparations on failed resets
Quoting Mika Kuoppala (2018-05-30 16:02:05)
> Our reset handling has a retry layer further up in the
> chain. As we have told the engine to prepare for reset,
> and failed it, make sure to remove that preparation so
> that the next attempted reset has a clean slate by triggering
> another full prepare cycle for the engines. Note that with
> successful reset, there is nothing to cleanup.
>
> Cc: Chris Wilson
> Signed-off-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/intel_uncore.c | 20
> 1 file changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index b36a3b5736a0..68fe4c16acfb 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -2092,22 +2092,26 @@ static int gen8_reset_engines(struct drm_i915_private
> *dev_priv,
> unsigned engine_mask)
> {
> struct intel_engine_cs *engine;
> - unsigned int tmp;
> + unsigned int tmp, ret;
int ret; Might as well keep the types clean.
> - for_each_engine_masked(engine, dev_priv, engine_mask, tmp)
> - if (gen8_reset_engine_start(engine))
> + for_each_engine_masked(engine, dev_priv, engine_mask, tmp) {
> + if (gen8_reset_engine_start(engine)) {
> + ret = -EIO;
> goto not_ready;
> + }
> + }
>
> if (INTEL_GEN(dev_priv) >= 11)
> - return gen11_reset_engines(dev_priv, engine_mask);
> + ret = gen11_reset_engines(dev_priv, engine_mask);
> else
> - return gen6_reset_engines(dev_priv, engine_mask);
> + ret = gen6_reset_engines(dev_priv, engine_mask);
>
> not_ready:
> - for_each_engine_masked(engine, dev_priv, engine_mask, tmp)
> - gen8_reset_engine_cancel(engine);
> + if (ret)
Or we just always clear the bit here. On the success path, it will be
just a nop. On the not_ready path we're already clearing untouched
engines, so might as well go whole hog and overkill everything?
Might as well throw in a
References: https://bugs.freedesktop.org/show_bug.cgi?id=106684
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/7] drm/i915/guc: Don't store runtime GuC log level in modparam
== Series Details == Series: series starting with [1/7] drm/i915/guc: Don't store runtime GuC log level in modparam URL : https://patchwork.freedesktop.org/series/43952/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4257 -> Patchwork_9149 = == Summary - FAILURE == Serious unknown changes coming with Patchwork_9149 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9149, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/43952/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9149: === IGT changes === Possible regressions igt@kms_flip@basic-flip-vs-wf_vblank: fi-glk-j4005: PASS -> FAIL Warnings igt@gem_exec_gttfill@basic: fi-pnv-d510:PASS -> SKIP == Known issues == Here are the changes found in Patchwork_9149 that come from known issues: === IGT changes === Issues hit igt@kms_flip@basic-flip-vs-wf_vblank: fi-hsw-4770:PASS -> FAIL (fdo#100368) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-bxt-dsi: PASS -> INCOMPLETE (fdo#103927) Possible fixes igt@kms_flip@basic-flip-vs-wf_vblank: fi-cnl-psr: FAIL (fdo#100368) -> PASS igt@kms_frontbuffer_tracking@basic: fi-bsw-n3050: INCOMPLETE (fdo#106729) -> PASS igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c: fi-skl-guc: FAIL (fdo#104724, fdo#103191) -> PASS igt@kms_pipe_crc_basic@read-crc-pipe-c: fi-glk-j4005: DMESG-WARN (fdo#106097, fdo#106000) -> PASS igt@prime_vgem@basic-fence-flip: fi-ilk-650: FAIL (fdo#104008) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#106000 https://bugs.freedesktop.org/show_bug.cgi?id=106000 fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097 fdo#106729 https://bugs.freedesktop.org/show_bug.cgi?id=106729 == Participating hosts (45 -> 39) == Missing(6): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-cfl-u2 fi-skl-6700hq == Build changes == * Linux: CI_DRM_4257 -> Patchwork_9149 CI_DRM_4257: 8aac35d26057479982a346c0e9cd57c2e930b7e1 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4501: 6796a604bab6df9c84af149e799902360afdd157 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9149: 0ad99c4dbd3b6cbeba24c531d591d023e8b7a462 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 0ad99c4dbd3b drm/i915/guc: Add support for define guc_log_size in megabytes. f72db2efed06 drm/i915/guc: Move defines with size of GuC logs to intel_guc_log.h 6848b97dc926 drm/i915/guc: Refactoring preparation of the GUC_CTL_CTXINFO parameter dcdde612e96a drm/i915/guc: Refactoring preparation of the GUC_CTL_LOG_PARAMS parameter 492303e41449 drm/i915/guc: Refactoring preparation of the GUC_CTL_FEATURE parameter fa025916c333 drm/i915/guc: Refactoring preparation of the GUC_CTL_DEBUG parameter ef254da06d89 drm/i915/guc: Don't store runtime GuC log level in modparam == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9149/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/pmu: Measure sampler intervals
Quoting Tvrtko Ursulin (2018-05-30 16:27:02)
>
> On 30/05/2018 15:55, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-05-30 15:37:18)
> >>
> >> On 30/05/2018 12:55, Chris Wilson wrote:
> >>> hrtimer is not reliable enough to assume fixed intervals, and so even
> >>> coarse accuracy (in the face of kasan and similar heavy debugging) we
> >>> need to measure the actual interval between sample.
> >>>
> >>> While using a single timestamp to compute the interval does not allow
> >>> very fine accuracy (consider the impact of a slow forcewake between
> >>> different samples after the timestamp is read) is much better than
> >>> assuming the interval.
> >>>
> >>> v2: Make use of the sample period for estimating the GPU clock cycles,
> >>> leaving the frequency calculation (the averaging) to the caller.
> >>> Introduce new samplers for reporting cycles instead of Hz.
> >>>
> >>> Testcase: igt/perf_pmu #ivb
> >>> Signed-off-by: Chris Wilson
> >>> Cc: Tvrtko Ursulin
> >>> ---
> >>>drivers/gpu/drm/i915/i915_pmu.c | 44 ++---
> >>>drivers/gpu/drm/i915/i915_pmu.h | 6 +
> >>>include/uapi/drm/i915_drm.h | 2 ++
> >>>3 files changed, 43 insertions(+), 9 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/i915_pmu.c
> >>> b/drivers/gpu/drm/i915/i915_pmu.c
> >>> index dc87797db500..12033e47e3b4 100644
> >>> --- a/drivers/gpu/drm/i915/i915_pmu.c
> >>> +++ b/drivers/gpu/drm/i915/i915_pmu.c
> >>> @@ -86,6 +86,8 @@ static bool pmu_needs_timer(struct drm_i915_private
> >>> *i915, bool gpu_active)
> >>> */
> >>>enable &= config_enabled_mask(I915_PMU_ACTUAL_FREQUENCY) |
> >>> config_enabled_mask(I915_PMU_REQUESTED_FREQUENCY) |
> >>> + config_enabled_mask(I915_PMU_ACTUAL_CLOCK) |
> >>> + config_enabled_mask(I915_PMU_REQUESTED_CLOCK) |
> >>> ENGINE_SAMPLE_MASK;
> >>>
> >>>/*
> >>> @@ -127,6 +129,7 @@ static void __i915_pmu_maybe_start_timer(struct
> >>> drm_i915_private *i915)
> >>>{
> >>>if (!i915->pmu.timer_enabled && pmu_needs_timer(i915, true)) {
> >>>i915->pmu.timer_enabled = true;
> >>> + i915->pmu.timestamp = ktime_get();
> >>>hrtimer_start_range_ns(>pmu.timer,
> >>> ns_to_ktime(PERIOD), 0,
> >>> HRTIMER_MODE_REL_PINNED);
> >>> @@ -160,7 +163,7 @@ update_sample(struct i915_pmu_sample *sample, u32
> >>> unit, u32 val)
> >>>sample->cur += mul_u32_u32(val, unit);
> >>>}
> >>>
> >>> -static void engines_sample(struct drm_i915_private *dev_priv)
> >>> +static void engines_sample(struct drm_i915_private *dev_priv, u64 period)
> >>>{
> >>>struct intel_engine_cs *engine;
> >>>enum intel_engine_id id;
> >>> @@ -183,7 +186,7 @@ static void engines_sample(struct drm_i915_private
> >>> *dev_priv)
> >>>val = !i915_seqno_passed(current_seqno, last_seqno);
> >>>
> >>>update_sample(>pmu.sample[I915_SAMPLE_BUSY],
> >>> - PERIOD, val);
> >>> + period, val);
> >>>
> >>>if (val && (engine->pmu.enable &
> >>>(BIT(I915_SAMPLE_WAIT) | BIT(I915_SAMPLE_SEMA {
> >>> @@ -195,10 +198,10 @@ static void engines_sample(struct drm_i915_private
> >>> *dev_priv)
> >>>}
> >>>
> >>>update_sample(>pmu.sample[I915_SAMPLE_WAIT],
> >>> - PERIOD, !!(val & RING_WAIT));
> >>> + period, !!(val & RING_WAIT));
> >>>
> >>>update_sample(>pmu.sample[I915_SAMPLE_SEMA],
> >>> - PERIOD, !!(val & RING_WAIT_SEMAPHORE));
> >>> + period, !!(val & RING_WAIT_SEMAPHORE));
> >>>}
> >>>
> >>>if (fw)
> >>> @@ -207,10 +210,11 @@ static void engines_sample(struct drm_i915_private
> >>> *dev_priv)
> >>>intel_runtime_pm_put(dev_priv);
> >>>}
> >>>
> >>> -static void frequency_sample(struct drm_i915_private *dev_priv)
> >>> +static void frequency_sample(struct drm_i915_private *dev_priv, u64
> >>> period)
> >>>{
> >>>if (dev_priv->pmu.enable &
> >>> - config_enabled_mask(I915_PMU_ACTUAL_FREQUENCY)) {
> >>> + (config_enabled_mask(I915_PMU_ACTUAL_CLOCK) |
> >>> + config_enabled_mask(I915_PMU_ACTUAL_FREQUENCY))) {
> >>>u32 val;
> >>>
> >>>val = dev_priv->gt_pm.rps.cur_freq;
> >>> @@ -223,13 +227,20 @@ static void frequency_sample(struct
> >>> drm_i915_private *dev_priv)
> >>>
> >>>
> >>> update_sample(_priv->pmu.sample[__I915_SAMPLE_FREQ_ACT],
> >>> 1, intel_gpu_freq(dev_priv, val));
> >>> +
> >>> update_sample(_priv->pmu.sample[__I915_SAMPLE_CLOCK_ACT],
> >>> + period,
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/7] drm/i915/guc: Don't store runtime GuC log level in modparam
== Series Details ==
Series: series starting with [1/7] drm/i915/guc: Don't store runtime GuC log
level in modparam
URL : https://patchwork.freedesktop.org/series/43952/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ef254da06d89 drm/i915/guc: Don't store runtime GuC log level in modparam
fa025916c333 drm/i915/guc: Refactoring preparation of the GUC_CTL_DEBUG
parameter
492303e41449 drm/i915/guc: Refactoring preparation of the GUC_CTL_FEATURE
parameter
dcdde612e96a drm/i915/guc: Refactoring preparation of the GUC_CTL_LOG_PARAMS
parameter
-:30: CHECK:LINE_SPACING: Please use a blank line after
function/struct/union/enum declarations
#30: FILE: drivers/gpu/drm/i915/intel_guc.c:242:
}
+static u32 guc_ctl_log_params_flags(struct intel_guc *guc)
total: 0 errors, 0 warnings, 1 checks, 60 lines checked
6848b97dc926 drm/i915/guc: Refactoring preparation of the GUC_CTL_CTXINFO
parameter
-:35: CHECK:BRACES: Blank lines aren't necessary after an open brace '{'
#35: FILE: drivers/gpu/drm/i915/intel_guc.c:250:
+ if (USES_GUC_SUBMISSION(guc_to_i915(guc))) {
+
total: 0 errors, 0 warnings, 1 checks, 42 lines checked
f72db2efed06 drm/i915/guc: Move defines with size of GuC logs to intel_guc_log.h
-:42: CHECK:SPACING: spaces preferred around that '/' (ctx:VxV)
#42: FILE: drivers/gpu/drm/i915/intel_guc.c:275:
+ BUILD_BUG_ON((CRASH_BUFFER_SIZE/UNIT - 1) >
^
-:44: CHECK:SPACING: spaces preferred around that '/' (ctx:VxV)
#44: FILE: drivers/gpu/drm/i915/intel_guc.c:277:
+ BUILD_BUG_ON((DPC_BUFFER_SIZE/UNIT - 1) >
^
-:46: CHECK:SPACING: spaces preferred around that '/' (ctx:VxV)
#46: FILE: drivers/gpu/drm/i915/intel_guc.c:279:
+ BUILD_BUG_ON((ISR_BUFFER_SIZE/UNIT - 1) >
^
-:51: CHECK:SPACING: spaces preferred around that '/' (ctx:VxV)
#51: FILE: drivers/gpu/drm/i915/intel_guc.c:284:
+ ((CRASH_BUFFER_SIZE/UNIT - 1) << GUC_LOG_CRASH_SHIFT) |
^
-:52: CHECK:SPACING: spaces preferred around that '/' (ctx:VxV)
#52: FILE: drivers/gpu/drm/i915/intel_guc.c:285:
+ ((DPC_BUFFER_SIZE/UNIT - 1) << GUC_LOG_DPC_SHIFT) |
^
-:53: CHECK:SPACING: spaces preferred around that '/' (ctx:VxV)
#53: FILE: drivers/gpu/drm/i915/intel_guc.c:286:
+ ((ISR_BUFFER_SIZE/UNIT - 1) << GUC_LOG_ISR_SHIFT) |
^
total: 0 errors, 0 warnings, 6 checks, 128 lines checked
0ad99c4dbd3b drm/i915/guc: Add support for define guc_log_size in megabytes.
-:47: CHECK:SPACING: spaces preferred around that '/' (ctx:VxV)
#47: FILE: drivers/gpu/drm/i915/intel_guc.c:291:
+ flags |= ((CRASH_BUFFER_SIZE/UNIT - 1) << GUC_LOG_CRASH_SHIFT) |
^
total: 0 errors, 0 warnings, 1 checks, 45 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 2/6] drm/i915: hdmi: add CEC notifier to intel_hdmi
On Thu, May 24, 2018 at 11:57:17AM +0200, Neil Armstrong wrote:
> This patchs adds the cec_notifier feature to the intel_hdmi part
> of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate
> between each HDMI ports.
> The changes will allow the i915 HDMI code to notify EDID and HPD changes
> to an eventual CEC adapter.
>
> Signed-off-by: Neil Armstrong
> Reviewed-by: Hans Verkuil
> ---
> drivers/gpu/drm/i915/Kconfig | 1 +
> drivers/gpu/drm/i915/intel_display.h | 20
> drivers/gpu/drm/i915/intel_drv.h | 2 ++
> drivers/gpu/drm/i915/intel_hdmi.c| 13 +
> 4 files changed, 36 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index dfd9588..2d65d56 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -23,6 +23,7 @@ config DRM_I915
> select SYNC_FILE
> select IOSF_MBI
> select CRC32
> + select CEC_CORE if CEC_NOTIFIER
> help
> Choose this option if you have a system that has "Intel Graphics
> Media Accelerator" or "HD Graphics" integrated graphics,
> diff --git a/drivers/gpu/drm/i915/intel_display.h
> b/drivers/gpu/drm/i915/intel_display.h
> index 4e7418b..c68d1c8 100644
> --- a/drivers/gpu/drm/i915/intel_display.h
> +++ b/drivers/gpu/drm/i915/intel_display.h
> @@ -126,6 +126,26 @@ enum port {
>
> #define port_name(p) ((p) + 'A')
>
> +static inline const char *port_identifier(enum port port)
> +{
> + switch (port) {
> + case PORT_A:
> + return "Port A";
> + case PORT_B:
> + return "Port B";
> + case PORT_C:
> + return "Port C";
> + case PORT_D:
> + return "Port D";
> + case PORT_E:
> + return "Port E";
> + case PORT_F:
> + return "Port F";
> + default:
> + return "";
> + }
> +}
Could use a comment to make it clear that this identifier is
expected to remain stable since it's referenced from other drivers.
> +
> enum dpio_channel {
> DPIO_CH0,
> DPIO_CH1
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index d436858..b50e51b 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -39,6 +39,7 @@
> #include
> #include
> #include
> +#include
>
> /**
> * __wait_for - magic wait macro
> @@ -1001,6 +1002,7 @@ struct intel_hdmi {
> bool has_audio;
> bool rgb_quant_range_selectable;
> struct intel_connector *attached_connector;
> + struct cec_notifier *notifier;
"notifier" seems a bit too generic a name. "cec_notifier" would be
better.
Apart from that this seems OK to me
Reviewed-by: Ville Syrjälä
> };
>
> struct intel_dp_mst_encoder;
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 1baef4a..d522b5b 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1868,6 +1868,8 @@ intel_hdmi_set_edid(struct drm_connector *connector)
> connected = true;
> }
>
> + cec_notifier_set_phys_addr_from_edid(intel_hdmi->notifier, edid);
> +
> return connected;
> }
>
> @@ -1876,6 +1878,7 @@ intel_hdmi_detect(struct drm_connector *connector, bool
> force)
> {
> enum drm_connector_status status;
> struct drm_i915_private *dev_priv = to_i915(connector->dev);
> + struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
>
> DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
> connector->base.id, connector->name);
> @@ -1891,6 +1894,9 @@ intel_hdmi_detect(struct drm_connector *connector, bool
> force)
>
> intel_display_power_put(dev_priv, POWER_DOMAIN_GMBUS);
>
> + if (status != connector_status_connected)
> + cec_notifier_phys_addr_invalidate(intel_hdmi->notifier);
> +
> return status;
> }
>
> @@ -2031,6 +2037,8 @@ static void chv_hdmi_pre_enable(struct intel_encoder
> *encoder,
>
> static void intel_hdmi_destroy(struct drm_connector *connector)
> {
> + if (intel_attached_hdmi(connector)->notifier)
> + cec_notifier_put(intel_attached_hdmi(connector)->notifier);
> kfree(to_intel_connector(connector)->detect_edid);
> drm_connector_cleanup(connector);
> kfree(connector);
> @@ -2358,6 +2366,11 @@ void intel_hdmi_init_connector(struct
> intel_digital_port *intel_dig_port,
> u32 temp = I915_READ(PEG_BAND_GAP_DATA);
> I915_WRITE(PEG_BAND_GAP_DATA, (temp & ~0xf) | 0xd);
> }
> +
> + intel_hdmi->notifier = cec_notifier_get_conn(dev->dev,
> + port_identifier(port));
> + if (!intel_hdmi->notifier)
> + DRM_DEBUG_KMS("CEC notifier get failed\n");
> }
>
> void intel_hdmi_init(struct drm_i915_private *dev_priv,
> --
> 2.7.4
>
>
Re: [Intel-gfx] [PATCH v2] drm/i915/pmu: Measure sampler intervals
On 30/05/2018 15:55, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-05-30 15:37:18)
On 30/05/2018 12:55, Chris Wilson wrote:
hrtimer is not reliable enough to assume fixed intervals, and so even
coarse accuracy (in the face of kasan and similar heavy debugging) we
need to measure the actual interval between sample.
While using a single timestamp to compute the interval does not allow
very fine accuracy (consider the impact of a slow forcewake between
different samples after the timestamp is read) is much better than
assuming the interval.
v2: Make use of the sample period for estimating the GPU clock cycles,
leaving the frequency calculation (the averaging) to the caller.
Introduce new samplers for reporting cycles instead of Hz.
Testcase: igt/perf_pmu #ivb
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_pmu.c | 44 ++---
drivers/gpu/drm/i915/i915_pmu.h | 6 +
include/uapi/drm/i915_drm.h | 2 ++
3 files changed, 43 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index dc87797db500..12033e47e3b4 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -86,6 +86,8 @@ static bool pmu_needs_timer(struct drm_i915_private *i915,
bool gpu_active)
*/
enable &= config_enabled_mask(I915_PMU_ACTUAL_FREQUENCY) |
config_enabled_mask(I915_PMU_REQUESTED_FREQUENCY) |
+ config_enabled_mask(I915_PMU_ACTUAL_CLOCK) |
+ config_enabled_mask(I915_PMU_REQUESTED_CLOCK) |
ENGINE_SAMPLE_MASK;
/*
@@ -127,6 +129,7 @@ static void __i915_pmu_maybe_start_timer(struct
drm_i915_private *i915)
{
if (!i915->pmu.timer_enabled && pmu_needs_timer(i915, true)) {
i915->pmu.timer_enabled = true;
+ i915->pmu.timestamp = ktime_get();
hrtimer_start_range_ns(>pmu.timer,
ns_to_ktime(PERIOD), 0,
HRTIMER_MODE_REL_PINNED);
@@ -160,7 +163,7 @@ update_sample(struct i915_pmu_sample *sample, u32 unit, u32
val)
sample->cur += mul_u32_u32(val, unit);
}
-static void engines_sample(struct drm_i915_private *dev_priv)
+static void engines_sample(struct drm_i915_private *dev_priv, u64 period)
{
struct intel_engine_cs *engine;
enum intel_engine_id id;
@@ -183,7 +186,7 @@ static void engines_sample(struct drm_i915_private
*dev_priv)
val = !i915_seqno_passed(current_seqno, last_seqno);
update_sample(>pmu.sample[I915_SAMPLE_BUSY],
- PERIOD, val);
+ period, val);
if (val && (engine->pmu.enable &
(BIT(I915_SAMPLE_WAIT) | BIT(I915_SAMPLE_SEMA {
@@ -195,10 +198,10 @@ static void engines_sample(struct drm_i915_private
*dev_priv)
}
update_sample(>pmu.sample[I915_SAMPLE_WAIT],
- PERIOD, !!(val & RING_WAIT));
+ period, !!(val & RING_WAIT));
update_sample(>pmu.sample[I915_SAMPLE_SEMA],
- PERIOD, !!(val & RING_WAIT_SEMAPHORE));
+ period, !!(val & RING_WAIT_SEMAPHORE));
}
if (fw)
@@ -207,10 +210,11 @@ static void engines_sample(struct drm_i915_private
*dev_priv)
intel_runtime_pm_put(dev_priv);
}
-static void frequency_sample(struct drm_i915_private *dev_priv)
+static void frequency_sample(struct drm_i915_private *dev_priv, u64 period)
{
if (dev_priv->pmu.enable &
- config_enabled_mask(I915_PMU_ACTUAL_FREQUENCY)) {
+ (config_enabled_mask(I915_PMU_ACTUAL_CLOCK) |
+ config_enabled_mask(I915_PMU_ACTUAL_FREQUENCY))) {
u32 val;
val = dev_priv->gt_pm.rps.cur_freq;
@@ -223,13 +227,20 @@ static void frequency_sample(struct drm_i915_private
*dev_priv)
update_sample(_priv->pmu.sample[__I915_SAMPLE_FREQ_ACT],
1, intel_gpu_freq(dev_priv, val));
+ update_sample(_priv->pmu.sample[__I915_SAMPLE_CLOCK_ACT],
+ period, intel_gpu_freq(dev_priv, val));
Cache intel_gpu_freq in a local.
}
if (dev_priv->pmu.enable &
- config_enabled_mask(I915_PMU_REQUESTED_FREQUENCY)) {
+ (config_enabled_mask(I915_PMU_REQUESTED_CLOCK) |
+ config_enabled_mask(I915_PMU_REQUESTED_FREQUENCY))) {
update_sample(_priv->pmu.sample[__I915_SAMPLE_FREQ_REQ], 1,
intel_gpu_freq(dev_priv,
dev_priv->gt_pm.rps.cur_freq));
+ update_sample(_priv->pmu.sample[__I915_SAMPLE_CLOCK_REQ],
+ period,
+ intel_gpu_freq(dev_priv,
+
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/pmu: Measure sampler intervals (rev2)
== Series Details == Series: drm/i915/pmu: Measure sampler intervals (rev2) URL : https://patchwork.freedesktop.org/series/43795/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4257_full -> Patchwork_9148_full = == Summary - FAILURE == Serious unknown changes coming with Patchwork_9148_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9148_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/43795/revisions/2/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9148_full: === IGT changes === Possible regressions igt@perf_pmu@other-init-4: shard-kbl: PASS -> DMESG-FAIL igt@perf_pmu@other-read-4: shard-glk: PASS -> DMESG-FAIL Warnings igt@gem_mocs_settings@mocs-rc6-render: shard-kbl: PASS -> SKIP +1 == Known issues == Here are the changes found in Patchwork_9148_full that come from known issues: === IGT changes === Issues hit igt@gem_ctx_isolation@bcs0-dirty-switch: shard-kbl: PASS -> INCOMPLETE (fdo#103665) +1 igt@kms_atomic_transition@1x-modeset-transitions-nonblocking: shard-glk: PASS -> FAIL (fdo#105703) igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic: shard-glk: PASS -> FAIL (fdo#106509, fdo#105454) igt@kms_flip@flip-vs-expired-vblank: shard-glk: PASS -> FAIL (fdo#102887, fdo#105363) igt@kms_flip_tiling@flip-x-tiled: shard-glk: PASS -> FAIL (fdo#104724) igt@perf_pmu@other-init-4: shard-snb: PASS -> INCOMPLETE (fdo#105411) +1 shard-apl: PASS -> INCOMPLETE (fdo#103927) +1 igt@perf_pmu@other-read-4: shard-hsw: PASS -> INCOMPLETE (fdo#103540) +2 igt@prime_vgem@wait-render: shard-glk: PASS -> INCOMPLETE (k.org#198133, fdo#103359) +2 Possible fixes igt@drv_selftest@live_hangcheck: shard-kbl: DMESG-FAIL (fdo#106560) -> PASS igt@gem_exec_parallel@render-fds: shard-snb: INCOMPLETE (fdo#105411) -> PASS igt@kms_flip@flip-vs-expired-vblank-interruptible: shard-glk: FAIL (fdo#105363) -> PASS igt@kms_flip@plain-flip-ts-check: shard-glk: FAIL (fdo#100368) -> PASS igt@kms_flip_tiling@flip-to-x-tiled: shard-glk: FAIL (fdo#104724) -> PASS igt@kms_flip_tiling@flip-to-y-tiled: shard-glk: FAIL (fdo#104724, fdo#103822) -> PASS igt@perf_pmu@rc6-runtime-pm: shard-kbl: FAIL (fdo#105010) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105010 https://bugs.freedesktop.org/show_bug.cgi?id=105010 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411 fdo#105454 https://bugs.freedesktop.org/show_bug.cgi?id=105454 fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703 fdo#106509 https://bugs.freedesktop.org/show_bug.cgi?id=106509 fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4257 -> Patchwork_9148 CI_DRM_4257: 8aac35d26057479982a346c0e9cd57c2e930b7e1 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4501: 6796a604bab6df9c84af149e799902360afdd157 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9148: 5d03705baa619c391ea3b8ce9e531f0c19e39cfc @ git://anongit.freedesktop.org/gfx-ci/linux == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9148/shards.html ___ 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/guc: Refactoring preparation of the GUC_CTL_CTXINFO parameter
On Wed, 30 May 2018 15:53:32 +0200, Piotr Piorkowski
wrote:
At the moment, the preparation of GUC_CTL_CTXINFO is disordered.
Lets move all GUC_CTL_CTXINFO related operations to one place.
Signed-off-by: Piotr Piórkowski
Cc: Michal Wajdeczko
Cc: Michał Winiarski
Cc: Joonas Lahtinen
Cc: Chris Wilson
---
drivers/gpu/drm/i915/intel_guc.c | 30 --
1 file changed, 20 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc.c
b/drivers/gpu/drm/i915/intel_guc.c
index 185459ee49c9..3b45f06b1aa2 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -239,6 +239,25 @@ static u32 guc_ctl_feature_flags(struct intel_guc
*guc)
return flags;
}
+
+static u32 guc_ctl_ctxinfo_flags(struct intel_guc *guc)
+{
+ u32 flags = 0;
+ u32 ctxnum;
+ u32 base;
better to declare ctxnum/base inside 'if' below
+
+ if (USES_GUC_SUBMISSION(guc_to_i915(guc))) {
+
+ base = intel_guc_ggtt_offset(guc, guc->stage_desc_pool);
+ ctxnum = GUC_MAX_STAGE_DESCRIPTORS / 16;
+
+ base >>= PAGE_SHIFT;
+ flags = (base << GUC_CTL_BASE_ADDR_SHIFT) |
to be future friendly and not overwrite other bits use:
flags |= ...
+ (ctxnum << GUC_CTL_CTXNUM_IN16_SHIFT);
+ }
+ return flags;
+}
+
static u32 guc_ctl_log_params_flags(struct intel_guc *guc)
{
u32 offset = intel_guc_ggtt_offset(guc, guc->log.vma) >> PAGE_SHIFT;
@@ -280,16 +299,7 @@ void intel_guc_init_params(struct intel_guc *guc)
params[GUC_CTL_FEATURE] = guc_ctl_feature_flags(guc);
params[GUC_CTL_LOG_PARAMS] = guc_ctl_log_params_flags(guc);
params[GUC_CTL_DEBUG] = guc_ctl_debug_flags(guc);
-
- /* If GuC submission is enabled, set up additional parameters here */
- if (USES_GUC_SUBMISSION(dev_priv)) {
- u32 pgs = intel_guc_ggtt_offset(guc, guc->stage_desc_pool);
- u32 ctx_in_16 = GUC_MAX_STAGE_DESCRIPTORS / 16;
-
- pgs >>= PAGE_SHIFT;
- params[GUC_CTL_CTXINFO] = (pgs << GUC_CTL_BASE_ADDR_SHIFT) |
- (ctx_in_16 << GUC_CTL_CTXNUM_IN16_SHIFT);
- }
+ params[GUC_CTL_CTXINFO] = guc_ctl_ctxinfo_flags(guc);
/*
* All SOFT_SCRATCH registers are in FORCEWAKE_BLITTER domain and
with above fixed,
Reviewed-by: Michal Wajdeczko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Add WaKBLVECSSemaphoreWaitPoll
There is a problem with kbl up to rev E0 where a heavy
memory traffic from adjacent engine(s) can cause an engine
reset to fail. This traffic can be from normal memory accesses
or it can be from heavy polling on a semaphore wait.
To combat the normal traffic, we do our best to idle the adjacent
engines, before we ask the engine to prepare for reset. For per
engine reset, this will add an unwanted extra latency as we
do blanket approach before every reset. In past already have
noticed that idling an engine before reset, improves our chances
of resetting it, but this only idles the engines we are about to
reset, not the adjancent ones.
We could only take the approach of idling adjacent engines,
if the first reset fails. But in this area, it is usually best
to get it right off the bat.
For the second issue where unlimited semaphore wait poll loop
is generating the heavy memory traffic and preventing a reset,
we add one microsecond poll interval to semaphore wait to
guarantee bandwidth for the reset preration. The side effect
is that we make semaphore completion latencies also 1us longer.
References: VTHSD#2227190, HSDES#1604216706, BSID#0917
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_engine_cs.c | 30
drivers/gpu/drm/i915/intel_ringbuffer.h | 1 +
drivers/gpu/drm/i915/intel_uncore.c | 25
drivers/gpu/drm/i915/intel_workarounds.c | 9 +++
5 files changed, 66 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f238b7b33cd9..3c615a865cc5 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2237,6 +2237,7 @@ enum i915_power_well_id {
#define RING_RESET_CTL(base) _MMIO((base)+0xd0)
#define RESET_CTL_REQUEST_RESET (1 << 0)
#define RESET_CTL_READY_TO_RESET (1 << 1)
+#define RING_SEMA_WAIT_POLL(base) _MMIO((base)+0x24c)
#define HSW_GTT_CACHE_EN _MMIO(0x4024)
#define GTT_CACHE_EN_ALL 0xF0007FFF
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 13448ea76f57..4d30cbb2281e 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -808,6 +808,36 @@ int intel_engine_stop_cs(struct intel_engine_cs *engine)
return err;
}
+int intel_engine_start_cs(struct intel_engine_cs *engine)
+{
+ struct drm_i915_private *dev_priv = engine->i915;
+ const u32 base = engine->mmio_base;
+ const i915_reg_t mode = RING_MI_MODE(base);
+ int err;
+
+ if (INTEL_GEN(dev_priv) < 3)
+ return -ENODEV;
+
+ GEM_TRACE("%s\n", engine->name);
+
+ I915_WRITE_FW(mode, _MASKED_BIT_DISABLE(STOP_RING));
+
+ err = 0;
+ if (__intel_wait_for_register_fw(dev_priv,
+mode, MODE_IDLE, 0,
+1000, 0,
+NULL)) {
+ GEM_TRACE("%s: timed out on STOP_RING -> NOT IDLE\n",
+ engine->name);
+ err = -ETIMEDOUT;
+ }
+
+ /* A final mmio read to let GPU writes be hopefully flushed to memory */
+ POSTING_READ_FW(mode);
+
+ return err;
+}
+
const char *i915_cache_level_str(struct drm_i915_private *i915, int type)
{
switch (type) {
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index acef385c4c80..5e2c59128fa9 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -879,6 +879,7 @@ int intel_init_blt_ring_buffer(struct intel_engine_cs
*engine);
int intel_init_vebox_ring_buffer(struct intel_engine_cs *engine);
int intel_engine_stop_cs(struct intel_engine_cs *engine);
+int intel_engine_start_cs(struct intel_engine_cs *engine);
u64 intel_engine_get_active_head(const struct intel_engine_cs *engine);
u64 intel_engine_get_last_batch_head(const struct intel_engine_cs *engine);
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 68fe4c16acfb..ffbae5c44b8c 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -2088,12 +2088,34 @@ static void gen8_reset_engine_cancel(struct
intel_engine_cs *engine)
_MASKED_BIT_DISABLE(RESET_CTL_REQUEST_RESET));
}
+static void gen8_idle_engines(struct drm_i915_private *i915)
+{
+ struct intel_engine_cs *engine;
+ unsigned int tmp;
+
+ for_each_engine(engine, i915, tmp)
+ intel_engine_stop_cs(engine);
+}
+
+static void gen8_unidle_engines(struct drm_i915_private *i915)
+{
+ struct intel_engine_cs *engine;
+ unsigned int tmp;
+
+ for_each_engine(engine, i915, tmp)
+ intel_engine_start_cs(engine);
+}
+
static int gen8_reset_engines(struct drm_i915_private *dev_priv,
[Intel-gfx] [PATCH 1/2] drm/i915: Cancel reset preparations on failed resets
Our reset handling has a retry layer further up in the
chain. As we have told the engine to prepare for reset,
and failed it, make sure to remove that preparation so
that the next attempted reset has a clean slate by triggering
another full prepare cycle for the engines. Note that with
successful reset, there is nothing to cleanup.
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_uncore.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index b36a3b5736a0..68fe4c16acfb 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -2092,22 +2092,26 @@ static int gen8_reset_engines(struct drm_i915_private
*dev_priv,
unsigned engine_mask)
{
struct intel_engine_cs *engine;
- unsigned int tmp;
+ unsigned int tmp, ret;
- for_each_engine_masked(engine, dev_priv, engine_mask, tmp)
- if (gen8_reset_engine_start(engine))
+ for_each_engine_masked(engine, dev_priv, engine_mask, tmp) {
+ if (gen8_reset_engine_start(engine)) {
+ ret = -EIO;
goto not_ready;
+ }
+ }
if (INTEL_GEN(dev_priv) >= 11)
- return gen11_reset_engines(dev_priv, engine_mask);
+ ret = gen11_reset_engines(dev_priv, engine_mask);
else
- return gen6_reset_engines(dev_priv, engine_mask);
+ ret = gen6_reset_engines(dev_priv, engine_mask);
not_ready:
- for_each_engine_masked(engine, dev_priv, engine_mask, tmp)
- gen8_reset_engine_cancel(engine);
+ if (ret)
+ for_each_engine_masked(engine, dev_priv, engine_mask, tmp)
+ gen8_reset_engine_cancel(engine);
- return -EIO;
+ return ret;
}
typedef int (*reset_func)(struct drm_i915_private *, unsigned engine_mask);
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/7] drm/i915/guc: Refactoring preparation of the GUC_CTL_LOG_PARAMS parameter
On Wed, 30 May 2018 15:53:31 +0200, Piotr Piorkowski wrote: At the moment, the preparation of GUC_CTL_LOG_PARAMS is disordered. Additionally, in struct intel_guc_log we have an unnecessary field 'flags' which we use only to assign value to GuC parameter. Lets move all GUC_CTL_LOG_PARAMS related operations to one place, and lets remove field 'flags' from struct intel_guc_log. Signed-off-by: Piotr Piórkowski Cc: Michal Wajdeczko Cc: Michał Winiarski Cc: Joonas Lahtinen Cc: Chris Wilson --- Reviewed-by: Michal Wajdeczko ___ 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/guc: Refactoring preparation of the GUC_CTL_FEATURE parameter
On Wed, 30 May 2018 15:53:30 +0200, Piotr Piorkowski wrote: At the moment, the preparation of GUC_CTL_FEATURE is disordered. Lets move all GUC_CTL_FEATURE related operations to one place. Signed-off-by: Piotr Piórkowski Cc: Michal Wajdeczko Cc: Michał Winiarski Cc: Joonas Lahtinen Cc: Chris Wilson --- Reviewed-by: Michal Wajdeczko ___ 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/guc: Refactoring preparation of the GUC_CTL_DEBUG parameter
On Wed, 30 May 2018 15:53:29 +0200, Piotr Piorkowski
wrote:
At the moment, the preparation of GUC_CTL_DEBUG is disordered.
Lets move all GUC_CTL_DEBUG related operations to one place.
Signed-off-by: Piotr Piórkowski
Cc: Michal Wajdeczko
Cc: Michał Winiarski
Cc: Joonas Lahtinen
Cc: Chris Wilson
---
drivers/gpu/drm/i915/intel_guc.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc.c
b/drivers/gpu/drm/i915/intel_guc.c
index 9025837850ad..3cc99fcaaea6 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -205,6 +205,7 @@ void intel_guc_fini(struct intel_guc *guc)
static u32 guc_ctl_debug_flags(struct intel_guc *guc)
{
+ u32 ads = intel_guc_ggtt_offset(guc, guc->ads_vma) >> PAGE_SHIFT;
if 'ads' is used only in USES_GUC_SUBMISSION case, then maybe we
should define it there ?
u32 level = intel_guc_log_level_get(>log);
u32 flags = 0;
@@ -217,6 +218,11 @@ static u32 guc_ctl_debug_flags(struct intel_guc
*guc)
flags |= GUC_LOG_LEVEL_TO_VERBOSITY(level) <<
GUC_LOG_VERBOSITY_SHIFT;
+ if (USES_GUC_SUBMISSION(guc_to_i915(guc))) {
+ flags |= ads << GUC_ADS_ADDR_SHIFT;
+ flags |= GUC_ADS_ENABLED;
this can done in single statement
+ }
+
return flags;
}
@@ -252,14 +258,9 @@ void intel_guc_init_params(struct intel_guc *guc)
/* If GuC submission is enabled, set up additional parameters here */
if (USES_GUC_SUBMISSION(dev_priv)) {
- u32 ads = intel_guc_ggtt_offset(guc,
- guc->ads_vma) >> PAGE_SHIFT;
u32 pgs = intel_guc_ggtt_offset(guc, guc->stage_desc_pool);
u32 ctx_in_16 = GUC_MAX_STAGE_DESCRIPTORS / 16;
- params[GUC_CTL_DEBUG] |= ads << GUC_ADS_ADDR_SHIFT;
- params[GUC_CTL_DEBUG] |= GUC_ADS_ENABLED;
-
pgs >>= PAGE_SHIFT;
params[GUC_CTL_CTXINFO] = (pgs << GUC_CTL_BASE_ADDR_SHIFT) |
(ctx_in_16 << GUC_CTL_CTXNUM_IN16_SHIFT);
with or/without bikesheds fixed,
Reviewed-by: Michal Wajdeczko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/pmu: Measure sampler intervals
Quoting Tvrtko Ursulin (2018-05-30 15:37:18)
>
> On 30/05/2018 12:55, Chris Wilson wrote:
> > hrtimer is not reliable enough to assume fixed intervals, and so even
> > coarse accuracy (in the face of kasan and similar heavy debugging) we
> > need to measure the actual interval between sample.
> >
> > While using a single timestamp to compute the interval does not allow
> > very fine accuracy (consider the impact of a slow forcewake between
> > different samples after the timestamp is read) is much better than
> > assuming the interval.
> >
> > v2: Make use of the sample period for estimating the GPU clock cycles,
> > leaving the frequency calculation (the averaging) to the caller.
> > Introduce new samplers for reporting cycles instead of Hz.
> >
> > Testcase: igt/perf_pmu #ivb
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > ---
> > drivers/gpu/drm/i915/i915_pmu.c | 44 ++---
> > drivers/gpu/drm/i915/i915_pmu.h | 6 +
> > include/uapi/drm/i915_drm.h | 2 ++
> > 3 files changed, 43 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_pmu.c
> > b/drivers/gpu/drm/i915/i915_pmu.c
> > index dc87797db500..12033e47e3b4 100644
> > --- a/drivers/gpu/drm/i915/i915_pmu.c
> > +++ b/drivers/gpu/drm/i915/i915_pmu.c
> > @@ -86,6 +86,8 @@ static bool pmu_needs_timer(struct drm_i915_private
> > *i915, bool gpu_active)
> >*/
> > enable &= config_enabled_mask(I915_PMU_ACTUAL_FREQUENCY) |
> > config_enabled_mask(I915_PMU_REQUESTED_FREQUENCY) |
> > + config_enabled_mask(I915_PMU_ACTUAL_CLOCK) |
> > + config_enabled_mask(I915_PMU_REQUESTED_CLOCK) |
> > ENGINE_SAMPLE_MASK;
> >
> > /*
> > @@ -127,6 +129,7 @@ static void __i915_pmu_maybe_start_timer(struct
> > drm_i915_private *i915)
> > {
> > if (!i915->pmu.timer_enabled && pmu_needs_timer(i915, true)) {
> > i915->pmu.timer_enabled = true;
> > + i915->pmu.timestamp = ktime_get();
> > hrtimer_start_range_ns(>pmu.timer,
> > ns_to_ktime(PERIOD), 0,
> > HRTIMER_MODE_REL_PINNED);
> > @@ -160,7 +163,7 @@ update_sample(struct i915_pmu_sample *sample, u32 unit,
> > u32 val)
> > sample->cur += mul_u32_u32(val, unit);
> > }
> >
> > -static void engines_sample(struct drm_i915_private *dev_priv)
> > +static void engines_sample(struct drm_i915_private *dev_priv, u64 period)
> > {
> > struct intel_engine_cs *engine;
> > enum intel_engine_id id;
> > @@ -183,7 +186,7 @@ static void engines_sample(struct drm_i915_private
> > *dev_priv)
> > val = !i915_seqno_passed(current_seqno, last_seqno);
> >
> > update_sample(>pmu.sample[I915_SAMPLE_BUSY],
> > - PERIOD, val);
> > + period, val);
> >
> > if (val && (engine->pmu.enable &
> > (BIT(I915_SAMPLE_WAIT) | BIT(I915_SAMPLE_SEMA {
> > @@ -195,10 +198,10 @@ static void engines_sample(struct drm_i915_private
> > *dev_priv)
> > }
> >
> > update_sample(>pmu.sample[I915_SAMPLE_WAIT],
> > - PERIOD, !!(val & RING_WAIT));
> > + period, !!(val & RING_WAIT));
> >
> > update_sample(>pmu.sample[I915_SAMPLE_SEMA],
> > - PERIOD, !!(val & RING_WAIT_SEMAPHORE));
> > + period, !!(val & RING_WAIT_SEMAPHORE));
> > }
> >
> > if (fw)
> > @@ -207,10 +210,11 @@ static void engines_sample(struct drm_i915_private
> > *dev_priv)
> > intel_runtime_pm_put(dev_priv);
> > }
> >
> > -static void frequency_sample(struct drm_i915_private *dev_priv)
> > +static void frequency_sample(struct drm_i915_private *dev_priv, u64 period)
> > {
> > if (dev_priv->pmu.enable &
> > - config_enabled_mask(I915_PMU_ACTUAL_FREQUENCY)) {
> > + (config_enabled_mask(I915_PMU_ACTUAL_CLOCK) |
> > + config_enabled_mask(I915_PMU_ACTUAL_FREQUENCY))) {
> > u32 val;
> >
> > val = dev_priv->gt_pm.rps.cur_freq;
> > @@ -223,13 +227,20 @@ static void frequency_sample(struct drm_i915_private
> > *dev_priv)
> >
> > update_sample(_priv->pmu.sample[__I915_SAMPLE_FREQ_ACT],
> > 1, intel_gpu_freq(dev_priv, val));
> > + update_sample(_priv->pmu.sample[__I915_SAMPLE_CLOCK_ACT],
> > + period, intel_gpu_freq(dev_priv, val));
>
> Cache intel_gpu_freq in a local.
>
> > }
> >
> > if (dev_priv->pmu.enable &
> > - config_enabled_mask(I915_PMU_REQUESTED_FREQUENCY)) {
> > + (config_enabled_mask(I915_PMU_REQUESTED_CLOCK) |
> > + config_enabled_mask(I915_PMU_REQUESTED_FREQUENCY))) {
> >
Re: [Intel-gfx] [PATCH 1/7] drm/i915/guc: Don't store runtime GuC log level in modparam
Hi,
On Wed, 30 May 2018 15:53:28 +0200, Piotr Piorkowski
wrote:
From: Piotr Piórkowski
Currently we are using modparam as placeholder for GuC log level.
Stop doing this and keep runtime GuC level in intel_guc_log struct.
Signed-off-by: Piotr Piórkowski
Cc: Michal Wajdeczko
Cc: Michał Winiarski
Cc: Joonas Lahtinen
Cc: Chris Wilson
---
drivers/gpu/drm/i915/intel_guc.c | 8 +++-
drivers/gpu/drm/i915/intel_guc_log.c | 18 +-
drivers/gpu/drm/i915/intel_guc_log.h | 9 -
drivers/gpu/drm/i915/intel_uc.c | 2 +-
4 files changed, 17 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc.c
b/drivers/gpu/drm/i915/intel_guc.c
index 116f4ccf1bbd..9025837850ad 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -203,13 +203,11 @@ void intel_guc_fini(struct intel_guc *guc)
guc_shared_data_destroy(guc);
}
-static u32 get_log_control_flags(void)
+static u32 guc_ctl_debug_flags(struct intel_guc *guc)
{
- u32 level = i915_modparams.guc_log_level;
+ u32 level = intel_guc_log_level_get(>log);
u32 flags = 0;
- GEM_BUG_ON(level < 0);
-
if (!GUC_LOG_LEVEL_IS_ENABLED(level))
flags |= GUC_LOG_DEFAULT_DISABLED;
@@ -250,7 +248,7 @@ void intel_guc_init_params(struct intel_guc *guc)
params[GUC_CTL_LOG_PARAMS] = guc->log.flags;
- params[GUC_CTL_DEBUG] = get_log_control_flags();
+ params[GUC_CTL_DEBUG] = guc_ctl_debug_flags(guc);
/* If GuC submission is enabled, set up additional parameters here */
if (USES_GUC_SUBMISSION(dev_priv)) {
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c
b/drivers/gpu/drm/i915/intel_guc_log.c
index 401e1704d61e..c036d0fac370 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -475,11 +475,12 @@ int intel_guc_log_create(struct intel_guc_log *log)
offset = intel_guc_ggtt_offset(guc, vma) >> PAGE_SHIFT;
log->flags = (offset << GUC_LOG_BUF_ADDR_SHIFT) | flags;
+ log->level = i915_modparams.guc_log_level;
+
return 0;
err:
- /* logging will be off */
- i915_modparams.guc_log_level = 0;
+ DRM_ERROR("Failed to allocate GuC log buffer. %d\n", ret);
return ret;
}
@@ -488,14 +489,6 @@ void intel_guc_log_destroy(struct intel_guc_log
*log)
i915_vma_unpin_and_release(>vma);
}
-int intel_guc_log_level_get(struct intel_guc_log *log)
-{
- GEM_BUG_ON(!log->vma);
- GEM_BUG_ON(i915_modparams.guc_log_level < 0);
-
- return i915_modparams.guc_log_level;
-}
-
int intel_guc_log_level_set(struct intel_guc_log *log, u64 val)
{
struct intel_guc *guc = log_to_guc(log);
@@ -504,7 +497,6 @@ int intel_guc_log_level_set(struct intel_guc_log
*log, u64 val)
BUILD_BUG_ON(GUC_LOG_VERBOSITY_MIN != 0);
GEM_BUG_ON(!log->vma);
- GEM_BUG_ON(i915_modparams.guc_log_level < 0);
/*
* GuC is recognizing log levels starting from 0 to max, we're using 0
@@ -515,7 +507,7 @@ int intel_guc_log_level_set(struct intel_guc_log
*log, u64 val)
mutex_lock(_priv->drm.struct_mutex);
- if (i915_modparams.guc_log_level == val) {
+ if (log->level == val) {
ret = 0;
goto out_unlock;
}
@@ -530,7 +522,7 @@ int intel_guc_log_level_set(struct intel_guc_log
*log, u64 val)
goto out_unlock;
}
- i915_modparams.guc_log_level = val;
+ log->level = val;
out_unlock:
mutex_unlock(_priv->drm.struct_mutex);
diff --git a/drivers/gpu/drm/i915/intel_guc_log.h
b/drivers/gpu/drm/i915/intel_guc_log.h
index fa80535a6f9d..ea375c3b5d08 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.h
+++ b/drivers/gpu/drm/i915/intel_guc_log.h
@@ -30,6 +30,7 @@
#include
#include "intel_guc_fwif.h"
+#include "i915_gem.h"
struct intel_guc;
@@ -58,6 +59,7 @@ struct intel_guc;
#define GUC_LOG_LEVEL_MAX
GUC_VERBOSITY_TO_LOG_LEVEL(GUC_LOG_VERBOSITY_MAX)
struct intel_guc_log {
+ u32 level;
u32 flags;
struct i915_vma *vma;
struct {
@@ -80,7 +82,6 @@ void intel_guc_log_init_early(struct intel_guc_log
*log);
int intel_guc_log_create(struct intel_guc_log *log);
void intel_guc_log_destroy(struct intel_guc_log *log);
-int intel_guc_log_level_get(struct intel_guc_log *log);
int intel_guc_log_level_set(struct intel_guc_log *log, u64 control_val);
bool intel_guc_log_relay_enabled(const struct intel_guc_log *log);
int intel_guc_log_relay_open(struct intel_guc_log *log);
@@ -89,4 +90,10 @@ void intel_guc_log_relay_close(struct intel_guc_log
*log);
void intel_guc_log_handle_flush_event(struct intel_guc_log *log);
+static inline u32 intel_guc_log_level_get(struct intel_guc_log *log)
hmm, it's little unfortunate that earlier this function was not named as:
intel_guc_log_get_level(struct intel_guc_log *log)
with matching:
intel_guc_log_set_level(struct
Re: [Intel-gfx] [PATCH v2] drm/i915/pmu: Measure sampler intervals
On 30/05/2018 12:55, Chris Wilson wrote:
hrtimer is not reliable enough to assume fixed intervals, and so even
coarse accuracy (in the face of kasan and similar heavy debugging) we
need to measure the actual interval between sample.
While using a single timestamp to compute the interval does not allow
very fine accuracy (consider the impact of a slow forcewake between
different samples after the timestamp is read) is much better than
assuming the interval.
v2: Make use of the sample period for estimating the GPU clock cycles,
leaving the frequency calculation (the averaging) to the caller.
Introduce new samplers for reporting cycles instead of Hz.
Testcase: igt/perf_pmu #ivb
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_pmu.c | 44 ++---
drivers/gpu/drm/i915/i915_pmu.h | 6 +
include/uapi/drm/i915_drm.h | 2 ++
3 files changed, 43 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index dc87797db500..12033e47e3b4 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -86,6 +86,8 @@ static bool pmu_needs_timer(struct drm_i915_private *i915,
bool gpu_active)
*/
enable &= config_enabled_mask(I915_PMU_ACTUAL_FREQUENCY) |
config_enabled_mask(I915_PMU_REQUESTED_FREQUENCY) |
+ config_enabled_mask(I915_PMU_ACTUAL_CLOCK) |
+ config_enabled_mask(I915_PMU_REQUESTED_CLOCK) |
ENGINE_SAMPLE_MASK;
/*
@@ -127,6 +129,7 @@ static void __i915_pmu_maybe_start_timer(struct
drm_i915_private *i915)
{
if (!i915->pmu.timer_enabled && pmu_needs_timer(i915, true)) {
i915->pmu.timer_enabled = true;
+ i915->pmu.timestamp = ktime_get();
hrtimer_start_range_ns(>pmu.timer,
ns_to_ktime(PERIOD), 0,
HRTIMER_MODE_REL_PINNED);
@@ -160,7 +163,7 @@ update_sample(struct i915_pmu_sample *sample, u32 unit, u32
val)
sample->cur += mul_u32_u32(val, unit);
}
-static void engines_sample(struct drm_i915_private *dev_priv)
+static void engines_sample(struct drm_i915_private *dev_priv, u64 period)
{
struct intel_engine_cs *engine;
enum intel_engine_id id;
@@ -183,7 +186,7 @@ static void engines_sample(struct drm_i915_private
*dev_priv)
val = !i915_seqno_passed(current_seqno, last_seqno);
update_sample(>pmu.sample[I915_SAMPLE_BUSY],
- PERIOD, val);
+ period, val);
if (val && (engine->pmu.enable &
(BIT(I915_SAMPLE_WAIT) | BIT(I915_SAMPLE_SEMA {
@@ -195,10 +198,10 @@ static void engines_sample(struct drm_i915_private
*dev_priv)
}
update_sample(>pmu.sample[I915_SAMPLE_WAIT],
- PERIOD, !!(val & RING_WAIT));
+ period, !!(val & RING_WAIT));
update_sample(>pmu.sample[I915_SAMPLE_SEMA],
- PERIOD, !!(val & RING_WAIT_SEMAPHORE));
+ period, !!(val & RING_WAIT_SEMAPHORE));
}
if (fw)
@@ -207,10 +210,11 @@ static void engines_sample(struct drm_i915_private
*dev_priv)
intel_runtime_pm_put(dev_priv);
}
-static void frequency_sample(struct drm_i915_private *dev_priv)
+static void frequency_sample(struct drm_i915_private *dev_priv, u64 period)
{
if (dev_priv->pmu.enable &
- config_enabled_mask(I915_PMU_ACTUAL_FREQUENCY)) {
+ (config_enabled_mask(I915_PMU_ACTUAL_CLOCK) |
+config_enabled_mask(I915_PMU_ACTUAL_FREQUENCY))) {
u32 val;
val = dev_priv->gt_pm.rps.cur_freq;
@@ -223,13 +227,20 @@ static void frequency_sample(struct drm_i915_private
*dev_priv)
update_sample(_priv->pmu.sample[__I915_SAMPLE_FREQ_ACT],
1, intel_gpu_freq(dev_priv, val));
+ update_sample(_priv->pmu.sample[__I915_SAMPLE_CLOCK_ACT],
+ period, intel_gpu_freq(dev_priv, val));
Cache intel_gpu_freq in a local.
}
if (dev_priv->pmu.enable &
- config_enabled_mask(I915_PMU_REQUESTED_FREQUENCY)) {
+ (config_enabled_mask(I915_PMU_REQUESTED_CLOCK) |
+config_enabled_mask(I915_PMU_REQUESTED_FREQUENCY))) {
update_sample(_priv->pmu.sample[__I915_SAMPLE_FREQ_REQ], 1,
intel_gpu_freq(dev_priv,
dev_priv->gt_pm.rps.cur_freq));
+ update_sample(_priv->pmu.sample[__I915_SAMPLE_CLOCK_REQ],
+ period,
+ intel_gpu_freq(dev_priv,
+dev_priv->gt_pm.rps.cur_freq));
Same here.
}
}
@@ -237,12 +248,17 @@ static enum
[Intel-gfx] [PATCH v9 6/7] drm/i915: Expose RPCS (SSEU) configuration to userspace
From: Chris Wilson
We want to allow userspace to reconfigure the subslice configuration for
its own use case. To do so, we expose a context parameter to allow
adjustment of the RPCS register stored within the context image (and
currently not accessible via LRI). If the context is adjusted before
first use, the adjustment is for "free"; otherwise if the context is
active we flush the context off the GPU (stalling all users) and forcing
the GPU to save the context to memory where we can modify it and so
ensure that the register is reloaded on next execution.
The overhead of managing additional EU subslices can be significant,
especially in multi-context workloads. Non-GPGPU contexts should
preferably disable the subslices it is not using, and others should
fine-tune the number to match their workload.
We expose complete control over the RPCS register, allowing
configuration of slice/subslice, via masks packed into a u64 for
simplicity. For example,
struct drm_i915_gem_context_param arg;
struct drm_i915_gem_context_param_sseu sseu = { .class = 0,
.instance = 0, };
memset(, 0, sizeof(arg));
arg.ctx_id = ctx;
arg.param = I915_CONTEXT_PARAM_SSEU;
arg.value = (uintptr_t)
if (drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_GETPARAM, ) == 0) {
sseu.packed.subslice_mask = 0;
drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_SETPARAM, );
}
could be used to disable all subslices where supported.
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu() (Lionel)
v3: Add ability to program this per engine (Chris)
v4: Move most get_sseu() into i915_gem_context.c (Lionel)
v5: Validate sseu configuration against the device's capabilities (Lionel)
v6: Change context powergating settings through MI_SDM on kernel context (Chris)
v7: Synchronize the requests following a powergating setting change using a
global
dependency (Chris)
Iterate timelines through dev_priv.gt.active_rings (Tvrtko)
Disable RPCS configuration setting for non capable users (Lionel/Tvrtko)
v8: s/union intel_sseu/struct intel_sseu/ (Lionel)
s/dev_priv/i915/ (Tvrtko)
Change uapi class/instance fields to u16 (Tvrtko)
Bump mask fields to 64bits (Lionel)
Don't return EPERM when dynamic sseu is disabled (Tvrtko)
v9: Import context image into kernel context's ppgtt only when
reconfiguring powergated slice/subslices (Chris)
Use aliasing ppgtt when needed (Michel)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Signed-off-by: Chris Wilson
Signed-off-by: Lionel Landwerlin
c: Dmitry Rogozhkin
CC: Tvrtko Ursulin
CC: Zhipeng Gong
CC: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h | 13 ++
drivers/gpu/drm/i915/i915_gem.c | 2 +
drivers/gpu/drm/i915/i915_gem_context.c | 176
drivers/gpu/drm/i915/i915_request.c | 20 +++
drivers/gpu/drm/i915/intel_lrc.c| 123 -
drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 4 +
include/uapi/drm/i915_drm.h | 43 ++
8 files changed, 348 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 25ffadfcd04b..b2386c37437d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2066,6 +2066,12 @@ struct drm_i915_private {
u32 active_requests;
u32 request_serial;
+ /**
+* Global barrier to ensuring ordering of sseu transitions
+* requests.
+*/
+ struct i915_gem_active global_barrier;
+
/**
* Is the GPU currently considered idle, or busy executing
* userspace requests? Whilst idle, we allow runtime power
@@ -3212,6 +3218,13 @@ i915_vm_to_ppgtt(struct i915_address_space *vm)
return container_of(vm, struct i915_hw_ppgtt, base);
}
+static inline void i915_gem_set_global_barrier(struct drm_i915_private *i915,
+ struct i915_request *rq)
+{
+ lockdep_assert_held(>drm.struct_mutex);
+ i915_gem_active_set(>gt.global_barrier, rq);
+}
+
/* i915_gem_fence_reg.c */
struct drm_i915_fence_reg *
i915_reserve_fence(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 530d6d0109b4..bbc141337b14 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5554,6 +5554,8 @@ int i915_gem_init_early(struct drm_i915_private *dev_priv)
if (!dev_priv->priorities)
goto err_dependencies;
+ init_request_active(_priv->gt.global_barrier, NULL);
+
INIT_LIST_HEAD(_priv->gt.timelines);
INIT_LIST_HEAD(_priv->gt.active_rings);
[Intel-gfx] [PATCH v9 7/7] drm/i915: add a sysfs entry to let users set sseu configs
There are concerns about denial of service around the per context sseu
configuration capability. In a previous commit introducing the
capability we allowed it only for capable users. This changes adds a
new debugfs entry to let any user configure its own context
powergating setup.
v2: Rename sysfs entry (Tvrtko)
Lock interruptible the device in sysfs (Tvrtko)
Fix dropped error code in getting dynamic sseu value (Tvrtko)
s/dev_priv/i915/ (Tvrtko)
v3: Drop locked function suffix (Tvrtko)
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 16 +++---
drivers/gpu/drm/i915/i915_gem_context.c | 38 +++
drivers/gpu/drm/i915/i915_sysfs.c | 40 +
3 files changed, 90 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b2386c37437d..5aa96a6650b4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1842,6 +1842,8 @@ struct drm_i915_private {
struct ida hw_ida;
#define MAX_CONTEXT_HW_ID (1<<21) /* exclusive */
#define GEN11_MAX_CONTEXT_HW_ID (1<<11) /* exclusive */
+
+ bool dynamic_sseu;
} contexts;
u32 fdi_rx_config;
@@ -3259,6 +3261,10 @@ i915_gem_context_lookup(struct drm_i915_file_private
*file_priv, u32 id)
return ctx;
}
+int i915_gem_contexts_set_dynamic_sseu(struct drm_i915_private *i915,
+ bool allowed);
+bool i915_gem_contexts_get_dynamic_sseu(struct drm_i915_private *i915);
+
int i915_perf_open_ioctl(struct drm_device *dev, void *data,
struct drm_file *file);
int i915_perf_add_config_ioctl(struct drm_device *dev, void *data,
@@ -3859,11 +3865,13 @@ intel_engine_prepare_sseu(struct intel_engine_cs
*engine,
struct drm_i915_private *i915 = engine->i915;
/*
-* If i915/perf is active, we want a stable powergating configuration
-* on the system. The most natural configuration to take in that case
-* is the default (i.e maximum the hardware can do).
+* If i915/perf is active or dynamic sseu configuration is not allowed
+* (through sysfs), we want a stable powergating configuration on the
+* system. The most natural configuration to take in that case is the
+* default (i.e maximum the hardware can do).
*/
- return i915->perf.oa.exclusive_stream ?
+ return (i915->perf.oa.exclusive_stream ||
+ !i915->contexts.dynamic_sseu) ?
intel_device_default_sseu(i915) : sseu;
}
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 79029815c21f..453bdc976be3 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -1118,6 +1118,44 @@ int i915_gem_context_reset_stats_ioctl(struct drm_device
*dev,
return ret;
}
+int i915_gem_contexts_set_dynamic_sseu(struct drm_i915_private *i915,
+ bool allowed)
+{
+ struct intel_engine_cs *engine = i915->engine[RCS];
+ struct i915_gem_context *ctx;
+ int ret = 0;
+
+ lockdep_assert_held(>drm.struct_mutex);
+
+ if (!engine->emit_rpcs_config)
+ return -ENODEV;
+
+ if (allowed == i915->contexts.dynamic_sseu)
+ return 0;
+
+ i915->contexts.dynamic_sseu = allowed;
+
+ list_for_each_entry(ctx, >contexts.list, link) {
+ struct intel_context *ce = to_intel_context(ctx, engine);
+
+ ret = i915_gem_context_reconfigure_sseu(ctx, engine, ce->sseu);
+ if (ret)
+ break;
+ }
+
+ return ret;
+}
+
+bool i915_gem_contexts_get_dynamic_sseu(struct drm_i915_private *i915)
+{
+ struct intel_engine_cs *engine = i915->engine[RCS];
+
+ if (!engine->emit_rpcs_config)
+ return false;
+
+ return i915->contexts.dynamic_sseu;
+}
+
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
#include "selftests/mock_context.c"
#include "selftests/i915_gem_context.c"
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
b/drivers/gpu/drm/i915/i915_sysfs.c
index e5e6f6bb2b05..d895054d245e 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -483,6 +483,44 @@ static ssize_t gt_rp_mhz_show(struct device *kdev, struct
device_attribute *attr
return snprintf(buf, PAGE_SIZE, "%d\n", val);
}
+static ssize_t allow_dynamic_sseu_show(struct device *kdev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct drm_i915_private *i915 = kdev_minor_to_i915(kdev);
+ bool value = i915_gem_contexts_get_dynamic_sseu(i915);
+
+ return snprintf(buf, PAGE_SIZE, "%d\n", value);
+}
+
+static ssize_t allow_dynamic_sseu_store(struct device *kdev,
+
[Intel-gfx] [PATCH v9 4/7] drm/i915/perf: reuse intel_lrc ctx regs macro
Abstract the context image access a bit.
Signed-off-by: Lionel Landwerlin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_perf.c | 34 +++-
1 file changed, 16 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 805dfc732bba..a5d98bda5c2e 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -210,6 +210,7 @@
#include "i915_oa_cflgt3.h"
#include "i915_oa_cnl.h"
#include "i915_oa_icl.h"
+#include "intel_lrc_reg.h"
/* HW requires this to be a power of two, between 128k and 16M, though driver
* is currently generally designed assuming the largest 16M size is used such
@@ -1579,27 +1580,25 @@ static void gen8_update_reg_state_unlocked(struct
i915_gem_context *ctx,
u32 ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
u32 ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
/* The MMIO offsets for Flex EU registers aren't contiguous */
- u32 flex_mmio[] = {
- i915_mmio_reg_offset(EU_PERF_CNTL0),
- i915_mmio_reg_offset(EU_PERF_CNTL1),
- i915_mmio_reg_offset(EU_PERF_CNTL2),
- i915_mmio_reg_offset(EU_PERF_CNTL3),
- i915_mmio_reg_offset(EU_PERF_CNTL4),
- i915_mmio_reg_offset(EU_PERF_CNTL5),
- i915_mmio_reg_offset(EU_PERF_CNTL6),
+ i915_reg_t flex_regs[] = {
+ EU_PERF_CNTL0,
+ EU_PERF_CNTL1,
+ EU_PERF_CNTL2,
+ EU_PERF_CNTL3,
+ EU_PERF_CNTL4,
+ EU_PERF_CNTL5,
+ EU_PERF_CNTL6,
};
int i;
- reg_state[ctx_oactxctrl] = i915_mmio_reg_offset(GEN8_OACTXCONTROL);
- reg_state[ctx_oactxctrl+1] = (dev_priv->perf.oa.period_exponent <<
- GEN8_OA_TIMER_PERIOD_SHIFT) |
-(dev_priv->perf.oa.periodic ?
- GEN8_OA_TIMER_ENABLE : 0) |
-GEN8_OA_COUNTER_RESUME;
+ CTX_REG(reg_state, ctx_oactxctrl, GEN8_OACTXCONTROL,
+ (dev_priv->perf.oa.period_exponent <<
GEN8_OA_TIMER_PERIOD_SHIFT) |
+ (dev_priv->perf.oa.periodic ? GEN8_OA_TIMER_ENABLE : 0) |
+ GEN8_OA_COUNTER_RESUME);
- for (i = 0; i < ARRAY_SIZE(flex_mmio); i++) {
+ for (i = 0; i < ARRAY_SIZE(flex_regs); i++) {
u32 state_offset = ctx_flexeu0 + i * 2;
- u32 mmio = flex_mmio[i];
+ u32 mmio = i915_mmio_reg_offset(flex_regs[i]);
/*
* This arbitrary default will select the 'EU FPU0 Pipeline
@@ -1619,8 +1618,7 @@ static void gen8_update_reg_state_unlocked(struct
i915_gem_context *ctx,
}
}
- reg_state[state_offset] = mmio;
- reg_state[state_offset+1] = value;
+ CTX_REG(reg_state, state_offset, flex_regs[i], value);
}
}
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 3/7] drm/i915/perf: simplify configure all context function
We don't need any special treatment on error so just return as soon as
possible.
Signed-off-by: Lionel Landwerlin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_perf.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 4f0eb84b3c00..805dfc732bba 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1762,7 +1762,7 @@ static int gen8_configure_all_contexts(struct
drm_i915_private *dev_priv,
/* Switch away from any user context. */
ret = gen8_switch_to_updated_kernel_context(dev_priv, oa_config);
if (ret)
- goto out;
+ return ret;
/*
* The OA register config is setup through the context image. This image
@@ -1779,7 +1779,7 @@ static int gen8_configure_all_contexts(struct
drm_i915_private *dev_priv,
*/
ret = i915_gem_wait_for_idle(dev_priv, wait_flags);
if (ret)
- goto out;
+ return ret;
/* Update all contexts now that we've stalled the submission. */
list_for_each_entry(ctx, _priv->contexts.list, link) {
@@ -1791,10 +1791,8 @@ static int gen8_configure_all_contexts(struct
drm_i915_private *dev_priv,
continue;
regs = i915_gem_object_pin_map(ce->state->obj, I915_MAP_WB);
- if (IS_ERR(regs)) {
- ret = PTR_ERR(regs);
- goto out;
- }
+ if (IS_ERR(regs))
+ return PTR_ERR(regs);
ce->state->obj->mm.dirty = true;
regs += LRC_STATE_PN * PAGE_SIZE / sizeof(*regs);
@@ -1804,7 +1802,6 @@ static int gen8_configure_all_contexts(struct
drm_i915_private *dev_priv,
i915_gem_object_unpin_map(ce->state->obj);
}
- out:
return ret;
}
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 5/7] drm/i915/perf: lock powergating configuration to default when active
If some of the contexts submitting workloads to the GPU have been
configured to shutdown slices/subslices, we might loose the NOA
configurations written in the NOA muxes.
One possible solution to this problem is to reprogram the NOA muxes
when we switch to a new context. We initially tried this in the
workaround batchbuffer but some concerns where raised about the cost
of reprogramming at every context switch. This solution is also not
without consequences from the userspace point of view. Reprogramming
of the muxes can only happen once the powergating configuration has
changed (which happens after context switch). This means for a window
of time during the recording, counters recorded by the OA unit might
be invalid. This requires userspace dealing with OA reports to discard
the invalid values.
Minimizing the reprogramming could be implemented by tracking of the
last programmed configuration somewhere in GGTT and use MI_PREDICATE
to discard some of the programming commands, but the command streamer
would still have to parse all the MI_LRI instructions in the
workaround batchbuffer.
Another solution, which this change implements, is to simply disregard
the user requested configuration for the period of time when i915/perf
is active. There is no known issue with this apart from a performance
penality for some media workloads that benefit from running on a
partially powergated GPU. We already prevent RC6 from affecting the
programming so it doesn't sound completely unreasonable to hold on
powergating for the same reason.
v2: Leave RPCS programming in intel_lrc.c (Lionel)
v3: Update for s/union intel_sseu/struct intel_sseu/ (Lionel)
More to_intel_context() (Tvrtko)
s/dev_priv/i915/ (Tvrtko)
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 15 +++
drivers/gpu/drm/i915/i915_perf.c | 23 ++-
drivers/gpu/drm/i915/intel_lrc.c | 11 +++
drivers/gpu/drm/i915/intel_lrc.h | 3 +++
4 files changed, 43 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 62ababfd39aa..25ffadfcd04b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3839,4 +3839,19 @@ static inline int intel_hws_csb_write_index(struct
drm_i915_private *i915)
return I915_HWS_CSB_WRITE_INDEX;
}
+static inline struct intel_sseu
+intel_engine_prepare_sseu(struct intel_engine_cs *engine,
+ struct intel_sseu sseu)
+{
+ struct drm_i915_private *i915 = engine->i915;
+
+ /*
+* If i915/perf is active, we want a stable powergating configuration
+* on the system. The most natural configuration to take in that case
+* is the default (i.e maximum the hardware can do).
+*/
+ return i915->perf.oa.exclusive_stream ?
+ intel_device_default_sseu(i915) : sseu;
+}
+
#endif
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index a5d98bda5c2e..4a62024cbf85 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1574,7 +1574,8 @@ static void hsw_disable_metric_set(struct
drm_i915_private *dev_priv)
*/
static void gen8_update_reg_state_unlocked(struct i915_gem_context *ctx,
u32 *reg_state,
- const struct i915_oa_config
*oa_config)
+ const struct i915_oa_config
*oa_config,
+ struct intel_sseu sseu)
{
struct drm_i915_private *dev_priv = ctx->i915;
u32 ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
@@ -1620,6 +1621,9 @@ static void gen8_update_reg_state_unlocked(struct
i915_gem_context *ctx,
CTX_REG(reg_state, state_offset, flex_regs[i], value);
}
+
+ CTX_REG(reg_state, CTX_R_PWR_CLK_STATE, GEN8_R_PWR_CLK_STATE,
+ gen8_make_rpcs(_INFO(dev_priv)->sseu, sseu));
}
/*
@@ -1750,6 +1754,7 @@ static int gen8_switch_to_updated_kernel_context(struct
drm_i915_private *dev_pr
static int gen8_configure_all_contexts(struct drm_i915_private *dev_priv,
const struct i915_oa_config *oa_config)
{
+ struct intel_sseu default_sseu = intel_device_default_sseu(dev_priv);
struct intel_engine_cs *engine = dev_priv->engine[RCS];
struct i915_gem_context *ctx;
int ret;
@@ -1795,7 +1800,8 @@ static int gen8_configure_all_contexts(struct
drm_i915_private *dev_priv,
ce->state->obj->mm.dirty = true;
regs += LRC_STATE_PN * PAGE_SIZE / sizeof(*regs);
- gen8_update_reg_state_unlocked(ctx, regs, oa_config);
+ gen8_update_reg_state_unlocked(ctx, regs, oa_config,
+ oa_config ? default_sseu :
ce->sseu);
[Intel-gfx] [PATCH v9 2/7] drm/i915: Record the sseu configuration per-context & engine
From: Chris Wilson
We want to expose the ability to reconfigure the slices, subslice and
eu per context and per engine. To facilitate that, store the current
configuration on the context for each engine, which is initially set
to the device default upon creation.
v2: record sseu configuration per context & engine (Chris)
v3: introduce the i915_gem_context_sseu to store powergating
programming, sseu_dev_info has grown quite a bit (Lionel)
v4: rename i915_gem_sseu into intel_sseu (Chris)
use to_intel_context() (Chris)
v5: More to_intel_context() (Tvrtko)
Switch intel_sseu from union to struct (Tvrtko)
Move context default sseu in existing loop (Chris)
v6: s/intel_sseu_from_device_sseu/intel_device_default_sseu/ (Tvrtko)
Signed-off-by: Chris Wilson
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 14 ++
drivers/gpu/drm/i915/i915_gem_context.c | 2 ++
drivers/gpu/drm/i915/i915_gem_context.h | 4
drivers/gpu/drm/i915/i915_request.h | 10 ++
drivers/gpu/drm/i915/intel_lrc.c| 22 +++---
5 files changed, 41 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 487922f88b76..62ababfd39aa 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3427,6 +3427,20 @@ mkwrite_device_info(struct drm_i915_private *dev_priv)
return (struct intel_device_info *)_priv->info;
}
+static inline struct intel_sseu
+intel_device_default_sseu(struct drm_i915_private *i915)
+{
+ const struct sseu_dev_info *sseu = _INFO(i915)->sseu;
+ struct intel_sseu value = {
+ .slice_mask = sseu->slice_mask,
+ .subslice_mask = sseu->subslice_mask[0],
+ .min_eus_per_subslice = sseu->max_eus_per_subslice,
+ .max_eus_per_subslice = sseu->max_eus_per_subslice,
+ };
+
+ return value;
+}
+
/* modesetting */
extern void intel_modeset_init_hw(struct drm_device *dev);
extern int intel_modeset_init(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 45393f6e0208..ee2ee6b4e5b0 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -282,6 +282,8 @@ __create_hw_context(struct drm_i915_private *dev_priv,
struct intel_context *ce = >__engine[n];
ce->gem_context = ctx;
+ /* Use the whole device by default */
+ ce->sseu = intel_device_default_sseu(dev_priv);
}
INIT_RADIX_TREE(>handles_vma, GFP_KERNEL);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.h
b/drivers/gpu/drm/i915/i915_gem_context.h
index b116e4942c10..f40d85448a28 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -31,6 +31,7 @@
#include "i915_gem.h"
#include "i915_scheduler.h"
+#include "intel_device_info.h"
struct pid;
@@ -160,6 +161,9 @@ struct i915_gem_context {
int pin_count;
const struct intel_context_ops *ops;
+
+ /** sseu: Control eu/slice partitioning */
+ struct intel_sseu sseu;
} __engine[I915_NUM_ENGINES];
/** ring_size: size for allocating the per-engine ring buffer */
diff --git a/drivers/gpu/drm/i915/i915_request.h
b/drivers/gpu/drm/i915/i915_request.h
index 17a9fa03..82c5dd153bfd 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -39,6 +39,16 @@ struct drm_i915_gem_object;
struct i915_request;
struct i915_timeline;
+/*
+ * Powergating configuration for a particular (context,engine).
+ */
+struct intel_sseu {
+ u8 slice_mask;
+ u8 subslice_mask;
+ u8 min_eus_per_subslice;
+ u8 max_eus_per_subslice;
+};
+
struct intel_wait {
struct rb_node node;
struct task_struct *tsk;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 05e069a5c836..8bac0483e784 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2512,8 +2512,8 @@ int logical_xcs_ring_init(struct intel_engine_cs *engine)
return logical_ring_init(engine);
}
-static u32
-make_rpcs(struct drm_i915_private *dev_priv)
+static u32 make_rpcs(const struct sseu_dev_info *sseu,
+struct intel_sseu ctx_sseu)
{
u32 rpcs = 0;
@@ -2523,24 +2523,23 @@ make_rpcs(struct drm_i915_private *dev_priv)
* must make an explicit request through RPCS for full
* enablement.
*/
- if (INTEL_INFO(dev_priv)->sseu.has_slice_pg) {
+ if (sseu->has_slice_pg) {
rpcs |= GEN8_RPCS_S_CNT_ENABLE;
- rpcs |= hweight8(INTEL_INFO(dev_priv)->sseu.slice_mask) <<
- GEN8_RPCS_S_CNT_SHIFT;
+ rpcs |= hweight8(ctx_sseu.slice_mask) <<
[Intel-gfx] [PATCH v9 1/7] drm/i915: Program RPCS for Broadwell
From: Chris Wilson
Currently we only configure the power gating for Skylake and above, but
the configuration should equally apply to Broadwell and Braswell. Even
though, there is not as much variation as for later generations, we want
to expose control over the configuration to userspace and may want to
opt out of the "always-enabled" setting.
Signed-off-by: Chris Wilson
Signed-off-by: Lionel Landwerlin
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/intel_lrc.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 8a6058b4102f..05e069a5c836 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2517,13 +2517,6 @@ make_rpcs(struct drm_i915_private *dev_priv)
{
u32 rpcs = 0;
- /*
-* No explicit RPCS request is needed to ensure full
-* slice/subslice/EU enablement prior to Gen9.
- */
- if (INTEL_GEN(dev_priv) < 9)
- return 0;
-
/*
* Starting in Gen9, render power gating can leave
* slice/subslice/EU in a partially enabled state. We
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 0/7] drm/i915: per context slice/subslice powergating
Hi again, Here are some updates following Chris & Michel's comments. I folded the patch 6 added in v8 into patch 6 of this series. Many thanks, Chris Wilson (3): drm/i915: Program RPCS for Broadwell drm/i915: Record the sseu configuration per-context & engine drm/i915: Expose RPCS (SSEU) configuration to userspace Lionel Landwerlin (4): drm/i915/perf: simplify configure all context function drm/i915/perf: reuse intel_lrc ctx regs macro drm/i915/perf: lock powergating configuration to default when active drm/i915: add a sysfs entry to let users set sseu configs drivers/gpu/drm/i915/i915_drv.h | 50 ++ drivers/gpu/drm/i915/i915_gem.c | 2 + drivers/gpu/drm/i915/i915_gem_context.c | 216 drivers/gpu/drm/i915/i915_gem_context.h | 4 + drivers/gpu/drm/i915/i915_perf.c| 68 drivers/gpu/drm/i915/i915_request.c | 20 +++ drivers/gpu/drm/i915/i915_request.h | 10 ++ drivers/gpu/drm/i915/i915_sysfs.c | 40 + drivers/gpu/drm/i915/intel_lrc.c| 137 ++- drivers/gpu/drm/i915/intel_lrc.h| 3 + drivers/gpu/drm/i915/intel_ringbuffer.c | 2 + drivers/gpu/drm/i915/intel_ringbuffer.h | 4 + include/uapi/drm/i915_drm.h | 43 + 13 files changed, 525 insertions(+), 74 deletions(-) -- 2.17.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pmu: Measure sampler intervals (rev2)
== Series Details == Series: drm/i915/pmu: Measure sampler intervals (rev2) URL : https://patchwork.freedesktop.org/series/43795/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4257 -> Patchwork_9148 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/43795/revisions/2/mbox/ == Known issues == Here are the changes found in Patchwork_9148 that come from known issues: === IGT changes === Issues hit igt@drv_module_reload@basic-no-display: fi-glk-j4005: PASS -> DMESG-WARN (fdo#106725) igt@kms_flip@basic-flip-vs-dpms: fi-glk-j4005: PASS -> DMESG-WARN (fdo#106000) igt@kms_flip@basic-flip-vs-modeset: fi-glk-j4005: PASS -> DMESG-WARN (fdo#106097, fdo#106000) igt@kms_flip@basic-flip-vs-wf_vblank: fi-glk-j4005: PASS -> FAIL (fdo#100368) fi-cfl-s3: PASS -> FAIL (fdo#100368, fdo#103928) Possible fixes igt@kms_flip@basic-flip-vs-wf_vblank: fi-cnl-psr: FAIL (fdo#100368) -> PASS igt@kms_frontbuffer_tracking@basic: fi-bsw-n3050: INCOMPLETE (fdo#106729) -> PASS igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c: fi-skl-guc: FAIL (fdo#103191, fdo#104724) -> PASS igt@kms_pipe_crc_basic@read-crc-pipe-c: fi-glk-j4005: DMESG-WARN (fdo#106097, fdo#106000) -> PASS igt@prime_vgem@basic-fence-flip: fi-ilk-650: FAIL (fdo#104008) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#106000 https://bugs.freedesktop.org/show_bug.cgi?id=106000 fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097 fdo#106725 https://bugs.freedesktop.org/show_bug.cgi?id=106725 fdo#106729 https://bugs.freedesktop.org/show_bug.cgi?id=106729 == Participating hosts (45 -> 39) == Missing(6): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-cfl-u2 fi-skl-6700hq == Build changes == * Linux: CI_DRM_4257 -> Patchwork_9148 CI_DRM_4257: 8aac35d26057479982a346c0e9cd57c2e930b7e1 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4501: 6796a604bab6df9c84af149e799902360afdd157 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9148: 5d03705baa619c391ea3b8ce9e531f0c19e39cfc @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 5d03705baa61 drm/i915/pmu: Measure sampler intervals == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9148/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/7] drm/i915/guc: Add support for define guc_log_size in megabytes.
At this moment we can define GuC logs sizes only using pages. But GuC also allows use for this values expressed in megabytes. Lets add support for define guc_log_size in megabytes when we debug of GuC. Signed-off-by: Piotr Piórkowski Cc: Michal Wajdeczko Cc: Michał Winiarski Cc: Joonas Lahtinen Cc: Chris Wilson --- drivers/gpu/drm/i915/intel_guc.c | 12 ++-- drivers/gpu/drm/i915/intel_guc_log.h | 6 ++ 2 files changed, 16 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c index e15047fedb45..5a42db47521b 100644 --- a/drivers/gpu/drm/i915/intel_guc.c +++ b/drivers/gpu/drm/i915/intel_guc.c @@ -263,7 +263,13 @@ static u32 guc_ctl_log_params_flags(struct intel_guc *guc) u32 offset = intel_guc_ggtt_offset(guc, guc->log.vma) >> PAGE_SHIFT; u32 flags; + #if (((CRASH_BUFFER_SIZE) % (1 << 20)) == 0) + #define UNIT (1 << 20) + #define FLAG GUC_LOG_ALLOC_IN_MEGABYTE + #else #define UNIT (4 << 10) + #define FLAG 0 + #endif BUILD_BUG_ON(!CRASH_BUFFER_SIZE); BUILD_BUG_ON(!IS_ALIGNED(CRASH_BUFFER_SIZE, UNIT)); @@ -280,13 +286,15 @@ static u32 guc_ctl_log_params_flags(struct intel_guc *guc) (GUC_LOG_ISR_MASK >> GUC_LOG_ISR_SHIFT)); flags = GUC_LOG_VALID | - GUC_LOG_NOTIFY_ON_HALF_FULL | - ((CRASH_BUFFER_SIZE/UNIT - 1) << GUC_LOG_CRASH_SHIFT) | + GUC_LOG_NOTIFY_ON_HALF_FULL; + flags |= FLAG; + flags |= ((CRASH_BUFFER_SIZE/UNIT - 1) << GUC_LOG_CRASH_SHIFT) | ((DPC_BUFFER_SIZE/UNIT - 1) << GUC_LOG_DPC_SHIFT) | ((ISR_BUFFER_SIZE/UNIT - 1) << GUC_LOG_ISR_SHIFT) | (offset << GUC_LOG_BUF_ADDR_SHIFT); #undef UNIT + #undef FLAG return flags; } diff --git a/drivers/gpu/drm/i915/intel_guc_log.h b/drivers/gpu/drm/i915/intel_guc_log.h index 1b3afdae6d0d..de39b965ae7a 100644 --- a/drivers/gpu/drm/i915/intel_guc_log.h +++ b/drivers/gpu/drm/i915/intel_guc_log.h @@ -34,9 +34,15 @@ struct intel_guc; +#ifdef DRM_I915_DEBUG_GUC +#define CRASH_BUFFER_SIZE 2097152 +#define DPC_BUFFER_SIZE8388608 +#define ISR_BUFFER_SIZE8388608 +#else #define CRASH_BUFFER_SIZE 8192 #define DPC_BUFFER_SIZE32768 #define ISR_BUFFER_SIZE32768 +#endif /* * While we're using plain log level in i915, GuC controls are much more... -- 2.14.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/7] drm/i915/guc: Move defines with size of GuC logs to intel_guc_log.h
At this moment, we have defined GuC logs sizes in intel_guc_fwif.h, but
as these values are related directly to the GuC logs, and not to API of
GuC parameters, we should move these defines to intel_guc_log.h.
Signed-off-by: Piotr Piórkowski
Cc: Michal Wajdeczko
Cc: Michał Winiarski
Cc: Joonas Lahtinen
Cc: Chris Wilson
---
drivers/gpu/drm/i915/intel_guc.c | 28 +++-
drivers/gpu/drm/i915/intel_guc_fwif.h | 20 +++-
drivers/gpu/drm/i915/intel_guc_log.c | 28 +---
drivers/gpu/drm/i915/intel_guc_log.h | 9 +++--
4 files changed, 54 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 3b45f06b1aa2..e15047fedb45 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -263,13 +263,31 @@ static u32 guc_ctl_log_params_flags(struct intel_guc *guc)
u32 offset = intel_guc_ggtt_offset(guc, guc->log.vma) >> PAGE_SHIFT;
u32 flags;
- /* each allocated unit is a page */
- flags = GUC_LOG_VALID | GUC_LOG_NOTIFY_ON_HALF_FULL |
- (GUC_LOG_CRASH_PAGES << GUC_LOG_CRASH_SHIFT) |
- (GUC_LOG_DPC_PAGES << GUC_LOG_DPC_SHIFT) |
- (GUC_LOG_ISR_PAGES << GUC_LOG_ISR_SHIFT) |
+ #define UNIT (4 << 10)
+
+ BUILD_BUG_ON(!CRASH_BUFFER_SIZE);
+ BUILD_BUG_ON(!IS_ALIGNED(CRASH_BUFFER_SIZE, UNIT));
+ BUILD_BUG_ON(!DPC_BUFFER_SIZE);
+ BUILD_BUG_ON(!IS_ALIGNED(DPC_BUFFER_SIZE, UNIT));
+ BUILD_BUG_ON(!ISR_BUFFER_SIZE);
+ BUILD_BUG_ON(!IS_ALIGNED(ISR_BUFFER_SIZE, UNIT));
+
+ BUILD_BUG_ON((CRASH_BUFFER_SIZE/UNIT - 1) >
+ (GUC_LOG_CRASH_MASK >> GUC_LOG_CRASH_SHIFT));
+ BUILD_BUG_ON((DPC_BUFFER_SIZE/UNIT - 1) >
+ (GUC_LOG_DPC_MASK >> GUC_LOG_DPC_SHIFT));
+ BUILD_BUG_ON((ISR_BUFFER_SIZE/UNIT - 1) >
+ (GUC_LOG_ISR_MASK >> GUC_LOG_ISR_SHIFT));
+
+ flags = GUC_LOG_VALID |
+ GUC_LOG_NOTIFY_ON_HALF_FULL |
+ ((CRASH_BUFFER_SIZE/UNIT - 1) << GUC_LOG_CRASH_SHIFT) |
+ ((DPC_BUFFER_SIZE/UNIT - 1) << GUC_LOG_DPC_SHIFT) |
+ ((ISR_BUFFER_SIZE/UNIT - 1) << GUC_LOG_ISR_SHIFT) |
(offset << GUC_LOG_BUF_ADDR_SHIFT);
+ #undef UNIT
+
return flags;
}
diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index 0867ba76d445..1a0f2a39cef9 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -84,12 +84,12 @@
#define GUC_LOG_VALID(1 << 0)
#define GUC_LOG_NOTIFY_ON_HALF_FULL (1 << 1)
#define GUC_LOG_ALLOC_IN_MEGABYTE(1 << 3)
-#define GUC_LOG_CRASH_PAGES 1
#define GUC_LOG_CRASH_SHIFT 4
-#define GUC_LOG_DPC_PAGES7
+#define GUC_LOG_CRASH_MASK (0x1 << GUC_LOG_CRASH_SHIFT)
#define GUC_LOG_DPC_SHIFT6
-#define GUC_LOG_ISR_PAGES7
+#define GUC_LOG_DPC_MASK (0x7 << GUC_LOG_DPC_SHIFT)
#define GUC_LOG_ISR_SHIFT9
+#define GUC_LOG_ISR_MASK (0x7 << GUC_LOG_ISR_SHIFT)
#define GUC_LOG_BUF_ADDR_SHIFT 12
#define GUC_CTL_PAGE_FAULT_CONTROL 5
@@ -532,20 +532,6 @@ enum guc_log_buffer_type {
};
/**
- * DOC: GuC Log buffer Layout
- *
- * Page0 +---+
- *| ISR state header (32 bytes) |
- *| DPC state header |
- *| Crash dump state header |
- * Page1 +---+
- *| ISR logs|
- * Page9 +---+
- *| DPC logs|
- * Page17 +---+
- *| Crash Dump logs |
- *+---+
- *
* Below state structure is used for coordination of retrieval of GuC firmware
* logs. Separate state is maintained for each log buffer type.
* read_ptr points to the location where i915 read last in log buffer and
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c
b/drivers/gpu/drm/i915/intel_guc_log.c
index a751025b6ad7..1c4a8de9c305 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -27,6 +27,28 @@
#include "intel_guc_log.h"
#include "i915_drv.h"
+/*
+ * GuC Log buffer Layout
+ *
+ * +===+ 00B
+ * |Crash dump state header|
+ * +---+ 32B
+ * | DPC state header|
+ * +---+ 64B
+ * | ISR state header|
+ * +---+ 96B
+ * | |
+ * +===+ PAGE_SIZE (4KB)
+ * |Crash Dump logs|
+ * +===+ + CRASH_SIZE
+ * | DPC logs|
+ *
[Intel-gfx] [PATCH 5/7] drm/i915/guc: Refactoring preparation of the GUC_CTL_CTXINFO parameter
At the moment, the preparation of GUC_CTL_CTXINFO is disordered.
Lets move all GUC_CTL_CTXINFO related operations to one place.
Signed-off-by: Piotr Piórkowski
Cc: Michal Wajdeczko
Cc: Michał Winiarski
Cc: Joonas Lahtinen
Cc: Chris Wilson
---
drivers/gpu/drm/i915/intel_guc.c | 30 --
1 file changed, 20 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 185459ee49c9..3b45f06b1aa2 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -239,6 +239,25 @@ static u32 guc_ctl_feature_flags(struct intel_guc *guc)
return flags;
}
+
+static u32 guc_ctl_ctxinfo_flags(struct intel_guc *guc)
+{
+ u32 flags = 0;
+ u32 ctxnum;
+ u32 base;
+
+ if (USES_GUC_SUBMISSION(guc_to_i915(guc))) {
+
+ base = intel_guc_ggtt_offset(guc, guc->stage_desc_pool);
+ ctxnum = GUC_MAX_STAGE_DESCRIPTORS / 16;
+
+ base >>= PAGE_SHIFT;
+ flags = (base << GUC_CTL_BASE_ADDR_SHIFT) |
+ (ctxnum << GUC_CTL_CTXNUM_IN16_SHIFT);
+ }
+ return flags;
+}
+
static u32 guc_ctl_log_params_flags(struct intel_guc *guc)
{
u32 offset = intel_guc_ggtt_offset(guc, guc->log.vma) >> PAGE_SHIFT;
@@ -280,16 +299,7 @@ void intel_guc_init_params(struct intel_guc *guc)
params[GUC_CTL_FEATURE] = guc_ctl_feature_flags(guc);
params[GUC_CTL_LOG_PARAMS] = guc_ctl_log_params_flags(guc);
params[GUC_CTL_DEBUG] = guc_ctl_debug_flags(guc);
-
- /* If GuC submission is enabled, set up additional parameters here */
- if (USES_GUC_SUBMISSION(dev_priv)) {
- u32 pgs = intel_guc_ggtt_offset(guc, guc->stage_desc_pool);
- u32 ctx_in_16 = GUC_MAX_STAGE_DESCRIPTORS / 16;
-
- pgs >>= PAGE_SHIFT;
- params[GUC_CTL_CTXINFO] = (pgs << GUC_CTL_BASE_ADDR_SHIFT) |
- (ctx_in_16 << GUC_CTL_CTXNUM_IN16_SHIFT);
- }
+ params[GUC_CTL_CTXINFO] = guc_ctl_ctxinfo_flags(guc);
/*
* All SOFT_SCRATCH registers are in FORCEWAKE_BLITTER domain and
--
2.14.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/7] drm/i915/guc: Refactoring preparation of the GUC_CTL_LOG_PARAMS parameter
At the moment, the preparation of GUC_CTL_LOG_PARAMS is disordered.
Additionally, in struct intel_guc_log we have an unnecessary field
'flags' which we use only to assign value to GuC parameter.
Lets move all GUC_CTL_LOG_PARAMS related operations to one place,
and lets remove field 'flags' from struct intel_guc_log.
Signed-off-by: Piotr Piórkowski
Cc: Michal Wajdeczko
Cc: Michał Winiarski
Cc: Joonas Lahtinen
Cc: Chris Wilson
---
drivers/gpu/drm/i915/intel_guc.c | 18 --
drivers/gpu/drm/i915/intel_guc_log.c | 11 ---
drivers/gpu/drm/i915/intel_guc_log.h | 1 -
3 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 9dd255a34e65..185459ee49c9 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -239,6 +239,21 @@ static u32 guc_ctl_feature_flags(struct intel_guc *guc)
return flags;
}
+static u32 guc_ctl_log_params_flags(struct intel_guc *guc)
+{
+ u32 offset = intel_guc_ggtt_offset(guc, guc->log.vma) >> PAGE_SHIFT;
+ u32 flags;
+
+ /* each allocated unit is a page */
+ flags = GUC_LOG_VALID | GUC_LOG_NOTIFY_ON_HALF_FULL |
+ (GUC_LOG_CRASH_PAGES << GUC_LOG_CRASH_SHIFT) |
+ (GUC_LOG_DPC_PAGES << GUC_LOG_DPC_SHIFT) |
+ (GUC_LOG_ISR_PAGES << GUC_LOG_ISR_SHIFT) |
+ (offset << GUC_LOG_BUF_ADDR_SHIFT);
+
+ return flags;
+}
+
/*
* Initialise the GuC parameter block before starting the firmware
* transfer. These parameters are read by the firmware on startup
@@ -263,8 +278,7 @@ void intel_guc_init_params(struct intel_guc *guc)
params[GUC_CTL_WA] |= GUC_CTL_WA_UK_BY_DRIVER;
params[GUC_CTL_FEATURE] = guc_ctl_feature_flags(guc);
- params[GUC_CTL_LOG_PARAMS] = guc->log.flags;
-
+ params[GUC_CTL_LOG_PARAMS] = guc_ctl_log_params_flags(guc);
params[GUC_CTL_DEBUG] = guc_ctl_debug_flags(guc);
/* If GuC submission is enabled, set up additional parameters here */
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c
b/drivers/gpu/drm/i915/intel_guc_log.c
index c036d0fac370..a751025b6ad7 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -452,8 +452,6 @@ int intel_guc_log_create(struct intel_guc_log *log)
{
struct intel_guc *guc = log_to_guc(log);
struct i915_vma *vma;
- unsigned long offset;
- u32 flags;
int ret;
GEM_BUG_ON(log->vma);
@@ -466,15 +464,6 @@ int intel_guc_log_create(struct intel_guc_log *log)
log->vma = vma;
- /* each allocated unit is a page */
- flags = GUC_LOG_VALID | GUC_LOG_NOTIFY_ON_HALF_FULL |
- (GUC_LOG_DPC_PAGES << GUC_LOG_DPC_SHIFT) |
- (GUC_LOG_ISR_PAGES << GUC_LOG_ISR_SHIFT) |
- (GUC_LOG_CRASH_PAGES << GUC_LOG_CRASH_SHIFT);
-
- offset = intel_guc_ggtt_offset(guc, vma) >> PAGE_SHIFT;
- log->flags = (offset << GUC_LOG_BUF_ADDR_SHIFT) | flags;
-
log->level = i915_modparams.guc_log_level;
return 0;
diff --git a/drivers/gpu/drm/i915/intel_guc_log.h
b/drivers/gpu/drm/i915/intel_guc_log.h
index ea375c3b5d08..995aeb29a3b9 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.h
+++ b/drivers/gpu/drm/i915/intel_guc_log.h
@@ -60,7 +60,6 @@ struct intel_guc;
struct intel_guc_log {
u32 level;
- u32 flags;
struct i915_vma *vma;
struct {
void *buf_addr;
--
2.14.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/7] drm/i915/guc: Refactoring preparation of the GUC_CTL_FEATURE parameter
At the moment, the preparation of GUC_CTL_FEATURE is disordered.
Lets move all GUC_CTL_FEATURE related operations to one place.
Signed-off-by: Piotr Piórkowski
Cc: Michal Wajdeczko
Cc: Michał Winiarski
Cc: Joonas Lahtinen
Cc: Chris Wilson
---
drivers/gpu/drm/i915/intel_guc.c | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 3cc99fcaaea6..9dd255a34e65 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -226,6 +226,19 @@ static u32 guc_ctl_debug_flags(struct intel_guc *guc)
return flags;
}
+static u32 guc_ctl_feature_flags(struct intel_guc *guc)
+{
+ u32 flags = 0;
+
+ flags |= GUC_CTL_VCS2_ENABLED;
+
+ if (USES_GUC_SUBMISSION(guc_to_i915(guc)))
+ flags |= GUC_CTL_KERNEL_SUBMISSIONS;
+ else
+ flags |= GUC_CTL_DISABLE_SCHEDULER;
+
+ return flags;
+}
/*
* Initialise the GuC parameter block before starting the firmware
* transfer. These parameters are read by the firmware on startup
@@ -249,9 +262,7 @@ void intel_guc_init_params(struct intel_guc *guc)
params[GUC_CTL_WA] |= GUC_CTL_WA_UK_BY_DRIVER;
- params[GUC_CTL_FEATURE] |= GUC_CTL_DISABLE_SCHEDULER |
- GUC_CTL_VCS2_ENABLED;
-
+ params[GUC_CTL_FEATURE] = guc_ctl_feature_flags(guc);
params[GUC_CTL_LOG_PARAMS] = guc->log.flags;
params[GUC_CTL_DEBUG] = guc_ctl_debug_flags(guc);
@@ -264,11 +275,6 @@ void intel_guc_init_params(struct intel_guc *guc)
pgs >>= PAGE_SHIFT;
params[GUC_CTL_CTXINFO] = (pgs << GUC_CTL_BASE_ADDR_SHIFT) |
(ctx_in_16 << GUC_CTL_CTXNUM_IN16_SHIFT);
-
- params[GUC_CTL_FEATURE] |= GUC_CTL_KERNEL_SUBMISSIONS;
-
- /* Unmask this bit to enable the GuC's internal scheduler */
- params[GUC_CTL_FEATURE] &= ~GUC_CTL_DISABLE_SCHEDULER;
}
/*
--
2.14.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/7] drm/i915/guc: Refactoring preparation of the GUC_CTL_DEBUG parameter
At the moment, the preparation of GUC_CTL_DEBUG is disordered.
Lets move all GUC_CTL_DEBUG related operations to one place.
Signed-off-by: Piotr Piórkowski
Cc: Michal Wajdeczko
Cc: Michał Winiarski
Cc: Joonas Lahtinen
Cc: Chris Wilson
---
drivers/gpu/drm/i915/intel_guc.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 9025837850ad..3cc99fcaaea6 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -205,6 +205,7 @@ void intel_guc_fini(struct intel_guc *guc)
static u32 guc_ctl_debug_flags(struct intel_guc *guc)
{
+ u32 ads = intel_guc_ggtt_offset(guc, guc->ads_vma) >> PAGE_SHIFT;
u32 level = intel_guc_log_level_get(>log);
u32 flags = 0;
@@ -217,6 +218,11 @@ static u32 guc_ctl_debug_flags(struct intel_guc *guc)
flags |= GUC_LOG_LEVEL_TO_VERBOSITY(level) <<
GUC_LOG_VERBOSITY_SHIFT;
+ if (USES_GUC_SUBMISSION(guc_to_i915(guc))) {
+ flags |= ads << GUC_ADS_ADDR_SHIFT;
+ flags |= GUC_ADS_ENABLED;
+ }
+
return flags;
}
@@ -252,14 +258,9 @@ void intel_guc_init_params(struct intel_guc *guc)
/* If GuC submission is enabled, set up additional parameters here */
if (USES_GUC_SUBMISSION(dev_priv)) {
- u32 ads = intel_guc_ggtt_offset(guc,
- guc->ads_vma) >> PAGE_SHIFT;
u32 pgs = intel_guc_ggtt_offset(guc, guc->stage_desc_pool);
u32 ctx_in_16 = GUC_MAX_STAGE_DESCRIPTORS / 16;
- params[GUC_CTL_DEBUG] |= ads << GUC_ADS_ADDR_SHIFT;
- params[GUC_CTL_DEBUG] |= GUC_ADS_ENABLED;
-
pgs >>= PAGE_SHIFT;
params[GUC_CTL_CTXINFO] = (pgs << GUC_CTL_BASE_ADDR_SHIFT) |
(ctx_in_16 << GUC_CTL_CTXNUM_IN16_SHIFT);
--
2.14.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/7] drm/i915/guc: Don't store runtime GuC log level in modparam
From: Piotr Piórkowski
Currently we are using modparam as placeholder for GuC log level.
Stop doing this and keep runtime GuC level in intel_guc_log struct.
Signed-off-by: Piotr Piórkowski
Cc: Michal Wajdeczko
Cc: Michał Winiarski
Cc: Joonas Lahtinen
Cc: Chris Wilson
---
drivers/gpu/drm/i915/intel_guc.c | 8 +++-
drivers/gpu/drm/i915/intel_guc_log.c | 18 +-
drivers/gpu/drm/i915/intel_guc_log.h | 9 -
drivers/gpu/drm/i915/intel_uc.c | 2 +-
4 files changed, 17 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 116f4ccf1bbd..9025837850ad 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -203,13 +203,11 @@ void intel_guc_fini(struct intel_guc *guc)
guc_shared_data_destroy(guc);
}
-static u32 get_log_control_flags(void)
+static u32 guc_ctl_debug_flags(struct intel_guc *guc)
{
- u32 level = i915_modparams.guc_log_level;
+ u32 level = intel_guc_log_level_get(>log);
u32 flags = 0;
- GEM_BUG_ON(level < 0);
-
if (!GUC_LOG_LEVEL_IS_ENABLED(level))
flags |= GUC_LOG_DEFAULT_DISABLED;
@@ -250,7 +248,7 @@ void intel_guc_init_params(struct intel_guc *guc)
params[GUC_CTL_LOG_PARAMS] = guc->log.flags;
- params[GUC_CTL_DEBUG] = get_log_control_flags();
+ params[GUC_CTL_DEBUG] = guc_ctl_debug_flags(guc);
/* If GuC submission is enabled, set up additional parameters here */
if (USES_GUC_SUBMISSION(dev_priv)) {
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c
b/drivers/gpu/drm/i915/intel_guc_log.c
index 401e1704d61e..c036d0fac370 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -475,11 +475,12 @@ int intel_guc_log_create(struct intel_guc_log *log)
offset = intel_guc_ggtt_offset(guc, vma) >> PAGE_SHIFT;
log->flags = (offset << GUC_LOG_BUF_ADDR_SHIFT) | flags;
+ log->level = i915_modparams.guc_log_level;
+
return 0;
err:
- /* logging will be off */
- i915_modparams.guc_log_level = 0;
+ DRM_ERROR("Failed to allocate GuC log buffer. %d\n", ret);
return ret;
}
@@ -488,14 +489,6 @@ void intel_guc_log_destroy(struct intel_guc_log *log)
i915_vma_unpin_and_release(>vma);
}
-int intel_guc_log_level_get(struct intel_guc_log *log)
-{
- GEM_BUG_ON(!log->vma);
- GEM_BUG_ON(i915_modparams.guc_log_level < 0);
-
- return i915_modparams.guc_log_level;
-}
-
int intel_guc_log_level_set(struct intel_guc_log *log, u64 val)
{
struct intel_guc *guc = log_to_guc(log);
@@ -504,7 +497,6 @@ int intel_guc_log_level_set(struct intel_guc_log *log, u64
val)
BUILD_BUG_ON(GUC_LOG_VERBOSITY_MIN != 0);
GEM_BUG_ON(!log->vma);
- GEM_BUG_ON(i915_modparams.guc_log_level < 0);
/*
* GuC is recognizing log levels starting from 0 to max, we're using 0
@@ -515,7 +507,7 @@ int intel_guc_log_level_set(struct intel_guc_log *log, u64
val)
mutex_lock(_priv->drm.struct_mutex);
- if (i915_modparams.guc_log_level == val) {
+ if (log->level == val) {
ret = 0;
goto out_unlock;
}
@@ -530,7 +522,7 @@ int intel_guc_log_level_set(struct intel_guc_log *log, u64
val)
goto out_unlock;
}
- i915_modparams.guc_log_level = val;
+ log->level = val;
out_unlock:
mutex_unlock(_priv->drm.struct_mutex);
diff --git a/drivers/gpu/drm/i915/intel_guc_log.h
b/drivers/gpu/drm/i915/intel_guc_log.h
index fa80535a6f9d..ea375c3b5d08 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.h
+++ b/drivers/gpu/drm/i915/intel_guc_log.h
@@ -30,6 +30,7 @@
#include
#include "intel_guc_fwif.h"
+#include "i915_gem.h"
struct intel_guc;
@@ -58,6 +59,7 @@ struct intel_guc;
#define GUC_LOG_LEVEL_MAX GUC_VERBOSITY_TO_LOG_LEVEL(GUC_LOG_VERBOSITY_MAX)
struct intel_guc_log {
+ u32 level;
u32 flags;
struct i915_vma *vma;
struct {
@@ -80,7 +82,6 @@ void intel_guc_log_init_early(struct intel_guc_log *log);
int intel_guc_log_create(struct intel_guc_log *log);
void intel_guc_log_destroy(struct intel_guc_log *log);
-int intel_guc_log_level_get(struct intel_guc_log *log);
int intel_guc_log_level_set(struct intel_guc_log *log, u64 control_val);
bool intel_guc_log_relay_enabled(const struct intel_guc_log *log);
int intel_guc_log_relay_open(struct intel_guc_log *log);
@@ -89,4 +90,10 @@ void intel_guc_log_relay_close(struct intel_guc_log *log);
void intel_guc_log_handle_flush_event(struct intel_guc_log *log);
+static inline u32 intel_guc_log_level_get(struct intel_guc_log *log)
+{
+ GEM_BUG_ON(!log->vma);
+ return log->level;
+}
+
#endif
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 6a73e81f373b..5ce8d5df1b58 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++
[Intel-gfx] [PATCH v2] drm/i915/pmu: Measure sampler intervals
hrtimer is not reliable enough to assume fixed intervals, and so even
coarse accuracy (in the face of kasan and similar heavy debugging) we
need to measure the actual interval between sample.
While using a single timestamp to compute the interval does not allow
very fine accuracy (consider the impact of a slow forcewake between
different samples after the timestamp is read) is much better than
assuming the interval.
v2: Make use of the sample period for estimating the GPU clock cycles,
leaving the frequency calculation (the averaging) to the caller.
Introduce new samplers for reporting cycles instead of Hz.
Testcase: igt/perf_pmu #ivb
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_pmu.c | 44 ++---
drivers/gpu/drm/i915/i915_pmu.h | 6 +
include/uapi/drm/i915_drm.h | 2 ++
3 files changed, 43 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index dc87797db500..12033e47e3b4 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -86,6 +86,8 @@ static bool pmu_needs_timer(struct drm_i915_private *i915,
bool gpu_active)
*/
enable &= config_enabled_mask(I915_PMU_ACTUAL_FREQUENCY) |
config_enabled_mask(I915_PMU_REQUESTED_FREQUENCY) |
+ config_enabled_mask(I915_PMU_ACTUAL_CLOCK) |
+ config_enabled_mask(I915_PMU_REQUESTED_CLOCK) |
ENGINE_SAMPLE_MASK;
/*
@@ -127,6 +129,7 @@ static void __i915_pmu_maybe_start_timer(struct
drm_i915_private *i915)
{
if (!i915->pmu.timer_enabled && pmu_needs_timer(i915, true)) {
i915->pmu.timer_enabled = true;
+ i915->pmu.timestamp = ktime_get();
hrtimer_start_range_ns(>pmu.timer,
ns_to_ktime(PERIOD), 0,
HRTIMER_MODE_REL_PINNED);
@@ -160,7 +163,7 @@ update_sample(struct i915_pmu_sample *sample, u32 unit, u32
val)
sample->cur += mul_u32_u32(val, unit);
}
-static void engines_sample(struct drm_i915_private *dev_priv)
+static void engines_sample(struct drm_i915_private *dev_priv, u64 period)
{
struct intel_engine_cs *engine;
enum intel_engine_id id;
@@ -183,7 +186,7 @@ static void engines_sample(struct drm_i915_private
*dev_priv)
val = !i915_seqno_passed(current_seqno, last_seqno);
update_sample(>pmu.sample[I915_SAMPLE_BUSY],
- PERIOD, val);
+ period, val);
if (val && (engine->pmu.enable &
(BIT(I915_SAMPLE_WAIT) | BIT(I915_SAMPLE_SEMA {
@@ -195,10 +198,10 @@ static void engines_sample(struct drm_i915_private
*dev_priv)
}
update_sample(>pmu.sample[I915_SAMPLE_WAIT],
- PERIOD, !!(val & RING_WAIT));
+ period, !!(val & RING_WAIT));
update_sample(>pmu.sample[I915_SAMPLE_SEMA],
- PERIOD, !!(val & RING_WAIT_SEMAPHORE));
+ period, !!(val & RING_WAIT_SEMAPHORE));
}
if (fw)
@@ -207,10 +210,11 @@ static void engines_sample(struct drm_i915_private
*dev_priv)
intel_runtime_pm_put(dev_priv);
}
-static void frequency_sample(struct drm_i915_private *dev_priv)
+static void frequency_sample(struct drm_i915_private *dev_priv, u64 period)
{
if (dev_priv->pmu.enable &
- config_enabled_mask(I915_PMU_ACTUAL_FREQUENCY)) {
+ (config_enabled_mask(I915_PMU_ACTUAL_CLOCK) |
+config_enabled_mask(I915_PMU_ACTUAL_FREQUENCY))) {
u32 val;
val = dev_priv->gt_pm.rps.cur_freq;
@@ -223,13 +227,20 @@ static void frequency_sample(struct drm_i915_private
*dev_priv)
update_sample(_priv->pmu.sample[__I915_SAMPLE_FREQ_ACT],
1, intel_gpu_freq(dev_priv, val));
+ update_sample(_priv->pmu.sample[__I915_SAMPLE_CLOCK_ACT],
+ period, intel_gpu_freq(dev_priv, val));
}
if (dev_priv->pmu.enable &
- config_enabled_mask(I915_PMU_REQUESTED_FREQUENCY)) {
+ (config_enabled_mask(I915_PMU_REQUESTED_CLOCK) |
+config_enabled_mask(I915_PMU_REQUESTED_FREQUENCY))) {
update_sample(_priv->pmu.sample[__I915_SAMPLE_FREQ_REQ], 1,
intel_gpu_freq(dev_priv,
dev_priv->gt_pm.rps.cur_freq));
+ update_sample(_priv->pmu.sample[__I915_SAMPLE_CLOCK_REQ],
+ period,
+ intel_gpu_freq(dev_priv,
+dev_priv->gt_pm.rps.cur_freq));
}
}
@@ -237,12 +248,17 @@ static enum hrtimer_restart i915_sample(struct hrtimer
[Intel-gfx] ✗ Fi.CI.BAT: failure for YCBCR 4:2:0/4:4:4 output support for LSPCON (rev8)
== Series Details == Series: YCBCR 4:2:0/4:4:4 output support for LSPCON (rev8) URL : https://patchwork.freedesktop.org/series/36068/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4256 -> Patchwork_9147 = == Summary - FAILURE == Serious unknown changes coming with Patchwork_9147 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9147, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/36068/revisions/8/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9147: === IGT changes === Possible regressions igt@gem_exec_suspend@basic-s4-devices: fi-cfl-s3: PASS -> DMESG-WARN +45 igt@kms_busy@basic-flip-a: fi-kbl-7567u: PASS -> DMESG-WARN +29 Warnings igt@gem_exec_gttfill@basic: fi-pnv-d510:SKIP -> PASS == Known issues == Here are the changes found in Patchwork_9147 that come from known issues: === IGT changes === Issues hit igt@debugfs_test@read_all_entries: fi-snb-2520m: PASS -> INCOMPLETE (fdo#103713) igt@kms_frontbuffer_tracking@basic: fi-hsw-4200u: PASS -> DMESG-FAIL (fdo#102614, fdo#106103) igt@prime_vgem@basic-fence-flip: fi-ilk-650: PASS -> FAIL (fdo#104008) Possible fixes igt@prime_vgem@basic-fence-flip: fi-bwr-2160:FAIL (fdo#103182) -> PASS fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#103182 https://bugs.freedesktop.org/show_bug.cgi?id=103182 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fdo#106103 https://bugs.freedesktop.org/show_bug.cgi?id=106103 == Participating hosts (45 -> 39) == Missing(6): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-cfl-u2 fi-skl-6700hq == Build changes == * Linux: CI_DRM_4256 -> Patchwork_9147 CI_DRM_4256: 02a9ddab7c0319d16af25f22f9b15b271e6bbc8f @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4500: 43f7a746ac092e41d4745ed190d4268ef1f82c55 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9147: cab98d0b19ea3480c673b95018780c905bc007ec @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == cab98d0b19ea drm/i915: Add YCBCR 4:2:0/4:4:4 support for LSPCON 6fcc9ce4c7b3 drm/i915: Write AVI infoframes for Parade LSPCON 42085377b498 drm/i915: Write AVI infoframes for MCA LSPCON e15310784af1 drm/i915: Add AVI infoframe support for LSPCON 7cdafd96c1e4 drm/i915: Check LSPCON vendor OUI 67ec2782ab55 drm/i915: Add CRTC output format YCBCR 4:4:4 22f13096d17e drm/i915: Add CRTC output format YCBCR 4:2:0 15891a2047c1 drm/i915: Introduce CRTC output format == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9147/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/5] drm/i915: Remove stale asserts from i915_gem_find_active_request()
Quoting Tvrtko Ursulin (2018-05-30 12:01:47)
>
> On 30/05/2018 11:55, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-05-30 11:43:16)
> >>
> >> On 29/05/2018 14:29, Chris Wilson wrote:
> >>> Since we use i915_gem_find_active_request() from inside
> >>> intel_engine_dump() and may call that at any time, we do not guarantee
> >>> that the engine is paused nor that the signal kthreads and irq handler
> >>> are suspended, so we cannot assert that the breadcrumb doesn't advance
> >>> and that the irq hasn't happened on another CPU signaling the request we
> >>> believe to be idle.
> >>>
> >>> Fixes: f636edb214a5 ("drm/i915: Make i915_engine_info pretty printer to
> >>> standalone")
> >>> Signed-off-by: Chris Wilson
> >>> Cc: Mika Kuoppala
> >>> Cc: Joonas Lahtinen
> >>> ---
> >>>drivers/gpu/drm/i915/i915_gem.c | 17 -
> >>>1 file changed, 8 insertions(+), 9 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/i915_gem.c
> >>> b/drivers/gpu/drm/i915/i915_gem.c
> >>> index 05f44ca35a06..530d6d0109b4 100644
> >>> --- a/drivers/gpu/drm/i915/i915_gem.c
> >>> +++ b/drivers/gpu/drm/i915/i915_gem.c
> >>> @@ -2972,23 +2972,22 @@ i915_gem_find_active_request(struct
> >>> intel_engine_cs *engine)
> >>>struct i915_request *request, *active = NULL;
> >>>unsigned long flags;
> >>>
> >>> - /* We are called by the error capture and reset at a random
> >>> - * point in time. In particular, note that neither is crucially
> >>> - * ordered with an interrupt. After a hang, the GPU is dead and we
> >>> - * assume that no more writes can happen (we waited long enough for
> >>> - * all writes that were in transaction to be flushed) - adding an
> >>> + /*
> >>> + * We are called by the error capture, reset and to dump engine
> >>> + * state at random points in time. In particular, note that neither
> >>> is
> >>> + * crucially ordered with an interrupt. After a hang, the GPU is
> >>> dead
> >>> + * and we assume that no more writes can happen (we waited long
> >>> enough
> >>> + * for all writes that were in transaction to be flushed) - adding
> >>> an
> >>> * extra delay for a recent interrupt is pointless. Hence, we do
> >>> * not need an engine->irq_seqno_barrier() before the seqno reads.
> >>> + * At all other times, we must assume the GPU is still running, but
> >>> + * we only care about the snapshot of this moment.
> >>> */
> >>>spin_lock_irqsave(>timeline.lock, flags);
> >>>list_for_each_entry(request, >timeline.requests, link) {
> >>>if (__i915_request_completed(request,
> >>> request->global_seqno))
> >>>continue;
> >>>
> >>> - GEM_BUG_ON(request->engine != engine);
> >>
> >> Removal of this one belongs to virtual engine perhaps?
> >
> > Nah, even with virtual engine; the engine timeline list is still true. I
> > was just thinking it was too random to check here (e.g. in the middle of
> > error capture) and that our more recent addition of checking during
> > retirement was a little more rigorous (and timely).
>
> It is a random check indeed. Commit message append: "While at it remove
> a random assert on..."
>
> Reviewed-by: Tvrtko Ursulin
Pushed this patch by itself, just so I can have a new CI baseline :)
Thanks for the review,
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/pmu: Measure sampler intervals
Quoting Tvrtko Ursulin (2018-05-30 11:57:39)
>
> On 25/05/2018 18:45, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-05-25 18:31:35)
> >>
> >> On 25/05/2018 18:11, Chris Wilson wrote:
> >>> hrtimer is not reliable enough to assume fixed intervals, and so even
> >>> coarse accuracy (in the face of kasan and similar heavy debugging) we
> >>> need to measure the actual interval between sample.
> >>
> >> It doesn't even average out to something acceptable under such Kconfigs?
> >> Horror.. precise but inaccurate. /O\
> >>
> >>> While using a single timestamp to compute the interval does not allow
> >>> very fine accuracy (consider the impact of a slow forcewake between
> >>> different samples after the timestamp is read) is much better than
> >>> assuming the interval.
> >>>
> >>> Testcase: igt/perf_pmu #ivb
> >>> Signed-off-by: Chris Wilson
> >>> Cc: Tvrtko Ursulin
> >>> ---
> >>>drivers/gpu/drm/i915/i915_pmu.c | 20 +---
> >>>drivers/gpu/drm/i915/i915_pmu.h | 4
> >>>2 files changed, 17 insertions(+), 7 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/i915_pmu.c
> >>> b/drivers/gpu/drm/i915/i915_pmu.c
> >>> index dc87797db500..f5087515eb43 100644
> >>> --- a/drivers/gpu/drm/i915/i915_pmu.c
> >>> +++ b/drivers/gpu/drm/i915/i915_pmu.c
> >>> @@ -127,6 +127,7 @@ static void __i915_pmu_maybe_start_timer(struct
> >>> drm_i915_private *i915)
> >>>{
> >>>if (!i915->pmu.timer_enabled && pmu_needs_timer(i915, true)) {
> >>>i915->pmu.timer_enabled = true;
> >>> + i915->pmu.timestamp = ktime_get();
> >>>hrtimer_start_range_ns(>pmu.timer,
> >>> ns_to_ktime(PERIOD), 0,
> >>> HRTIMER_MODE_REL_PINNED);
> >>> @@ -160,7 +161,7 @@ update_sample(struct i915_pmu_sample *sample, u32
> >>> unit, u32 val)
> >>>sample->cur += mul_u32_u32(val, unit);
> >>>}
> >>>
> >>> -static void engines_sample(struct drm_i915_private *dev_priv)
> >>> +static void engines_sample(struct drm_i915_private *dev_priv, u64 period)
> >>>{
> >>>struct intel_engine_cs *engine;
> >>>enum intel_engine_id id;
> >>> @@ -183,7 +184,7 @@ static void engines_sample(struct drm_i915_private
> >>> *dev_priv)
> >>>val = !i915_seqno_passed(current_seqno, last_seqno);
> >>>
> >>>update_sample(>pmu.sample[I915_SAMPLE_BUSY],
> >>> - PERIOD, val);
> >>> + period, val);
> >>>
> >>>if (val && (engine->pmu.enable &
> >>>(BIT(I915_SAMPLE_WAIT) | BIT(I915_SAMPLE_SEMA {
> >>> @@ -195,10 +196,10 @@ static void engines_sample(struct drm_i915_private
> >>> *dev_priv)
> >>>}
> >>>
> >>>update_sample(>pmu.sample[I915_SAMPLE_WAIT],
> >>> - PERIOD, !!(val & RING_WAIT));
> >>> + period, !!(val & RING_WAIT));
> >>>
> >>>update_sample(>pmu.sample[I915_SAMPLE_SEMA],
> >>> - PERIOD, !!(val & RING_WAIT_SEMAPHORE));
> >>> + period, !!(val & RING_WAIT_SEMAPHORE));
> >>>}
> >>>
> >>>if (fw)
> >>> @@ -207,7 +208,7 @@ static void engines_sample(struct drm_i915_private
> >>> *dev_priv)
> >>>intel_runtime_pm_put(dev_priv);
> >>>}
> >>>
> >>> -static void frequency_sample(struct drm_i915_private *dev_priv)
> >>> +static void frequency_sample(struct drm_i915_private *dev_priv, u64
> >>> period)
> >>
> >> Period is unused in this function.
> >>
> >> But more importantly that leads to a problem. When reading the counter
> >> the frequencies accumulator is divided by FREQUENCY define, which is
> >> inverse of PERIOD. If the error is big enough to mess up the engines
> >> sampling, is it big enough to affect the frequencies as well?
> >
> > Yes, but fixing up frequencies I left for another patch, because it's
> > going to be more involved (having to choose the divider more carefully)
> > and would you believe it, but CI only complains about busy sampling ;)
> >
> > I passed in the period as a reminder.
>
> It might only remind someone to remove the unused variable so I am not
> sure it is worth it.
>
> >> Improving that would need average frequency between two counter reads.
> >> Which looks tricky to shoehorn into the pmu api. Maybe primitive running
> >> average would do.
> >
> > My plan was to expose cycles (Frequency x time) to the user, and then
> > they calculate frequency by the comparing their own samples. (Since we
> > give them (time, samples) for each pmu read).
>
> Frequency times which time? On read? Don't exactly follow. :(
On sample: sample[FREQ] += period * instantaneous_measurement
The (perf_event_read) caller has to compute freq by d_cycles / d_time.
i.e. we don't have a frequency sampler, but a cycles sampler. I think
this is a big
Re: [Intel-gfx] [PATCH 1/5] drm/i915: Remove stale asserts from i915_gem_find_active_request()
On 30/05/2018 11:55, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-05-30 11:43:16)
On 29/05/2018 14:29, Chris Wilson wrote:
Since we use i915_gem_find_active_request() from inside
intel_engine_dump() and may call that at any time, we do not guarantee
that the engine is paused nor that the signal kthreads and irq handler
are suspended, so we cannot assert that the breadcrumb doesn't advance
and that the irq hasn't happened on another CPU signaling the request we
believe to be idle.
Fixes: f636edb214a5 ("drm/i915: Make i915_engine_info pretty printer to
standalone")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 05f44ca35a06..530d6d0109b4 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2972,23 +2972,22 @@ i915_gem_find_active_request(struct intel_engine_cs
*engine)
struct i915_request *request, *active = NULL;
unsigned long flags;
- /* We are called by the error capture and reset at a random
- * point in time. In particular, note that neither is crucially
- * ordered with an interrupt. After a hang, the GPU is dead and we
- * assume that no more writes can happen (we waited long enough for
- * all writes that were in transaction to be flushed) - adding an
+ /*
+ * We are called by the error capture, reset and to dump engine
+ * state at random points in time. In particular, note that neither is
+ * crucially ordered with an interrupt. After a hang, the GPU is dead
+ * and we assume that no more writes can happen (we waited long enough
+ * for all writes that were in transaction to be flushed) - adding an
* extra delay for a recent interrupt is pointless. Hence, we do
* not need an engine->irq_seqno_barrier() before the seqno reads.
+ * At all other times, we must assume the GPU is still running, but
+ * we only care about the snapshot of this moment.
*/
spin_lock_irqsave(>timeline.lock, flags);
list_for_each_entry(request, >timeline.requests, link) {
if (__i915_request_completed(request, request->global_seqno))
continue;
- GEM_BUG_ON(request->engine != engine);
Removal of this one belongs to virtual engine perhaps?
Nah, even with virtual engine; the engine timeline list is still true. I
was just thinking it was too random to check here (e.g. in the middle of
error capture) and that our more recent addition of checking during
retirement was a little more rigorous (and timely).
It is a random check indeed. Commit message append: "While at it remove
a random assert on..."
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for YCBCR 4:2:0/4:4:4 output support for LSPCON (rev8)
== Series Details == Series: YCBCR 4:2:0/4:4:4 output support for LSPCON (rev8) URL : https://patchwork.freedesktop.org/series/36068/ State : warning == Summary == $ dim checkpatch origin/drm-tip 15891a2047c1 drm/i915: Introduce CRTC output format 22f13096d17e drm/i915: Add CRTC output format YCBCR 4:2:0 67ec2782ab55 drm/i915: Add CRTC output format YCBCR 4:4:4 7cdafd96c1e4 drm/i915: Check LSPCON vendor OUI e15310784af1 drm/i915: Add AVI infoframe support for LSPCON 42085377b498 drm/i915: Write AVI infoframes for MCA LSPCON 6fcc9ce4c7b3 drm/i915: Write AVI infoframes for Parade LSPCON cab98d0b19ea drm/i915: Add YCBCR 4:2:0/4:4:4 support for LSPCON -:65: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #65: FILE: drivers/gpu/drm/i915/i915_reg.h:8834: +#define TRANS_MSA_SAMPLING_444(2<<1) ^ -:66: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #66: FILE: drivers/gpu/drm/i915/i915_reg.h:8835: +#define TRANS_MSA_CLRSP_YCBCR (2<<3) ^ total: 0 errors, 0 warnings, 2 checks, 128 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/pmu: Measure sampler intervals
On 25/05/2018 18:45, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-05-25 18:31:35)
On 25/05/2018 18:11, Chris Wilson wrote:
hrtimer is not reliable enough to assume fixed intervals, and so even
coarse accuracy (in the face of kasan and similar heavy debugging) we
need to measure the actual interval between sample.
It doesn't even average out to something acceptable under such Kconfigs?
Horror.. precise but inaccurate. /O\
While using a single timestamp to compute the interval does not allow
very fine accuracy (consider the impact of a slow forcewake between
different samples after the timestamp is read) is much better than
assuming the interval.
Testcase: igt/perf_pmu #ivb
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_pmu.c | 20 +---
drivers/gpu/drm/i915/i915_pmu.h | 4
2 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index dc87797db500..f5087515eb43 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -127,6 +127,7 @@ static void __i915_pmu_maybe_start_timer(struct
drm_i915_private *i915)
{
if (!i915->pmu.timer_enabled && pmu_needs_timer(i915, true)) {
i915->pmu.timer_enabled = true;
+ i915->pmu.timestamp = ktime_get();
hrtimer_start_range_ns(>pmu.timer,
ns_to_ktime(PERIOD), 0,
HRTIMER_MODE_REL_PINNED);
@@ -160,7 +161,7 @@ update_sample(struct i915_pmu_sample *sample, u32 unit, u32
val)
sample->cur += mul_u32_u32(val, unit);
}
-static void engines_sample(struct drm_i915_private *dev_priv)
+static void engines_sample(struct drm_i915_private *dev_priv, u64 period)
{
struct intel_engine_cs *engine;
enum intel_engine_id id;
@@ -183,7 +184,7 @@ static void engines_sample(struct drm_i915_private
*dev_priv)
val = !i915_seqno_passed(current_seqno, last_seqno);
update_sample(>pmu.sample[I915_SAMPLE_BUSY],
- PERIOD, val);
+ period, val);
if (val && (engine->pmu.enable &
(BIT(I915_SAMPLE_WAIT) | BIT(I915_SAMPLE_SEMA {
@@ -195,10 +196,10 @@ static void engines_sample(struct drm_i915_private
*dev_priv)
}
update_sample(>pmu.sample[I915_SAMPLE_WAIT],
- PERIOD, !!(val & RING_WAIT));
+ period, !!(val & RING_WAIT));
update_sample(>pmu.sample[I915_SAMPLE_SEMA],
- PERIOD, !!(val & RING_WAIT_SEMAPHORE));
+ period, !!(val & RING_WAIT_SEMAPHORE));
}
if (fw)
@@ -207,7 +208,7 @@ static void engines_sample(struct drm_i915_private
*dev_priv)
intel_runtime_pm_put(dev_priv);
}
-static void frequency_sample(struct drm_i915_private *dev_priv)
+static void frequency_sample(struct drm_i915_private *dev_priv, u64 period)
Period is unused in this function.
But more importantly that leads to a problem. When reading the counter
the frequencies accumulator is divided by FREQUENCY define, which is
inverse of PERIOD. If the error is big enough to mess up the engines
sampling, is it big enough to affect the frequencies as well?
Yes, but fixing up frequencies I left for another patch, because it's
going to be more involved (having to choose the divider more carefully)
and would you believe it, but CI only complains about busy sampling ;)
I passed in the period as a reminder.
It might only remind someone to remove the unused variable so I am not
sure it is worth it.
Improving that would need average frequency between two counter reads.
Which looks tricky to shoehorn into the pmu api. Maybe primitive running
average would do.
My plan was to expose cycles (Frequency x time) to the user, and then
they calculate frequency by the comparing their own samples. (Since we
give them (time, samples) for each pmu read).
Frequency times which time? On read? Don't exactly follow. :(
{
if (dev_priv->pmu.enable &
config_enabled_mask(I915_PMU_ACTUAL_FREQUENCY)) {
@@ -237,12 +238,17 @@ static enum hrtimer_restart i915_sample(struct hrtimer
*hrtimer)
{
struct drm_i915_private *i915 =
container_of(hrtimer, struct drm_i915_private, pmu.timer);
+ ktime_t now, period;
if (!READ_ONCE(i915->pmu.timer_enabled))
return HRTIMER_NORESTART;
- engines_sample(i915);
- frequency_sample(i915);
+ now = ktime_get();
+ period = ktime_sub(now, i915->pmu.timestamp);
+ i915->pmu.timestamp = now;
+
+ engines_sample(i915, period);
+ frequency_sample(i915, period);
hrtimer_forward_now(hrtimer, ns_to_ktime(PERIOD));
return HRTIMER_RESTART;
diff --git
Re: [Intel-gfx] [PATCH i-g-t] igt/perf_pmu: Flush to idle after hang
Quoting Tvrtko Ursulin (2018-05-30 11:48:16)
>
> On 25/05/2018 16:14, Chris Wilson wrote:
> > We may not idle immediately after a hang, and indeed may send a pulse
> > down the pipeline periodically to become idle. Rather than make a flimsy
> > assumption about how long we need to sleep before the system idles,
> > wait for the system to declare itself idle; flushing it to idle in the
> > process!
> >
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > ---
> > tests/perf_pmu.c | 11 ++-
> > 1 file changed, 2 insertions(+), 9 deletions(-)
> >
> > diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
> > index 590e6526b..9af192dd8 100644
> > --- a/tests/perf_pmu.c
> > +++ b/tests/perf_pmu.c
> > @@ -281,16 +281,9 @@ single(int gem_fd, const struct
> > intel_execution_engine2 *e, unsigned int flags)
> >
> > /* Check for idle after hang. */
> > if (flags & FLAG_HANG) {
> > - /* Sleep for a bit for reset unwind to settle. */
> > - usleep(500e3);
> > - /*
> > - * Ensure batch was executing before reset, meaning it must be
> > - * idle by now. Unless it did not even manage to start before
> > we
> > - * triggered the reset, in which case the idleness check below
> > - * might fail. The latter is very unlikely since there are two
> > - * sleeps during which it had an opportunity to start.
> > - */
> > + gem_quiescent_gpu(gem_fd);
> > igt_assert(!gem_bo_busy(gem_fd, spin->handle));
> > +
> > val = pmu_read_single(fd);
> > slept = measured_usleep(batch_duration_ns / 1000);
> > val = pmu_read_single(fd) - val;
> >
>
> Reviewed-by: Tvrtko Ursulin
That's a relief. I was fearing you might argue that we need some sort of
check that it does idle in a timely fashion without intervention. Off
the top of my head, we do have some gem_wait/gem_eio checks that should
cover that.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/5] drm/i915: Remove stale asserts from i915_gem_find_active_request()
Quoting Tvrtko Ursulin (2018-05-30 11:43:16)
>
> On 29/05/2018 14:29, Chris Wilson wrote:
> > Since we use i915_gem_find_active_request() from inside
> > intel_engine_dump() and may call that at any time, we do not guarantee
> > that the engine is paused nor that the signal kthreads and irq handler
> > are suspended, so we cannot assert that the breadcrumb doesn't advance
> > and that the irq hasn't happened on another CPU signaling the request we
> > believe to be idle.
> >
> > Fixes: f636edb214a5 ("drm/i915: Make i915_engine_info pretty printer to
> > standalone")
> > Signed-off-by: Chris Wilson
> > Cc: Mika Kuoppala
> > Cc: Joonas Lahtinen
> > ---
> > drivers/gpu/drm/i915/i915_gem.c | 17 -
> > 1 file changed, 8 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 05f44ca35a06..530d6d0109b4 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -2972,23 +2972,22 @@ i915_gem_find_active_request(struct intel_engine_cs
> > *engine)
> > struct i915_request *request, *active = NULL;
> > unsigned long flags;
> >
> > - /* We are called by the error capture and reset at a random
> > - * point in time. In particular, note that neither is crucially
> > - * ordered with an interrupt. After a hang, the GPU is dead and we
> > - * assume that no more writes can happen (we waited long enough for
> > - * all writes that were in transaction to be flushed) - adding an
> > + /*
> > + * We are called by the error capture, reset and to dump engine
> > + * state at random points in time. In particular, note that neither is
> > + * crucially ordered with an interrupt. After a hang, the GPU is dead
> > + * and we assume that no more writes can happen (we waited long enough
> > + * for all writes that were in transaction to be flushed) - adding an
> >* extra delay for a recent interrupt is pointless. Hence, we do
> >* not need an engine->irq_seqno_barrier() before the seqno reads.
> > + * At all other times, we must assume the GPU is still running, but
> > + * we only care about the snapshot of this moment.
> >*/
> > spin_lock_irqsave(>timeline.lock, flags);
> > list_for_each_entry(request, >timeline.requests, link) {
> > if (__i915_request_completed(request, request->global_seqno))
> > continue;
> >
> > - GEM_BUG_ON(request->engine != engine);
>
> Removal of this one belongs to virtual engine perhaps?
Nah, even with virtual engine; the engine timeline list is still true. I
was just thinking it was too random to check here (e.g. in the middle of
error capture) and that our more recent addition of checking during
retirement was a little more rigorous (and timely).
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] igt/perf_pmu: Flush to idle after hang
On 25/05/2018 16:14, Chris Wilson wrote:
We may not idle immediately after a hang, and indeed may send a pulse
down the pipeline periodically to become idle. Rather than make a flimsy
assumption about how long we need to sleep before the system idles,
wait for the system to declare itself idle; flushing it to idle in the
process!
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tests/perf_pmu.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
index 590e6526b..9af192dd8 100644
--- a/tests/perf_pmu.c
+++ b/tests/perf_pmu.c
@@ -281,16 +281,9 @@ single(int gem_fd, const struct intel_execution_engine2
*e, unsigned int flags)
/* Check for idle after hang. */
if (flags & FLAG_HANG) {
- /* Sleep for a bit for reset unwind to settle. */
- usleep(500e3);
- /*
-* Ensure batch was executing before reset, meaning it must be
-* idle by now. Unless it did not even manage to start before we
-* triggered the reset, in which case the idleness check below
-* might fail. The latter is very unlikely since there are two
-* sleeps during which it had an opportunity to start.
-*/
+ gem_quiescent_gpu(gem_fd);
igt_assert(!gem_bo_busy(gem_fd, spin->handle));
+
val = pmu_read_single(fd);
slept = measured_usleep(batch_duration_ns / 1000);
val = pmu_read_single(fd) - val;
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/5] drm/i915: Remove stale asserts from i915_gem_find_active_request()
On 29/05/2018 14:29, Chris Wilson wrote:
Since we use i915_gem_find_active_request() from inside
intel_engine_dump() and may call that at any time, we do not guarantee
that the engine is paused nor that the signal kthreads and irq handler
are suspended, so we cannot assert that the breadcrumb doesn't advance
and that the irq hasn't happened on another CPU signaling the request we
believe to be idle.
Fixes: f636edb214a5 ("drm/i915: Make i915_engine_info pretty printer to
standalone")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 05f44ca35a06..530d6d0109b4 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2972,23 +2972,22 @@ i915_gem_find_active_request(struct intel_engine_cs
*engine)
struct i915_request *request, *active = NULL;
unsigned long flags;
- /* We are called by the error capture and reset at a random
-* point in time. In particular, note that neither is crucially
-* ordered with an interrupt. After a hang, the GPU is dead and we
-* assume that no more writes can happen (we waited long enough for
-* all writes that were in transaction to be flushed) - adding an
+ /*
+* We are called by the error capture, reset and to dump engine
+* state at random points in time. In particular, note that neither is
+* crucially ordered with an interrupt. After a hang, the GPU is dead
+* and we assume that no more writes can happen (we waited long enough
+* for all writes that were in transaction to be flushed) - adding an
* extra delay for a recent interrupt is pointless. Hence, we do
* not need an engine->irq_seqno_barrier() before the seqno reads.
+* At all other times, we must assume the GPU is still running, but
+* we only care about the snapshot of this moment.
*/
spin_lock_irqsave(>timeline.lock, flags);
list_for_each_entry(request, >timeline.requests, link) {
if (__i915_request_completed(request, request->global_seqno))
continue;
- GEM_BUG_ON(request->engine != engine);
Removal of this one belongs to virtual engine perhaps?
Regards,
Tvrtko
- GEM_BUG_ON(test_bit(DMA_FENCE_FLAG_SIGNALED_BIT,
- >fence.flags));
-
active = request;
break;
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 3/3] lib: Double check ring measurement
Check twice for the signal interrupting the execbuf, because the real
world is messy.
References: https://bugs.freedesktop.org/show_bug.cgi?id=106695
Signed-off-by: Chris Wilson
Cc: Antonio Argenziano
---
lib/i915/gem_ring.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/lib/i915/gem_ring.c b/lib/i915/gem_ring.c
index 0c061000c..0708c8a2e 100644
--- a/lib/i915/gem_ring.c
+++ b/lib/i915/gem_ring.c
@@ -55,7 +55,7 @@ __gem_measure_ring_inflight(int fd, unsigned int engine, enum
measure_ring_flags
struct drm_i915_gem_exec_object2 obj[2];
struct drm_i915_gem_execbuffer2 execbuf;
const uint32_t bbe = MI_BATCH_BUFFER_END;
- unsigned int count, last;
+ unsigned int last[2]= { -1, -1 }, count;
struct itimerval itv;
IGT_CORK_HANDLE(cork);
@@ -85,7 +85,6 @@ __gem_measure_ring_inflight(int fd, unsigned int engine, enum
measure_ring_flags
itv.it_value.tv_usec = 1;
setitimer(ITIMER_REAL, , NULL);
- last = -1;
count = 0;
do {
if (__execbuf(fd, ) == 0) {
@@ -93,12 +92,13 @@ __gem_measure_ring_inflight(int fd, unsigned int engine,
enum measure_ring_flags
continue;
}
- if (last == count)
+ if (last[1] == count)
break;
/* sleep until the next timer interrupt (woken on signal) */
pause();
- last = count;
+ last[1] = last[0];
+ last[0] = count;
} while (1);
igt_assert_eq(__execbuf(fd, ), -EINTR);
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gvt: fix spelling mistake: "resseting" -> "resetting" (rev2)
== Series Details == Series: drm/i915/gvt: fix spelling mistake: "resseting" -> "resetting" (rev2) URL : https://patchwork.freedesktop.org/series/42903/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4256 -> Patchwork_9146 = == Summary - FAILURE == Serious unknown changes coming with Patchwork_9146 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9146, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/42903/revisions/2/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9146: === IGT changes === Possible regressions igt@gem_ctx_create@basic-files: fi-glk-j4005: PASS -> DMESG-WARN Warnings igt@gem_exec_gttfill@basic: fi-pnv-d510:SKIP -> PASS == Known issues == Here are the changes found in Patchwork_9146 that come from known issues: === IGT changes === Issues hit igt@kms_flip@basic-plain-flip: fi-glk-j4005: PASS -> DMESG-WARN (fdo#106000) igt@prime_vgem@basic-fence-flip: fi-ilk-650: PASS -> FAIL (fdo#104008) Possible fixes igt@kms_flip@basic-flip-vs-wf_vblank: fi-glk-j4005: FAIL (fdo#100368) -> PASS igt@prime_vgem@basic-fence-flip: fi-bwr-2160:FAIL (fdo#103182) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103182 https://bugs.freedesktop.org/show_bug.cgi?id=103182 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fdo#106000 https://bugs.freedesktop.org/show_bug.cgi?id=106000 == Participating hosts (45 -> 39) == Missing(6): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-cfl-u2 fi-skl-6700hq == Build changes == * Linux: CI_DRM_4256 -> Patchwork_9146 CI_DRM_4256: 02a9ddab7c0319d16af25f22f9b15b271e6bbc8f @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4500: 43f7a746ac092e41d4745ed190d4268ef1f82c55 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9146: 80dfa4992e8f5c90467e8a9db995a13191933add @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 80dfa4992e8f drm/i915/gvt: fix spelling mistake: "resseting" -> "resetting" == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9146/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
