[Intel-gfx] ✓ Fi.CI.BAT: success for Add support for Gen 11 pipe color features (rev5)
== Series Details ==
Series: Add support for Gen 11 pipe color features (rev5)
URL : https://patchwork.freedesktop.org/series/51408/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5372 -> Patchwork_11205
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_11205 need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11205, 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/51408/revisions/5/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_11205:
### IGT changes ###
Warnings
* igt@kms_busy@basic-flip-a:
- fi-kbl-7567u: SKIP -> PASS +2
Known issues
Here are the changes found in Patchwork_11205 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_hangcheck:
- fi-bwr-2160:PASS -> DMESG-FAIL [fdo#108735]
* igt@kms_busy@basic-flip-b:
- fi-gdg-551: PASS -> FAIL [fdo#103182]
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: PASS -> FAIL [fdo#108767]
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: PASS -> DMESG-WARN [fdo#102614]
- fi-byt-clapper: PASS -> FAIL [fdo#103167]
Possible fixes
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b:
- fi-byt-clapper: FAIL [fdo#107362] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#108735]: https://bugs.freedesktop.org/show_bug.cgi?id=108735
[fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767
[fdo#108915]: https://bugs.freedesktop.org/show_bug.cgi?id=108915
[fdo#109241]: https://bugs.freedesktop.org/show_bug.cgi?id=109241
Participating hosts (48 -> 45)
--
Additional (1): fi-icl-y
Missing(4): fi-kbl-7560u fi-byt-squawks fi-bsw-cyan fi-ilk-m540
Build changes
-
* Linux: CI_DRM_5372 -> Patchwork_11205
CI_DRM_5372: 5d1d46df77190f1702e3417e9bf9091c9242fd4a @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4756: 75081c6bfb9998bd7cbf35a7ac0578c683fe55a8 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11205: e87cbe12496ca89a000c362e2a576c85836f23a2 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
e87cbe12496c drm/i915/icl: Add degamma and gamma lut size to gen11 caps
3dbc64967efa drm/i915/icl: Enable ICL Pipe CSC block
749868f3f974 drm/i915/icl: Add icl pipe degamma and gamma support
f9a2b86dd563 drm/i915: Remove gamma_mode state variable
167453134516 drm/i915: Sanitize crtc gamma mode
6036b681a025 drm/i915: Check for Null for color lut callbacks
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11205/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/cnl: Fix CNL macros for Voltage Swing programming
On Mon, 07 Jan 2019, Aditya Swarup wrote:
> On Mon, Dec 31, 2018 at 11:03:22AM +0200, Jani Nikula wrote:
>> On Fri, 14 Dec 2018, Aditya Swarup wrote:
>> > CNL macros for register groups CNL_PORT_TX_DW2_* / CNL_PORT_TX_DW5_* are
>> > configured incorrectly wrt definition of _CNL_PORT_TX_DW_GRP.
>>
>> What a mess.
>>
>> Please fix this by making CNL and ICL macros behave the same way. It's
>> silly to have the macro args reversed between them. I think dw first,
>> port second.
>>
>> BR,
>> Jani.
>
> I believe it should be the other way round for the macros to make sense.
> Port first, followed by dw and then ln. For example we can see in the
> following
> macro expansion:
> #define _ICL_PORT_CL_DW(dw, port) (_ICL_COMBOPHY(port) + \
> 4 * (dw))
>
> port is used before dw and we should follow that sequence.
It's not about the usage, it's about semantics. We group primarily by
function, secondarily by port/pipe/transcoder.
BR,
Jani.
>
> I have another patch ready which makes ICL macros consistent with CNL
> macros if you approve the sequence of (port, dw, ln).
>
> Let me know if you agree.
>
> Regards,
> Aditya Swarup
>>
>>
>> >
>> > Cc: Clint Taylor
>> > Cc: Imre Deak
>> > Signed-off-by: Aditya Swarup
>> > ---
>> > drivers/gpu/drm/i915/i915_reg.h | 8
>> > 1 file changed, 4 insertions(+), 4 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> > b/drivers/gpu/drm/i915/i915_reg.h
>> > index 0796526dc10f..db1332cd9dcd 100644
>> > --- a/drivers/gpu/drm/i915/i915_reg.h
>> > +++ b/drivers/gpu/drm/i915/i915_reg.h
>> > @@ -1836,8 +1836,8 @@ enum i915_power_well_id {
>> > #define _ICL_PORT_TX_DW_LN(dw, ln, port) (_ICL_COMBOPHY(port) + \
>> > _ICL_PORT_TX_LN(ln) + 4 * (dw))
>> >
>> > -#define CNL_PORT_TX_DW2_GRP(port) _MMIO(_CNL_PORT_TX_DW_GRP(2, port))
>> > -#define CNL_PORT_TX_DW2_LN0(port) _MMIO(_CNL_PORT_TX_DW_LN0(2, port))
>> > +#define CNL_PORT_TX_DW2_GRP(port) _MMIO(_CNL_PORT_TX_DW_GRP(port, 2))
>> > +#define CNL_PORT_TX_DW2_LN0(port) _MMIO(_CNL_PORT_TX_DW_LN0(port, 2))
>> > #define ICL_PORT_TX_DW2_AUX(port) _MMIO(_ICL_PORT_TX_DW_AUX(2, port))
>> > #define ICL_PORT_TX_DW2_GRP(port) _MMIO(_ICL_PORT_TX_DW_GRP(2, port))
>> > #define ICL_PORT_TX_DW2_LN0(port) _MMIO(_ICL_PORT_TX_DW_LN(2, 0, port))
>> > @@ -1869,8 +1869,8 @@ enum i915_power_well_id {
>> > #define CURSOR_COEFF(x) ((x) << 0)
>> > #define CURSOR_COEFF_MASK (0x3F << 0)
>> >
>> > -#define CNL_PORT_TX_DW5_GRP(port) _MMIO(_CNL_PORT_TX_DW_GRP(5, port))
>> > -#define CNL_PORT_TX_DW5_LN0(port) _MMIO(_CNL_PORT_TX_DW_LN0(5, port))
>> > +#define CNL_PORT_TX_DW5_GRP(port) _MMIO(_CNL_PORT_TX_DW_GRP(port, 5))
>> > +#define CNL_PORT_TX_DW5_LN0(port) _MMIO(_CNL_PORT_TX_DW_LN0(port, 5))
>> > #define ICL_PORT_TX_DW5_AUX(port) _MMIO(_ICL_PORT_TX_DW_AUX(5, port))
>> > #define ICL_PORT_TX_DW5_GRP(port) _MMIO(_ICL_PORT_TX_DW_GRP(5, port))
>> > #define ICL_PORT_TX_DW5_LN0(port) _MMIO(_ICL_PORT_TX_DW_LN(5, 0, port))
>>
>> --
>> Jani Nikula, Intel Open Source Graphics Center
--
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] [v2 14/14] drivers/video: Constantify function argument for HDMI infoframe log
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Sharma, Shashank
>Sent: Friday, December 21, 2018 2:28 PM
>To: Shankar, Uma ; intel-gfx@lists.freedesktop.org;
>dri-de...@lists.freedesktop.org
>Cc: Syrjala, Ville ; Lankhorst, Maarten
>
>Subject: Re: [v2 14/14] drivers/video: Constantify function argument for HDMI
>infoframe log
>
>Regards
>
>Shashank
>
>
>On 12/12/2018 2:08 AM, Uma Shankar wrote:
>> From: Ville Syrjälä
>>
>> Function argument for hdmi_drm_infoframe_log is made constant.
>>
>> Signed-off-by: Ville Syrjälä
>> Signed-off-by: Uma Shankar
>> ---
>> drivers/video/hdmi.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c index
>> 0937c8c..7ab8086 100644
>> --- a/drivers/video/hdmi.c
>> +++ b/drivers/video/hdmi.c
>> @@ -1383,8 +1383,8 @@ static void hdmi_audio_infoframe_log(const char
>*level,
>>* @frame: HDMI DRM infoframe
>>*/
>> static void hdmi_drm_infoframe_log(const char *level,
>> - struct device *dev,
>> - struct hdmi_drm_infoframe *frame)
>> + struct device *dev,
>> + const struct hdmi_drm_infoframe *frame)
>Why not merge this patch with 8/14 drm: Enable HDR infoframe support ?
Will update this.
Thanks Shashank for the review and valuable comments.
Regards,
Uma Shankar
>- Shashank
>> {
>> int i;
>>
>
>___
>dri-devel mailing list
>dri-de...@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/cnl: Fix CNL macros for Voltage Swing programming
On Mon, Dec 31, 2018 at 11:03:22AM +0200, Jani Nikula wrote:
> On Fri, 14 Dec 2018, Aditya Swarup wrote:
> > CNL macros for register groups CNL_PORT_TX_DW2_* / CNL_PORT_TX_DW5_* are
> > configured incorrectly wrt definition of _CNL_PORT_TX_DW_GRP.
>
> What a mess.
>
> Please fix this by making CNL and ICL macros behave the same way. It's
> silly to have the macro args reversed between them. I think dw first,
> port second.
>
> BR,
> Jani.
I believe it should be the other way round for the macros to make sense.
Port first, followed by dw and then ln. For example we can see in the following
macro expansion:
#define _ICL_PORT_CL_DW(dw, port) (_ICL_COMBOPHY(port) + \
4 * (dw))
port is used before dw and we should follow that sequence.
I have another patch ready which makes ICL macros consistent with CNL
macros if you approve the sequence of (port, dw, ln).
Let me know if you agree.
Regards,
Aditya Swarup
>
>
> >
> > Cc: Clint Taylor
> > Cc: Imre Deak
> > Signed-off-by: Aditya Swarup
> > ---
> > drivers/gpu/drm/i915/i915_reg.h | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 0796526dc10f..db1332cd9dcd 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -1836,8 +1836,8 @@ enum i915_power_well_id {
> > #define _ICL_PORT_TX_DW_LN(dw, ln, port) (_ICL_COMBOPHY(port) + \
> > _ICL_PORT_TX_LN(ln) + 4 * (dw))
> >
> > -#define CNL_PORT_TX_DW2_GRP(port) _MMIO(_CNL_PORT_TX_DW_GRP(2, port))
> > -#define CNL_PORT_TX_DW2_LN0(port) _MMIO(_CNL_PORT_TX_DW_LN0(2, port))
> > +#define CNL_PORT_TX_DW2_GRP(port) _MMIO(_CNL_PORT_TX_DW_GRP(port, 2))
> > +#define CNL_PORT_TX_DW2_LN0(port) _MMIO(_CNL_PORT_TX_DW_LN0(port, 2))
> > #define ICL_PORT_TX_DW2_AUX(port) _MMIO(_ICL_PORT_TX_DW_AUX(2, port))
> > #define ICL_PORT_TX_DW2_GRP(port) _MMIO(_ICL_PORT_TX_DW_GRP(2, port))
> > #define ICL_PORT_TX_DW2_LN0(port) _MMIO(_ICL_PORT_TX_DW_LN(2, 0, port))
> > @@ -1869,8 +1869,8 @@ enum i915_power_well_id {
> > #define CURSOR_COEFF(x) ((x) << 0)
> > #define CURSOR_COEFF_MASK(0x3F << 0)
> >
> > -#define CNL_PORT_TX_DW5_GRP(port) _MMIO(_CNL_PORT_TX_DW_GRP(5, port))
> > -#define CNL_PORT_TX_DW5_LN0(port) _MMIO(_CNL_PORT_TX_DW_LN0(5, port))
> > +#define CNL_PORT_TX_DW5_GRP(port) _MMIO(_CNL_PORT_TX_DW_GRP(port, 5))
> > +#define CNL_PORT_TX_DW5_LN0(port) _MMIO(_CNL_PORT_TX_DW_LN0(port, 5))
> > #define ICL_PORT_TX_DW5_AUX(port) _MMIO(_ICL_PORT_TX_DW_AUX(5, port))
> > #define ICL_PORT_TX_DW5_GRP(port) _MMIO(_ICL_PORT_TX_DW_GRP(5, port))
> > #define ICL_PORT_TX_DW5_LN0(port) _MMIO(_ICL_PORT_TX_DW_LN(5, 0, port))
>
> --
> 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] [v5 5/6] drm/i915/icl: Enable ICL Pipe CSC block
Enable ICL pipe csc hardware. CSC block is enabled
in CSC_MODE register instead of PLANE_COLOR_CTL.
ToDO: Extend the ABI to accept 32 bit coefficient values
instead of 16bit for future platforms.
v2: Addressed Maarten's review comments.
v3: Addressed Matt's review comments. Removed rmw patterns
as suggested by Matt.
v4: Addressed Matt's review comments.
v5: Addressed Ville's review comments.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_reg.h| 10 +++---
drivers/gpu/drm/i915/intel_color.c | 12 ++--
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f29eef7..5a262c0 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9861,10 +9861,14 @@ enum skl_power_gate {
#define _PIPE_A_CSC_COEFF_BU 0x4901c
#define _PIPE_A_CSC_COEFF_RV_GV0x49020
#define _PIPE_A_CSC_COEFF_BV 0x49024
+
#define _PIPE_A_CSC_MODE 0x49028
-#define CSC_BLACK_SCREEN_OFFSET (1 << 2)
-#define CSC_POSITION_BEFORE_GAMMA(1 << 1)
-#define CSC_MODE_YUV_TO_RGB (1 << 0)
+#define ICL_CSC_ENABLE(1 << 31)
+#define ICL_OUTPUT_CSC_ENABLE (1 << 30)
+#define CSC_BLACK_SCREEN_OFFSET (1 << 2)
+#define CSC_POSITION_BEFORE_GAMMA (1 << 1)
+#define CSC_MODE_YUV_TO_RGB (1 << 0)
+
#define _PIPE_A_CSC_PREOFF_HI 0x49030
#define _PIPE_A_CSC_PREOFF_ME 0x49034
#define _PIPE_A_CSC_PREOFF_LO 0x49038
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index 9cd4646..c3e4ff6 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -134,7 +134,11 @@ static void ilk_load_ycbcr_conversion_matrix(struct
intel_crtc *crtc)
I915_WRITE(PIPE_CSC_POSTOFF_HI(pipe), POSTOFF_RGB_TO_YUV_HI);
I915_WRITE(PIPE_CSC_POSTOFF_ME(pipe), POSTOFF_RGB_TO_YUV_ME);
I915_WRITE(PIPE_CSC_POSTOFF_LO(pipe), POSTOFF_RGB_TO_YUV_LO);
- I915_WRITE(PIPE_CSC_MODE(pipe), 0);
+
+ if (INTEL_GEN(dev_priv) >= 11)
+ I915_WRITE(PIPE_CSC_MODE(pipe), ICL_OUTPUT_CSC_ENABLE);
+ else
+ I915_WRITE(PIPE_CSC_MODE(pipe), 0);
}
static void ilk_load_csc_matrix(struct intel_crtc_state *crtc_state)
@@ -242,7 +246,10 @@ static void ilk_load_csc_matrix(struct intel_crtc_state
*crtc_state)
I915_WRITE(PIPE_CSC_POSTOFF_ME(pipe), postoff);
I915_WRITE(PIPE_CSC_POSTOFF_LO(pipe), postoff);
- I915_WRITE(PIPE_CSC_MODE(pipe), 0);
+ if (INTEL_GEN(dev_priv) >= 11)
+ I915_WRITE(PIPE_CSC_MODE(pipe), ICL_CSC_ENABLE);
+ else
+ I915_WRITE(PIPE_CSC_MODE(pipe), 0);
} else {
uint32_t mode = CSC_MODE_YUV_TO_RGB;
@@ -700,6 +707,7 @@ void intel_color_init(struct intel_crtc *crtc)
dev_priv->display.load_csc_matrix = ilk_load_csc_matrix;
dev_priv->display.load_luts = glk_load_luts;
} else if (IS_ICELAKE(dev_priv)) {
+ dev_priv->display.load_csc_matrix = ilk_load_csc_matrix;
dev_priv->display.load_luts = icl_load_luts;
} else {
dev_priv->display.load_luts = i9xx_load_luts;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v5 3/6] drm/i915: Remove gamma_mode state variable
Removed crtc state variable for gamma mode as it's
redundant since currently we have fixed modes on respective
hardware platforms. This was making this state variable
irrelevant.
v2: Updated logic to check for split gamma mode. This is moved
to a separate patch and handled as part of intel_sanitize_crtc.
Credits-to: Matt Roper
Signed-off-by: Uma Shankar
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/intel_color.c | 17 -
drivers/gpu/drm/i915/intel_display.c | 3 ---
drivers/gpu/drm/i915/intel_drv.h | 3 ---
3 files changed, 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index 4ff4db6..9a72e64 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -363,25 +363,10 @@ static void haswell_load_luts(struct intel_crtc_state
*crtc_state)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- bool reenable_ips = false;
- /*
-* Workaround : Do not read or write the pipe palette/gamma data while
-* GAMMA_MODE is configured for split gamma and IPS_CTL has IPS enabled.
-*/
- if (IS_HASWELL(dev_priv) && crtc_state->ips_enabled &&
- (crtc_state->gamma_mode == GAMMA_MODE_MODE_SPLIT)) {
- hsw_disable_ips(crtc_state);
- reenable_ips = true;
- }
-
- crtc_state->gamma_mode = GAMMA_MODE_MODE_8BIT;
I915_WRITE(GAMMA_MODE(crtc->pipe), GAMMA_MODE_MODE_8BIT);
i9xx_load_luts(crtc_state);
-
- if (reenable_ips)
- hsw_enable_ips(crtc_state);
}
static void bdw_load_degamma_lut(struct intel_crtc_state *crtc_state)
@@ -476,7 +461,6 @@ static void broadwell_load_luts(struct intel_crtc_state
*crtc_state)
bdw_load_gamma_lut(crtc_state,
INTEL_INFO(dev_priv)->color.degamma_lut_size);
- crtc_state->gamma_mode = GAMMA_MODE_MODE_SPLIT;
I915_WRITE(GAMMA_MODE(pipe), GAMMA_MODE_MODE_SPLIT);
POSTING_READ(GAMMA_MODE(pipe));
@@ -532,7 +516,6 @@ static void glk_load_luts(struct intel_crtc_state
*crtc_state)
bdw_load_gamma_lut(crtc_state, 0);
- crtc_state->gamma_mode = GAMMA_MODE_MODE_10BIT;
I915_WRITE(GAMMA_MODE(pipe), GAMMA_MODE_MODE_10BIT);
POSTING_READ(GAMMA_MODE(pipe));
}
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 03c8f68..8bd47e2 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9699,9 +9699,6 @@ static bool haswell_get_pipe_config(struct intel_crtc
*crtc,
intel_get_pipe_src_size(crtc, pipe_config);
intel_get_crtc_ycbcr_config(crtc, pipe_config);
- pipe_config->gamma_mode =
- I915_READ(GAMMA_MODE(crtc->pipe)) & GAMMA_MODE_MODE_MASK;
-
power_domain = POWER_DOMAIN_PIPE_PANEL_FITTER(crtc->pipe);
if (intel_display_power_get_if_enabled(dev_priv, power_domain)) {
power_domain_mask |= BIT_ULL(power_domain);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 1a11c2be..048090d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -924,9 +924,6 @@ struct intel_crtc_state {
struct intel_crtc_wm_state wm;
- /* Gamma mode programmed on the pipe */
- uint32_t gamma_mode;
-
/* bitmask of visible planes (enum plane_id) */
u8 active_planes;
u8 nv12_planes;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v5 0/6] Add support for Gen 11 pipe color features
This patch series adds support for Gen11 pipe degamma, CSC and gamma hardware blocks. CRC checks are not working for 10bit gamma but works for 8bit pallete modes which seems to be due to some rounding errors in pipe. ToDo: Support for Multi Segmented Gamma will be added later. v2: Addressed Maarten's review comments and re-ordered the patch series. v3: Addressed Matt's review comments. Removed rmw patterns as suggested by Matt. v4: Addressed Matt's review comments. v5: Addressed Matt's, Ville and Jani Nikula's review comments. Uma Shankar (6): drm/i915: Check for Null for color lut callbacks drm/i915: Sanitize crtc gamma mode drm/i915: Remove gamma_mode state variable drm/i915/icl: Add icl pipe degamma and gamma support drm/i915/icl: Enable ICL Pipe CSC block drm/i915/icl: Add degamma and gamma lut size to gen11 caps drivers/gpu/drm/i915/i915_pci.c | 3 +- drivers/gpu/drm/i915/i915_reg.h | 22 +--- drivers/gpu/drm/i915/intel_color.c | 97 drivers/gpu/drm/i915/intel_display.c | 20 ++-- drivers/gpu/drm/i915/intel_drv.h | 3 -- 5 files changed, 110 insertions(+), 35 deletions(-) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v5 6/6] drm/i915/icl: Add degamma and gamma lut size to gen11 caps
Add the degamma and gamma lut sizes to gen11 capability
structure.
Note: Currently this doesn't account for the extended range gamma
entries and this will be addressed with new segmented gamma ABI
in a future patch.
v2: Reorder the patch as per Maarten's suggestion.
v3: Rebase
v4: Updated commit message with a note as per Matt's suggestion.
v5: No Change.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_pci.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index dd4aff2..14e5bb4 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -639,7 +639,8 @@
}, \
GEN(11), \
.ddb_size = 2048, \
- .has_logical_ring_elsq = 1
+ .has_logical_ring_elsq = 1, \
+ .color = { .degamma_lut_size = 33, .gamma_lut_size = 1024 }
static const struct intel_device_info intel_icelake_11_info = {
GEN11_FEATURES,
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v5 4/6] drm/i915/icl: Add icl pipe degamma and gamma support
Add support for icl pipe degamma and gamma.
v2: Removed a POSTING_READ and corrected the Bit
Definition as per Maarten's comments.
v3: Addressed Matt's review comments. Removed rmw patterns
as suggested by Matt.
v4: Fixed Matt's review comments.
v5: Corrected macro alignment as per Jani Nikula's comments.
Addressed Ville and Matt's review comments.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_reg.h| 12 ---
drivers/gpu/drm/i915/intel_color.c | 65 ++
2 files changed, 72 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 44958d9..f29eef7 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7088,11 +7088,13 @@ enum {
#define _GAMMA_MODE_A 0x4a480
#define _GAMMA_MODE_B 0x4ac80
#define GAMMA_MODE(pipe) _MMIO_PIPE(pipe, _GAMMA_MODE_A, _GAMMA_MODE_B)
-#define GAMMA_MODE_MODE_MASK (3 << 0)
-#define GAMMA_MODE_MODE_8BIT (0 << 0)
-#define GAMMA_MODE_MODE_10BIT (1 << 0)
-#define GAMMA_MODE_MODE_12BIT (2 << 0)
-#define GAMMA_MODE_MODE_SPLIT (3 << 0)
+#define PRE_CSC_GAMMA_ENABLE (1 << 31)
+#define POST_CSC_GAMMA_ENABLE (1 << 30)
+#define GAMMA_MODE_MODE_MASK (3 << 0)
+#define GAMMA_MODE_MODE_8BIT (0 << 0)
+#define GAMMA_MODE_MODE_10BIT (1 << 0)
+#define GAMMA_MODE_MODE_12BIT (2 << 0)
+#define GAMMA_MODE_MODE_SPLIT (3 << 0)
/* DMC/CSR */
#define CSR_PROGRAM(i) _MMIO(0x8 + (i) * 4)
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index 9a72e64..9cd4646 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -520,6 +520,69 @@ static void glk_load_luts(struct intel_crtc_state
*crtc_state)
POSTING_READ(GAMMA_MODE(pipe));
}
+static void icl_load_degamma_lut(struct intel_crtc_state *crtc_state)
+{
+ struct drm_device *dev = crtc_state->base.crtc->dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ enum pipe pipe = to_intel_crtc(crtc_state->base.crtc)->pipe;
+ const uint32_t lut_size = INTEL_INFO(dev_priv)->color.degamma_lut_size;
+ uint32_t i;
+
+ /*
+* When setting the auto-increment bit, the hardware seems to
+* ignore the index bits, so we need to reset it to index 0
+* separately.
+*/
+ I915_WRITE(PRE_CSC_GAMC_INDEX(pipe), 0);
+ I915_WRITE(PRE_CSC_GAMC_INDEX(pipe), PRE_CSC_GAMC_AUTO_INCREMENT);
+
+ if (crtc_state->base.degamma_lut) {
+ struct drm_color_lut *lut = crtc_state->base.degamma_lut->data;
+
+ for (i = 0; i < lut_size; i++) {
+ /*
+* First 33 entries represent range from 0 to 1.0
+* 34th and 35th entry will represent extended range
+* inputs 3.0 and 7.0 respectively, currently clamped
+* at 1.0. Since the precision is 16bit, the user value
+* can be directly filled to register.
+* ToDo: Extend to max 7.0.
+*/
+ I915_WRITE(PRE_CSC_GAMC_DATA(pipe), lut[i].green);
+ }
+ } else {
+ /* load a linear table. */
+ for (i = 0; i < lut_size; i++) {
+ uint32_t v = (i * (1 << 16)) / (lut_size - 1);
+
+ I915_WRITE(PRE_CSC_GAMC_DATA(pipe), v);
+ }
+ }
+
+ /* Clamp values > 1.0. */
+ while (i++ < 35)
+ I915_WRITE(PRE_CSC_GAMC_DATA(pipe), (1 << 16));
+}
+
+static void icl_load_luts(struct intel_crtc_state *crtc_state)
+{
+ struct drm_crtc *crtc = crtc_state->base.crtc;
+ struct drm_device *dev = crtc_state->base.crtc->dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ enum pipe pipe = to_intel_crtc(crtc)->pipe;
+
+ if (crtc_state_is_legacy_gamma(crtc_state)) {
+ haswell_load_luts(crtc_state);
+ return;
+ }
+
+ icl_load_degamma_lut(crtc_state);
+ bdw_load_gamma_lut(crtc_state, 0);
+
+ I915_WRITE(GAMMA_MODE(pipe), GAMMA_MODE_MODE_10BIT |
+ PRE_CSC_GAMMA_ENABLE | POST_CSC_GAMMA_ENABLE);
+}
+
/* Loads the palette/gamma unit for the CRTC on CherryView. */
static void cherryview_load_luts(struct intel_crtc_state *crtc_state)
{
@@ -636,6 +699,8 @@ void intel_color_init(struct intel_crtc *crtc)
} else if (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) {
dev_priv->display.load_csc_matrix = ilk_load_csc_matrix;
dev_priv->display.load_luts = glk_load_luts;
+ } else if (IS_ICELAKE(dev_priv)) {
+ dev_priv->display.load_luts = icl_load_luts;
} else {
dev_priv->display.load_luts = i9xx_load_luts;
}
--
1.9.1
___
Intel-gfx mailing list
I
[Intel-gfx] [v5 1/6] drm/i915: Check for Null for color lut callbacks
Check if de-gamma/gamma lut callback is assigned before calling the same. Signed-off-by: Uma Shankar --- drivers/gpu/drm/i915/intel_color.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_color.c b/drivers/gpu/drm/i915/intel_color.c index 37fd9dd..4ff4db6 100644 --- a/drivers/gpu/drm/i915/intel_color.c +++ b/drivers/gpu/drm/i915/intel_color.c @@ -602,7 +602,8 @@ void intel_color_load_luts(struct intel_crtc_state *crtc_state) struct drm_device *dev = crtc_state->base.crtc->dev; struct drm_i915_private *dev_priv = to_i915(dev); - dev_priv->display.load_luts(crtc_state); + if (dev_priv->display.load_luts) + dev_priv->display.load_luts(crtc_state); } int intel_color_check(struct intel_crtc_state *crtc_state) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v5 2/6] drm/i915: Sanitize crtc gamma mode
Sanitize crtc gamma mode and update the mode in driver in case
BIOS has setup a different gamma mode as to what is expected by
driver. There is restriction on HSW platform not to read/write
color LUT's if ips is enabled. Handled the same accordingly.
Credits-to: Matt Roper
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_display.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 696e6f5..03c8f68 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15401,6 +15401,23 @@ static void intel_sanitize_crtc(struct intel_crtc
*crtc,
}
}
+ /*
+* Sanitize gamma mode incase BIOS leaves it in SPLIT GAMMA MODE
+* Workaround HSW : Do not read or write the pipe palette/gamma data
+* while GAMMA_MODE is configured for split gamma and IPS_CTL has IPS
+* enabled.
+*/
+ if (IS_HASWELL(dev_priv)) {
+ if (crtc_state->ips_enabled)
+ hsw_disable_ips(crtc_state);
+
+ intel_color_set_csc(crtc_state);
+ intel_color_load_luts(crtc_state);
+
+ if (crtc_state->ips_enabled)
+ hsw_enable_ips(crtc_state);
+ }
+
/* Adjust the state of the output pipe according to whether we
* have active connectors/encoders. */
if (crtc_state->base.active && !intel_crtc_has_encoders(crtc))
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v2 04/14] drm: Parse Colorimetry data block from EDID
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Sharma, Shashank
>Sent: Tuesday, January 8, 2019 12:27 PM
>To: Shankar, Uma ; intel-gfx@lists.freedesktop.org;
>dri-de...@lists.freedesktop.org
>Cc: Syrjala, Ville ; Lankhorst, Maarten
>
>Subject: Re: [v2 04/14] drm: Parse Colorimetry data block from EDID
>
>
>
>On 1/8/2019 12:10 PM, Shankar, Uma wrote:
>>
>>> -Original Message-
>>> From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On
>>> Behalf Of Sharma, Shashank
>>> Sent: Thursday, December 20, 2018 11:54 PM
>>> To: Shankar, Uma ;
>>> intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
>>> Cc: Syrjala, Ville ; Lankhorst, Maarten
>>>
>>> Subject: Re: [v2 04/14] drm: Parse Colorimetry data block from EDID
>>>
>>> Regards
>>>
>>> Shashank
>>>
>>>
>>> On 12/12/2018 2:08 AM, Uma Shankar wrote:
CEA 861.3 spec adds colorimetry data block for HDMI.
Parsing the block to get the colorimetry data from panel.
v2: Rebase
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_edid.c | 24
include/drm/drm_connector.h | 2 ++
2 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index d12b74e..344d8c1 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3818,6 +3818,28 @@ static void
fixup_detailed_cea_mode_clock(struct
>>> drm_display_mode *mode)
mode->clock = clock;
}
+static bool cea_db_is_hdmi_colorimetry_data_block(const u8 *db) {
+ if (cea_db_tag(db) != DATA_BLOCK_EXTENDED_TAG)
+ return false;
+
+ if (db[1] != COLORIMETRY_DATA_BLOCK)
+
>>> Again, the COLORIMETRY_DATA_BLOCK definition should be added into
>>> this patch.
>> Ok, will do that.
>>
return false;
+
+ return true;
+}
+
+static void
+drm_parse_colorimetry_data_block(struct drm_connector *connector,
+const u8 *db) {
+ struct drm_hdmi_info *info = &connector->display_info.hdmi;
+ uint16_t len;
+
+ len = cea_db_payload_len(db);
>>> Again, the return value of this function doesn't account for extended
>>> db tag byte, so what we are looking for is len -1
>> Will update this.
>>
+ info->colorimetry = db[2];
>>> colorimetry block is actually db[2] and db[3].bit7 (which represents
>>> DCI-P3 space), so we probably want to make info->colorimetryuint16_t
>> 3 BT2020RGB BT2020YCC BT2020cYCC AdobeRGB AdobeYCC601 sYCC601
>xvYCC709
>> xvYCC601
>> 4 F47=0 F46=0 F45=0 F44=0 MD3 MD2 MD1 MD0
>>
>> This is how db[2] and db[3] is described in spec. There is not much
>> clarity on F47. Not sure if they are for DCI-P3, can you clarify once.
>Ah, check CEA-861-G table 70, there there is no F47, but I could see
>DCI-P3 in that place, which spec is that you are following right now ?
I am looking to 861-F. So seems like its updated in 861-G ?
Regards,
Uma Shankar
>- Shashank
>> Regards,
>> Uma Shankar
>>
+}
+
+
static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db)
{
if (cea_db_tag(db) != DATA_BLOCK_EXTENDED_TAG) @@ -4513,6
>>> +4535,8
@@ static void drm_parse_cea_ext(struct drm_connector *connector,
drm_parse_y420cmdb_bitmap(connector, db);
if (cea_db_is_hdmi_hdr_metadata_block(db))
drm_parse_hdr_metadata_block(connector, db);
+ if (cea_db_is_hdmi_colorimetry_data_block(db))
+ drm_parse_colorimetry_data_block(connector, db);
}
}
diff --git a/include/drm/drm_connector.h
b/include/drm/drm_connector.h index 2ee45dc..90ce364 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -206,6 +206,8 @@ struct drm_hdmi_info {
/** @y420_dc_modes: bitmap of deep color support index */
u8 y420_dc_modes;
+
>>> Please add a one line description about this variable.
>> Sure will update this.
>>
+ u8 colorimetry;
};
/**
>>> Shashank
>>> ___
>>> dri-devel mailing list
>>> dri-de...@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>___
>dri-devel mailing list
>dri-de...@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v2 11/14] drm/i915: Add HLG EOTF
>-Original Message-
>From: Sharma, Shashank
>Sent: Friday, December 21, 2018 2:17 PM
>To: Shankar, Uma ; intel-gfx@lists.freedesktop.org;
>dri-de...@lists.freedesktop.org
>Cc: Lankhorst, Maarten ; Syrjala, Ville
>; brian.star...@arm.com; Ville Syrjälä
>
>Subject: Re: [v2 11/14] drm/i915: Add HLG EOTF
>
>Regards
>
>Shashank
>
>
>On 12/12/2018 2:08 AM, Uma Shankar wrote:
>> From: Ville Syrjälä
>>
>> ADD HLG EOTF to the list of EOTF transfer functions supported.
>Would it be possible to add some details about HLG ?
Sure, will add that.
Regards,
Uma Shankar
>>
>> Signed-off-by: Ville Syrjälä
>> Signed-off-by: Uma Shankar
>> ---
>> drivers/gpu/drm/drm_edid.c | 4 ++--
>> include/linux/hdmi.h | 1 +
>> 2 files changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index 5a7fc9b..fa86494 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -3857,8 +3857,8 @@ static uint16_t eotf_supported(const u8 *edid_ext)
>> return edid_ext[2] &
>> (BIT(HDMI_EOTF_TRADITIONAL_GAMMA_SDR) |
>> BIT(HDMI_EOTF_TRADITIONAL_GAMMA_HDR) |
>> - BIT(HDMI_EOTF_SMPTE_ST2084));
>> -
>> + BIT(HDMI_EOTF_SMPTE_ST2084) |
>> + BIT(HDMI_EOTF_BT_2100_HLG));
>> }
>>
>> static uint16_t hdr_metadata_type(const u8 *edid_ext)
>> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
>> index ce00e1e..b5346c3 100644
>> --- a/include/linux/hdmi.h
>> +++ b/include/linux/hdmi.h
>> @@ -146,6 +146,7 @@ enum hdmi_eotf {
>> HDMI_EOTF_TRADITIONAL_GAMMA_SDR,
>> HDMI_EOTF_TRADITIONAL_GAMMA_HDR,
>> HDMI_EOTF_SMPTE_ST2084,
>> +HDMI_EOTF_BT_2100_HLG,
>> };
>>
>> struct hdmi_avi_infoframe {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v2 04/14] drm: Parse Colorimetry data block from EDID
On 1/8/2019 12:10 PM, Shankar, Uma wrote:
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Sharma, Shashank
Sent: Thursday, December 20, 2018 11:54 PM
To: Shankar, Uma ; intel-gfx@lists.freedesktop.org;
dri-de...@lists.freedesktop.org
Cc: Syrjala, Ville ; Lankhorst, Maarten
Subject: Re: [v2 04/14] drm: Parse Colorimetry data block from EDID
Regards
Shashank
On 12/12/2018 2:08 AM, Uma Shankar wrote:
CEA 861.3 spec adds colorimetry data block for HDMI.
Parsing the block to get the colorimetry data from panel.
v2: Rebase
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_edid.c | 24
include/drm/drm_connector.h | 2 ++
2 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index d12b74e..344d8c1 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3818,6 +3818,28 @@ static void fixup_detailed_cea_mode_clock(struct
drm_display_mode *mode)
mode->clock = clock;
}
+static bool cea_db_is_hdmi_colorimetry_data_block(const u8 *db) {
+ if (cea_db_tag(db) != DATA_BLOCK_EXTENDED_TAG)
+ return false;
+
+ if (db[1] != COLORIMETRY_DATA_BLOCK)
+
Again, the COLORIMETRY_DATA_BLOCK definition should be added into this
patch.
Ok, will do that.
return false;
+
+ return true;
+}
+
+static void
+drm_parse_colorimetry_data_block(struct drm_connector *connector,
+const u8 *db) {
+ struct drm_hdmi_info *info = &connector->display_info.hdmi;
+ uint16_t len;
+
+ len = cea_db_payload_len(db);
Again, the return value of this function doesn't account for extended db tag
byte,
so what we are looking for is len -1
Will update this.
+ info->colorimetry = db[2];
colorimetry block is actually db[2] and db[3].bit7 (which represents
DCI-P3 space), so we probably want to make info->colorimetryuint16_t
3 BT2020RGB BT2020YCC BT2020cYCC AdobeRGB AdobeYCC601 sYCC601 xvYCC709 xvYCC601
4 F47=0 F46=0 F45=0 F44=0 MD3 MD2 MD1 MD0
This is how db[2] and db[3] is described in spec. There is not much clarity on
F47. Not sure if they
are for DCI-P3, can you clarify once.
Ah, check CEA-861-G table 70, there there is no F47, but I could see
DCI-P3 in that place, which spec is that you are following right now ?
- Shashank
Regards,
Uma Shankar
+}
+
+
static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db)
{
if (cea_db_tag(db) != DATA_BLOCK_EXTENDED_TAG) @@ -4513,6
+4535,8
@@ static void drm_parse_cea_ext(struct drm_connector *connector,
drm_parse_y420cmdb_bitmap(connector, db);
if (cea_db_is_hdmi_hdr_metadata_block(db))
drm_parse_hdr_metadata_block(connector, db);
+ if (cea_db_is_hdmi_colorimetry_data_block(db))
+ drm_parse_colorimetry_data_block(connector, db);
}
}
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 2ee45dc..90ce364 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -206,6 +206,8 @@ struct drm_hdmi_info {
/** @y420_dc_modes: bitmap of deep color support index */
u8 y420_dc_modes;
+
Please add a one line description about this variable.
Sure will update this.
+ u8 colorimetry;
};
/**
Shashank
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v2 09/14] drm/i915: Write HDR infoframe and send to panel
>-Original Message-
>From: Sharma, Shashank
>Sent: Friday, December 21, 2018 2:14 PM
>To: Shankar, Uma ; intel-gfx@lists.freedesktop.org;
>dri-de...@lists.freedesktop.org
>Cc: Lankhorst, Maarten ; Syrjala, Ville
>; brian.star...@arm.com
>Subject: Re: [v2 09/14] drm/i915: Write HDR infoframe and send to panel
>
>Regards
>
>Shashank
>
>
>On 12/12/2018 2:08 AM, Uma Shankar wrote:
>> Enable writing of HDR metadata infoframe to panel.
>> The data will be provid by usersapace compositors, based on blending
>> policies and passsed to driver through a blob property.
>>
>> v2: Rebase
>>
>> Signed-off-by: Uma Shankar
>> ---
>> drivers/gpu/drm/i915/intel_hdmi.c | 27 +++
>> 1 file changed, 27 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
>> b/drivers/gpu/drm/i915/intel_hdmi.c
>> index 8a1e5cb..6286c4a 100644
>> --- a/drivers/gpu/drm/i915/intel_hdmi.c
>> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
>> @@ -475,6 +475,29 @@ static void intel_write_infoframe(struct intel_encoder
>*encoder,
>> frame->any.type, buffer, len);
>> }
>>
>> +/* Set Dynamic Range and Mastering Infoframe */ static void
>> +intel_hdmi_set_drm_infoframe(struct drm_encoder *encoder,
>> + const struct intel_crtc_state
>> + *crtc_state,
>> + const struct drm_connector_state
>> +
>We will need this function for lspcon too, if you want to add in a different
>series,
>please add a TODO: here.
Sure, will add the same.
Regards,
Uma Shankar
>> *conn_state)
>> +{
>> +union hdmi_infoframe frame;
>> +struct hdr_static_metadata *hdr_metadata;
>> +int ret;
>> +
>> +hdr_metadata = (struct hdr_static_metadata *)
>> +conn_state->hdr_source_metadata_blob_ptr->data;
>> +
>> +ret = drm_hdmi_infoframe_set_hdr_metadata(&frame.drm,
>hdr_metadata);
>> +if (ret < 0) {
>> +DRM_ERROR("couldn't set HDR metadata in infoframe\n");
>> +return;
>> +}
>> +
>> +intel_write_infoframe(encoder, crtc_state, &frame); }
>> +
>> static void intel_hdmi_set_avi_infoframe(struct intel_encoder *encoder,
>> const struct intel_crtc_state
>*crtc_state,
>> const struct drm_connector_state
>*conn_state) @@ -883,6
>> +906,10 @@ static void hsw_set_infoframes(struct intel_encoder *encoder,
>> intel_hdmi_set_avi_infoframe(encoder, crtc_state, conn_state);
>> intel_hdmi_set_spd_infoframe(encoder, crtc_state);
>> intel_hdmi_set_hdmi_infoframe(encoder, crtc_state, conn_state);
>> +
>> +/* Set Dynamic Range and Mastering Infoframe if supported and changed
>*/
>> +if (conn_state->hdr_metadata_changed)
>> +intel_hdmi_set_drm_infoframe(encoder, crtc_state,
>conn_state);
>> }
>>
>> void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi *hdmi,
>> bool enable)
>- Shashank
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v2 08/14] drm: Enable HDR infoframe support
>-Original Message-
>From: Sharma, Shashank
>Sent: Friday, December 21, 2018 2:11 PM
>To: Shankar, Uma ; intel-gfx@lists.freedesktop.org;
>dri-de...@lists.freedesktop.org
>Cc: Lankhorst, Maarten ; Syrjala, Ville
>; brian.star...@arm.com
>Subject: Re: [v2 08/14] drm: Enable HDR infoframe support
>
>Regards
>
>Shashank
>
>
>On 12/12/2018 2:08 AM, Uma Shankar wrote:
>> Enable Dynamic Range and Mastering Infoframe for HDR content, which is
>> defined in CEA 861.3 spec.
>>
>> The metadata will be computed based on blending policy in userspace
>> compositors and passed as a connector property blob to driver. The
>> same will be sent as infoframe to panel which support HDR.
>>
>> v2: Rebase and added Ville's POC changes.
>>
>> Signed-off-by: Uma Shankar
>> ---
>> drivers/gpu/drm/drm_edid.c | 58
>> drivers/video/hdmi.c | 129
>+
>> include/drm/drm_edid.h | 4 ++
>> include/linux/hdmi.h | 22
>> 4 files changed, 213 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index 344d8c1..5a7fc9b 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -4916,6 +4916,64 @@ void drm_set_preferred_mode(struct
>drm_connector *connector,
>> EXPORT_SYMBOL(drm_set_preferred_mode);
>>
>> /**
>> + * drm_hdmi_infoframe_set_hdr_metadata() - fill an HDMI AVI infoframe with
>> + * HDR metadata from userspace
>> + * @frame: HDMI AVI infoframe
>> + * @hdr_source_metadata: hdr_source_metadata info from userspace
>> + *
>> + * Return: 0 on success or a negative error code on failure.
>> + */
>> +int
>> +drm_hdmi_infoframe_set_hdr_metadata(struct hdmi_drm_infoframe *frame,
>> +void *hdr_metadata)
>> +{
>> +struct hdr_static_metadata *hdr_source_metadata;
>> +int err, i;
>> +
>> +if (!frame || !hdr_metadata)
>> +return -EINVAL;
>> +
>> +err = hdmi_drm_infoframe_init(frame);
>> +if (err < 0)
>> +return err;
>> +
>> +DRM_DEBUG_KMS("type = %x\n", frame->type);
>> +
>> +hdr_source_metadata = (struct hdr_static_metadata *)hdr_metadata;
>> +
>> +frame->length = sizeof(struct hdr_static_metadata);
>> +
>> +
>> +frame->eotf = hdr_source_metadata->eotf;
>> +frame->metadata_type = hdr_source_metadata->metadata_type;
>> +
>> +for (i = 0; i < 3; i++) {
>> +frame->display_primaries[i].x =
>> +hdr_source_metadata->display_primaries[i].x;
>> +frame->display_primaries[i].y =
>> +hdr_source_metadata->display_primaries[i].y;
>> +}
>> +
>> +frame->white_point.x = hdr_source_metadata->white_point.x;
>> +frame->white_point.y = hdr_source_metadata->white_point.y;
>> +
>> +frame->max_mastering_display_luminance =
>> +hdr_source_metadata->max_mastering_display_luminance;
>> +frame->min_mastering_display_luminance =
>> +hdr_source_metadata->min_mastering_display_luminance;
>> +
>> +frame->max_cll = hdr_source_metadata->max_cll;
>> +frame->max_fall = hdr_source_metadata->max_fall;
>> +
>> +hdmi_infoframe_log(KERN_CRIT, NULL,
>> + (union hdmi_infoframe *)frame);
>> +
>> +return 0;
>> +}
>> +EXPORT_SYMBOL(drm_hdmi_infoframe_set_hdr_metadata);
>> +
>> +
>> +/**
>>* drm_hdmi_avi_infoframe_from_display_mode() - fill an HDMI AVI infoframe
>with
>>* data from a DRM display
>> mode
>>* @frame: HDMI AVI infoframe
>> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c index
>> 799ae49..0937c8c 100644
>> --- a/drivers/video/hdmi.c
>> +++ b/drivers/video/hdmi.c
>> @@ -650,6 +650,93 @@ ssize_t hdmi_vendor_infoframe_pack(struct
>hdmi_vendor_infoframe *frame,
>> return 0;
>> }
>>
>> +/**
>> + * hdmi_drm_infoframe_init() - initialize an HDMI Dynaminc Range and
>> + * mastering infoframe
>> + * @frame: HDMI DRM infoframe
>> + *
>> + * Returns 0 on success or a negative error code on failure.
>> + */
>> +int hdmi_drm_infoframe_init(struct hdmi_drm_infoframe *frame) {
>> +memset(frame, 0, sizeof(*frame));
>> +
>> +frame->type = HDMI_INFOFRAME_TYPE_DRM;
>> +frame->version = 1;
>> +
>> +return 0;
>> +}
>> +EXPORT_SYMBOL(hdmi_drm_infoframe_init);
>> +
>> +/**
>> + * hdmi_drm_infoframe_pack() - write HDMI DRM infoframe to binary
>> +buffer
>> + * @frame: HDMI DRM infoframe
>> + * @buffer: destination buffer
>> + * @size: size of buffer
>> + *
>> + * Packs the information contained in the @frame structure into a
>> +binary
>> + * representation that can be written into the corresponding
>> +controller
>> + * registers. Also computes the checksum as required by section 5.3.5
>> +of
>> + * the HDMI 1.4 specification.
>> + *
>> + * Returns the number of bytes packed into the binary buffer or a
>> +negative
>> + * error code on failure.
>> + */
>>
Re: [Intel-gfx] [v2 07/14] drm: Implement HDR source metadata set and get property handling
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Sharma, Shashank
>Sent: Friday, December 21, 2018 12:04 AM
>To: Shankar, Uma ; intel-gfx@lists.freedesktop.org;
>dri-de...@lists.freedesktop.org
>Cc: Syrjala, Ville ; Lankhorst, Maarten
>
>Subject: Re: [v2 07/14] drm: Implement HDR source metadata set and get
>property handling
>
>Regards
>
>Shashank
>
>
>On 12/12/2018 2:08 AM, Uma Shankar wrote:
>> HDR source metadata set and get property implemented in this patch.
>Again, HDR output metadata ? How about re-arranging the line like "This patch
>implements get() and set() functions for HDR output metadata property" just to
>make it more clear ?
Sure, will update this.
>> The blob data is received from userspace and saved in connector state,
>> the same is returned as blob in get property call to userspace.
>>
>> v2: Rebase and added Ville's POC changes
>>
>> Signed-off-by: Uma Shankar
>> ---
>> drivers/gpu/drm/drm_atomic.c | 2 ++
>> drivers/gpu/drm/drm_atomic_uapi.c | 13 +
>> 2 files changed, 15 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic.c
>> b/drivers/gpu/drm/drm_atomic.c index 5eb4013..4e71c6b 100644
>> --- a/drivers/gpu/drm/drm_atomic.c
>> +++ b/drivers/gpu/drm/drm_atomic.c
>> @@ -881,6 +881,8 @@ static void
>> drm_atomic_connector_print_state(struct drm_printer *p,
>>
>> drm_printf(p, "connector[%u]: %s\n", connector->base.id, connector-
>>name);
>> drm_printf(p, "\tcrtc=%s\n", state->crtc ? state->crtc->name :
>> "(null)");
>> +drm_printf(p, "\thdr_metadata_changed=%d\n",
>> +state->hdr_metadata_changed);
>Alignment
Ok, will update.
>>
>> if (connector->connector_type ==
>DRM_MODE_CONNECTOR_WRITEBACK)
>> if (state->writeback_job && state->writeback_job->fb) diff --git
>> a/drivers/gpu/drm/drm_atomic_uapi.c
>> b/drivers/gpu/drm/drm_atomic_uapi.c
>> index c408898..b721b12 100644
>> --- a/drivers/gpu/drm/drm_atomic_uapi.c
>> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
>> @@ -686,6 +686,8 @@ static int drm_atomic_connector_set_property(struct
>drm_connector *connector,
>> {
>> struct drm_device *dev = connector->dev;
>> struct drm_mode_config *config = &dev->mode_config;
>> +bool replaced = false;
>> +int ret;
>>
>> if (property == config->prop_crtc_id) {
>> struct drm_crtc *crtc = drm_crtc_find(dev, NULL, val); @@ -
>734,6
>> +736,14 @@ static int drm_atomic_connector_set_property(struct
>drm_connector *connector,
>> */
>> if (state->link_status != DRM_LINK_STATUS_GOOD)
>> state->link_status = val;
>> +} else if (property == config->hdr_source_metadata_property) {
>> +ret = drm_atomic_replace_property_blob_from_id(dev,
>> +&state->hdr_source_metadata_blob_ptr,
>> +val,
>> +-1, sizeof(struct hdr_static_metadata),
>> +&replaced);
>Alignment, but I know it might be difficult to contain the params within
>80 chars.
Yeah, not sure what is higher priority - 80 character limit or the
alignment here. Currently went with 80 character limit.
Regards,
Uma Shankar
>> +state->hdr_metadata_changed |= replaced;
>> +return ret;
>> } else if (property == config->aspect_ratio_property) {
>> state->picture_aspect_ratio = val;
>> } else if (property == config->content_type_property) { @@ -816,6
>> +826,9 @@ static int drm_atomic_connector_set_property(struct
>drm_connector *connector,
>> *val = state->content_type;
>> } else if (property == connector->scaling_mode_property) {
>> *val = state->scaling_mode;
>> +} else if (property == config->hdr_source_metadata_property) {
>> +*val = (state->hdr_source_metadata_blob_ptr) ?
>> +state->hdr_source_metadata_blob_ptr->base.id : 0;
>> } else if (property == connector->content_protection_property) {
>> *val = state->content_protection;
>> } else if (property == config->writeback_fb_id_property) {
>- Shashank
>___
>dri-devel mailing list
>dri-de...@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v2 05/14] drm/i915: Attach HDR metadata property to connector
>-Original Message- >From: Sharma, Shashank >Sent: Thursday, December 20, 2018 11:56 PM >To: Shankar, Uma ; intel-gfx@lists.freedesktop.org; >dri-de...@lists.freedesktop.org >Cc: Lankhorst, Maarten ; Syrjala, Ville >; brian.star...@arm.com >Subject: Re: [v2 05/14] drm/i915: Attach HDR metadata property to connector > >Regards > >Shashank > > >On 12/12/2018 2:08 AM, Uma Shankar wrote: >> Attach HDR metadata property to connector object. >> >> v2: Rebase >> >> Signed-off-by: Uma Shankar >> --- >> drivers/gpu/drm/i915/intel_hdmi.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c >b/drivers/gpu/drm/i915/intel_hdmi.c >> index 07e803a..8a1e5cb 100644 >> --- a/drivers/gpu/drm/i915/intel_hdmi.c >> +++ b/drivers/gpu/drm/i915/intel_hdmi.c >> @@ -2154,6 +2154,8 @@ static void intel_hdmi_destroy(struct drm_connector >*connector) >> intel_attach_aspect_ratio_property(connector); >> drm_connector_attach_content_type_property(connector); >> connector->state->picture_aspect_ratio = >HDMI_PICTURE_ASPECT_NONE; >> +drm_object_attach_property(&connector->base, >> +connector->dev->mode_config.hdr_source_metadata_property, >0); >Alignment with line above missing. It's just to keep it within 80 characters. Hope this is ok. Not sure whether this alignment or 80 character limit takes more priority. Regards, Uma Shankar >- Shashank >> >> if (!HAS_GMCH_DISPLAY(dev_priv)) >> drm_connector_attach_max_bpc_property(connector, 8, 12); ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v2 04/14] drm: Parse Colorimetry data block from EDID
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Sharma, Shashank
>Sent: Thursday, December 20, 2018 11:54 PM
>To: Shankar, Uma ; intel-gfx@lists.freedesktop.org;
>dri-de...@lists.freedesktop.org
>Cc: Syrjala, Ville ; Lankhorst, Maarten
>
>Subject: Re: [v2 04/14] drm: Parse Colorimetry data block from EDID
>
>Regards
>
>Shashank
>
>
>On 12/12/2018 2:08 AM, Uma Shankar wrote:
>> CEA 861.3 spec adds colorimetry data block for HDMI.
>> Parsing the block to get the colorimetry data from panel.
>>
>> v2: Rebase
>>
>> Signed-off-by: Uma Shankar
>> ---
>> drivers/gpu/drm/drm_edid.c | 24
>> include/drm/drm_connector.h | 2 ++
>> 2 files changed, 26 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index d12b74e..344d8c1 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -3818,6 +3818,28 @@ static void fixup_detailed_cea_mode_clock(struct
>drm_display_mode *mode)
>> mode->clock = clock;
>> }
>>
>> +static bool cea_db_is_hdmi_colorimetry_data_block(const u8 *db) {
>> +if (cea_db_tag(db) != DATA_BLOCK_EXTENDED_TAG)
>> +return false;
>> +
>> +if (db[1] != COLORIMETRY_DATA_BLOCK)
>> +
>Again, the COLORIMETRY_DATA_BLOCK definition should be added into this
>patch.
Ok, will do that.
>> return false;
>> +
>> +return true;
>> +}
>> +
>> +static void
>> +drm_parse_colorimetry_data_block(struct drm_connector *connector,
>> +const u8 *db) {
>> +struct drm_hdmi_info *info = &connector->display_info.hdmi;
>> +uint16_t len;
>> +
>> +len = cea_db_payload_len(db);
>Again, the return value of this function doesn't account for extended db tag
>byte,
>so what we are looking for is len -1
Will update this.
>> +info->colorimetry = db[2];
>colorimetry block is actually db[2] and db[3].bit7 (which represents
>DCI-P3 space), so we probably want to make info->colorimetryuint16_t
3 BT2020RGB BT2020YCC BT2020cYCC AdobeRGB AdobeYCC601 sYCC601 xvYCC709 xvYCC601
4 F47=0 F46=0 F45=0 F44=0 MD3 MD2 MD1 MD0
This is how db[2] and db[3] is described in spec. There is not much clarity on
F47. Not sure if they
are for DCI-P3, can you clarify once.
Regards,
Uma Shankar
>> +}
>> +
>> +
>> static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db)
>> {
>> if (cea_db_tag(db) != DATA_BLOCK_EXTENDED_TAG) @@ -4513,6
>+4535,8
>> @@ static void drm_parse_cea_ext(struct drm_connector *connector,
>> drm_parse_y420cmdb_bitmap(connector, db);
>> if (cea_db_is_hdmi_hdr_metadata_block(db))
>> drm_parse_hdr_metadata_block(connector, db);
>> +if (cea_db_is_hdmi_colorimetry_data_block(db))
>> +drm_parse_colorimetry_data_block(connector, db);
>> }
>> }
>>
>> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
>> index 2ee45dc..90ce364 100644
>> --- a/include/drm/drm_connector.h
>> +++ b/include/drm/drm_connector.h
>> @@ -206,6 +206,8 @@ struct drm_hdmi_info {
>>
>> /** @y420_dc_modes: bitmap of deep color support index */
>> u8 y420_dc_modes;
>> +
>Please add a one line description about this variable.
Sure will update this.
>> +u8 colorimetry;
>> };
>>
>> /**
>Shashank
>___
>dri-devel mailing list
>dri-de...@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v2 03/14] drm: Parse HDR metadata info from EDID
>-Original Message-
>From: Sharma, Shashank
>Sent: Tuesday, January 8, 2019 11:26 AM
>To: Shankar, Uma ; intel-gfx@lists.freedesktop.org;
>dri-de...@lists.freedesktop.org
>Cc: Syrjala, Ville ; Lankhorst, Maarten
>
>Subject: Re: [v2 03/14] drm: Parse HDR metadata info from EDID
>
>Regards
>
>Shashank
>
>
>On 1/8/2019 11:10 AM, Shankar, Uma wrote:
>>
>>> -Original Message-
>>> From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On
>>> Behalf Of Sharma, Shashank
>>> Sent: Thursday, December 20, 2018 11:47 PM
>>> To: Shankar, Uma ;
>>> intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
>>> Cc: Syrjala, Ville ; Lankhorst, Maarten
>>>
>>> Subject: Re: [v2 03/14] drm: Parse HDR metadata info from EDID
>>>
>>> Regards
>>>
>>> Shashank
>>>
>>>
>>> On 12/12/2018 2:08 AM, Uma Shankar wrote:
HDR metadata block is introduced in CEA-861.3 spec.
Parsing the same to get the panel's HDR metadata.
v2: Rebase and added Ville's POC changes to the patch.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_edid.c | 45
>>> +
1 file changed, 45 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 106fd38..d12b74e 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3818,6 +3818,49 @@ static void
fixup_detailed_cea_mode_clock(struct
>>> drm_display_mode *mode)
mode->clock = clock;
}
>>> I guess the previous patch (or a art of previous patch) should be
>>> merged in this patch.
>> Sure, will update this.
>>
+static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db) {
+ if (cea_db_tag(db) != DATA_BLOCK_EXTENDED_TAG)
+ return false;
+
+ if (db[1] != HDR_STATIC_METADATA_BLOCK)
+ return false;
+
+ return true;
+}
+
+static uint16_t eotf_supported(const u8 *edid_ext)
>>> Why uint16 ? why not uint8_t ? this is clearly one byte.
>> Ok, will change this.
>>
+{
+
+ return edid_ext[2] &
+ (BIT(HDMI_EOTF_TRADITIONAL_GAMMA_SDR) |
>>> Should we bother about SDR bit at all ? Why not just check HDR bits ?
>> As per spec, all of these are EOTF types. So lets update whatever is
>> supported.
>> User should put correct EOTF for HDR from this list.
>>
+ BIT(HDMI_EOTF_TRADITIONAL_GAMMA_HDR) |
+ BIT(HDMI_EOTF_SMPTE_ST2084));
+
+}
+
+static uint16_t hdr_metadata_type(const u8 *edid_ext) {
>>> Same uint8_t stuff
>> Ok. Will update.
>>
+
+ return edid_ext[3] &
+ BIT(HDMI_STATIC_METADATA_TYPE1);
+}
+
+static void
+drm_parse_hdr_metadata_block(struct drm_connector *connector, const
+u8 *db) {
+ uint16_t len;
+
+ len = cea_db_payload_len(db);
>>> Length is incorrect here for extended tag blocks, as this function
>>> doesn't account the extended tag byte's size. So the payload length
>>> is looking for is len - 1. May be a good time to add
>>> cea_extended_db_payload_len() ?
>> As per spec, the definition says length after this byte so it factors
>> the extended tag byte well, IIUC. Please correct me if my understanding is
>wrong.
>This is how the data is arranged in a normal CEA DB and Extended CEA DB
>++ +-+
>|Tag|Length= 3 | |Tag|Length=3 |
>++ +-+
>| Data | |Extended tag |
>++ +-+
>| Data | |Data |
>++ +-+
>| Data | |Data |
>++ +-+
>
>This function cea_db_payload_len() was written before the CEA extended blocks
>were introduced, so it is unaware of Extended tag code, and assumes its a part
>of
>data. But in case of extended tag block the actual data length is 3 -1 = 2.
>You can
>have a look at how we are parsing the YCBCR 4:2:0 blocks. That's why I made
>this
>comment "may be a good time to add cea_extended_db_payload_len() function"
>or enhance the existing function to reflect the extended tag.
Oh ok got it, thanks for the explanation. Will update the patch accordingly.
Regards,
Uma Shankar
>- Shashank
>>
>> Regards,
>> Uma Shankar
>>
+ connector->hdr_metadata.eotf = eotf_supported(db);
+ connector->hdr_metadata.metadata_type = hdr_metadata_type(db);
+
+ if (len >= 5)
+ connector->hdr_metadata.max_fall = db[5];
+ if (len >= 4)
+ connector->hdr_metadata.max_cll = db[4]; }
+
static void
drm_parse_hdmi_vsdb_audio(struct drm_connector *connector, const u8
>*db)
{
@@ -4468,6 +4511,8 @@ static void drm_parse_cea_ext(struct
drm_connector
>>> *connector,
drm_parse_hdmi_forum_vsdb(co
Re: [Intel-gfx] [v2 03/14] drm: Parse HDR metadata info from EDID
Regards
Shashank
On 1/8/2019 11:10 AM, Shankar, Uma wrote:
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Sharma, Shashank
Sent: Thursday, December 20, 2018 11:47 PM
To: Shankar, Uma ; intel-gfx@lists.freedesktop.org;
dri-de...@lists.freedesktop.org
Cc: Syrjala, Ville ; Lankhorst, Maarten
Subject: Re: [v2 03/14] drm: Parse HDR metadata info from EDID
Regards
Shashank
On 12/12/2018 2:08 AM, Uma Shankar wrote:
HDR metadata block is introduced in CEA-861.3 spec.
Parsing the same to get the panel's HDR metadata.
v2: Rebase and added Ville's POC changes to the patch.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_edid.c | 45
+
1 file changed, 45 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 106fd38..d12b74e 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3818,6 +3818,49 @@ static void fixup_detailed_cea_mode_clock(struct
drm_display_mode *mode)
mode->clock = clock;
}
I guess the previous patch (or a art of previous patch) should be merged in this
patch.
Sure, will update this.
+static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db) {
+ if (cea_db_tag(db) != DATA_BLOCK_EXTENDED_TAG)
+ return false;
+
+ if (db[1] != HDR_STATIC_METADATA_BLOCK)
+ return false;
+
+ return true;
+}
+
+static uint16_t eotf_supported(const u8 *edid_ext)
Why uint16 ? why not uint8_t ? this is clearly one byte.
Ok, will change this.
+{
+
+ return edid_ext[2] &
+ (BIT(HDMI_EOTF_TRADITIONAL_GAMMA_SDR) |
Should we bother about SDR bit at all ? Why not just check HDR bits ?
As per spec, all of these are EOTF types. So lets update whatever is supported.
User should put correct EOTF for HDR from this list.
+BIT(HDMI_EOTF_TRADITIONAL_GAMMA_HDR) |
+BIT(HDMI_EOTF_SMPTE_ST2084));
+
+}
+
+static uint16_t hdr_metadata_type(const u8 *edid_ext) {
Same uint8_t stuff
Ok. Will update.
+
+ return edid_ext[3] &
+ BIT(HDMI_STATIC_METADATA_TYPE1);
+}
+
+static void
+drm_parse_hdr_metadata_block(struct drm_connector *connector, const
+u8 *db) {
+ uint16_t len;
+
+ len = cea_db_payload_len(db);
Length is incorrect here for extended tag blocks, as this function doesn't
account
the extended tag byte's size. So the payload length is looking for is len - 1.
May be
a good time to add
cea_extended_db_payload_len() ?
As per spec, the definition says length after this byte so it factors the
extended tag byte
well, IIUC. Please correct me if my understanding is wrong.
This is how the data is arranged in a normal CEA DB and Extended CEA DB
++ +-+
|Tag|Length= 3 | |Tag|Length=3 |
++ +-+
| Data | |Extended tag |
++ +-+
| Data | |Data |
++ +-+
| Data | |Data |
++ +-+
This function cea_db_payload_len() was written before the CEA extended
blocks were introduced, so it is unaware of Extended tag code, and
assumes its a part of data. But in case of extended tag block the actual
data length is 3 -1 = 2. You can have a look at how we are parsing the
YCBCR 4:2:0 blocks. That's why I made this comment "may be a good time
to add cea_extended_db_payload_len() function" or enhance the existing
function to reflect the extended tag.
- Shashank
Regards,
Uma Shankar
+ connector->hdr_metadata.eotf = eotf_supported(db);
+ connector->hdr_metadata.metadata_type = hdr_metadata_type(db);
+
+ if (len >= 5)
+ connector->hdr_metadata.max_fall = db[5];
+ if (len >= 4)
+ connector->hdr_metadata.max_cll = db[4]; }
+
static void
drm_parse_hdmi_vsdb_audio(struct drm_connector *connector, const u8 *db)
{
@@ -4468,6 +4511,8 @@ static void drm_parse_cea_ext(struct drm_connector
*connector,
drm_parse_hdmi_forum_vsdb(connector, db);
if (cea_db_is_y420cmdb(db))
drm_parse_y420cmdb_bitmap(connector, db);
+ if (cea_db_is_hdmi_hdr_metadata_block(db))
+ drm_parse_hdr_metadata_block(connector, db);
}
}
- Shashank
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v2 03/14] drm: Parse HDR metadata info from EDID
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Sharma, Shashank
>Sent: Thursday, December 20, 2018 11:47 PM
>To: Shankar, Uma ; intel-gfx@lists.freedesktop.org;
>dri-de...@lists.freedesktop.org
>Cc: Syrjala, Ville ; Lankhorst, Maarten
>
>Subject: Re: [v2 03/14] drm: Parse HDR metadata info from EDID
>
>Regards
>
>Shashank
>
>
>On 12/12/2018 2:08 AM, Uma Shankar wrote:
>> HDR metadata block is introduced in CEA-861.3 spec.
>> Parsing the same to get the panel's HDR metadata.
>>
>> v2: Rebase and added Ville's POC changes to the patch.
>>
>> Signed-off-by: Uma Shankar
>> ---
>> drivers/gpu/drm/drm_edid.c | 45
>+
>> 1 file changed, 45 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index 106fd38..d12b74e 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -3818,6 +3818,49 @@ static void fixup_detailed_cea_mode_clock(struct
>drm_display_mode *mode)
>> mode->clock = clock;
>> }
>I guess the previous patch (or a art of previous patch) should be merged in
>this
>patch.
Sure, will update this.
>> +static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db) {
>> +if (cea_db_tag(db) != DATA_BLOCK_EXTENDED_TAG)
>> +return false;
>> +
>> +if (db[1] != HDR_STATIC_METADATA_BLOCK)
>> +return false;
>> +
>> +return true;
>> +}
>> +
>> +static uint16_t eotf_supported(const u8 *edid_ext)
>Why uint16 ? why not uint8_t ? this is clearly one byte.
Ok, will change this.
>> +{
>> +
>> +return edid_ext[2] &
>> +(BIT(HDMI_EOTF_TRADITIONAL_GAMMA_SDR) |
>Should we bother about SDR bit at all ? Why not just check HDR bits ?
As per spec, all of these are EOTF types. So lets update whatever is supported.
User should put correct EOTF for HDR from this list.
>> + BIT(HDMI_EOTF_TRADITIONAL_GAMMA_HDR) |
>> + BIT(HDMI_EOTF_SMPTE_ST2084));
>> +
>> +}
>> +
>> +static uint16_t hdr_metadata_type(const u8 *edid_ext) {
>Same uint8_t stuff
Ok. Will update.
>> +
>> +return edid_ext[3] &
>> +BIT(HDMI_STATIC_METADATA_TYPE1);
>> +}
>> +
>> +static void
>> +drm_parse_hdr_metadata_block(struct drm_connector *connector, const
>> +u8 *db) {
>> +uint16_t len;
>> +
>> +len = cea_db_payload_len(db);
>Length is incorrect here for extended tag blocks, as this function doesn't
>account
>the extended tag byte's size. So the payload length is looking for is len - 1.
>May be
>a good time to add
>cea_extended_db_payload_len() ?
As per spec, the definition says length after this byte so it factors the
extended tag byte
well, IIUC. Please correct me if my understanding is wrong.
Regards,
Uma Shankar
>> +connector->hdr_metadata.eotf = eotf_supported(db);
>> +connector->hdr_metadata.metadata_type = hdr_metadata_type(db);
>> +
>> +if (len >= 5)
>> +connector->hdr_metadata.max_fall = db[5];
>> +if (len >= 4)
>> +connector->hdr_metadata.max_cll = db[4]; }
>> +
>> static void
>> drm_parse_hdmi_vsdb_audio(struct drm_connector *connector, const u8 *db)
>> {
>> @@ -4468,6 +4511,8 @@ static void drm_parse_cea_ext(struct drm_connector
>*connector,
>> drm_parse_hdmi_forum_vsdb(connector, db);
>> if (cea_db_is_y420cmdb(db))
>> drm_parse_y420cmdb_bitmap(connector, db);
>> +if (cea_db_is_hdmi_hdr_metadata_block(db))
>> +drm_parse_hdr_metadata_block(connector, db);
>> }
>> }
>>
>- Shashank
>
>___
>dri-devel mailing list
>dri-de...@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v2 02/14] drm: Add CEA extended tag blocks and HDR bitfield macros
>-Original Message- >From: Sharma, Shashank >Sent: Thursday, December 20, 2018 11:38 PM >To: Shankar, Uma ; intel-gfx@lists.freedesktop.org; >dri-de...@lists.freedesktop.org >Cc: Lankhorst, Maarten ; Syrjala, Ville >; brian.star...@arm.com >Subject: Re: [v2 02/14] drm: Add CEA extended tag blocks and HDR bitfield >macros > >Regards > >Shashank > > >On 12/12/2018 2:08 AM, Uma Shankar wrote: >> Add bit field and macro for extended tag in CEA block. Also, declare >> macros for HDR metadata block. >This should have been a part of patch, where these macros are being used, so >that we can see it being used properly. While re-basing can you please merge ? Idea was to define all new block additions and bit fields in 1 patch. But will add to respective patches where they are getting used as you mentioned. >> v2: Rebase >> >> Signed-off-by: Uma Shankar >> --- >> drivers/gpu/drm/drm_edid.c | 16 >> 1 file changed, 16 insertions(+) >> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c >> index b506e36..106fd38 100644 >> --- a/drivers/gpu/drm/drm_edid.c >> +++ b/drivers/gpu/drm/drm_edid.c >> @@ -2843,6 +2843,22 @@ static int drm_cvt_modes(struct drm_connector >*connector, >> #define EDID_CEA_YCRCB422 (1 << 4) >> #define EDID_CEA_VCDB_QS (1 << 6) >> >> +#define DATA_BLOCK_EXTENDED_TAG 0x07 >Alignment should be one tab back, also I think we already have added >extended tag macro (for parsing YCBCR420 blocks) Ok, will drop this. >> +#define VIDEO_CAPABILITY_DATA_BLOCK 0x0 >> +#define VSVD_DATA_BLOCK 0x1 >Alignment one tab back This is some editor issue, change looks ok on applying. Will recheck while rebasing. >> +#define COLORIMETRY_DATA_BLOCK 0x5 >> +#define HDR_STATIC_METADATA_BLOCK 0x6 >> + >> +/* HDR Metadata Block: Bit fields */ >> +#define SUPPORTED_EOTF_MASK0x3f >> +#define TRADITIONAL_GAMMA_SDR (0x1 << 0) >> +#define TRADITIONAL_GAMMA_HDR (0x1 << 1) >> +#define SMPTE_ST2084 (0x1 << 2) >> +#define FUTURE_EOTF(0x1 << 3) >why not properly call it HLG if we are adding a bit for it already ? Ok. Will update. Regards, Uma Shankar >> +#define RESERVED_EOTF (0x3 << 4) >> + >> +#define STATIC_METADATA_TYPE1 (0x1 << 0) >> + >> /* >>* Search EDID for CEA extension block. >>*/ >- Shashank ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v2 01/14] drm: Add HDR source metadata property
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Sharma, Shashank
>Sent: Thursday, December 20, 2018 11:21 PM
>To: Shankar, Uma ; intel-gfx@lists.freedesktop.org;
>dri-de...@lists.freedesktop.org
>Cc: Syrjala, Ville ; Lankhorst, Maarten
>
>Subject: Re: [v2 01/14] drm: Add HDR source metadata property
>
>Regards
>
>Shashank
>
>
>On 12/12/2018 2:08 AM, Uma Shankar wrote:
>> This patch adds a blob property to get HDR metadata information from
>> userspace. This will be send as part of AVI Infoframe to panel.
>>
>> v2: Rebase and modified the metadata structure elements as per Ville's
>> POC changes.
>>
>> Signed-off-by: Uma Shankar
>> ---
>> drivers/gpu/drm/drm_connector.c | 6 ++
>> include/drm/drm_connector.h | 10 ++
>> include/drm/drm_mode_config.h | 6 ++
>> include/linux/hdmi.h| 10 ++
>> include/uapi/drm/drm_mode.h | 16
>> 5 files changed, 48 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_connector.c
>> b/drivers/gpu/drm/drm_connector.c index da8ae80..361fcda 100644
>> --- a/drivers/gpu/drm/drm_connector.c
>> +++ b/drivers/gpu/drm/drm_connector.c
>> @@ -1027,6 +1027,12 @@ int
>drm_connector_create_standard_properties(struct drm_device *dev)
>> return -ENOMEM;
>> dev->mode_config.non_desktop_property = prop;
>>
>> +prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,
>> + "HDR_SOURCE_METADATA", 0);
>I see that the compositor would be using this blob to setup the output HDR
>curve
>post blending, which would be in most of cases, sink HDR. So we should ideally
>call it HDR_OUTPUT_METADATA or output_hdr_metadata.
Ok Sure, will update the property name.
>> +if (!prop)
>> +return -ENOMEM;
>> +dev->mode_config.hdr_source_metadata_property = prop;
>> +
>> return 0;
>> }
>>
>> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
>> index 9be2181..2ee45dc 100644
>> --- a/include/drm/drm_connector.h
>> +++ b/include/drm/drm_connector.h
>> @@ -520,6 +520,13 @@ struct drm_connector_state {
>> * and the connector bpc limitations obtained from edid.
>> */
>> u8 max_bpc;
>> +
>> +/**
>> + * @metadata_blob_ptr:
>> + * DRM blob property for HDR metadata
>> + */
>> +struct drm_property_blob *hdr_source_metadata_blob_ptr;
>Same goes again here, output_hdr_metadata_blob ?
Ok.
>> +u8 hdr_metadata_changed : 1;
>> };
>>
>> /**
>> @@ -1154,6 +1161,9 @@ struct drm_connector {
>> * &drm_mode_config.connector_free_work.
>> */
>> struct llist_node free_node;
>> +
>> +/* HDR metdata */
>> +struct hdr_static_metadata hdr_metadata;
>I think while designing this framework, we should leave the scope for dynamic
>metadata, which would be following up soon. So we should have a union inside
>struct hdr_metedata, which will have option for both static and dynamic type of
>metadata. I will add details to the place where you are adding definition of
>hdr_static_metadata().
I feel since we are not yet targeting beyond HDR10, lets not add dynamic
metadata
definitions as of now. We will add when the same gets enabled. I hope this is
ok.
>> };
>>
>> #define obj_to_connector(x) container_of(x, struct drm_connector,
>> base) diff --git a/include/drm/drm_mode_config.h
>> b/include/drm/drm_mode_config.h index 69ccd27..4b3211b 100644
>> --- a/include/drm/drm_mode_config.h
>> +++ b/include/drm/drm_mode_config.h
>> @@ -836,6 +836,12 @@ struct drm_mode_config {
>> */
>> struct drm_property *writeback_out_fence_ptr_property;
>>
>> +/*
>> + * hdr_metadata_property: Connector property containing hdr metatda
>> + * This will be provided by userspace compositors based on HDR content
>> + */
>> +struct drm_property *hdr_source_metadata_property;
>Again, source->output
Sure, will change it.
>> +
>> /* dumb ioctl parameters */
>> uint32_t preferred_depth, prefer_shadow;
>>
>> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h index
>> d2bacf5..bed3e08 100644
>> --- a/include/linux/hdmi.h
>> +++ b/include/linux/hdmi.h
>> @@ -137,6 +137,16 @@ enum hdmi_content_type {
>> HDMI_CONTENT_TYPE_GAME,
>> };
>>
>> +enum hdmi_metadata_type {
>> +HDMI_STATIC_METADATA_TYPE1 = 1,
>> +};
>> +
>> +enum hdmi_eotf {
>> +HDMI_EOTF_TRADITIONAL_GAMMA_SDR,
>> +HDMI_EOTF_TRADITIONAL_GAMMA_HDR,
>> +HDMI_EOTF_SMPTE_ST2084,
>I guess we are not bothering about HLG now, which is fine actually, less
>complicated for now.
Yeah.
>> +};
>> +
>> struct hdmi_avi_infoframe {
>> enum hdmi_infoframe_type type;
>> unsigned char version;
>> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
>> index a439c2e..5012af2 100644
>> --- a/include/uapi/drm/drm_mode.h
>> +++ b/include/uapi/drm/drm_mode.h
>> @@ -630,6 +630,22 @@ struct drm_color_lut {
>> __u16 reserved;
>> };
>>
>> +/*
[Intel-gfx] linux-next: build failure after merge of the drm-misc tree
Hi all,
After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In function
'amdgpu_dm_mode_config_init':
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:1695:30: error:
passing argument 1 of 'drm_atomic_private_obj_init' from incompatible pointer
type [-Werror=incompatible-pointer-types]
drm_atomic_private_obj_init(&adev->dm.atomic_obj,
^~~~
In file included from include/drm/drm_dp_mst_helper.h:27,
from drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h:46,
from drivers/gpu/drm/amd/amdgpu/amdgpu.h:57,
from
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:34:
include/drm/drm_atomic.h:437:53: note: expected 'struct drm_device *' but
argument is of type 'struct drm_private_obj *'
void drm_atomic_private_obj_init(struct drm_device *dev,
~~~^~~
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:1696:9: error:
passing argument 2 of 'drm_atomic_private_obj_init' from incompatible pointer
type [-Werror=incompatible-pointer-types]
&state->base,
^~~~
In file included from include/drm/drm_dp_mst_helper.h:27,
from drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h:46,
from drivers/gpu/drm/amd/amdgpu/amdgpu.h:57,
from
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:34:
include/drm/drm_atomic.h:438:30: note: expected 'struct drm_private_obj *' but
argument is of type 'struct drm_private_state *'
struct drm_private_obj *obj,
^~~
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:1697:9: error:
passing argument 3 of 'drm_atomic_private_obj_init' from incompatible pointer
type [-Werror=incompatible-pointer-types]
&dm_atomic_state_funcs);
^~
In file included from include/drm/drm_dp_mst_helper.h:27,
from drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h:46,
from drivers/gpu/drm/amd/amdgpu/amdgpu.h:57,
from
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:34:
include/drm/drm_atomic.h:439:32: note: expected 'struct drm_private_state *'
but argument is of type 'struct drm_private_state_funcs *'
struct drm_private_state *state,
~~^
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:1695:2: error: too
few arguments to function 'drm_atomic_private_obj_init'
drm_atomic_private_obj_init(&adev->dm.atomic_obj,
^~~
In file included from include/drm/drm_dp_mst_helper.h:27,
from drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h:46,
from drivers/gpu/drm/amd/amdgpu/amdgpu.h:57,
from
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:34:
include/drm/drm_atomic.h:437:6: note: declared here
void drm_atomic_private_obj_init(struct drm_device *dev,
^~~
Caused by commit
b962a12050a3 ("drm/atomic: integrate modeset lock with private objects")
interacting with commit
eb3dc8978596 ("drm/amd/display: Use private obj helpers for dm_atomic_state")
from Linus' tree (merged during the merge window).
Its not obvious how to fix this up, so I have used the drm-misc tree
from next-20190107 for today.
--
Cheers,
Stephen Rothwell
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] linux-next: build warning after merge of the drm-misc tree
Hi all,
After merging the drm-misc tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:
drivers/gpu/drm/msm/msm_gem.c: In function 'describe_fence':
drivers/gpu/drm/msm/msm_gem.c:761:36: warning: format '%u' expects argument of
type 'unsigned int', but argument 6 has type 'u64' {aka 'long long unsigned
int'} [-Wformat=]
seq_printf(m, "\t%9s: %s %s seq %u\n", type,
~^
%llu
drivers/gpu/drm/msm/msm_gem.c:764:5:
fence->seqno);
Introduced by commit
b312d8ca3a7c ("dma-buf: make fence sequence numbers 64 bit v2")
--
Cheers,
Stephen Rothwell
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] linux-next: build warnings after merge of the drm-intel tree
Hi all,
After merging the drm-intel tree, today's linux-next build (x86_64
allmodconfig) produced these warnings:
In file included from include/linux/printk.h:7,
from include/linux/kernel.h:14,
from include/asm-generic/bug.h:18,
from arch/x86/include/asm/bug.h:83,
from include/linux/bug.h:5,
from include/linux/mmdebug.h:5,
from include/linux/gfp.h:5,
from include/linux/slab.h:15,
from include/linux/io-mapping.h:22,
from drivers/gpu/drm/i915/i915_drv.h:36,
from drivers/gpu/drm/i915/intel_hangcheck.c:25:
drivers/gpu/drm/i915/selftests/intel_hangcheck.c: In function
'igt_atomic_reset_engine':
include/linux/kern_levels.h:5:18: warning: format '%llx' expects argument of
type 'long long unsigned int', but argument 4 has type 'unsigned int'
[-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^~
include/linux/kern_levels.h:11:18: note: in expansion of macro 'KERN_SOH'
#define KERN_ERR KERN_SOH "3" /* error conditions */
^~~~
include/linux/printk.h:303:9: note: in expansion of macro 'KERN_ERR'
printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
^~~~
drivers/gpu/drm/i915/selftests/intel_hangcheck.c:1564:3: note: in expansion of
macro 'pr_err'
pr_err("%s(%s): Failed to start request %llx, at %x\n",
^~
In file included from drivers/gpu/drm/i915/intel_hangcheck.c:315:
drivers/gpu/drm/i915/selftests/intel_hangcheck.c:1564:46: note: format string
is defined here
pr_err("%s(%s): Failed to start request %llx, at %x\n",
~~~^
%x
Introduced by commit
921f3a60e54e ("drm/i915/selftests: Verify we can perform resets from atomic
context")
--
Cheers,
Stephen Rothwell
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Mark the whole mock device as DMA capable (rev2)
== Series Details == Series: drm/i915/selftests: Mark the whole mock device as DMA capable (rev2) URL : https://patchwork.freedesktop.org/series/54825/ State : success == Summary == CI Bug Log - changes from CI_DRM_5369_full -> Patchwork_11204_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_11204_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_whisper@normal: - shard-skl: PASS -> TIMEOUT [fdo#108592] * igt@gem_ppgtt@blt-vs-render-ctx0: - shard-skl: NOTRUN -> TIMEOUT [fdo#108039] * igt@gem_userptr_blits@readonly-unsync: - shard-apl: PASS -> INCOMPLETE [fdo#103927] +1 * igt@i915_selftest@live_contexts: - shard-iclb: NOTRUN -> DMESG-FAIL [fdo#108569] * igt@kms_busy@extended-modeset-hang-newfb-render-c: - shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] +2 * igt@kms_color@pipe-c-legacy-gamma: - shard-apl: PASS -> FAIL [fdo#104782] * igt@kms_cursor_crc@cursor-128x128-sliding: - shard-iclb: NOTRUN -> FAIL [fdo#103232] * igt@kms_cursor_crc@cursor-256x256-random: - shard-apl: PASS -> FAIL [fdo#103232] +1 * igt@kms_fbcon_fbt@psr-suspend: - shard-iclb: NOTRUN -> FAIL [fdo#107882] * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-skl: NOTRUN -> FAIL [fdo#105363] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-mmap-gtt: - shard-skl: PASS -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-move: - shard-iclb: PASS -> FAIL [fdo#103167] +7 * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-onoff: - shard-glk: PASS -> FAIL [fdo#103167] +3 * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-mmap-gtt: - shard-skl: NOTRUN -> FAIL [fdo#103167] * igt@kms_plane@pixel-format-pipe-b-planes-source-clamping: - shard-skl: NOTRUN -> DMESG-WARN [fdo#106885] * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes: - shard-iclb: PASS -> FAIL [fdo#103375] +2 * igt@kms_plane_alpha_blend@pipe-a-alpha-basic: - shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145] * igt@kms_plane_multiple@atomic-pipe-b-tiling-x: - shard-glk: PASS -> FAIL [fdo#103166] - shard-iclb: PASS -> FAIL [fdo#103166] +1 * igt@kms_plane_scaling@pipe-b-scaler-with-pixel-format: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] * igt@kms_rotation_crc@multiplane-rotation-cropping-top: - shard-kbl: PASS -> DMESG-FAIL [fdo#108950] * igt@perf_pmu@rc6-runtime-pm-long: - shard-skl: PASS -> FAIL [fdo#105010] * igt@pm_rpm@dpms-lpsp: - shard-skl: PASS -> INCOMPLETE [fdo#107807] Possible fixes * igt@gem_exec_suspend@basic-s4-devices: - shard-kbl: DMESG-WARN [fdo#103558] / [fdo#105602] / [fdo#107139] -> PASS * igt@gem_softpin@noreloc-s3: - shard-skl: INCOMPLETE [fdo#104108] / [fdo#107773] -> PASS * igt@i915_selftest@mock_vma: - shard-kbl: DMESG-WARN [fdo#109243] -> PASS - shard-snb: DMESG-WARN [fdo#109243] -> PASS - shard-apl: DMESG-WARN [fdo#109243] -> PASS - shard-iclb: DMESG-WARN [fdo#109243] -> PASS * igt@kms_ccs@pipe-a-crc-sprite-planes-basic: - shard-glk: FAIL [fdo#108145] -> PASS * igt@kms_cursor_crc@cursor-128x128-suspend: - shard-skl: INCOMPLETE [fdo#104108] -> PASS * igt@kms_cursor_crc@cursor-128x42-onscreen: - shard-glk: FAIL [fdo#103232] -> PASS +2 * igt@kms_cursor_crc@cursor-256x85-onscreen: - shard-apl: FAIL [fdo#103232] -> PASS +3 * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite: - shard-apl: FAIL [fdo#103167] -> PASS +1 - shard-glk: FAIL [fdo#103167] -> PASS +2 * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-mmap-wc: - shard-iclb: FAIL [fdo#103167] -> PASS +1 * igt@kms_plane@plane-panning-bottom-right-pipe-b-planes: - shard-skl: FAIL [fdo#103166] -> PASS * igt@kms_plane_multiple@atomic-pipe-a-tiling-x: - shard-apl: FAIL [fdo#103166] -> PASS +1 * igt@kms_plane_multiple@atomic-pipe-a-tiling-y: - shard-glk: FAIL [fdo#103166] -> PASS +2 - shard-iclb: FAIL [fdo#103166] -> PASS * igt@kms_plane_scaling@pipe-b-scaler-with-rotation: - shard-iclb: DMESG-WARN [fdo#107724] -> PASS +1 * igt@kms_vblank@pipe-c-ts-continuation-modeset-rpm: - shard-kbl: DMESG-WARN [fdo#103558] / [fdo#105602] -> PASS +2 * igt@perf@rc6-disable: - shard-kbl: FAIL [fdo#103179] -> PASS * igt@pm_rpm@modeset-non-lpsp-stress: - shard-skl: IN
Re: [Intel-gfx] [PATCH 21/39] drm/i915/guc: Disable global reset
On 01/07/2019 01:35 PM, Chris Wilson wrote: Quoting Daniele Ceraolo Spurio (2019-01-07 21:28:48) On 01/07/2019 10:50 AM, Chris Wilson wrote: Quoting Daniele Ceraolo Spurio (2019-01-07 18:31:52) Were you already planning/working on something along the lines of the possible solution mentioned in the commit message? Just trying to understand what the status is before jumping in to avoid duplication of work ;) The compromises required (reserving space for the firmware) seem like it will just end up with a lot of screaming to make it mutexless today. Aren't we already keeping some GuC stuff perma-pinned (e.g. the stage_desc_pool)? Current Gen11+ firmware needs more space and uses objects up to tens of MBs, the blobs aren't that big in comparison. Hmm, there's always the guc reserved region (top/bottom). Is that large enough to store the firmware, and would it be legal to load from those addresses? (After the dma transfer we wouldn't use those ourselves, so the guc is free to utilise them for its scratch. Then after the guc is reset, we would put the firmware there again for dma xfer). -Chris I've asked and the DMA engine should be able to fetch from there, so this sounds like quite a good compromise. We wouldn't need to move the blob after the reset either because those regions are not accessible at all by GuC and they're not used by the firmware in any way. The top region in particular is several MBs big, so the firmware would fit quite nicely in there. Daniele ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 21/39] drm/i915/guc: Disable global reset
Quoting Daniele Ceraolo Spurio (2019-01-07 21:28:48) > > On 01/07/2019 10:50 AM, Chris Wilson wrote: > > Quoting Daniele Ceraolo Spurio (2019-01-07 18:31:52) > >> > >> Were you already > >> planning/working on something along the lines of the possible solution > >> mentioned in the commit message? Just trying to understand what the > >> status is before jumping in to avoid duplication of work ;) > > > > The compromises required (reserving space for the firmware) seem like it > > will just end up with a lot of screaming to make it mutexless today. > > Aren't we already keeping some GuC stuff perma-pinned (e.g. the > stage_desc_pool)? Current Gen11+ firmware needs more space and uses > objects up to tens of MBs, the blobs aren't that big in comparison. Hmm, there's always the guc reserved region (top/bottom). Is that large enough to store the firmware, and would it be legal to load from those addresses? (After the dma transfer we wouldn't use those ourselves, so the guc is free to utilise them for its scratch. Then after the guc is reset, we would put the firmware there again for dma xfer). -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 21/39] drm/i915/guc: Disable global reset
On 01/07/2019 10:50 AM, Chris Wilson wrote:
Quoting Daniele Ceraolo Spurio (2019-01-07 18:31:52)
On 01/02/2019 01:41 AM, Chris Wilson wrote:
The guc (and huc) currently inexcruitably depend on struct_mutex for
device reinitialisation from inside the reset, and indeed taking any
mutex here is verboten (as we must be able to reset from underneath any
of our mutexes). That makes recovering the guc unviable without, for
example, reserving contiguous vma space and pages for it to use.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_reset.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reset.c
b/drivers/gpu/drm/i915/i915_reset.c
index f5da67f1bc04..77fc2f74e427 100644
--- a/drivers/gpu/drm/i915/i915_reset.c
+++ b/drivers/gpu/drm/i915/i915_reset.c
@@ -590,6 +590,9 @@ int intel_gpu_reset(struct drm_i915_private *i915, unsigned
int engine_mask)
bool intel_has_gpu_reset(struct drm_i915_private *i915)
{
+ if (USES_GUC(i915))
+ return false;
+
Do we need to tweak the getparam so we can report that we have engine
reset but not full reset?
Oh, we cut a corner. But is userspace ready for having one but not the
other... What userspace other than igt, I wonder. I suspect even igt
treats it as boolean for the large part, with just a few correctly
checking when they want per-engine resets.
Also, this is a regression of capabilities when GuC is enabled, so we
need to make lockless reset work with GuC soon.
Hah. It frequently fails to recover after reset :-p
Were you already
planning/working on something along the lines of the possible solution
mentioned in the commit message? Just trying to understand what the
status is before jumping in to avoid duplication of work ;)
The compromises required (reserving space for the firmware) seem like it
will just end up with a lot of screaming to make it mutexless today.
Aren't we already keeping some GuC stuff perma-pinned (e.g. the
stage_desc_pool)? Current Gen11+ firmware needs more space and uses
objects up to tens of MBs, the blobs aren't that big in comparison.
I was planning on coming back to it after breaking up the struct_mutex
to see which locks were required. If we get to the point where we can
guarantee that those locks are never held when waiting (inc.
allocations) (the plan there is to annotate them with lockdep to catch
waiters), then we can safely use those inside the reset.
Sounds good.
Or maybe we can get away with using just a single page in the global gtt
and just loading the firmware piecemeal, or something.
From my understanding the HW consider the firmware loaded and starts
processing it as soon as the first DMA transfer completes, so loading it
bit by bit wouldn't work.
Thanks,
Daniele
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Reduce i915_request_alloc retirement to local context
== Series Details == Series: drm/i915: Reduce i915_request_alloc retirement to local context URL : https://patchwork.freedesktop.org/series/54820/ State : success == Summary == CI Bug Log - changes from CI_DRM_5369_full -> Patchwork_11202_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_11202_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ppgtt@blt-vs-render-ctx0: - shard-skl: NOTRUN -> TIMEOUT [fdo#108039] * igt@i915_suspend@fence-restore-untiled: - shard-iclb: PASS -> INCOMPLETE [fdo#107713] * igt@kms_atomic_transition@1x-modeset-transitions-fencing: - shard-skl: PASS -> FAIL [fdo#107815] / [fdo#108470] * igt@kms_atomic_transition@plane-all-transition-fencing: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] / [fdo#109225] +1 * igt@kms_busy@extended-modeset-hang-newfb-render-c: - shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] +2 * igt@kms_busy@extended-modeset-hang-oldfb-with-reset-render-a: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] +28 * igt@kms_color@pipe-a-ctm-0-5: - shard-apl: PASS -> DMESG-WARN [fdo#103558] / [fdo#105602] +3 * igt@kms_color@pipe-c-legacy-gamma: - shard-apl: PASS -> FAIL [fdo#104782] * igt@kms_cursor_crc@cursor-128x128-sliding: - shard-iclb: NOTRUN -> FAIL [fdo#103232] * igt@kms_cursor_crc@cursor-128x128-suspend: - shard-apl: PASS -> FAIL [fdo#103191] / [fdo#103232] * igt@kms_cursor_crc@cursor-256x85-random: - shard-glk: PASS -> FAIL [fdo#103232] +1 * igt@kms_cursor_crc@cursor-64x21-onscreen: - shard-apl: PASS -> FAIL [fdo#103232] +1 * igt@kms_cursor_legacy@flip-vs-cursor-crc-legacy: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] / [fdo#108336] +20 * igt@kms_draw_crc@draw-method-rgb565-pwrite-xtiled: - shard-iclb: PASS -> WARN [fdo#108336] +5 * igt@kms_fbcon_fbt@psr-suspend: - shard-iclb: NOTRUN -> FAIL [fdo#107882] * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-mmap-gtt: - shard-iclb: PASS -> DMESG-FAIL [fdo#107724] +10 * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt: - shard-apl: PASS -> FAIL [fdo#103167] +2 * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite: - shard-iclb: PASS -> FAIL [fdo#103167] +3 * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-mmap-gtt: - shard-skl: NOTRUN -> FAIL [fdo#103167] * igt@kms_pipe_crc_basic@hang-read-crc-pipe-c: - shard-skl: PASS -> FAIL [fdo#103191] / [fdo#107362] * igt@kms_plane@pixel-format-pipe-b-planes-source-clamping: - shard-skl: NOTRUN -> DMESG-WARN [fdo#106885] * igt@kms_plane_alpha_blend@pipe-a-alpha-basic: - shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145] * igt@kms_plane_multiple@atomic-pipe-b-tiling-x: - shard-apl: PASS -> FAIL [fdo#103166] +1 * igt@kms_plane_multiple@atomic-pipe-c-tiling-x: - shard-glk: PASS -> FAIL [fdo#103166] +1 * igt@kms_plane_multiple@atomic-pipe-c-tiling-y: - shard-iclb: PASS -> FAIL [fdo#103166] * igt@kms_setmode@basic: - shard-hsw: PASS -> FAIL [fdo#99912] * igt@kms_universal_plane@universal-plane-pipe-b-functional: - shard-iclb: PASS -> DMESG-FAIL [fdo#103166] / [fdo#107724] * igt@perf_pmu@rc6-runtime-pm-long: - shard-iclb: PASS -> FAIL [fdo#105010] * igt@pm_rpm@dpms-lpsp: - shard-skl: PASS -> INCOMPLETE [fdo#107807] * igt@pm_rpm@pc8-residency: - shard-skl: SKIP -> INCOMPLETE [fdo#107807] * igt@pm_rpm@pm-tiling: - shard-iclb: PASS -> DMESG-WARN [fdo#108654] * igt@pm_rpm@system-suspend-devices: - shard-iclb: PASS -> INCOMPLETE [fdo#107713] / [fdo#108840] Possible fixes * igt@gem_exec_suspend@basic-s4-devices: - shard-kbl: DMESG-WARN [fdo#103558] / [fdo#105602] / [fdo#107139] -> PASS * igt@gem_softpin@noreloc-s3: - shard-skl: INCOMPLETE [fdo#104108] / [fdo#107773] -> PASS * igt@kms_available_modes_crc@available_mode_test_crc: - shard-apl: FAIL [fdo#106641] -> PASS * igt@kms_cursor_crc@cursor-128x128-suspend: - shard-skl: INCOMPLETE [fdo#104108] -> PASS * igt@kms_cursor_crc@cursor-256x85-onscreen: - shard-apl: FAIL [fdo#103232] -> PASS +3 * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: FAIL [fdo#105363] -> PASS * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite: - shard-apl: FAIL [fdo#103167] -> PASS +1 * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-render: - shard-iclb: FAIL [fdo#103167] -> PAS
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/debugfs: store rotation string buffer on stack
== Series Details == Series: drm/i915/debugfs: store rotation string buffer on stack URL : https://patchwork.freedesktop.org/series/54816/ State : success == Summary == CI Bug Log - changes from CI_DRM_5369_full -> Patchwork_11201_full Summary --- **WARNING** Minor unknown changes coming with Patchwork_11201_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_11201_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_11201_full: ### IGT changes ### Warnings * igt@pm_rc6_residency@rc6-accuracy: - shard-kbl: PASS -> SKIP Known issues Here are the changes found in Patchwork_11201_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ppgtt@blt-vs-render-ctx0: - shard-skl: NOTRUN -> TIMEOUT [fdo#108039] * igt@kms_atomic_transition@plane-all-modeset-transition-internal-panels: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] +4 * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b: - shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] +2 * igt@kms_color@pipe-b-legacy-gamma: - shard-apl: PASS -> FAIL [fdo#104782] * igt@kms_cursor_crc@cursor-128x128-sliding: - shard-iclb: NOTRUN -> FAIL [fdo#103232] * igt@kms_cursor_crc@cursor-128x128-suspend: - shard-apl: PASS -> FAIL [fdo#103191] / [fdo#103232] +1 * igt@kms_cursor_crc@cursor-256x85-random: - shard-apl: PASS -> FAIL [fdo#103232] +1 * igt@kms_fbcon_fbt@psr-suspend: - shard-iclb: NOTRUN -> FAIL [fdo#107882] * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: - shard-glk: PASS -> FAIL [fdo#105363] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt: - shard-apl: PASS -> FAIL [fdo#103167] +2 * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-move: - shard-iclb: PASS -> FAIL [fdo#103167] +9 * igt@kms_plane@pixel-format-pipe-b-planes-source-clamping: - shard-skl: NOTRUN -> DMESG-WARN [fdo#106885] * igt@kms_plane@pixel-format-pipe-c-planes-source-clamping: - shard-apl: PASS -> FAIL [fdo#108948] * igt@kms_plane@plane-position-covered-pipe-b-planes: - shard-iclb: PASS -> FAIL [fdo#103166] +1 * igt@kms_plane_alpha_blend@pipe-a-alpha-transparant-fb: - shard-skl: NOTRUN -> FAIL [fdo#108145] * igt@kms_plane_alpha_blend@pipe-b-alpha-7efc: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] / [fdo#108336] +1 * igt@kms_plane_alpha_blend@pipe-c-alpha-transparant-fb: - shard-iclb: PASS -> DMESG-FAIL [fdo#107724] * igt@kms_plane_multiple@atomic-pipe-c-tiling-x: - shard-apl: PASS -> FAIL [fdo#103166] +1 * igt@kms_rotation_crc@multiplane-rotation-cropping-top: - shard-kbl: PASS -> DMESG-FAIL [fdo#108950] * igt@kms_setmode@basic: - shard-hsw: PASS -> FAIL [fdo#99912] * igt@pm_rpm@gem-idle: - shard-iclb: PASS -> INCOMPLETE [fdo#107713] / [fdo#108840] * igt@pm_rpm@i2c: - shard-skl: PASS -> INCOMPLETE [fdo#107807] Possible fixes * igt@gem_exec_suspend@basic-s4-devices: - shard-kbl: DMESG-WARN [fdo#103558] / [fdo#105602] / [fdo#107139] -> PASS * igt@gem_userptr_blits@readonly-unsync: - shard-skl: TIMEOUT [fdo#108887] -> PASS * igt@kms_busy@extended-pageflip-hang-newfb-render-b: - shard-glk: DMESG-WARN [fdo#107956] -> PASS * igt@kms_chv_cursor_fail@pipe-b-64x64-left-edge: - shard-skl: FAIL [fdo#104671] -> PASS * igt@kms_cursor_crc@cursor-256x256-sliding: - shard-skl: FAIL [fdo#103232] -> PASS * igt@kms_cursor_crc@cursor-256x85-onscreen: - shard-apl: FAIL [fdo#103232] -> PASS * igt@kms_cursor_crc@cursor-64x64-suspend: - shard-apl: FAIL [fdo#103191] / [fdo#103232] -> PASS * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: FAIL [fdo#105363] -> PASS * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-blt: - shard-glk: FAIL [fdo#103167] -> PASS * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-mmap-wc: - shard-iclb: FAIL [fdo#103167] -> PASS +1 * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c: - shard-skl: FAIL [fdo#107362] -> PASS * igt@kms_plane@plane-panning-bottom-right-pipe-b-planes: - shard-skl: FAIL [fdo#103166] -> PASS * igt@kms_plane@plane-position-covered-pipe-b-planes: - shard-glk: FAIL [fdo#103166] -> PASS +1 * igt@kms_plane_alpha_blend@pipe-c-coverage-7ef
Re: [Intel-gfx] [PATCH] drm/i915/icl: Apply WaEnablePreemptionGranularityControlByUMD
On Mon, Jan 07, 2019 at 01:23:50PM +0100, Michał Winiarski wrote:
> On Mon, Jan 07, 2019 at 01:01:16PM +0200, Joonas Lahtinen wrote:
> > Quoting José Roberto de Souza (2019-01-04 19:37:00)
> > > According to Workaround database ICL also needs
> > > WaEnablePreemptionGranularityControlByUMD, to allow userspace to do
> > > fine-granularity preemptions per-context.
> >
> > I must wonder where is the userspace component that needs this, and why
> > it hasn't been noticed earlier?
> >
> > Or is this one more of the cases when no userspace actually uses the
> > register?
>
> It's used:
> https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/mesa/drivers/dri/i965/brw_state_upload.c#L64
>
> -Michał
Wasn't this just an artificial i915-only workaround that was added to
prevent breakage of pre-preemption UMD's? Initial gen9 driver releases
didn't support preemption, so when preemption support did get added to
i915, the kernel had to force object-level off by default at context
creation to avoid breaking old userspace that didn't build batch buffers
with all the necessary preemption workarounds. This CS_CHICKEN1
register was then exposed to userspace so that newer, preemption-aware
userspace could opt back in if it properly supported preemption.
For gen11, there shouldn't be any "old" userspace around that doesn't
support preemption, so shouldn't the kernel just leave object-level
preemption enabled by default (meaning there's no need to expose this
register to userspace to allow it to explicitly opt-in)?
Matt
>
> > Regards, Joonas
> >
> > >
> > > BSpec: 11348
> > > Cc: Oscar Mateo
> > > Cc: Radhakrishna Sripada
> > > Signed-off-by: José Roberto de Souza
> > > ---
> > > drivers/gpu/drm/i915/intel_workarounds.c | 9 ++---
> > > 1 file changed, 6 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
> > > b/drivers/gpu/drm/i915/intel_workarounds.c
> > > index 480c53a2ecb5..bbc5a66faa07 100644
> > > --- a/drivers/gpu/drm/i915/intel_workarounds.c
> > > +++ b/drivers/gpu/drm/i915/intel_workarounds.c
> > > @@ -1014,7 +1014,7 @@ static void gen9_whitelist_build(struct
> > > i915_wa_list *w)
> > > /* WaVFEStateAfterPipeControlwithMediaStateClear:skl,bxt,glk,cfl
> > > */
> > > whitelist_reg(w, GEN9_CTX_PREEMPT_REG);
> > >
> > > - /*
> > > WaEnablePreemptionGranularityControlByUMD:skl,bxt,kbl,cfl,[cnl] */
> > > + /*
> > > WaEnablePreemptionGranularityControlByUMD:skl,bxt,kbl,cfl,[cnl,icl] */
> > > whitelist_reg(w, GEN8_CS_CHICKEN1);
> > >
> > > /* WaAllowUMDToModifyHDCChicken1:skl,bxt,kbl,glk,cfl */
> > > @@ -1068,6 +1068,9 @@ static void icl_whitelist_build(struct i915_wa_list
> > > *w)
> > >
> > > /* WaAllowUMDToModifySamplerMode:icl */
> > > whitelist_reg(w, GEN10_SAMPLER_MODE);
> > > +
> > > + /* WaEnablePreemptionGranularityControlByUMD:icl */
> > > + whitelist_reg(w, GEN8_CS_CHICKEN1);
> > > }
> > >
> > > void intel_engine_init_whitelist(struct intel_engine_cs *engine)
> > > @@ -1186,8 +1189,8 @@ static void rcs_engine_wa_init(struct
> > > intel_engine_cs *engine)
> > > GEN7_DISABLE_SAMPLER_PREFETCH);
> > > }
> > >
> > > - if (IS_GEN(i915, 9) || IS_CANNONLAKE(i915)) {
> > > - /*
> > > WaEnablePreemptionGranularityControlByUMD:skl,bxt,kbl,cfl,cnl */
> > > + if (IS_GEN_RANGE(i915, 9, 11)) {
> > > + /*
> > > WaEnablePreemptionGranularityControlByUMD:skl,bxt,kbl,cfl,cnl,icl */
> > > wa_masked_en(wal,
> > > GEN7_FF_SLICE_CS_CHICKEN1,
> > > GEN9_FFSC_PERCTX_PREEMPT_CTRL);
> > > --
> > > 2.20.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
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 21/39] drm/i915/guc: Disable global reset
Quoting Daniele Ceraolo Spurio (2019-01-07 18:31:52)
>
>
> On 01/02/2019 01:41 AM, Chris Wilson wrote:
> > The guc (and huc) currently inexcruitably depend on struct_mutex for
> > device reinitialisation from inside the reset, and indeed taking any
> > mutex here is verboten (as we must be able to reset from underneath any
> > of our mutexes). That makes recovering the guc unviable without, for
> > example, reserving contiguous vma space and pages for it to use.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/i915_reset.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reset.c
> > b/drivers/gpu/drm/i915/i915_reset.c
> > index f5da67f1bc04..77fc2f74e427 100644
> > --- a/drivers/gpu/drm/i915/i915_reset.c
> > +++ b/drivers/gpu/drm/i915/i915_reset.c
> > @@ -590,6 +590,9 @@ int intel_gpu_reset(struct drm_i915_private *i915,
> > unsigned int engine_mask)
> >
> > bool intel_has_gpu_reset(struct drm_i915_private *i915)
> > {
> > + if (USES_GUC(i915))
> > + return false;
> > +
>
> Do we need to tweak the getparam so we can report that we have engine
> reset but not full reset?
Oh, we cut a corner. But is userspace ready for having one but not the
other... What userspace other than igt, I wonder. I suspect even igt
treats it as boolean for the large part, with just a few correctly
checking when they want per-engine resets.
> Also, this is a regression of capabilities when GuC is enabled, so we
> need to make lockless reset work with GuC soon.
Hah. It frequently fails to recover after reset :-p
> Were you already
> planning/working on something along the lines of the possible solution
> mentioned in the commit message? Just trying to understand what the
> status is before jumping in to avoid duplication of work ;)
The compromises required (reserving space for the firmware) seem like it
will just end up with a lot of screaming to make it mutexless today.
I was planning on coming back to it after breaking up the struct_mutex
to see which locks were required. If we get to the point where we can
guarantee that those locks are never held when waiting (inc.
allocations) (the plan there is to annotate them with lockdep to catch
waiters), then we can safely use those inside the reset.
Or maybe we can get away with using just a single page in the global gtt
and just loading the firmware piecemeal, or something.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Mark the whole mock device as DMA capable (rev2)
== Series Details == Series: drm/i915/selftests: Mark the whole mock device as DMA capable (rev2) URL : https://patchwork.freedesktop.org/series/54825/ State : success == Summary == CI Bug Log - changes from CI_DRM_5369 -> Patchwork_11204 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/54825/revisions/2/mbox/ Known issues Here are the changes found in Patchwork_11204 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@userptr: - fi-kbl-8809g: PASS -> DMESG-WARN [fdo#108965] * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: PASS -> FAIL [fdo#108767] * igt@kms_frontbuffer_tracking@basic: - fi-byt-clapper: PASS -> FAIL [fdo#103167] * igt@prime_vgem@basic-fence-flip: - fi-gdg-551: PASS -> FAIL [fdo#103182] Possible fixes * igt@gem_mmap_gtt@basic-small-copy: - fi-glk-dsi: INCOMPLETE [fdo#103359] / [k.org#198133] -> PASS * igt@i915_selftest@live_coherency: - fi-gdg-551: DMESG-FAIL [fdo#107164] -> PASS * igt@i915_selftest@live_hangcheck: - fi-bwr-2160:DMESG-FAIL [fdo#108735] -> PASS * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: - fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: - fi-cfl-8109u: INCOMPLETE [fdo#106070] / [fdo#108126] -> PASS [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182 [fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359 [fdo#106070]: https://bugs.freedesktop.org/show_bug.cgi?id=106070 [fdo#107164]: https://bugs.freedesktop.org/show_bug.cgi?id=107164 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#108126]: https://bugs.freedesktop.org/show_bug.cgi?id=108126 [fdo#108735]: https://bugs.freedesktop.org/show_bug.cgi?id=108735 [fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767 [fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965 [k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133 Participating hosts (49 -> 46) -- Additional (1): fi-pnv-d510 Missing(4): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan Build changes - * Linux: CI_DRM_5369 -> Patchwork_11204 CI_DRM_5369: 4d637a8d160356f01d22695ec1a76858bfb55758 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4756: 75081c6bfb9998bd7cbf35a7ac0578c683fe55a8 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_11204: a90742ce70c4f241ed8dcfcb55d72da9668757a1 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == a90742ce70c4 drm/i915/selftests: Mark the whole mock device as DMA capable == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11204/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 21/39] drm/i915/guc: Disable global reset
On 01/02/2019 01:41 AM, Chris Wilson wrote:
The guc (and huc) currently inexcruitably depend on struct_mutex for
device reinitialisation from inside the reset, and indeed taking any
mutex here is verboten (as we must be able to reset from underneath any
of our mutexes). That makes recovering the guc unviable without, for
example, reserving contiguous vma space and pages for it to use.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_reset.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reset.c
b/drivers/gpu/drm/i915/i915_reset.c
index f5da67f1bc04..77fc2f74e427 100644
--- a/drivers/gpu/drm/i915/i915_reset.c
+++ b/drivers/gpu/drm/i915/i915_reset.c
@@ -590,6 +590,9 @@ int intel_gpu_reset(struct drm_i915_private *i915, unsigned
int engine_mask)
bool intel_has_gpu_reset(struct drm_i915_private *i915)
{
+ if (USES_GUC(i915))
+ return false;
+
Do we need to tweak the getparam so we can report that we have engine
reset but not full reset?
Also, this is a regression of capabilities when GuC is enabled, so we
need to make lockless reset work with GuC soon. Were you already
planning/working on something along the lines of the possible solution
mentioned in the commit message? Just trying to understand what the
status is before jumping in to avoid duplication of work ;)
Thanks,
Daniele
return intel_get_gpu_reset(i915);
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915: Watchdog timeout: IRQ handler for gen8+
Quoting Tvrtko Ursulin (2019-01-07 16:58:24) > And finally there is one programming restriction which says: > > * SW must not preempt the workload which has watchdog enabled. Either > it must: > > a) disable preemption for that workload completely, or > b) disable the watchdog via mmio write before any write to ELSP Oh dear. I'm at a loss for words. Any ELSP write, *shudders*. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v3] tests/gem_shrink: Exercise OOM and other routes to shrinking in reasonable time
From: Tvrtko Ursulin
A set of subtests which exercises different paths to our shrinker code
(including the OOM killer) in predictable and reasonable time budget.
v2:
* Fix blacklist regexp. (Petri Latvala)
v3:
* Skip userptr test if not userptr support.
Signed-off-by: Tvrtko Ursulin
---
lib/igt_core.c| 19 ++
lib/igt_core.h| 1 +
tests/i915/gem_shrink.c | 401 ++
tests/intel-ci/blacklist.txt | 2 +-
tests/intel-ci/fast-feedback.testlist | 3 +
5 files changed, 425 insertions(+), 1 deletion(-)
diff --git a/lib/igt_core.c b/lib/igt_core.c
index 50d6008f6c82..351da0b4e020 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -1685,6 +1685,25 @@ void igt_stop_helper(struct igt_helper_process *proc)
assert(helper_was_alive(proc, status));
}
+/**
+ * igt_try_stop_helper:
+ * @proc: #igt_helper_process structure
+ *
+ * Terminates a helper process if it is still running and returns true, or
false
+ * if the process wasn't running.
+ */
+bool igt_try_stop_helper(struct igt_helper_process *proc)
+{
+ int status;
+
+ /* failure here means the pid is already dead and so waiting is safe */
+ kill(proc->pid, proc->use_SIGKILL ? SIGKILL : SIGTERM);
+
+ status = igt_wait_helper(proc);
+
+ return helper_was_alive(proc, status);
+}
+
static void children_exit_handler(int sig)
{
int status;
diff --git a/lib/igt_core.h b/lib/igt_core.h
index 6f8c3852a686..ed5ceebf1205 100644
--- a/lib/igt_core.h
+++ b/lib/igt_core.h
@@ -795,6 +795,7 @@ bool __igt_fork_helper(struct igt_helper_process *proc);
for (; __igt_fork_helper(proc); exit(0))
int igt_wait_helper(struct igt_helper_process *proc);
void igt_stop_helper(struct igt_helper_process *proc);
+bool igt_try_stop_helper(struct igt_helper_process *proc);
/* exit handler code */
diff --git a/tests/i915/gem_shrink.c b/tests/i915/gem_shrink.c
index c8e05814ee70..3d48cbebc2f9 100644
--- a/tests/i915/gem_shrink.c
+++ b/tests/i915/gem_shrink.c
@@ -26,6 +26,10 @@
*
* Exercise the shrinker by overallocating GEM objects
*/
+#include
+#include
+#include
+#include
#include "igt.h"
#include "igt_gt.h"
@@ -366,6 +370,378 @@ static void reclaim(unsigned engine, int timeout)
close(fd);
}
+static unsigned long get_meminfo(const char *info, const char *tag)
+{
+ const char *str;
+ unsigned long val;
+
+ str = strstr(info, tag);
+ if (str && sscanf(str + strlen(tag), " %lu", &val) == 1)
+ return val >> 10;
+
+ igt_warn("Unrecognised /proc/meminfo field: '%s'\n", tag);
+ return 0;
+}
+
+static unsigned long get_avail_ram_mb(void)
+{
+ int fd;
+ int ret;
+ char buf[4096];
+ unsigned long ram;
+
+ fd = open("/proc/meminfo", O_RDONLY);
+ igt_assert_fd(fd);
+
+ ret = read(fd, buf, sizeof(buf));
+ igt_assert(ret >= 0);
+
+ close(fd);
+
+ ram = get_meminfo(buf, "MemAvailable:");
+ ram += get_meminfo(buf, "Buffers:");
+ ram += get_meminfo(buf, "Cached:");
+ ram += get_meminfo(buf, "SwapCached:");
+
+ return ram;
+}
+
+struct test {
+#define TEST_BO(1)
+#define TEST_USERPTR (2)
+ unsigned int flags;
+ int fd;
+};
+
+static uint32_t __get_pages(int fd, unsigned long alloc)
+{
+ uint32_t handle = gem_create(fd, alloc);
+
+ gem_set_domain(fd, handle, I915_GEM_DOMAIN_GTT, 0);
+ gem_madvise(fd, handle, I915_MADV_DONTNEED);
+
+ return handle;
+}
+
+struct test_obj {
+ void *ptr;
+ uint32_t handle;
+};
+
+#define PAGE_SIZE 4096
+static void
+__get_userptr(int fd, struct test_obj *obj, unsigned long sz)
+{
+ struct local_i915_gem_userptr userptr = { };
+ void *ptr;
+
+ igt_assert_eq(sz & 4095, 0);
+
+ ptr = mmap(NULL, sz, PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
+ assert(ptr != MAP_FAILED);
+
+ for (size_t page = 0; page < sz; page += PAGE_SIZE)
+ *(volatile uint32_t *)((unsigned char *)ptr + page) = 0;
+
+ userptr.user_size = sz;
+ userptr.user_ptr = to_user_pointer(ptr);
+ do_ioctl(fd, LOCAL_IOCTL_I915_GEM_USERPTR, &userptr);
+
+ gem_set_domain(fd, userptr.handle, I915_GEM_DOMAIN_GTT, 0);
+ gem_madvise(fd, userptr.handle, I915_MADV_DONTNEED);
+
+ obj->ptr = ptr;
+ obj->handle = userptr.handle;
+}
+
+/*
+ * Use a specific way of using up memory until we are below a certain
threshold.
+ */
+static void *mempressure(void *arg)
+{
+ const unsigned int free_threshold_mb = 256;
+ struct test_obj *list = NULL;
+ struct test *test = arg;
+ const unsigned int sz_mb = 2;
+ const unsigned int sz = sz_mb << 20;
+ unsigned int n = 0, max = 0;
+ unsigned int blocks;
+
+ for (;;) {
+ unsigned long ram_mb = get_avail_ram_mb();
+
+ if (!list) {
+
[Intel-gfx] [PATCH] drm/i915/selftests: Mark the whole mock device as DMA capable
Being a mock device, we suffer no DMA restrictions, so set the coherent
mask to 64b.
v2: Fix up mock_huge_selftests
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/selftests/huge_pages.c | 4
drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 +-
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/huge_pages.c
b/drivers/gpu/drm/i915/selftests/huge_pages.c
index a0c7cbc212ba..6c10734e948d 100644
--- a/drivers/gpu/drm/i915/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/selftests/huge_pages.c
@@ -1702,7 +1702,6 @@ int i915_gem_huge_page_mock_selftests(void)
};
struct drm_i915_private *dev_priv;
struct i915_hw_ppgtt *ppgtt;
- struct pci_dev *pdev;
int err;
dev_priv = mock_gem_device();
@@ -1712,9 +1711,6 @@ int i915_gem_huge_page_mock_selftests(void)
/* Pretend to be a device which supports the 48b PPGTT */
mkwrite_device_info(dev_priv)->ppgtt = INTEL_PPGTT_FULL_4LVL;
- pdev = dev_priv->drm.pdev;
- dma_coerce_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(39));
-
mutex_lock(&dev_priv->drm.struct_mutex);
ppgtt = i915_ppgtt_create(dev_priv, ERR_PTR(-ENODEV));
if (IS_ERR(ppgtt)) {
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index 43ed8b28aeaa..baa3c38919de 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -147,7 +147,7 @@ struct drm_i915_private *mock_gem_device(void)
pdev->class = PCI_BASE_CLASS_DISPLAY << 16;
pdev->dev.release = release_dev;
dev_set_name(&pdev->dev, "mock");
- dma_coerce_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
+ dma_coerce_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
#if IS_ENABLED(CONFIG_IOMMU_API) && defined(CONFIG_INTEL_IOMMU)
/* hack to disable iommu for the fake device; force identity mapping */
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Mark the whole mock device as DMA capable
Quoting Matthew Auld (2019-01-07 18:01:18) > On Mon, 7 Jan 2019 at 16:28, Chris Wilson wrote: > > > > Being a mock device, we suffer no DMA restrictions, so set the coherent > > mask to 64b. > > > > Signed-off-by: Chris Wilson > > Care to get rid of the call in i915_gem_huge_page_mock_selftests? You strike a hard bargain. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PULL] topic/drmp-cleanup for drm-misc-next and drm-intel-next-queued
Hi Jani, On Wed, Jan 02, 2019 at 12:00:49PM +0200, Jani Nikula wrote: > I embarked on removing drmP.h includes from i915, but that requires a > bunch of drm header cleanup to add relevant includes and forward > declarations. Due to the timing, propagating the patches back to i915 > would take eons, so Daniel suggested a topic branch to be merged both to > drm-misc-next and drm-intel-next-queued. So here it is, with $(git > merge-base drm-misc-next drm-intel-next-queued) as the starting point. > > The topic branch has been part of drm-tip since, uh, last year, but I > did just force push it to update the commit messages to reflect > Laurent's review. No code changes. > > I'll merge the same thing to i915 after it's been pulled to > drm-misc-next, and with this, I should be able to get rid of all drmP.h > includes in i915. I merged the PR, and it's on its way to Daniel and Dave now. Thanks Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com 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-next
Hi Dave, Daniel, Here is the first PR for 5.1 for drm-misc-next. This is my first PR ever for drm-misc, so please let me know if I screwed up somehow :) Thanks! Maxime drm-misc-next-2019-01-07-1: drm-misc-next for 5.1: UAPI Changes: Cross-subsystem Changes: - Turn dma-buf fence sequence numbers into 64 bit numbers Core Changes: - Move to a common helper for the DP MST hotplug for radeon, i915 and amdgpu - i2c improvements for drm_dp_mst - Removal of drm_syncobj_cb - Introduction of an helper to create and attach the TV margin properties Driver Changes: - Improve cache flushes for v3d - Reflection support for vc4 - HDMI overscan support for vc4 - Add implicit fencing support for rockchip and sun4i - Switch to generic fbdev emulation for virtio The following changes since commit 0b258ed1a219a9776e8f6967eb34837ae0332e64: drm: revert "expand replace_fence to support timeline point v2" (2018-12-05 11:01:11 +0100) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2019-01-07-1 for you to fetch changes up to 1c95f662fceeb8ae2f34e3de9478e21fd31f09dd: Merge tag 'topic/drmp-cleanup-2019-01-02' of git://anongit.freedesktop.org/drm/drm-intel into drm-misc-next (2019-01-07 16:43:24 +0100) drm-misc-next for 5.1: UAPI Changes: Cross-subsystem Changes: - Turn dma-buf fence sequence numbers into 64 bit numbers Core Changes: - Move to a common helper for the DP MST hotplug for radeon, i915 and amdgpu - i2c improvements for drm_dp_mst - Removal of drm_syncobj_cb - Introduction of an helper to create and attach the TV margin properties Driver Changes: - Improve cache flushes for v3d - Reflection support for vc4 - HDMI overscan support for vc4 - Add implicit fencing support for rockchip and sun4i - Switch to generic fbdev emulation for virtio Archit Taneja (1): MAINTAINERS: drm: Remove myself as drm-bridge maintainer Boris Brezillon (7): drm/vc4: Fix negative X/Y positioning on SAND planes drm/vc4: Add support for X/Y reflection drm/connector: Fix drm_mode_create_tv_properties() doc drm/connector: Clarify the unit of TV margins drm/connector: Allow creation of margin props alone drm/vc4: Take margin setup into account when updating planes drm/vc4: Attach margin props to the HDMI connector Brajeswar Ghosh (1): drm/drm_drv.c: Remove duplicate header Chris Wilson (1): drm: Reorder set_property_atomic to avoid returning with an active ww_ctx Christian König (4): drm/v3d: fix broken build dma-buf: make fence sequence numbers 64 bit v2 drm/etnaviv: fix for 64bit seqno change drm/syncobj: remove drm_syncobj_cb and cleanup Dan Carpenter (2): drm: Fix an error pointer dereference() drm/ati_pcigart: Fix error code in drm_ati_pcigart_init() Daniel Vetter (3): drm/dp-mst-helper: Remove hotplug callback drm/qxl: Don't set the dpms hook drm/xen: Don't set the dpms hook Eric Anholt (6): drm/v3d: Document cache flushing ABI. drm/v3d: Drop unused v3d_flush_caches(). drm/v3d: Don't bother flushing L1TD at job start. drm/v3d: Drop the wait for L2T flush to complete. drm/v3d: Stop trying to flush L2C on V3D 3.3+ drm/v3d: Invalidate the caches from the outside in. Gerd Hoffmann (3): drm/qxl: add spice-devel list to MAINTAINERS drm/virtio: switch to generic fbdev emulation drm/bochs: add edid present check Heiko Stuebner (1): drm/rockchip: Add implicit fencing support for planes Jani Nikula (5): drm: un-inline drm_legacy_findmap() drm: include kernel.h and agp_backend.h from intel-gtt.h drm: include idr.h from drm_file.h drm: include types.h from drm_hdcp.h drm: forward declare struct drm_file in drm_syncobj.h Kuninori Morimoto (1): drm: dw-hdmi-i2s: convert to SPDX identifiers Lyude Paul (3): drm/dp_mst: Fix memory leak in drm_dp_mst_topology_mgr_destroy() drm/dp_mst: Remove bogus conditional in drm_dp_update_payload_part1() drm/dp_mst: Refactor drm_dp_update_payload_part1() Maxime Ripard (1): Merge tag 'topic/drmp-cleanup-2019-01-02' of git://anongit.freedesktop.org/drm/drm-intel into drm-misc-next Mika Kuoppala (1): drm/i915: Compile fix for 64b dma-fence seqno Rob Clark (1): drm/atomic: integrate modeset lock with private objects Sam Ravnborg (1): drm: move DRM_IF_VERSION to drm_internal.h Shayenne da Luz Moura (2): drm: Rename crtc_idr as object_idr to KMS cleanups drm: Remove complete task from TODO documentation Ville Syrjälä (2): drm/dp/mst: Configure no_stop_bit correctly for remote i2c xfers drm/dp/mst: Validate REMOTE_I2C_READ harder Yangtao Li (1): dma-buf: Change to use DEFINE_SHOW_ATTR
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Mark the whole mock device as DMA capable
On Mon, 7 Jan 2019 at 16:28, Chris Wilson wrote: > > Being a mock device, we suffer no DMA restrictions, so set the coherent > mask to 64b. > > Signed-off-by: Chris Wilson Care to get rid of the call in i915_gem_huge_page_mock_selftests? Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v2] tests/gem_shrink: Exercise OOM and other routes to shrinking in reasonable time
From: Tvrtko Ursulin
A set of subtests which exercises different paths to our shrinker code
(including the OOM killer) in predictable and reasonable time budget.
v2:
* Fix blacklist regexp. (Petri Latvala)
Signed-off-by: Tvrtko Ursulin
---
lib/igt_core.c| 19 ++
lib/igt_core.h| 1 +
tests/i915/gem_shrink.c | 399 ++
tests/intel-ci/blacklist.txt | 2 +-
tests/intel-ci/fast-feedback.testlist | 3 +
5 files changed, 423 insertions(+), 1 deletion(-)
diff --git a/lib/igt_core.c b/lib/igt_core.c
index 50d6008f6c82..351da0b4e020 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -1685,6 +1685,25 @@ void igt_stop_helper(struct igt_helper_process *proc)
assert(helper_was_alive(proc, status));
}
+/**
+ * igt_try_stop_helper:
+ * @proc: #igt_helper_process structure
+ *
+ * Terminates a helper process if it is still running and returns true, or
false
+ * if the process wasn't running.
+ */
+bool igt_try_stop_helper(struct igt_helper_process *proc)
+{
+ int status;
+
+ /* failure here means the pid is already dead and so waiting is safe */
+ kill(proc->pid, proc->use_SIGKILL ? SIGKILL : SIGTERM);
+
+ status = igt_wait_helper(proc);
+
+ return helper_was_alive(proc, status);
+}
+
static void children_exit_handler(int sig)
{
int status;
diff --git a/lib/igt_core.h b/lib/igt_core.h
index 6f8c3852a686..ed5ceebf1205 100644
--- a/lib/igt_core.h
+++ b/lib/igt_core.h
@@ -795,6 +795,7 @@ bool __igt_fork_helper(struct igt_helper_process *proc);
for (; __igt_fork_helper(proc); exit(0))
int igt_wait_helper(struct igt_helper_process *proc);
void igt_stop_helper(struct igt_helper_process *proc);
+bool igt_try_stop_helper(struct igt_helper_process *proc);
/* exit handler code */
diff --git a/tests/i915/gem_shrink.c b/tests/i915/gem_shrink.c
index c8e05814ee70..7c002de0ef1f 100644
--- a/tests/i915/gem_shrink.c
+++ b/tests/i915/gem_shrink.c
@@ -26,6 +26,10 @@
*
* Exercise the shrinker by overallocating GEM objects
*/
+#include
+#include
+#include
+#include
#include "igt.h"
#include "igt_gt.h"
@@ -366,6 +370,376 @@ static void reclaim(unsigned engine, int timeout)
close(fd);
}
+static unsigned long get_meminfo(const char *info, const char *tag)
+{
+ const char *str;
+ unsigned long val;
+
+ str = strstr(info, tag);
+ if (str && sscanf(str + strlen(tag), " %lu", &val) == 1)
+ return val >> 10;
+
+ igt_warn("Unrecognised /proc/meminfo field: '%s'\n", tag);
+ return 0;
+}
+
+static unsigned long get_avail_ram_mb(void)
+{
+ int fd;
+ int ret;
+ char buf[4096];
+ unsigned long ram;
+
+ fd = open("/proc/meminfo", O_RDONLY);
+ igt_assert_fd(fd);
+
+ ret = read(fd, buf, sizeof(buf));
+ igt_assert(ret >= 0);
+
+ close(fd);
+
+ ram = get_meminfo(buf, "MemAvailable:");
+ ram += get_meminfo(buf, "Buffers:");
+ ram += get_meminfo(buf, "Cached:");
+ ram += get_meminfo(buf, "SwapCached:");
+
+ return ram;
+}
+
+struct test {
+#define TEST_BO(1)
+#define TEST_USERPTR (2)
+ unsigned int flags;
+ int fd;
+};
+
+static uint32_t __get_pages(int fd, unsigned long alloc)
+{
+ uint32_t handle = gem_create(fd, alloc);
+
+ gem_set_domain(fd, handle, I915_GEM_DOMAIN_GTT, 0);
+ gem_madvise(fd, handle, I915_MADV_DONTNEED);
+
+ return handle;
+}
+
+struct test_obj {
+ void *ptr;
+ uint32_t handle;
+};
+
+#define PAGE_SIZE 4096
+static void
+__get_userptr(int fd, struct test_obj *obj, unsigned long sz)
+{
+ struct local_i915_gem_userptr userptr = { };
+ void *ptr;
+
+ igt_assert_eq(sz & 4095, 0);
+
+ ptr = mmap(NULL, sz, PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
+ assert(ptr != MAP_FAILED);
+
+ for (size_t page = 0; page < sz; page += PAGE_SIZE)
+ *(volatile uint32_t *)((unsigned char *)ptr + page) = 0;
+
+ userptr.user_size = sz;
+ userptr.user_ptr = to_user_pointer(ptr);
+ do_ioctl(fd, LOCAL_IOCTL_I915_GEM_USERPTR, &userptr);
+
+ gem_set_domain(fd, userptr.handle, I915_GEM_DOMAIN_GTT, 0);
+ gem_madvise(fd, userptr.handle, I915_MADV_DONTNEED);
+
+ obj->ptr = ptr;
+ obj->handle = userptr.handle;
+}
+
+/*
+ * Use a specific way of using up memory until we are below a certain
threshold.
+ */
+static void *mempressure(void *arg)
+{
+ const unsigned int free_threshold_mb = 256;
+ struct test_obj *list = NULL;
+ struct test *test = arg;
+ const unsigned int sz_mb = 2;
+ const unsigned int sz = sz_mb << 20;
+ unsigned int n = 0, max = 0;
+ unsigned int blocks;
+
+ for (;;) {
+ unsigned long ram_mb = get_avail_ram_mb();
+
+ if (!list) {
+ /*
+* On first pass
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] tests/gem_shrink: Exercise OOM and other routes to shrinking in reasonable time
On 07/01/2019 11:28, Petri Latvala wrote: On Mon, Jan 07, 2019 at 11:12:30AM +, Tvrtko Ursulin wrote: On 07/01/2019 11:01, Petri Latvala wrote: On Fri, Jan 04, 2019 at 03:37:09PM +, Tvrtko Ursulin wrote: diff --git a/tests/intel-ci/blacklist.txt b/tests/intel-ci/blacklist.txt index 73d127603d28..d76a4b3b1c71 100644 --- a/tests/intel-ci/blacklist.txt +++ b/tests/intel-ci/blacklist.txt @@ -60,6 +60,7 @@ igt@gem_ring_sync_copy(@.*)? igt@gem_ring_sync_loop(@.*)? igt@gem_seqno_wrap(@.*)? igt@gem_shrink@(?!reclaim$).* +igt@gem_shrink@(?!reclaims-and-oom).* igt@gem_softpin@.*(hang|S4).* igt@gem_spin_batch(@.*)? igt@gem_stolen@.*hibernate.* In case you didn't notice: The first gem_shrink line removes the reclaims-and-oom* subtests, and the second line (the one you added) then removes the 'reclaim' subtest, resulting in all gem_shrink subtests blacklisted. No I haven't thank you. Interestingly the reclaim subtest still did run. https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2185/shards-all.html it's NOTRUN on all machines on patched IGT. My fail while looking at the pages.. I saw the test mentioned in the list but fail to spot that was only because it was run in the baseline. :I Okay, but in essence should this work then: igt@gem_shrink@(?!reclaim).* To blacklist everything apart from reclaims and reclaims-and-oom.* subtests? Yeah that looks correct. Thanks, I'll send a v2 shortly. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Mark the whole mock device as DMA capable
== Series Details == Series: drm/i915/selftests: Mark the whole mock device as DMA capable URL : https://patchwork.freedesktop.org/series/54825/ State : success == Summary == CI Bug Log - changes from CI_DRM_5369 -> Patchwork_11203 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/54825/revisions/1/mbox/ Known issues Here are the changes found in Patchwork_11203 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@userptr: - fi-kbl-8809g: PASS -> DMESG-WARN [fdo#108965] * igt@gem_exec_suspend@basic-s3: - fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718] * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: PASS -> FAIL [fdo#108767] * igt@kms_flip@basic-flip-vs-modeset: - fi-skl-6700hq: PASS -> DMESG-WARN [fdo#105998] * igt@kms_pipe_crc_basic@read-crc-pipe-b: - fi-byt-clapper: PASS -> FAIL [fdo#107362] Possible fixes * igt@gem_mmap_gtt@basic-small-copy: - fi-glk-dsi: INCOMPLETE [fdo#103359] / [k.org#198133] -> PASS * igt@i915_selftest@live_coherency: - fi-gdg-551: DMESG-FAIL [fdo#107164] -> PASS * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: - fi-cfl-8109u: INCOMPLETE [fdo#106070] / [fdo#108126] -> PASS [fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359 [fdo#105998]: https://bugs.freedesktop.org/show_bug.cgi?id=105998 [fdo#106070]: https://bugs.freedesktop.org/show_bug.cgi?id=106070 [fdo#107164]: https://bugs.freedesktop.org/show_bug.cgi?id=107164 [fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#108126]: https://bugs.freedesktop.org/show_bug.cgi?id=108126 [fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767 [fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965 [k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133 Participating hosts (49 -> 46) -- Additional (1): fi-pnv-d510 Missing(4): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan Build changes - * Linux: CI_DRM_5369 -> Patchwork_11203 CI_DRM_5369: 4d637a8d160356f01d22695ec1a76858bfb55758 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4756: 75081c6bfb9998bd7cbf35a7ac0578c683fe55a8 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_11203: 4b05a574fb54fd0c84a164ca5952f9dd2d7db13b @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 4b05a574fb54 drm/i915/selftests: Mark the whole mock device as DMA capable == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11203/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915: Watchdog timeout: DRM kernel interface to set the timeout
On 07/01/2019 17:00, Tvrtko Ursulin wrote:
On 07/01/2019 12:38, Tvrtko Ursulin wrote:
[snip]
+#define GEN8_TIMESTAMP_CNTS_PER_USEC 12
+#define GEN9_LP_TIMESTAMP_CNTS_PER_USEC 19
+static inline u32 cs_timestamp_in_us(struct drm_i915_private *dev_priv)
+{
+ u32 cs_timestamp_base = dev_priv->cs_timestamp_base;
+
+ if (cs_timestamp_base)
+ return cs_timestamp_base;
+
+ switch (INTEL_GEN(dev_priv)) {
+ default:
+ MISSING_CASE(INTEL_GEN(dev_priv));
+ /* fall through */
+ case 9:
+ cs_timestamp_base = IS_GEN9_LP(dev_priv) ?
+ GEN9_LP_TIMESTAMP_CNTS_PER_USEC :
+ GEN8_TIMESTAMP_CNTS_PER_USEC;
+ break;
+ case 8:
+ cs_timestamp_base = GEN8_TIMESTAMP_CNTS_PER_USEC;
+ break;
+ }
+
+ dev_priv->cs_timestamp_base = cs_timestamp_base;
+ return cs_timestamp_base;
+}
We already have RUNTIME_INFO(i915)->cs_timestamp_frequency_khz and
read_timestamp_frequency which sets it.
Here I missed the mark, please ignore.
One thing I am not sure though is whether CTC_MODE register affects this
clock. In other words should this code read it to get the correct
effective tick duration.
Bspec chain of Watchdog Timers (14970) -> Reported Timestamp Count
(12610) ->
Timestamp Bases (13569) does not answer that for me.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [01/46] drm/i915: Return immediately if trylock fails for direct-reclaim
Quoting Patchwork (2019-01-07 17:10:25) > Possible regressions > > * igt@i915_missed_irq: > - shard-snb: PASS -> FAIL > - shard-kbl: PASS -> FAIL > - shard-hsw: PASS -> FAIL > - shard-skl: PASS -> FAIL > - shard-glk: PASS -> FAIL > - shard-apl: PASS -> FAIL It's not really a bug, just a failure in how we test. (Not that I could think of a better test.) The issue is that since we have coupled together the waiting + dma_fence, every time we retire/signal the fences, we remove the waiter. So in this test, the retire worker runs in the background signaling all the fences before the intel_breadcrumbs_hangcheck runs -- so we never see the missed interrupt as we do asynchronous polling. My conclusion is a patch to just remove the fake_irq as we do not need it anymore. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [01/46] drm/i915: Return immediately if trylock fails for direct-reclaim
== Series Details == Series: series starting with [01/46] drm/i915: Return immediately if trylock fails for direct-reclaim URL : https://patchwork.freedesktop.org/series/54803/ State : failure == Summary == CI Bug Log - changes from CI_DRM_5368_full -> Patchwork_11200_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_11200_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_11200_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_11200_full: ### IGT changes ### Possible regressions * igt@i915_missed_irq: - shard-snb: PASS -> FAIL - shard-kbl: PASS -> FAIL - shard-hsw: PASS -> FAIL - shard-skl: PASS -> FAIL - shard-glk: PASS -> FAIL - shard-apl: PASS -> FAIL Warnings * igt@pm_rc6_residency@rc6-accuracy: - shard-kbl: SKIP -> PASS Known issues Here are the changes found in Patchwork_11200_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_schedule@pi-ringfull-blt: - shard-skl: NOTRUN -> FAIL [fdo#103158] +2 * igt@gem_ppgtt@blt-vs-render-ctx0: - shard-skl: NOTRUN -> TIMEOUT [fdo#108039] * igt@i915_suspend@shrink: - shard-skl: NOTRUN -> INCOMPLETE [fdo#106886] - shard-apl: NOTRUN -> DMESG-WARN [fdo#107886] / [fdo#109244] * igt@kms_atomic_transition@1x-modeset-transitions: - shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108470] +1 * igt@kms_busy@extended-modeset-hang-newfb-render-b: - shard-kbl: NOTRUN -> DMESG-WARN [fdo#107956] +1 * igt@kms_busy@extended-modeset-hang-newfb-render-c: - shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] +4 * igt@kms_chv_cursor_fail@pipe-b-128x128-top-edge: - shard-skl: NOTRUN -> FAIL [fdo#104671] * igt@kms_color@pipe-b-ctm-0-25: - shard-skl: NOTRUN -> FAIL [fdo#108682] * igt@kms_color@pipe-b-ctm-max: - shard-apl: PASS -> FAIL [fdo#108147] * igt@kms_cursor_crc@cursor-256x85-onscreen: - shard-apl: PASS -> FAIL [fdo#103232] +1 * igt@kms_draw_crc@draw-method-rgb565-render-xtiled: - shard-skl: PASS -> FAIL [fdo#103184] * igt@kms_fbcon_fbt@psr-suspend: - shard-skl: NOTRUN -> FAIL [fdo#107882] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-mmap-gtt: - shard-skl: NOTRUN -> FAIL [fdo#105682] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite: - shard-apl: PASS -> FAIL [fdo#103167] +1 * igt@kms_frontbuffer_tracking@fbcpsr-suspend: - shard-iclb: PASS -> INCOMPLETE [fdo#106978] / [fdo#107713] * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-mmap-gtt: - shard-skl: NOTRUN -> FAIL [fdo#103167] * igt@kms_panel_fitting@legacy: - shard-skl: NOTRUN -> FAIL [fdo#105456] * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: - shard-skl: NOTRUN -> FAIL [fdo#103191] / [fdo#107362] +1 * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: - shard-skl: PASS -> INCOMPLETE [fdo#104108] / [fdo#107773] * igt@kms_plane@pixel-format-pipe-a-planes-source-clamping: - shard-skl: NOTRUN -> DMESG-WARN [fdo#106885] +2 * igt@kms_plane@pixel-format-pipe-c-planes-source-clamping: - shard-glk: PASS -> FAIL [fdo#108948] - shard-apl: PASS -> FAIL [fdo#108948] * igt@kms_plane_alpha_blend@pipe-a-alpha-7efc: - shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145] +1 * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max: - shard-skl: NOTRUN -> FAIL [fdo#108145] +2 * igt@kms_plane_multiple@atomic-pipe-a-tiling-x: - shard-apl: PASS -> FAIL [fdo#103166] * igt@kms_plane_multiple@atomic-pipe-a-tiling-y: - shard-glk: PASS -> FAIL [fdo#103166] +3 * igt@kms_plane_multiple@atomic-pipe-b-tiling-yf: - shard-skl: NOTRUN -> FAIL [fdo#103166] / [fdo#107815] * igt@kms_psr@suspend: - shard-skl: NOTRUN -> INCOMPLETE [fdo#107773] * igt@kms_rmfb@close-fd: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] +1 * igt@kms_rotation_crc@multiplane-rotation-cropping-top: - shard-kbl: PASS -> DMESG-FAIL [fdo#108950] - shard-iclb: PASS -> DMESG-FAIL [fdo#107724] * igt@kms_setmode@basic: - shard-skl: NOTRUN -> FAIL [fdo#99912] * igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend: - shard-kbl: PASS -> INCOMPLETE [fdo#103665] * igt@pm_rpm@unive
Re: [Intel-gfx] drm/i915: Watchdog timeout: DRM kernel interface to set the timeout
On 07/01/2019 12:38, Tvrtko Ursulin wrote:
[snip]
+#define GEN8_TIMESTAMP_CNTS_PER_USEC 12
+#define GEN9_LP_TIMESTAMP_CNTS_PER_USEC 19
+static inline u32 cs_timestamp_in_us(struct drm_i915_private *dev_priv)
+{
+ u32 cs_timestamp_base = dev_priv->cs_timestamp_base;
+
+ if (cs_timestamp_base)
+ return cs_timestamp_base;
+
+ switch (INTEL_GEN(dev_priv)) {
+ default:
+ MISSING_CASE(INTEL_GEN(dev_priv));
+ /* fall through */
+ case 9:
+ cs_timestamp_base = IS_GEN9_LP(dev_priv) ?
+ GEN9_LP_TIMESTAMP_CNTS_PER_USEC :
+ GEN8_TIMESTAMP_CNTS_PER_USEC;
+ break;
+ case 8:
+ cs_timestamp_base = GEN8_TIMESTAMP_CNTS_PER_USEC;
+ break;
+ }
+
+ dev_priv->cs_timestamp_base = cs_timestamp_base;
+ return cs_timestamp_base;
+}
We already have RUNTIME_INFO(i915)->cs_timestamp_frequency_khz and
read_timestamp_frequency which sets it.
Here I missed the mark, please ignore.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915: Watchdog timeout: IRQ handler for gen8+
On 07/01/2019 13:57, Chris Wilson wrote: Quoting Tvrtko Ursulin (2019-01-07 13:43:29) On 07/01/2019 11:58, Tvrtko Ursulin wrote: [snip] Note about future interaction with preemption: Preemption could happen in a command sequence prior to watchdog counter getting disabled, resulting in watchdog being triggered following preemption (e.g. when watchdog had been enabled in the low priority batch). The driver will need to explicitly disable the watchdog counter as part of the preemption sequence. Does the series take care of preemption? I did not find that it does. Oh. I hoped that the watchdog was saved as part of the context... Then despite preemption, the timeout would resume from where we left off as soon as it was back on the gpu. If the timeout remaining was context saved it would be much simpler (at least on first glance), please say it is. I made my comments going only by the text from the commit message and the absence of any preemption special handling. Having read the spec, the situation seems like this: * Watchdog control and threshold register are context saved and restored. * On a context switch watchdog counter is reset to zero and automatically disabled until enabled by a context restore or explicitly. So it sounds the commit message could be wrong that special handling is needed from this direction. But read till the end on the restriction listed. * Watchdog counter is reset to zero and is not accumulated across multiple submission of the same context (due preemption). I read this as - after preemption contexts gets a new full timeout allocation. Or in other words, if a context is preempted N times, it's cumulative watchdog timeout will be N * set value. This could be theoretically exploitable to bypass the timeout. If a client sets up two contexts with prio -1 and -2, and keeps submitting periodical no-op batches against prio -1 context, while prio -2 is it's own hog, then prio -2 context defeats the watchdog timer. I think.. would appreciate is someone challenged this conclusion. And finally there is one programming restriction which says: * SW must not preempt the workload which has watchdog enabled. Either it must: a) disable preemption for that workload completely, or b) disable the watchdog via mmio write before any write to ELSP This seems it contradiction with the statement that the counter gets disabled on context switch and stays disabled. I did not spot anything like this in the series. So it would seem the commit message is correct after all. It would be good if someone could re-read the bspec text on register 0x2178 to double check what I wrote. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] intel-ci/blacklist: Exclude gem_exec_parse lri
These exercise a certain HW misfeature, no longer protected by the kernel cmdparser due to obsolete userspace requirements. Signed-off-by: Chris Wilson Cc: Joonas Lahtinen --- tests/intel-ci/blacklist.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/intel-ci/blacklist.txt b/tests/intel-ci/blacklist.txt index 73d127603..0c6b87695 100644 --- a/tests/intel-ci/blacklist.txt +++ b/tests/intel-ci/blacklist.txt @@ -35,6 +35,7 @@ igt@gem_exec_gttfill@(?!.*basic).* igt@gem_exec_latency(@.*)? igt@gem_exec_lut_handle(@.*)? igt@gem_exec_nop@(?!.*(basic|signal-all)).* +igt@gem_exec_parse@.*lri.* igt@gem_exec_reloc@(?!.*basic).* igt@gem_exec_suspend@(?!.*basic).* igt@gem_exec_whisper@(?!normal$).* -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/selftests: Mark the whole mock device as DMA capable
Being a mock device, we suffer no DMA restrictions, so set the coherent mask to 64b. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c b/drivers/gpu/drm/i915/selftests/mock_gem_device.c index 6ade7b3ed579..3f465c7559ea 100644 --- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c +++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c @@ -150,7 +150,7 @@ struct drm_i915_private *mock_gem_device(void) pdev->class = PCI_BASE_CLASS_DISPLAY << 16; pdev->dev.release = release_dev; dev_set_name(&pdev->dev, "mock"); - dma_coerce_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32)); + dma_coerce_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64)); #if IS_ENABLED(CONFIG_IOMMU_API) && defined(CONFIG_INTEL_IOMMU) /* hack to disable iommu for the fake device; force identity mapping */ -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for ACPI/i915: Add support for PMIC MIPI sequence elements (rev2)
== Series Details == Series: ACPI/i915: Add support for PMIC MIPI sequence elements (rev2) URL : https://patchwork.freedesktop.org/series/54050/ State : success == Summary == CI Bug Log - changes from CI_DRM_5368_full -> Patchwork_11199_full Summary --- **WARNING** Minor unknown changes coming with Patchwork_11199_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_11199_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_11199_full: ### IGT changes ### Warnings * igt@pm_rc6_residency@rc6-accuracy: - shard-kbl: SKIP -> PASS Known issues Here are the changes found in Patchwork_11199_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@in-flight-internal-immediate: - shard-apl: PASS -> INCOMPLETE [fdo#103927] * igt@gem_exec_schedule@pi-ringfull-vebox: - shard-skl: NOTRUN -> FAIL [fdo#103158] * igt@gem_exec_whisper@normal: - shard-skl: PASS -> TIMEOUT [fdo#108592] * igt@gem_ppgtt@blt-vs-render-ctx0: - shard-skl: NOTRUN -> TIMEOUT [fdo#108039] * igt@kms_atomic_transition@1x-modeset-transitions: - shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108470] * igt@kms_atomic_transition@plane-all-transition: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] / [fdo#109225] * igt@kms_busy@extended-modeset-hang-newfb-render-b: - shard-kbl: NOTRUN -> DMESG-WARN [fdo#107956] +1 * igt@kms_busy@extended-modeset-hang-newfb-render-c: - shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] +4 * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b: - shard-iclb: NOTRUN -> DMESG-WARN [fdo#107956] * igt@kms_ccs@pipe-c-bad-aux-stride: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] +1 * igt@kms_chv_cursor_fail@pipe-b-128x128-top-edge: - shard-skl: NOTRUN -> FAIL [fdo#104671] * igt@kms_chv_cursor_fail@pipe-b-64x64-left-edge: - shard-skl: PASS -> FAIL [fdo#104671] * igt@kms_color@pipe-b-legacy-gamma: - shard-apl: PASS -> FAIL [fdo#104782] * igt@kms_cursor_crc@cursor-128x42-sliding: - shard-apl: PASS -> FAIL [fdo#103232] * igt@kms_cursor_crc@cursor-256x256-suspend: - shard-snb: PASS -> DMESG-WARN [fdo#102365] / [fdo#109241] * igt@kms_cursor_crc@cursor-64x21-random: - shard-iclb: NOTRUN -> FAIL [fdo#103232] * igt@kms_draw_crc@draw-method-rgb565-render-xtiled: - shard-skl: PASS -> FAIL [fdo#103184] * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-skl: NOTRUN -> FAIL [fdo#105363] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite: - shard-apl: PASS -> FAIL [fdo#103167] +1 * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-pwrite: - shard-glk: PASS -> FAIL [fdo#103167] +1 * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-mmap-wc: - shard-iclb: PASS -> FAIL [fdo#103167] +1 * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-mmap-gtt: - shard-skl: NOTRUN -> FAIL [fdo#103167] * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: - shard-skl: NOTRUN -> FAIL [fdo#103191] / [fdo#107362] * igt@kms_plane@pixel-format-pipe-b-planes-source-clamping: - shard-skl: NOTRUN -> DMESG-WARN [fdo#106885] * igt@kms_plane@plane-panning-bottom-right-pipe-b-planes: - shard-skl: PASS -> FAIL [fdo#103166] * igt@kms_plane_alpha_blend@pipe-b-alpha-transparant-fb: - shard-iclb: PASS -> DMESG-FAIL [fdo#107724] * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min: - shard-skl: NOTRUN -> FAIL [fdo#108145] * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: PASS -> FAIL [fdo#107815] * igt@kms_plane_multiple@atomic-pipe-a-tiling-x: - shard-apl: PASS -> FAIL [fdo#103166] * igt@kms_plane_multiple@atomic-pipe-b-tiling-x: - shard-glk: PASS -> FAIL [fdo#103166] * igt@kms_plane_multiple@atomic-pipe-b-tiling-yf: - shard-skl: NOTRUN -> FAIL [fdo#103166] / [fdo#107815] * igt@kms_plane_multiple@atomic-pipe-c-tiling-y: - shard-iclb: PASS -> FAIL [fdo#103166] * igt@kms_rotation_crc@primary-y-tiled-reflect-x-0: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] / [fdo#108336] +2 * igt@kms_setmode@basic: - shard-skl: NOTRUN -> FAIL [fdo#99912] - shard-kbl: PASS -> FAIL [fdo#99912] * igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend: - shard-kbl:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Reduce i915_request_alloc retirement to local context
== Series Details ==
Series: drm/i915: Reduce i915_request_alloc retirement to local context
URL : https://patchwork.freedesktop.org/series/54820/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5369 -> Patchwork_11202
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_11202 need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11202, 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/54820/revisions/1/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_11202:
### IGT changes ###
Warnings
* igt@pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: PASS -> SKIP
Known issues
Here are the changes found in Patchwork_11202 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload-no-display:
- fi-kbl-7567u: PASS -> DMESG-WARN [fdo#103558] / [fdo#105602] +1
* igt@i915_module_load@reload-with-fault-injection:
- fi-kbl-7567u: PASS -> DMESG-WARN [fdo#105602]
* igt@pm_rpm@basic-rte:
- fi-bsw-kefka: PASS -> FAIL [fdo#108800]
Possible fixes
* igt@gem_mmap_gtt@basic-small-copy:
- fi-glk-dsi: INCOMPLETE [fdo#103359] / [k.org#198133] -> PASS
* igt@i915_selftest@live_coherency:
- fi-gdg-551: DMESG-FAIL [fdo#107164] -> PASS
* igt@i915_selftest@live_hangcheck:
- fi-bwr-2160:DMESG-FAIL [fdo#108735] -> PASS
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
- fi-cfl-8109u: INCOMPLETE [fdo#106070] / [fdo#108126] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359
[fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#106070]: https://bugs.freedesktop.org/show_bug.cgi?id=106070
[fdo#107164]: https://bugs.freedesktop.org/show_bug.cgi?id=107164
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108126]: https://bugs.freedesktop.org/show_bug.cgi?id=108126
[fdo#108735]: https://bugs.freedesktop.org/show_bug.cgi?id=108735
[fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800
[fdo#109241]: https://bugs.freedesktop.org/show_bug.cgi?id=109241
[k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133
Participating hosts (49 -> 45)
--
Missing(4): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
Build changes
-
* Linux: CI_DRM_5369 -> Patchwork_11202
CI_DRM_5369: 4d637a8d160356f01d22695ec1a76858bfb55758 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4756: 75081c6bfb9998bd7cbf35a7ac0578c683fe55a8 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11202: ceb365430726ab7c83d716837df68aec68b90420 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
ceb365430726 drm/i915: Reduce i915_request_alloc retirement to local context
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11202/
___
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/debugfs: store rotation string buffer on stack
== Series Details == Series: drm/i915/debugfs: store rotation string buffer on stack URL : https://patchwork.freedesktop.org/series/54816/ State : success == Summary == CI Bug Log - changes from CI_DRM_5369 -> Patchwork_11201 Summary --- **WARNING** Minor unknown changes coming with Patchwork_11201 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_11201, 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/54816/revisions/1/mbox/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_11201: ### IGT changes ### Warnings * igt@pm_rpm@basic-pci-d3-state: - fi-byt-j1900: PASS -> SKIP Known issues Here are the changes found in Patchwork_11201 that come from known issues: ### IGT changes ### Issues hit * igt@kms_busy@basic-flip-b: - fi-gdg-551: PASS -> FAIL [fdo#103182] * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: PASS -> FAIL [fdo#108767] * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence: - fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362] * igt@pm_rpm@basic-rte: - fi-byt-j1900: PASS -> FAIL [fdo#108800] Possible fixes * igt@gem_mmap_gtt@basic-small-copy: - fi-glk-dsi: INCOMPLETE [fdo#103359] / [k.org#198133] -> PASS * igt@i915_selftest@live_coherency: - fi-gdg-551: DMESG-FAIL [fdo#107164] -> PASS * igt@i915_selftest@live_hangcheck: - fi-bwr-2160:DMESG-FAIL [fdo#108735] -> PASS * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: - fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: - fi-cfl-8109u: INCOMPLETE [fdo#106070] / [fdo#108126] -> PASS [fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182 [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191 [fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359 [fdo#106070]: https://bugs.freedesktop.org/show_bug.cgi?id=106070 [fdo#107164]: https://bugs.freedesktop.org/show_bug.cgi?id=107164 [fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#108126]: https://bugs.freedesktop.org/show_bug.cgi?id=108126 [fdo#108735]: https://bugs.freedesktop.org/show_bug.cgi?id=108735 [fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767 [fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800 [k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133 Participating hosts (49 -> 44) -- Additional (1): fi-pnv-d510 Missing(6): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-apl-guc fi-kbl-8809g Build changes - * Linux: CI_DRM_5369 -> Patchwork_11201 CI_DRM_5369: 4d637a8d160356f01d22695ec1a76858bfb55758 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4756: 75081c6bfb9998bd7cbf35a7ac0578c683fe55a8 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_11201: 67c358d496e5d191638e2ee97224f3dfdd70c602 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 67c358d496e5 drm/i915/debugfs: store rotation string buffer on stack == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11201/ ___ 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: Reduce i915_request_alloc retirement to local context
== Series Details ==
Series: drm/i915: Reduce i915_request_alloc retirement to local context
URL : https://patchwork.freedesktop.org/series/54820/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ceb365430726 drm/i915: Reduce i915_request_alloc retirement to local context
-:11: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#11:
References: 11abf0c5a021 ("drm/i915: Limit the backpressure for i915_request
allocation")
-:11: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 11abf0c5a021 ("drm/i915: Limit
the backpressure for i915_request allocation")'
#11:
References: 11abf0c5a021 ("drm/i915: Limit the backpressure for i915_request
allocation")
total: 1 errors, 1 warnings, 0 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 3/4] ACPI / PMIC: Add generic intel_soc_pmic_exec_mipi_pmic_seq_element handling
On Mon, Jan 07, 2019 at 12:15:55PM +0100, Hans de Goede wrote:
> Most PMIC-s use only a single i2c-address, so after verifying the
> i2c-address matches, we can simply pass the call to regmap_update_bits.
>
> This commit adds support for this and hooks this up for the xpower AXP288
> PMIC by setting the new pmic_i2c_address field.
>
> This fixes the following errors on display on / off on a Jumper Ezpad
> mini 3 and an Onda V80 plus tablet, both of which use the AXP288:
>
> intel_soc_pmic_exec_mipi_pmic_seq_element: Not implemented
> intel_soc_pmic_exec_mipi_pmic_seq_element: i2c-addr: 0x34 reg-addr ...
> [drm:mipi_exec_pmic [i915]] *ERROR* mipi_exec_pmic failed, error: -95
>
> Instead of these errors on both devices we now correctly turn on / off
> DLDO3 (through direct register manipulation). On the Onda V80 plus this
> fixes an issue with the backlight being brighter around the borders after
> an off / on cycle. This should also help to save some power when the
> display is off.
> + } else if (d->pmic_i2c_address) {
> + if (i2c_address == d->pmic_i2c_address) {
> + ret = regmap_update_bits(intel_pmic_opregion->regmap,
> + reg_address, mask, value);
> + } else {
> + pr_err("%s: Unexpected i2c-addr: 0x%02x (reg-addr 0x%x
> value 0x%x mask 0x%x)\n",
> +__func__, i2c_address, reg_address, value, mask);
> + ret = -ENXIO;
> + }
> --- a/drivers/acpi/pmic/intel_pmic_xpower.c
> +++ b/drivers/acpi/pmic/intel_pmic_xpower.c
> + .pmic_i2c_address = 0x34,
Can we just have a hook here instead of exposing PMIC I2C address?
Am I missing something in case it's not possible?
--
With Best Regards,
Andy Shevchenko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 2/4] ACPI / PMIC: Implement exec_mipi_pmic_seq_element for CHT Whiskey Cove PMIC
On Mon, Jan 07, 2019 at 12:15:54PM +0100, Hans de Goede wrote:
> Implement the exec_mipi_pmic_seq_element callback for the CHT Whiskey Cove
> PMIC.
>
> On some CHT devices this fixes the LCD panel not lighting up when it was
> not initialized by the GOP, because an external monitor was plugged in and
> the GOP initialized only the external monitor.
> + if (i2c_client_address > 0xff || reg_address > 0xff) {
> + pr_warn("%s warning addresses too big client 0x%x reg 0x%x\n",
> + __func__, i2c_client_address, reg_address);
I tried to parse the message and failed.
Perhaps something like
"%s: addresses too big for client 0x%x, reg 0x%x\n"
would be easier to understand?
> + return -ERANGE;
> + }
--
With Best Regards,
Andy Shevchenko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 1/4] ACPI / PMIC: Add support for executing PMIC MIPI sequence elements
On Mon, Jan 07, 2019 at 12:15:53PM +0100, Hans de Goede wrote:
> DSI LCD panels describe an initialization sequence in the Video BIOS
> Tables using so called MIPI sequences. One possible element in these
> sequences is a PMIC specific element of 15 bytes.
>
> Although this is not really an ACPI opregion, the ACPI opregion code is the
> closest thing we have. We need to have support for these PMIC specific MIPI
> sequence elements somwhere. Since we already instantiate a special platform
> device for Intel PMICs for the ACPI PMIC OpRegion handler to bind to,
> with PMIC specific implementations of the OpRegion, the handling of MIPI
> sequence PMIC elements fits very well in the ACPI PMIC OpRegion code.
>
> This commit adds a new intel_soc_pmic_exec_mipi_pmic_seq_element()
> function, which is to be backed by a PMIC specific
> exec_mipi_pmic_seq_element callback. This function will be called by the
> i915 code to execture MIPI sequence PMIC elements.
> +/**
> + * intel_soc_pmic_exec_mipi_pmic_seq_element - Execute PMIC MIPI sequence
I wonder if we need pmic duplication in the name.
> + * @i2c_address: I2C client address for the PMIC
> + * @reg_address: PMIC register address
> + * @value:New value for the register bits to change
> + * @mask: Mask indicating which register bits to change
> + *
> + * DSI LCD panels describe an initialization sequence in the i915 VBT (Video
> + * BIOS Tables) using so called MIPI sequences. One possible element in these
> + * sequences is a PMIC specific element of 15 bytes.
> + *
> + * This function executes these PMIC specific elements sending the embedded
> + * commands to the PMIC.
> + *
> + * Return 0 on success, < 0 on failure.
> + */
> +int intel_soc_pmic_exec_mipi_pmic_seq_element(u16 i2c_address, u32
> reg_address,
> + u32 value, u32 mask)
> +{
> + struct intel_pmic_opregion_data *d;
> + int ret;
> +
> + if (!intel_pmic_opregion) {
> + pr_warn("%s: No PMIC registered\n", __func__);
> + return -ENXIO;
> + }
> +
> + d = intel_pmic_opregion->data;
> +
> + mutex_lock(&intel_pmic_opregion->lock);
> +
> + if (d->exec_mipi_pmic_seq_element) {
> + ret = d->exec_mipi_pmic_seq_element(intel_pmic_opregion->regmap,
> + i2c_address, reg_address,
> + value, mask);
Here it's not quite a dup, but it's implied by the name of structure...
> + } else {
> + pr_warn("%s: Not implemented\n", __func__);
> + pr_warn("%s: i2c-addr: 0x%x reg-addr 0x%x value 0x%x mask
> 0x%x\n",
> + __func__, i2c_address, reg_address, value, mask);
> + ret = -EOPNOTSUPP;
> + }
> +
> + mutex_unlock(&intel_pmic_opregion->lock);
> +
> + return ret;
> +}
--
With Best Regards,
Andy Shevchenko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 3/4] ACPI / PMIC: Add generic intel_soc_pmic_exec_mipi_pmic_seq_element handling
On Mon, Jan 07, 2019 at 12:15:55PM +0100, Hans de Goede wrote:
> Most PMIC-s use only a single i2c-address, so after verifying the
> i2c-address matches, we can simply pass the call to regmap_update_bits.
>
> This commit adds support for this and hooks this up for the xpower AXP288
> PMIC by setting the new pmic_i2c_address field.
>
> This fixes the following errors on display on / off on a Jumper Ezpad
> mini 3 and an Onda V80 plus tablet, both of which use the AXP288:
>
> intel_soc_pmic_exec_mipi_pmic_seq_element: Not implemented
> intel_soc_pmic_exec_mipi_pmic_seq_element: i2c-addr: 0x34 reg-addr ...
> [drm:mipi_exec_pmic [i915]] *ERROR* mipi_exec_pmic failed, error: -95
>
> Instead of these errors on both devices we now correctly turn on / off
> DLDO3 (through direct register manipulation). On the Onda V80 plus this
> fixes an issue with the backlight being brighter around the borders after
> an off / on cycle. This should also help to save some power when the
> display is off.
>
> Signed-off-by: Hans de Goede
> ---
> Changes in v6:
> -This is a new patch in v6 of this patch-set
> ---
> drivers/acpi/pmic/intel_pmic.c| 9 +
> drivers/acpi/pmic/intel_pmic.h| 2 ++
> drivers/acpi/pmic/intel_pmic_xpower.c | 1 +
> 3 files changed, 12 insertions(+)
>
> diff --git a/drivers/acpi/pmic/intel_pmic.c b/drivers/acpi/pmic/intel_pmic.c
> index 471afeea87c2..c14cfaea92e2 100644
> --- a/drivers/acpi/pmic/intel_pmic.c
> +++ b/drivers/acpi/pmic/intel_pmic.c
> @@ -359,6 +359,15 @@ int intel_soc_pmic_exec_mipi_pmic_seq_element(u16
> i2c_address, u32 reg_address,
> ret = d->exec_mipi_pmic_seq_element(intel_pmic_opregion->regmap,
> i2c_address, reg_address,
> value, mask);
> + } else if (d->pmic_i2c_address) {
> + if (i2c_address == d->pmic_i2c_address) {
> + ret = regmap_update_bits(intel_pmic_opregion->regmap,
> + reg_address, mask, value);
> + } else {
> + pr_err("%s: Unexpected i2c-addr: 0x%02x (reg-addr 0x%x
> value 0x%x mask 0x%x)\n",
> +__func__, i2c_address, reg_address, value, mask);
> + ret = -ENXIO;
> + }
> } else {
> pr_warn("%s: Not implemented\n", __func__);
> pr_warn("%s: i2c-addr: 0x%x reg-addr 0x%x value 0x%x mask
> 0x%x\n",
> diff --git a/drivers/acpi/pmic/intel_pmic.h b/drivers/acpi/pmic/intel_pmic.h
> index 5cd195fabca8..89379476a1df 100644
> --- a/drivers/acpi/pmic/intel_pmic.h
> +++ b/drivers/acpi/pmic/intel_pmic.h
> @@ -21,6 +21,8 @@ struct intel_pmic_opregion_data {
> int power_table_count;
> struct pmic_table *thermal_table;
> int thermal_table_count;
> + /* For generic exec_mipi_pmic_seq_element handling */
> + int pmic_i2c_address;
> };
>
> int intel_pmic_install_opregion_handler(struct device *dev, acpi_handle
> handle, struct regmap *regmap, struct intel_pmic_opregion_data *d);
> diff --git a/drivers/acpi/pmic/intel_pmic_xpower.c
> b/drivers/acpi/pmic/intel_pmic_xpower.c
> index e7c0006e6602..a091d5a8392c 100644
> --- a/drivers/acpi/pmic/intel_pmic_xpower.c
> +++ b/drivers/acpi/pmic/intel_pmic_xpower.c
> @@ -265,6 +265,7 @@ static struct intel_pmic_opregion_data
> intel_xpower_pmic_opregion_data = {
> .power_table_count = ARRAY_SIZE(power_table),
> .thermal_table = thermal_table,
> .thermal_table_count = ARRAY_SIZE(thermal_table),
> + .pmic_i2c_address = 0x34,
Seems to match the axp288 datasheet.
FWIW
Reviewed-by: Ville Syrjälä
> };
>
> static acpi_status intel_xpower_pmic_gpio_handler(u32 function,
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 4/4] drm/i915/intel_dsi_vbt: Add support for PMIC MIPI sequences
On Mon, Jan 07, 2019 at 12:15:56PM +0100, Hans de Goede wrote:
> Add support for PMIC MIPI sequences using the new
> intel_soc_pmic_exec_mipi_pmic_seq_element function.
>
> This fixes the DSI LCD panel not lighting up when not initialized by the
> GOP (because an external monitor was connected) on GPD win and GPD pocket
> devices.
>
> Specifically the LCD panel seems to need GPIO pin 9 on the PMIC to be
> driven high, which is done through a PMIC MIPI sequence. Before this commit
> if the sequence was not executed by the GOP the pin would stay low causing
> the LCD panel to not work. Having the MIPI sequences properly control this
> GPIO should also help save some power when the panel is off.
>
> Changes in v2, v3:
> -Only changes to other patches in this patch-set
>
> Changes in v4:
> -Move decoding of the raw 15 bytes PMIC MIPI sequence element into
> i2c-address, register-address, value and mask into the mipi_exec_pmic()
> function instead of passing the raw data to
> intel_soc_pmic_exec_mipi_pmic_seq_element()
>
> Signed-off-by: Hans de Goede
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_dsi_vbt.c | 22 +-
> 1 file changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c
> b/drivers/gpu/drm/i915/intel_dsi_vbt.c
> index 3d1fa1a03a66..240664ef294c 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c
> @@ -29,9 +29,11 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> +#include
> #include "i915_drv.h"
> #include "intel_drv.h"
> #include "intel_dsi.h"
> @@ -392,7 +394,25 @@ static const u8 *mipi_exec_spi(struct intel_dsi
> *intel_dsi, const u8 *data)
>
> static const u8 *mipi_exec_pmic(struct intel_dsi *intel_dsi, const u8 *data)
> {
> - DRM_DEBUG_KMS("Skipping PMIC element execution\n");
> +#ifdef CONFIG_PMIC_OPREGION
> + u32 value, mask, reg_address;
> + u16 i2c_address;
> + int ret;
> +
> + /* byte 0 aka PMIC Flag is reserved */
> + i2c_address = get_unaligned_le16(data + 1);
> + reg_address = get_unaligned_le32(data + 3);
> + value = get_unaligned_le32(data + 7);
> + mask= get_unaligned_le32(data + 11);
> +
> + ret = intel_soc_pmic_exec_mipi_pmic_seq_element(i2c_address,
> + reg_address,
> + value, mask);
> + if (ret)
> + DRM_ERROR("%s failed, error: %d\n", __func__, ret);
> +#else
> + DRM_ERROR("Your hardware requires CONFIG_PMIC_OPREGION and it is not
> set\n");
> +#endif
>
> return data + 15;
> }
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Reduce i915_request_alloc retirement to local context
In the continual quest to reduce the amount of global work required when
submitting requests, replace i915_retire_requests() after allocation
failure to retiring just our ring.
References: 11abf0c5a021 ("drm/i915: Limit the backpressure for i915_request
allocation")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 33 +
1 file changed, 24 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 1e158eb8cb97..9ba218c6029b 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -477,6 +477,29 @@ submit_notify(struct i915_sw_fence *fence, enum
i915_sw_fence_notify state)
return NOTIFY_DONE;
}
+static noinline struct i915_request *
+i915_request_alloc_slow(struct intel_context *ce)
+{
+ struct intel_ring *ring = ce->ring;
+ struct i915_request *rq, *next;
+
+ list_for_each_entry_safe(rq, next, &ring->request_list, ring_link) {
+ /* Ratelimit ourselves to prevent oom from malicious clients */
+ if (&next->ring_link == &ring->request_list) {
+ cond_synchronize_rcu(rq->rcustate);
+ break; /* keep the last objects for the next request */
+ }
+
+ if (!i915_request_completed(rq))
+ break;
+
+ /* Retire our old requests in the hope that we free some */
+ i915_request_retire(rq);
+ }
+
+ return kmem_cache_alloc(ce->gem_context->i915->requests, GFP_KERNEL);
+}
+
/**
* i915_request_alloc - allocate a request structure
*
@@ -559,15 +582,7 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
rq = kmem_cache_alloc(i915->requests,
GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_NOWARN);
if (unlikely(!rq)) {
- i915_retire_requests(i915);
-
- /* Ratelimit ourselves to prevent oom from malicious clients */
- rq = i915_gem_active_raw(&ce->ring->timeline->last_request,
-&i915->drm.struct_mutex);
- if (rq)
- cond_synchronize_rcu(rq->rcustate);
-
- rq = kmem_cache_alloc(i915->requests, GFP_KERNEL);
+ rq = i915_request_alloc_slow(ce);
if (!rq) {
ret = -ENOMEM;
goto err_unreserve;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/debugfs: store rotation string buffer on stack
Quoting Jani Nikula (2019-01-07 14:51:49) > Minimal change to nuke the static buf. > > Signed-off-by: Jani Nikula I'm sure there's a grander plan, Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/debugfs: store rotation string buffer on stack
Minimal change to nuke the static buf.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_debugfs.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index c77326a7d058..95813e21ae02 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2961,14 +2961,13 @@ static const char *plane_type(enum drm_plane_type type)
return "unknown";
}
-static const char *plane_rotation(unsigned int rotation)
+static void plane_rotation(char *buf, size_t bufsize, unsigned int rotation)
{
- static char buf[48];
/*
* According to doc only one DRM_MODE_ROTATE_ is allowed but this
* will print them all to visualize if the values are misused
*/
- snprintf(buf, sizeof(buf),
+ snprintf(buf, bufsize,
"%s%s%s%s%s%s(0x%08x)",
(rotation & DRM_MODE_ROTATE_0) ? "0 " : "",
(rotation & DRM_MODE_ROTATE_90) ? "90 " : "",
@@ -2977,8 +2976,6 @@ static const char *plane_rotation(unsigned int rotation)
(rotation & DRM_MODE_REFLECT_X) ? "FLIPX " : "",
(rotation & DRM_MODE_REFLECT_Y) ? "FLIPY " : "",
rotation);
-
- return buf;
}
static void intel_plane_info(struct seq_file *m, struct intel_crtc *intel_crtc)
@@ -2991,6 +2988,7 @@ static void intel_plane_info(struct seq_file *m, struct
intel_crtc *intel_crtc)
struct drm_plane_state *state;
struct drm_plane *plane = &intel_plane->base;
struct drm_format_name_buf format_name;
+ char rot_str[48];
if (!plane->state) {
seq_puts(m, "plane->state is NULL!\n");
@@ -3006,6 +3004,8 @@ static void intel_plane_info(struct seq_file *m, struct
intel_crtc *intel_crtc)
sprintf(format_name.str, "N/A");
}
+ plane_rotation(rot_str, sizeof(rot_str), state->rotation);
+
seq_printf(m, "\t--Plane id %d: type=%s, crtc_pos=%4dx%4d,
crtc_size=%4dx%4d, src_pos=%d.%04ux%d.%04u, src_size=%d.%04ux%d.%04u,
format=%s, rotation=%s\n",
plane->base.id,
plane_type(intel_plane->base.type),
@@ -3020,7 +3020,7 @@ static void intel_plane_info(struct seq_file *m, struct
intel_crtc *intel_crtc)
(state->src_h >> 16),
((state->src_h & 0x) * 15625) >> 10,
format_name.str,
- plane_rotation(state->rotation));
+ rot_str);
}
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 2/3] drm/i915: Move on the new pm runtime interface
On Mon, Jan 7, 2019 at 3:04 PM Vincent Guittot wrote: > > Hi Tvrtko, > > On Mon, 31 Dec 2018 at 13:32, Tvrtko Ursulin > wrote: > > > > > > On 21/12/2018 13:26, Vincent Guittot wrote: > > > On Fri, 21 Dec 2018 at 12:33, Tvrtko Ursulin > > [snip] > > > >> > > >> If it is always monotonic, then worst case we report one wrong sample, > > >> which I guess is still not ideal since someone could be querying the PMU > > >> with quite low frequency. > > >> > > >> There are tests which probably can hit this, but to run them > > >> automatically your patches would need to be rebased on drm-tip and maybe > > >> sent to our trybot. I can do that after the holiday break if you are > > >> okay with having the series waiting until then. > > > > > > yes looks good to me > > > > Looks good to me as well. And our CI agrees with it. So: > > > > Reviewed-by: Tvrtko Ursulin > > Thanks for the review and the test > > > > > I assume you will take the patch through some power related tree and we > > will eventually pull it back to drm-tip. > > Rafael, > How do you want to proceed with this patch and the 2 others of the serie ? I'm going to queue up the whole series for 5.1. Thanks! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/46] drm/i915: Return immediately if trylock fails for direct-reclaim
Quoting Tvrtko Ursulin (2019-01-07 14:00:25) > > On 07/01/2019 11:54, Chris Wilson wrote: > > Ignore trying to shrink from i915 if we fail to acquire the struct_mutex > > in the shrinker while performing direct-reclaim. The trade-off being > > (much) lower latency for non-i915 clients at an increased risk of being > > unable to obtain a page from direct-reclaim without hitting the > > oom-notifier. The proviso being that we still keep trying to hard > > obtain the lock for kswapd so that we can reap under heavy memory > > pressure. > > > > v2: Taint all mutexes taken within the shrinker with the struct_mutex > > subclass as an early warning system, and drop I915_SHRINK_ACTIVE from > > vmap to reduce the number of dangerous paths. We also have to drop > > I915_SHRINK_ACTIVE from oom-notifier to be able to make the same claim > > that ACTIVE is only used from outside context, which fits in with a > > longer strategy of avoiding stalls due to scanning active during > > shrinking. > > Oom notifier is not always the outside context? oom-notifier is the final death throes of direct reclaim. > > @@ -2255,8 +2256,7 @@ int i915_gem_gtt_prepare_pages(struct > > drm_i915_gem_object *obj, > > } while (i915_gem_shrink(to_i915(obj->base.dev), > >obj->base.size >> PAGE_SHIFT, NULL, > >I915_SHRINK_BOUND | > > - I915_SHRINK_UNBOUND | > > - I915_SHRINK_ACTIVE)); > > + I915_SHRINK_UNBOUND)); > > > > Why this change? gtt_prepare_pages is called at the end of obj->ops->get_pages() which is not guaranteed to be outside of struct_mutex (yet). So I dropped the ACTIVE here as part of the claim that ACTIVE is only used from kswapd (or at known idle times such as i915_gem_freeze where I can handwave that ACTIVE is meaningless). -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 2/3] drm/i915: Move on the new pm runtime interface
Hi Tvrtko, On Mon, 31 Dec 2018 at 13:32, Tvrtko Ursulin wrote: > > > On 21/12/2018 13:26, Vincent Guittot wrote: > > On Fri, 21 Dec 2018 at 12:33, Tvrtko Ursulin [snip] > >> > >> If it is always monotonic, then worst case we report one wrong sample, > >> which I guess is still not ideal since someone could be querying the PMU > >> with quite low frequency. > >> > >> There are tests which probably can hit this, but to run them > >> automatically your patches would need to be rebased on drm-tip and maybe > >> sent to our trybot. I can do that after the holiday break if you are > >> okay with having the series waiting until then. > > > > yes looks good to me > > Looks good to me as well. And our CI agrees with it. So: > > Reviewed-by: Tvrtko Ursulin Thanks for the review and the test > > I assume you will take the patch through some power related tree and we > will eventually pull it back to drm-tip. Rafael, How do you want to proceed with this patch and the 2 others of the serie ? Regards, Vincent > > Regards, > > Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/46] drm/i915: Return immediately if trylock fails for direct-reclaim
On 07/01/2019 11:54, Chris Wilson wrote:
Ignore trying to shrink from i915 if we fail to acquire the struct_mutex
in the shrinker while performing direct-reclaim. The trade-off being
(much) lower latency for non-i915 clients at an increased risk of being
unable to obtain a page from direct-reclaim without hitting the
oom-notifier. The proviso being that we still keep trying to hard
obtain the lock for kswapd so that we can reap under heavy memory
pressure.
v2: Taint all mutexes taken within the shrinker with the struct_mutex
subclass as an early warning system, and drop I915_SHRINK_ACTIVE from
vmap to reduce the number of dangerous paths. We also have to drop
I915_SHRINK_ACTIVE from oom-notifier to be able to make the same claim
that ACTIVE is only used from outside context, which fits in with a
longer strategy of avoiding stalls due to scanning active during
shrinking.
Oom notifier is not always the outside context?
The danger in using the subclass struct_mutex is that we declare
ourselves more knowledgable than lockdep and deprive ourselves of
automatic coverage. Instead, we require ourselves to mark up any mutex
taken inside the shrinker in order to detect lock-inversion, and if we
miss any we are doomed to a deadlock at the worst possible moment.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 7 +--
drivers/gpu/drm/i915/i915_gem_gtt.c | 8 +--
drivers/gpu/drm/i915/i915_gem_shrinker.c | 68
3 files changed, 54 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7fa2a405c5fe..17a017645c5d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2899,9 +2899,9 @@ i915_gem_object_unpin_pages(struct drm_i915_gem_object
*obj)
__i915_gem_object_unpin_pages(obj);
}
-enum i915_mm_subclass { /* lockdep subclass for obj->mm.lock */
+enum i915_mm_subclass { /* lockdep subclass for obj->mm.lock/struct_mutex */
I915_MM_NORMAL = 0,
- I915_MM_SHRINKER
+ I915_MM_SHRINKER /* called "recursively" from direct-reclaim-esque */
};
void __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
@@ -3187,7 +3187,8 @@ unsigned long i915_gem_shrink(struct drm_i915_private
*i915,
unsigned long i915_gem_shrink_all(struct drm_i915_private *i915);
void i915_gem_shrinker_register(struct drm_i915_private *i915);
void i915_gem_shrinker_unregister(struct drm_i915_private *i915);
-void i915_gem_shrinker_taints_mutex(struct mutex *mutex);
+void i915_gem_shrinker_taints_mutex(struct drm_i915_private *i915,
+ struct mutex *mutex);
/* i915_gem_tiling.c */
static inline bool i915_gem_object_needs_bit17_swizzle(struct
drm_i915_gem_object *obj)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index d4c5973ea33d..5cc8968eb3bf 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -483,7 +483,7 @@ static void i915_address_space_init(struct
i915_address_space *vm,
* attempt holding the lock is immediately reported by lockdep.
*/
mutex_init(&vm->mutex);
- i915_gem_shrinker_taints_mutex(&vm->mutex);
+ i915_gem_shrinker_taints_mutex(vm->i915, &vm->mutex);
GEM_BUG_ON(!vm->total);
drm_mm_init(&vm->mm, 0, vm->total);
@@ -2245,7 +2245,8 @@ int i915_gem_gtt_prepare_pages(struct drm_i915_gem_object
*obj,
DMA_ATTR_NO_WARN))
return 0;
- /* If the DMA remap fails, one cause can be that we have
+ /*
+* If the DMA remap fails, one cause can be that we have
* too many objects pinned in a small remapping table,
* such as swiotlb. Incrementally purge all other objects and
* try again - if there are no more pages to remove from
@@ -2255,8 +2256,7 @@ int i915_gem_gtt_prepare_pages(struct drm_i915_gem_object
*obj,
} while (i915_gem_shrink(to_i915(obj->base.dev),
obj->base.size >> PAGE_SHIFT, NULL,
I915_SHRINK_BOUND |
-I915_SHRINK_UNBOUND |
-I915_SHRINK_ACTIVE));
+I915_SHRINK_UNBOUND));
Why this change?
Regards,
Tvrtko
return -ENOSPC;
}
diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c
b/drivers/gpu/drm/i915/i915_gem_shrinker.c
index ea90d3a0d511..72d6ea0cac7e 100644
--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
@@ -36,7 +36,9 @@
#include "i915_drv.h"
#include "i915_trace.h"
-static bool shrinker_lock(struct drm_i915_private *i915, bool *unlock)
+static bool shrinker_lock(struct drm_i915_private *i915,
+ unsigned int flags,
+
Re: [Intel-gfx] drm/i915: Watchdog timeout: IRQ handler for gen8+
Quoting Tvrtko Ursulin (2019-01-07 13:43:29) > > On 07/01/2019 11:58, Tvrtko Ursulin wrote: > > [snip] > > >> Note about future interaction with preemption: Preemption could happen > >> in a command sequence prior to watchdog counter getting disabled, > >> resulting in watchdog being triggered following preemption (e.g. when > >> watchdog had been enabled in the low priority batch). The driver will > >> need to explicitly disable the watchdog counter as part of the > >> preemption sequence. > > > > Does the series take care of preemption? > > I did not find that it does. Oh. I hoped that the watchdog was saved as part of the context... Then despite preemption, the timeout would resume from where we left off as soon as it was back on the gpu. If the timeout remaining was context saved it would be much simpler (at least on first glance), please say it is. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915: Watchdog timeout: DRM kernel interface to set the timeout
Quoting Tvrtko Ursulin (2019-01-07 13:39:24)
>
> On 07/01/2019 12:50, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-01-07 12:38:47)
> >> On 05/01/2019 02:39, Carlos Santa wrote:
> >>> +/* Return the timer count threshold in microseconds. */
> >>> +int i915_gem_context_get_watchdog(struct i915_gem_context *ctx,
> >>> + struct drm_i915_gem_context_param *args)
> >>> + if (__copy_to_user(u64_to_user_ptr(args->value),
> >>> +&threshold_in_us,
> >>> +sizeof(threshold_in_us))) {
> >>
> >> I think user pointer hasn't been verified for write access yet so
> >> standard copy_to_user should be used.
> >
> > The starting point here is that this bakes in OTHER_CLASS as uABI when
> > clearly it is not uABI. The array must be variable size and so the first
> > pass is to report the size to userspace (if they pass args->size = 0)
> > and then to copy up to the user requested size. Since it is a variable
> > array with uncertain indexing, the output should be along the lines of
> > [class, instance, watchdog]. But what about virtual engine? Good
> > question. (Remember set must follow the same pattern as get, so you can
> > always do a rmw cleanly.)
> >
> > I guess we just have to accept class == -1 as meaning use instance as an
> > index into ctx->engines[]. Tvrtko? Virtual engine would be reported as
> > (-1, 0, watchdog), and settable similarly with the other engines being
> > addressable either by index or by class-instance.
>
> Or use index based addressing mode if engine map is set? Index 0 only
> being valid if load balancing is enabled on top.
I was trying to avoid tying ctx->engines[] into such an extensive set of
API changes, but given that it affects execbuffer_ioctl, the die is
cast. With that approach, every time we use class-instance (with respect
to a context) we should also swap it over to using an index when
ctx->engines[] is set.
The advantage to using a flag (in this case instance=-1) is that we can
then write igt (or library routines) oblivious to the state of
ctx->engines[].
From an application pov, they can ignore it, as they will be doing the
SET_ENGINES as part of their initial context construction (one presumes)
and so will always have ctx->engines[] known to be active.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915: Watchdog timeout: IRQ handler for gen8+
On 07/01/2019 11:58, Tvrtko Ursulin wrote: [snip] Note about future interaction with preemption: Preemption could happen in a command sequence prior to watchdog counter getting disabled, resulting in watchdog being triggered following preemption (e.g. when watchdog had been enabled in the low priority batch). The driver will need to explicitly disable the watchdog counter as part of the preemption sequence. Does the series take care of preemption? I did not find that it does. So this is something which definitely needs to be handled. And it is not only disabling the watchdog on preemption, but there is also a question of restoring it when/before a preempted context continues execution. (Can we ignore the thresholds changing in between? Probably yes. Otherwise we'll have to record it in the request structure.) Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915: Watchdog timeout: DRM kernel interface to set the timeout
On 07/01/2019 12:50, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-07 12:38:47)
On 05/01/2019 02:39, Carlos Santa wrote:
+/* Return the timer count threshold in microseconds. */
+int i915_gem_context_get_watchdog(struct i915_gem_context *ctx,
+ struct drm_i915_gem_context_param *args)
+ if (__copy_to_user(u64_to_user_ptr(args->value),
+&threshold_in_us,
+sizeof(threshold_in_us))) {
I think user pointer hasn't been verified for write access yet so
standard copy_to_user should be used.
The starting point here is that this bakes in OTHER_CLASS as uABI when
clearly it is not uABI. The array must be variable size and so the first
pass is to report the size to userspace (if they pass args->size = 0)
and then to copy up to the user requested size. Since it is a variable
array with uncertain indexing, the output should be along the lines of
[class, instance, watchdog]. But what about virtual engine? Good
question. (Remember set must follow the same pattern as get, so you can
always do a rmw cleanly.)
I guess we just have to accept class == -1 as meaning use instance as an
index into ctx->engines[]. Tvrtko? Virtual engine would be reported as
(-1, 0, watchdog), and settable similarly with the other engines being
addressable either by index or by class-instance.
Or use index based addressing mode if engine map is set? Index 0 only
being valid if load balancing is enabled on top.
So an array of structs like:
struct drm_i915_watchdog_timeout {
union {
struct {
u16 class;
u16 instance;
};
u32 index;
};
u32 timeout_us;
};
?
We can allow standalone set param and via extension as well.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] "flip_done timed out" messages causing huge increase in boot time
On Sat, Jan 05, 2019 at 12:47:12AM +0100, Daniel Kamil Kozar wrote:
> Hello.
> After upgrading the kernel to 4.20, I noticed that the boot time
> increased from about 5 seconds to 25 seconds. My machine is an Asus
> K53SV with an Intel i7-2630QM, i.e. Sandy Bridge. I have an external
> display connected to it via HDMI. If the display is unplugged when
> booting the machine, the boot time stays at its old value.
> The kernel log shows two messages like this :
>
> [ 15.747206] [drm:drm_atomic_helper_wait_for_flip_done
> [drm_kms_helper]] *ERROR* [CRTC:39:pipe A] flip_done timed out
> [ 26.198968] [drm:drm_atomic_helper_wait_for_dependencies
> [drm_kms_helper]] *ERROR* [CRTC:39:pipe A] flip_done timed out
Hrm. With SNB I would be tempted to blame the LP3 watermarks, but
4.20 already has commit 21556350ade3 ("drm/i915: Disable LP3 watermarks
on all SNB machines").
Can you file a bug at
https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel
and attach the full dmesg from the boot with drm.debug=0xe passed to the
kernel cmdline?
--
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 03/46] drm/i915: Track all held rpm wakerefs
Quoting Mika Kuoppala (2019-01-07 13:14:00)
> Chris Wilson writes:
> > @@ -2011,6 +2011,8 @@ static int i915_drm_suspend_late(struct drm_device
> > *dev, bool hibernation)
> >
> > out:
> > enable_rpm_wakeref_asserts(dev_priv);
> > + if (!dev_priv->uncore.user_forcewake.count)
> > + intel_runtime_pm_cleanup(dev_priv);
> >
>
> Why would we have forcewake active in here?
Why would the user suspend while holding
open("/debug/dri/0/i915_user_forcewake")?
Because they can.
> Are you planning on extending the intel_runtime_pm_cleanup?
> Atleast in the callsite 'intel_runtime_assert_no_wakerefs' would
> make more sense.
Oh yes, yes, yes. The challenge is that we take the rpm wakeref with
such frequency and variety of lifetimes is that we end up with so much
tracked that it makes finding the leak very hard (and we cannot report
an underflow elsewhere at the moment for similar reasons). So this first
wave was to catch the easy stuff and report a leak on module unload, then
once everyone is tracking their own wakeref, we can do the must_check
annotation and WARN on underflow.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/46] drm/i915: Track all held rpm wakerefs
Chris Wilson writes:
> Everytime we take a wakeref, record the stack trace of where it was
> taken; clearing the set if we ever drop back to no owners. For debugging
> a rpm leak, we can look at all the current wakerefs and check if they
> have a matching rpm_put.
>
> Signed-off-by: Chris Wilson
> Cc: Jani Nikula
> ---
> drivers/gpu/drm/i915/Kconfig.debug| 2 +-
> drivers/gpu/drm/i915/i915_debugfs.c | 6 +
> drivers/gpu/drm/i915/i915_drv.c | 8 +-
> drivers/gpu/drm/i915/i915_drv.h | 7 +
> drivers/gpu/drm/i915/intel_drv.h | 44 ++-
> drivers/gpu/drm/i915/intel_runtime_pm.c | 267 --
> .../gpu/drm/i915/selftests/mock_gem_device.c | 8 +-
> 7 files changed, 292 insertions(+), 50 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/Kconfig.debug
> b/drivers/gpu/drm/i915/Kconfig.debug
> index 9e36ffb5eb7c..a97929c47466 100644
> --- a/drivers/gpu/drm/i915/Kconfig.debug
> +++ b/drivers/gpu/drm/i915/Kconfig.debug
> @@ -21,11 +21,11 @@ config DRM_I915_DEBUG
> select DEBUG_FS
> select PREEMPT_COUNT
> select I2C_CHARDEV
> +select STACKDEPOT
> select DRM_DP_AUX_CHARDEV
> select X86_MSR # used by igt/pm_rpm
> select DRM_VGEM # used by igt/prime_vgem (dmabuf interop checks)
> select DRM_DEBUG_MM if DRM=y
> -select STACKDEPOT if DRM=y # for DRM_DEBUG_MM
> select DRM_DEBUG_SELFTEST
> select SW_SYNC # signaling validation framework (igt/syncobj*)
> select DRM_I915_SW_FENCE_DEBUG_OBJECTS
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index c77326a7d058..3a369245d7e6 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2702,6 +2702,12 @@ static int i915_runtime_pm_status(struct seq_file *m,
> void *unused)
> pci_power_name(pdev->current_state),
> pdev->current_state);
>
> + if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM)) {
> + struct drm_printer p = drm_seq_file_printer(m);
> +
> + print_intel_runtime_pm_wakeref(dev_priv, &p);
> + }
> +
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 17fca3ba343e..e2f4753ca21f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -906,6 +906,7 @@ static int i915_driver_init_early(struct drm_i915_private
> *dev_priv)
> mutex_init(&dev_priv->pps_mutex);
>
> i915_memcpy_init_early(dev_priv);
> + intel_runtime_pm_init_early(dev_priv);
>
> ret = i915_workqueues_init(dev_priv);
> if (ret < 0)
> @@ -1808,8 +1809,7 @@ void i915_driver_unload(struct drm_device *dev)
> i915_driver_cleanup_mmio(dev_priv);
>
> enable_rpm_wakeref_asserts(dev_priv);
> -
> - WARN_ON(atomic_read(&dev_priv->runtime_pm.wakeref_count));
> + intel_runtime_pm_cleanup(dev_priv);
> }
>
> static void i915_driver_release(struct drm_device *dev)
> @@ -2011,6 +2011,8 @@ static int i915_drm_suspend_late(struct drm_device
> *dev, bool hibernation)
>
> out:
> enable_rpm_wakeref_asserts(dev_priv);
> + if (!dev_priv->uncore.user_forcewake.count)
> + intel_runtime_pm_cleanup(dev_priv);
>
Why would we have forcewake active in here?
Are you planning on extending the intel_runtime_pm_cleanup?
Atleast in the callsite 'intel_runtime_assert_no_wakerefs' would
make more sense.
> return ret;
> }
> @@ -2966,7 +2968,7 @@ static int intel_runtime_suspend(struct device *kdev)
> }
>
> enable_rpm_wakeref_asserts(dev_priv);
> - WARN_ON_ONCE(atomic_read(&dev_priv->runtime_pm.wakeref_count));
> + intel_runtime_pm_cleanup(dev_priv);
>
> if (intel_uncore_arm_unclaimed_mmio_detection(dev_priv))
> DRM_ERROR("Unclaimed access detected prior to suspending\n");
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 17a017645c5d..60b98103aba3 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -45,6 +45,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -1156,6 +1157,12 @@ struct i915_runtime_pm {
> atomic_t wakeref_count;
> bool suspended;
> bool irqs_enabled;
> +
> +#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM)
> + spinlock_t debug_lock;
> + depot_stack_handle_t *debug_owners;
> + unsigned long debug_count;
> +#endif
> };
>
> enum intel_pipe_crc_source {
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 1a11c2beb7f3..ac513fd70315 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -41,6 +41,8 @@
> #include
> #include
>
> +struct drm_printer;
> +
> /**
> * __wait_for - magic wait macro
> *
> @@ -2084,6 +2086,7 @@ bool int
Re: [Intel-gfx] drm/i915: Watchdog timeout: IRQ handler for gen8+
On 07/01/2019 13:02, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-07 12:58:39)
On 07/01/2019 12:16, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-07 11:58:13)
On 05/01/2019 02:39, Carlos Santa wrote:
+static void gen8_watchdog_irq_handler(unsigned long data)
+{
+ struct intel_engine_cs *engine = (struct intel_engine_cs *)data;
+ struct drm_i915_private *dev_priv = engine->i915;
+ enum forcewake_domains fw_domains;
+ u32 current_seqno;
+
+ switch (engine->id) {
+ default:
+ MISSING_CASE(engine->id);
+ /* fall through */
+ case RCS:
+ fw_domains = FORCEWAKE_RENDER;
+ break;
+ case VCS:
+ case VCS2:
+ case VECS:
+ fw_domains = FORCEWAKE_MEDIA;
+ break;
+ }
+
+ intel_uncore_forcewake_get(dev_priv, fw_domains);
I'd be tempted to drop this and just use I915_WRITE. It doesn't feel
like there is any performance to be gained with it and it embeds too
much knowledge here.
No, no, no. Let's not reintroduce a fw inside irq context on a frequent
timer again.
Tasklet and hopefully watchdog timeouts are not frequent. :)
I thought the typical value mentioned elsewhere was a 1ms watchdog. Some
Commit message to a patch from this series says 60ms is recommended.
might say why even use a watchdog for longer than that as a hrtimer will
be more efficient (coupling in with other timer activity) ;)
For the normal case (longish batches, very few timeouts) it feels more
efficient to have ten or so extra dwords with each request than to
fiddle with hrtimers, no?
But interactions with preemption and future time-slicing yeah don't
know. Maybe a single solution will be simpler at that point.
Regards,
Tvrtko
___
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 [01/46] drm/i915: Return immediately if trylock fails for direct-reclaim
== Series Details ==
Series: series starting with [01/46] drm/i915: Return immediately if trylock
fails for direct-reclaim
URL : https://patchwork.freedesktop.org/series/54803/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5368 -> Patchwork_11200
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_11200 need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11200, 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/54803/revisions/1/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_11200:
### IGT changes ###
Warnings
* igt@kms_pipe_crc_basic@hang-read-crc-pipe-b:
- fi-skl-guc: PASS -> SKIP +2
- fi-apl-guc: PASS -> SKIP +2
- fi-cfl-guc: PASS -> SKIP +2
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c:
- fi-kbl-7567u: SKIP -> PASS +33
* igt@pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: PASS -> SKIP
Known issues
Here are the changes found in Patchwork_11200 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_contexts:
- fi-icl-u3: NOTRUN -> DMESG-FAIL [fdo#108569]
* igt@i915_selftest@live_execlists:
- fi-apl-guc: PASS -> INCOMPLETE [fdo#103927]
* igt@kms_busy@basic-flip-b:
- fi-gdg-551: PASS -> FAIL [fdo#103182]
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: PASS -> FAIL [fdo#108767]
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a:
- fi-byt-clapper: PASS -> FAIL [fdo#107362]
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362]
* igt@pm_rpm@basic-rte:
- fi-bsw-kefka: PASS -> FAIL [fdo#108800]
Possible fixes
* igt@pm_rpm@module-reload:
- fi-icl-u2: DMESG-WARN [fdo#108654] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622
[fdo#108654]: https://bugs.freedesktop.org/show_bug.cgi?id=108654
[fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767
[fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800
[fdo#108915]: https://bugs.freedesktop.org/show_bug.cgi?id=108915
Participating hosts (47 -> 44)
--
Additional (3): fi-icl-y fi-byt-j1900 fi-icl-u3
Missing(6): fi-kbl-soraka fi-hsw-4770r fi-ilk-m540 fi-byt-squawks
fi-bsw-cyan fi-ctg-p8600
Build changes
-
* Linux: CI_DRM_5368 -> Patchwork_11200
CI_DRM_5368: 64bd30ea3ce0edd057a5b393569947a955472757 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4756: 75081c6bfb9998bd7cbf35a7ac0578c683fe55a8 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11200: 0bf3389593c055c874799a4cd89caa7cfaa86927 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
0bf3389593c0 drm/i915: Replace global breadcrumbs with per-context interrupt
tracking
494f87700216 drm/i915: Identify active requests
caa054848443 drm/i915: Track the context's seqno in its own timeline HWSP
3a18270b30aa drm/i915: Allocate a status page for each timeline
b74a0ab29880 drm/i915: Enlarge vma->pin_count
82cb670aee32 drm/i915: Introduce concept of per-timeline (context) HWSP
7eaf41844056 drm/i915: Move list of timelines under its own lock
7addb9fa85ee drm/i915: Always allocate an object/vma for the HWSP
bcbacd09560a drm/i915: Remove the intel_engine_notify tracepoint
898cc7add579 drm/i915/selftests: Make evict tolerant of foreign objects
f100df244053 drm/i915/selftests: Allocate mock ring/timeline per context
710f39b1dd59 drm/i915: Use b->irq_enable() as predicate for mock engine
d7ed47a26a28 drm/i915: Move intel_execlists_show_requests() aside
aaf60bafd95e drm/i915: Move vma lookup to its own lock
05f0e0d4f8c8 drm/i915: Pull VM lists under the VM mutex.
850cfae97d02 drm/i915: Stop tracking MRU activity on VMA
5c6544073058 drm/i915: Issue engine resets onto idle engines
5872f352bbf4 drm/i915: Remove GPU reset dependence on struct_mutex
d9c35bdc837f drm/i915/guc: Disable global reset
0129900c3794 drm/i915: Make all GPU resets atomic
015a2f8dbceb drm/i915: Pull all the reset f
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/46] drm/i915: Return immediately if trylock fails for direct-reclaim
== Series Details == Series: series starting with [01/46] drm/i915: Return immediately if trylock fails for direct-reclaim URL : https://patchwork.freedesktop.org/series/54803/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Return immediately if trylock fails for direct-reclaim -drivers/gpu/drm/i915/selftests/../i915_drv.h:3545:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3546:16: warning: expression using sizeof(void) Commit: drm/i915: Report the number of closed vma held by each context in debugfs Okay! Commit: drm/i915: Track all held rpm wakerefs -drivers/gpu/drm/i915/selftests/../i915_drv.h:3546:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3553:16: warning: expression using sizeof(void) Commit: drm/i915: Markup paired operations on wakerefs -drivers/gpu/drm/i915/selftests/../i915_drv.h:3553:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3555:16: warning: expression using sizeof(void) Commit: drm/i915: Track GT wakeref Okay! Commit: drm/i915: Track the rpm wakerefs for error handling Okay! Commit: drm/i915: Mark up sysfs with rpm wakeref tracking Okay! Commit: drm/i915: Mark up debugfs with rpm wakeref tracking Okay! Commit: drm/i915/perf: Track the rpm wakeref -drivers/gpu/drm/i915/selftests/../i915_drv.h:3555:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3557:16: warning: expression using sizeof(void) Commit: drm/i915/pmu: Track rpm wakeref Okay! Commit: drm/i915/guc: Track the rpm wakeref Okay! Commit: drm/i915/gem: Track the rpm wakerefs Okay! Commit: drm/i915/fb: Track rpm wakerefs Okay! Commit: drm/i915/hotplug: Track temporary rpm wakeref Okay! Commit: drm/i915/panel: Track temporary rpm wakeref Okay! Commit: drm/i915/selftests: Mark up rpm wakerefs Okay! Commit: drm/i915: Syntatic sugar for using intel_runtime_pm Okay! Commit: drm/i915: Markup paired operations on display power domains -drivers/gpu/drm/i915/selftests/../i915_drv.h:3557:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3559:16: warning: expression using sizeof(void) Commit: drm/i915: Track the wakeref used to initialise display power domains -drivers/gpu/drm/i915/selftests/../i915_drv.h:3559:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3561:16: warning: expression using sizeof(void) Commit: drm/i915: Combined gt.awake/gt.power wakerefs -drivers/gpu/drm/i915/selftests/../i915_drv.h:3561:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3560:16: warning: expression using sizeof(void) Commit: drm/i915/dp: Markup pps lock power well Okay! Commit: drm/i915: Complain if hsw_get_pipe_config acquires the same power well twice Okay! Commit: drm/i915: Mark up Ironlake ips with rpm wakerefs Okay! Commit: drm/i915: Serialise concurrent calls to i915_gem_set_wedged() Okay! Commit: drm/i915: Differentiate between ggtt->mutex and ppgtt->mutex Okay! Commit: drm/i915: Pull all the reset functionality together into i915_reset.c -drivers/gpu/drm/i915/selftests/../i915_drv.h:3560:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3529:16: warning: expression using sizeof(void) +./include/uapi/linux/perf_event.h:147:56: warning: cast truncates bits from constant value (8000 becomes 0) Commit: drm/i915: Make all GPU resets atomic Okay! Commit: drm/i915/guc: Disable global reset Okay! Commit: drm/i915: Remove GPU reset dependence on struct_mutex -drivers/gpu/drm/i915/selftests/../i915_drv.h:3529:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3524:16: warning: expression using sizeof(void) Commit: drm/i915: Issue engine resets onto idle engines Okay! Commit: drm/i915: Stop tracking MRU activity on VMA Okay! Commit: drm/i915: Pull VM lists under the VM mutex. Okay! Commit: drm/i915: Move vma lookup to its own lock Okay! Commit: drm/i915: Move intel_execlists_show_requests() aside Okay! Commit: drm/i915: Use b->irq_enable() as predicate for mock engine Okay! Commit: drm/i915/selftests: Allocate mock ring/timeline per context Okay! Commit: drm/i915/selftests: Make evict tolerant of foreign objects Okay! Commit: drm/i915: Remove the intel_engine_notify tracepoint Okay! Commit: drm/i915: Always allocate an object/vma for the HWSP Okay! Commit: drm/i915: Move list of timelines under its own lock -drivers/gpu/drm/i915/selftests/../i915_drv.h:3524:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3525:16: warning: expression using sizeof(void) Commit: drm/i915: Introduce concept of per-timeline (context) HWSP Okay! Commit: drm/i915: Enlarge vma->pin_count Okay! Commit: drm/i915: Allocate a status page for each timeline -d
Re: [Intel-gfx] drm/i915: Watchdog timeout: IRQ handler for gen8+
Quoting Tvrtko Ursulin (2019-01-07 12:58:39)
>
> On 07/01/2019 12:16, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-01-07 11:58:13)
> >> On 05/01/2019 02:39, Carlos Santa wrote:
> >>> +static void gen8_watchdog_irq_handler(unsigned long data)
> >>> +{
> >>> + struct intel_engine_cs *engine = (struct intel_engine_cs *)data;
> >>> + struct drm_i915_private *dev_priv = engine->i915;
> >>> + enum forcewake_domains fw_domains;
> >>> + u32 current_seqno;
> >>> +
> >>> + switch (engine->id) {
> >>> + default:
> >>> + MISSING_CASE(engine->id);
> >>> + /* fall through */
> >>> + case RCS:
> >>> + fw_domains = FORCEWAKE_RENDER;
> >>> + break;
> >>> + case VCS:
> >>> + case VCS2:
> >>> + case VECS:
> >>> + fw_domains = FORCEWAKE_MEDIA;
> >>> + break;
> >>> + }
> >>> +
> >>> + intel_uncore_forcewake_get(dev_priv, fw_domains);
> >>
> >> I'd be tempted to drop this and just use I915_WRITE. It doesn't feel
> >> like there is any performance to be gained with it and it embeds too
> >> much knowledge here.
> >
> > No, no, no. Let's not reintroduce a fw inside irq context on a frequent
> > timer again.
>
> Tasklet and hopefully watchdog timeouts are not frequent. :)
I thought the typical value mentioned elsewhere was a 1ms watchdog. Some
might say why even use a watchdog for longer than that as a hrtimer will
be more efficient (coupling in with other timer activity) ;)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915/watchdog: move emit_stop_watchdog until the very end of the ring commands
On 07/01/2019 12:54, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-07 12:50:24)
On 05/01/2019 02:40, Carlos Santa wrote:
+static void gen8_emit_breadcrumb_vcs(struct i915_request *request, u32 *cs)
+{
+ /* w/a: bit 5 needs to be zero for MI_FLUSH_DW address. */
+ BUILD_BUG_ON(I915_GEM_HWS_INDEX_ADDR & (1 << 5));
+
+ cs = gen8_emit_ggtt_write(cs, request->global_seqno,
+ intel_hws_seqno_address(request->engine));
+ *cs++ = MI_USER_INTERRUPT;
+ *cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE;
+
+ // stop_watchdog at the very end of the ring commands
+ if (request->gem_context->__engine[VCS].watchdog_threshold != 0)
VCS is wrong. Whole check needs to be to_intel_context(ctx,
engine)->watchdog_threshold I think.
You too! rq->hw_context->watchdog_threshold. It's as if hw_context may
not even be part of gem_context...
Oops.. this is what happens when you just review and review - new stuff
does not get ingrained in memory unless typing it enough. :)
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915: Watchdog timeout: IRQ handler for gen8+
On 07/01/2019 12:16, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-07 11:58:13)
Hi,
This series has not been recognized by Patchwork as such, nor are the
patches numbered. Have you used git format-patch - --cover-letter and
git send-email to send it out?
Rest inline.
On 05/01/2019 02:39, Carlos Santa wrote:
+static void gen8_watchdog_irq_handler(unsigned long data)
+{
+ struct intel_engine_cs *engine = (struct intel_engine_cs *)data;
+ struct drm_i915_private *dev_priv = engine->i915;
+ enum forcewake_domains fw_domains;
+ u32 current_seqno;
+
+ switch (engine->id) {
+ default:
+ MISSING_CASE(engine->id);
+ /* fall through */
+ case RCS:
+ fw_domains = FORCEWAKE_RENDER;
+ break;
+ case VCS:
+ case VCS2:
+ case VECS:
+ fw_domains = FORCEWAKE_MEDIA;
+ break;
+ }
+
+ intel_uncore_forcewake_get(dev_priv, fw_domains);
I'd be tempted to drop this and just use I915_WRITE. It doesn't feel
like there is any performance to be gained with it and it embeds too
much knowledge here.
No, no, no. Let's not reintroduce a fw inside irq context on a frequent
timer again.
Tasklet and hopefully watchdog timeouts are not frequent. :)
Rule of thumb for fw_get:
gen6+: 10us to 50ms.
gen8+: 10us to 500us.
And then we don't release fw for 1ms after the fw_put. So we basically
prevent GT powersaving while the watchdog is active. That strikes me as
hopefully an unintended consequence.
The fw_get will be required if we actually hang, but for the timer
check, we should be able to do without.
That would be nice, but it is needed by the watchdog disable/re-enable
logic. Which I commented looks suspect to me so maybe something can be
done about that.
But in general, I didn't quite get if you are opposed to my suggestion
not to open code knowledge of fw domains here in favour of simple
I915_WRITE, or just the whole concept of taking a fw by any means here.
And while on the topic of the timer irq, it should be forcibly cleared
along intel_engine_park, so that we ensure it is not raised while the
device/driver is supposed to be asleep. Or something to that effect.
I have raised the issue of syncing the potentially delayed tasklet, but
yeah, could be that more is needed.
+ current_seqno = intel_engine_get_seqno(engine);
+
+ /* did the request complete after the timer expired? */
+ if (intel_engine_last_submit(engine) == current_seqno)
+ goto fw_put;
+
+ if (engine->hangcheck.watchdog == current_seqno) {
+ /* Make sure the active request will be marked as guilty */
+ engine->hangcheck.stalled = true;
+ engine->hangcheck.acthd = intel_engine_get_active_head(engine);
+ engine->hangcheck.seqno = current_seqno;
+
+ /* And try to run the hangcheck_work as soon as possible */
+ set_bit(I915_RESET_WATCHDOG, &dev_priv->gpu_error.flags);
+ queue_delayed_work(system_long_wq,
+&dev_priv->gpu_error.hangcheck_work,
+round_jiffies_up_relative(HZ));
+ } else {
+ engine->hangcheck.watchdog = current_seqno;
The logic above potentially handles my previous question? Could be if
batch 2 hangs. But..
Also, DO NOT USE HANGCHECK for this. The whole design was to be able to
do the engine reset right away. (Now guc can't but that's known broken.)
Aside, we have to rewrite this entire logic anyway as the engine seqno
and global_seqno are obsolete.
Btw one thing I forgot to say - I did not focus on the hangcheck
interactions - I'll leave that for people more in the know of that.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] tests/gem_shrink: Exercise OOM and other routes to shrinking in reasonable time
Quoting Tvrtko Ursulin (2019-01-07 12:52:28)
>
> On 07/01/2019 12:31, Chris Wilson wrote:
> > Quoting Michał Winiarski (2019-01-07 12:27:07)
> >> On Fri, Jan 04, 2019 at 03:37:09PM +, Tvrtko Ursulin wrote:
> >>> From: Tvrtko Ursulin
> >>>
> >>> A set of subtests which exercises different paths to our shrinker code
> >>> (including the OOM killer) in predictable and reasonable time budget.
> >>>
> >>> Signed-off-by: Tvrtko Ursulin
> >>> ---
> >>> lib/igt_core.c| 19 ++
> >>> lib/igt_core.h| 1 +
> >>> tests/i915/gem_shrink.c | 399 ++
> >>> tests/intel-ci/blacklist.txt | 1 +
> >>> tests/intel-ci/fast-feedback.testlist | 3 +
> >>> 5 files changed, 423 insertions(+)
> >>
> >> [snip]
> >>
> >>> diff --git a/tests/i915/gem_shrink.c b/tests/i915/gem_shrink.c
> >>> index c8e05814ee70..7c002de0ef1f 100644
> >>> --- a/tests/i915/gem_shrink.c
> >>> +++ b/tests/i915/gem_shrink.c
> >>> @@ -26,6 +26,10 @@
> >>>*
> >>>* Exercise the shrinker by overallocating GEM objects
> >>>*/
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +#include
> >>>
> >>> #include "igt.h"
> >>> #include "igt_gt.h"
> >>> @@ -366,6 +370,376 @@ static void reclaim(unsigned engine, int timeout)
> >>>close(fd);
> >>> }
> >>>
> >>> +static unsigned long get_meminfo(const char *info, const char *tag)
> >>> +{
> >>> + const char *str;
> >>> + unsigned long val;
> >>> +
> >>> + str = strstr(info, tag);
> >>> + if (str && sscanf(str + strlen(tag), " %lu", &val) == 1)
> >>> + return val >> 10;
> >>> +
> >>> + igt_warn("Unrecognised /proc/meminfo field: '%s'\n", tag);
> >>> + return 0;
> >>> +}
> >>> +
> >>> +static unsigned long get_avail_ram_mb(void)
> >>> +{
> >>> + int fd;
> >>> + int ret;
> >>> + char buf[4096];
> >>> + unsigned long ram;
> >>> +
> >>> + fd = open("/proc/meminfo", O_RDONLY);
> >>> + igt_assert_fd(fd);
> >>> +
> >>> + ret = read(fd, buf, sizeof(buf));
> >>> + igt_assert(ret >= 0);
> >>> +
> >>> + close(fd);
> >>> +
> >>> + ram = get_meminfo(buf, "MemAvailable:");
> >>> + ram += get_meminfo(buf, "Buffers:");
> >>> + ram += get_meminfo(buf, "Cached:");
> >>> + ram += get_meminfo(buf, "SwapCached:");
> >>> +
> >>> + return ram;
> >>> +}
> >>
> >> What's wrong with ones from intel_os.c?
> >
> > They pull in both an i915 and mm purge, which iirc, had to be avoided
> > here.
>
> Yep. I can sense a suggestion of adding a lighter weight version to the
> library now.. :)
Nah, I refrained because I hope for the same leniency (many times over).
Anyway, the third user has to refactor ;)
To serendipity,
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915/watchdog: move emit_stop_watchdog until the very end of the ring commands
Quoting Tvrtko Ursulin (2019-01-07 12:50:24)
>
> On 05/01/2019 02:40, Carlos Santa wrote:
> > +static void gen8_emit_breadcrumb_vcs(struct i915_request *request, u32 *cs)
> > +{
> > + /* w/a: bit 5 needs to be zero for MI_FLUSH_DW address. */
> > + BUILD_BUG_ON(I915_GEM_HWS_INDEX_ADDR & (1 << 5));
> > +
> > + cs = gen8_emit_ggtt_write(cs, request->global_seqno,
> > + intel_hws_seqno_address(request->engine));
> > + *cs++ = MI_USER_INTERRUPT;
> > + *cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE;
> > +
> > + // stop_watchdog at the very end of the ring commands
> > + if (request->gem_context->__engine[VCS].watchdog_threshold != 0)
>
> VCS is wrong. Whole check needs to be to_intel_context(ctx,
> engine)->watchdog_threshold I think.
You too! rq->hw_context->watchdog_threshold. It's as if hw_context may
not even be part of gem_context...
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] tests/gem_shrink: Exercise OOM and other routes to shrinking in reasonable time
On 07/01/2019 12:31, Chris Wilson wrote:
Quoting Michał Winiarski (2019-01-07 12:27:07)
On Fri, Jan 04, 2019 at 03:37:09PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
A set of subtests which exercises different paths to our shrinker code
(including the OOM killer) in predictable and reasonable time budget.
Signed-off-by: Tvrtko Ursulin
---
lib/igt_core.c| 19 ++
lib/igt_core.h| 1 +
tests/i915/gem_shrink.c | 399 ++
tests/intel-ci/blacklist.txt | 1 +
tests/intel-ci/fast-feedback.testlist | 3 +
5 files changed, 423 insertions(+)
[snip]
diff --git a/tests/i915/gem_shrink.c b/tests/i915/gem_shrink.c
index c8e05814ee70..7c002de0ef1f 100644
--- a/tests/i915/gem_shrink.c
+++ b/tests/i915/gem_shrink.c
@@ -26,6 +26,10 @@
*
* Exercise the shrinker by overallocating GEM objects
*/
+#include
+#include
+#include
+#include
#include "igt.h"
#include "igt_gt.h"
@@ -366,6 +370,376 @@ static void reclaim(unsigned engine, int timeout)
close(fd);
}
+static unsigned long get_meminfo(const char *info, const char *tag)
+{
+ const char *str;
+ unsigned long val;
+
+ str = strstr(info, tag);
+ if (str && sscanf(str + strlen(tag), " %lu", &val) == 1)
+ return val >> 10;
+
+ igt_warn("Unrecognised /proc/meminfo field: '%s'\n", tag);
+ return 0;
+}
+
+static unsigned long get_avail_ram_mb(void)
+{
+ int fd;
+ int ret;
+ char buf[4096];
+ unsigned long ram;
+
+ fd = open("/proc/meminfo", O_RDONLY);
+ igt_assert_fd(fd);
+
+ ret = read(fd, buf, sizeof(buf));
+ igt_assert(ret >= 0);
+
+ close(fd);
+
+ ram = get_meminfo(buf, "MemAvailable:");
+ ram += get_meminfo(buf, "Buffers:");
+ ram += get_meminfo(buf, "Cached:");
+ ram += get_meminfo(buf, "SwapCached:");
+
+ return ram;
+}
What's wrong with ones from intel_os.c?
They pull in both an i915 and mm purge, which iirc, had to be avoided
here.
Yep. I can sense a suggestion of adding a lighter weight version to the
library now.. :)
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915/watchdog: move emit_stop_watchdog until the very end of the ring commands
On 05/01/2019 02:40, Carlos Santa wrote:
From: Michel Thierry
On command streams that could potentially hang the GPU after a last
flush command, it's best not to cancel the watchdog
until after all commands have executed.
Patch shared by Michel Thierry through IIRC after reproduction on
Joonas pointed out on IRC that IRC is called IRC. :)
my local setup.
Tested-by: Carlos Santa
CC: Antonio Argenziano
Cc: Tvrtko Ursulin
Signed-off-by: Michel Thierry
Signed-off-by: Carlos Santa
---
drivers/gpu/drm/i915/intel_lrc.c | 53 +++-
1 file changed, 45 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 0afcbeb18329..25ba5fcc9466 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1885,8 +1885,8 @@ static int gen8_emit_bb_start(struct i915_request *rq,
GEM_BUG_ON(!engine->emit_start_watchdog ||
!engine->emit_stop_watchdog);
- /* + start_watchdog (6) + stop_watchdog (4) */
- num_dwords += 10;
+ /* + start_watchdog (6) */
+ num_dwords += 6;
watchdog_running = true;
}
@@ -1927,10 +1927,7 @@ static int gen8_emit_bb_start(struct i915_request *rq,
*cs++ = MI_ARB_ON_OFF | MI_ARB_DISABLE;
*cs++ = MI_NOOP;
- if (watchdog_running) {
- /* Cancel watchdog timer */
- cs = engine->emit_stop_watchdog(rq, cs);
- }
+ // XXX: emit_stop_watchdog happens in gen8_emit_breadcrumb_vcs
No C++ comments please. And what does XXX mean? Doesn't feel like it
belongs.
intel_ring_advance(rq, cs);
return 0;
@@ -2189,6 +2186,37 @@ static void gen8_emit_breadcrumb(struct i915_request
*request, u32 *cs)
}
static const int gen8_emit_breadcrumb_sz = 6 + WA_TAIL_DWORDS;
+static void gen8_emit_breadcrumb_vcs(struct i915_request *request, u32 *cs)
+{
+ /* w/a: bit 5 needs to be zero for MI_FLUSH_DW address. */
+ BUILD_BUG_ON(I915_GEM_HWS_INDEX_ADDR & (1 << 5));
+
+ cs = gen8_emit_ggtt_write(cs, request->global_seqno,
+ intel_hws_seqno_address(request->engine));
+ *cs++ = MI_USER_INTERRUPT;
+ *cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE;
+
+ // stop_watchdog at the very end of the ring commands
+ if (request->gem_context->__engine[VCS].watchdog_threshold != 0)
VCS is wrong. Whole check needs to be to_intel_context(ctx,
engine)->watchdog_threshold I think.
+ {
+ /* Cancel watchdog timer */
+ GEM_BUG_ON(!request->engine->emit_stop_watchdog);
+ cs = request->engine->emit_stop_watchdog(request, cs);
+ }
+ else
+ {
Coding style is wrong (curly braces for if else).
+ *cs++ = MI_NOOP;
+ *cs++ = MI_NOOP;
+ *cs++ = MI_NOOP;
+ *cs++ = MI_NOOP;
+ }
+
+ request->tail = intel_ring_offset(request, cs);
+ assert_ring_tail_valid(request->ring, request->tail);
+ gen8_emit_wa_tail(request, cs);
+}
+static const int gen8_emit_breadcrumb_vcs_sz = 6 + WA_TAIL_DWORDS + 4; //+4
for optional stop_watchdog
+
static void gen8_emit_breadcrumb_rcs(struct i915_request *request, u32 *cs)
{
/* We're using qword write, seqno should be aligned to 8 bytes. */
@@ -2306,8 +2334,17 @@ logical_ring_default_vfuncs(struct intel_engine_cs
*engine)
engine->request_alloc = execlists_request_alloc;
engine->emit_flush = gen8_emit_flush;
- engine->emit_breadcrumb = gen8_emit_breadcrumb;
- engine->emit_breadcrumb_sz = gen8_emit_breadcrumb_sz;
+
+ if (engine->id == VCS || engine->id == VCS2)
What about VCS3 or 4? Hint use engine class.
And what about RCS and VECS?
+ {
+ engine->emit_breadcrumb = gen8_emit_breadcrumb_vcs;
+ engine->emit_breadcrumb_sz = gen8_emit_breadcrumb_vcs_sz;
+ }
+ else
+ {
+ engine->emit_breadcrumb = gen8_emit_breadcrumb;
+ engine->emit_breadcrumb_sz = gen8_emit_breadcrumb_sz;
+ }
engine->set_default_submission = intel_execlists_set_default_submission;
Looks like the patch should be squashed with the one which implements
watchdog emit start/end? I mean if the whole setup has broken edge cases
without this..
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915: Watchdog timeout: DRM kernel interface to set the timeout
Quoting Tvrtko Ursulin (2019-01-07 12:38:47)
> On 05/01/2019 02:39, Carlos Santa wrote:
> > +/* Return the timer count threshold in microseconds. */
> > +int i915_gem_context_get_watchdog(struct i915_gem_context *ctx,
> > + struct drm_i915_gem_context_param *args)
> > + if (__copy_to_user(u64_to_user_ptr(args->value),
> > +&threshold_in_us,
> > +sizeof(threshold_in_us))) {
>
> I think user pointer hasn't been verified for write access yet so
> standard copy_to_user should be used.
The starting point here is that this bakes in OTHER_CLASS as uABI when
clearly it is not uABI. The array must be variable size and so the first
pass is to report the size to userspace (if they pass args->size = 0)
and then to copy up to the user requested size. Since it is a variable
array with uncertain indexing, the output should be along the lines of
[class, instance, watchdog]. But what about virtual engine? Good
question. (Remember set must follow the same pattern as get, so you can
always do a rmw cleanly.)
I guess we just have to accept class == -1 as meaning use instance as an
index into ctx->engines[]. Tvrtko? Virtual engine would be reported as
(-1, 0, watchdog), and settable similarly with the other engines being
addressable either by index or by class-instance.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for ACPI/i915: Add support for PMIC MIPI sequence elements (rev2)
== Series Details ==
Series: ACPI/i915: Add support for PMIC MIPI sequence elements (rev2)
URL : https://patchwork.freedesktop.org/series/54050/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5368 -> Patchwork_11199
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_11199 need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11199, 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/54050/revisions/2/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_11199:
### IGT changes ###
Warnings
* igt@kms_busy@basic-flip-a:
- fi-kbl-7567u: PASS -> SKIP +2
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c:
- fi-kbl-7567u: SKIP -> PASS +33
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
- fi-hsw-4770:PASS -> SKIP +4
Known issues
Here are the changes found in Patchwork_11199 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_contexts:
- fi-icl-u3: NOTRUN -> DMESG-FAIL [fdo#108569]
* igt@kms_busy@basic-flip-b:
- fi-gdg-551: PASS -> FAIL [fdo#103182]
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362] +1
Possible fixes
* igt@kms_frontbuffer_tracking@basic:
- fi-byt-clapper: FAIL [fdo#103167] -> PASS
* igt@pm_rpm@module-reload:
- fi-icl-u2: DMESG-WARN [fdo#108654] -> PASS
* igt@prime_vgem@basic-fence-flip:
- fi-gdg-551: FAIL [fdo#103182] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108654]: https://bugs.freedesktop.org/show_bug.cgi?id=108654
[fdo#108915]: https://bugs.freedesktop.org/show_bug.cgi?id=108915
Participating hosts (47 -> 45)
--
Additional (3): fi-icl-y fi-byt-j1900 fi-icl-u3
Missing(5): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600
Build changes
-
* Linux: CI_DRM_5368 -> Patchwork_11199
CI_DRM_5368: 64bd30ea3ce0edd057a5b393569947a955472757 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4756: 75081c6bfb9998bd7cbf35a7ac0578c683fe55a8 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11199: 901d195444787d9174b6f5c8c18e44ed0adbd60b @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
901d19544478 drm/i915/intel_dsi_vbt: Add support for PMIC MIPI sequences
477f2670daa3 ACPI / PMIC: Add generic intel_soc_pmic_exec_mipi_pmic_seq_element
handling
3283d4be483f ACPI / PMIC: Implement exec_mipi_pmic_seq_element for CHT Whiskey
Cove PMIC
5e6bd13cdb2b ACPI / PMIC: Add support for executing PMIC MIPI sequence elements
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11199/
___
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 [01/46] drm/i915: Return immediately if trylock fails for direct-reclaim
== Series Details == Series: series starting with [01/46] drm/i915: Return immediately if trylock fails for direct-reclaim URL : https://patchwork.freedesktop.org/series/54803/ State : warning == Summary == $ dim checkpatch origin/drm-tip 7b61c9e7b9d7 drm/i915: Return immediately if trylock fails for direct-reclaim -:54: CHECK:UNCOMMENTED_DEFINITION: struct mutex definition without comment #54: FILE: drivers/gpu/drm/i915/i915_drv.h:3191: + struct mutex *mutex); total: 0 errors, 0 warnings, 1 checks, 172 lines checked 15f754232c8b drm/i915: Report the number of closed vma held by each context in debugfs -:68: WARNING:LONG_LINE: line over 100 characters #68: FILE: drivers/gpu/drm/i915/i915_debugfs.c:348: + seq_printf(m, "%s: %lu objects, %llu bytes (%llu active, %llu inactive, %llu global, %llu shared, %llu unbound, %llu closed)\n", \ total: 0 errors, 1 warnings, 0 checks, 201 lines checked 44eb22b9d0e9 drm/i915: Track all held rpm wakerefs -:106: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment #106: FILE: drivers/gpu/drm/i915/i915_drv.h:1162: + spinlock_t debug_lock; total: 0 errors, 0 warnings, 1 checks, 571 lines checked 4474d8b3116c drm/i915: Markup paired operations on wakerefs -:380: WARNING:NEW_TYPEDEFS: do not add new typedefs #380: FILE: drivers/gpu/drm/i915/i915_drv.h:134: +typedef depot_stack_handle_t intel_wakeref_t; total: 0 errors, 1 warnings, 0 checks, 1168 lines checked 73bb87c62275 drm/i915: Track GT wakeref ecc94ab152f0 drm/i915: Track the rpm wakerefs for error handling 51f4dc876674 drm/i915: Mark up sysfs with rpm wakeref tracking bbadf9c61168 drm/i915: Mark up debugfs with rpm wakeref tracking 6f69f6cb282d drm/i915/perf: Track the rpm wakeref 4a6ad9c0bf6b drm/i915/pmu: Track rpm wakeref 27ac441fad2c drm/i915/guc: Track the rpm wakeref 31d63b175d79 drm/i915/gem: Track the rpm wakerefs a92f6a6c3356 drm/i915/fb: Track rpm wakerefs 8cc18f52ef6e drm/i915/hotplug: Track temporary rpm wakeref bb14613eca20 drm/i915/panel: Track temporary rpm wakeref 597c006df1dc drm/i915/selftests: Mark up rpm wakerefs 6f2468caa207 drm/i915: Syntatic sugar for using intel_runtime_pm -:512: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'i915' - possible side-effects? #512: FILE: drivers/gpu/drm/i915/intel_drv.h:2190: +#define with_intel_runtime_pm(i915, wf) \ + for (wf = intel_runtime_pm_get(i915); wf; \ +intel_runtime_pm_put(i915, wf), wf = 0) -:512: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'wf' - possible side-effects? #512: FILE: drivers/gpu/drm/i915/intel_drv.h:2190: +#define with_intel_runtime_pm(i915, wf) \ + for (wf = intel_runtime_pm_get(i915); wf; \ +intel_runtime_pm_put(i915, wf), wf = 0) -:516: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'i915' - possible side-effects? #516: FILE: drivers/gpu/drm/i915/intel_drv.h:2194: +#define with_intel_runtime_pm_if_in_use(i915, wf) \ + for (wf = intel_runtime_pm_get_if_in_use(i915); wf; \ +intel_runtime_pm_put(i915, wf), wf = 0) -:516: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'wf' - possible side-effects? #516: FILE: drivers/gpu/drm/i915/intel_drv.h:2194: +#define with_intel_runtime_pm_if_in_use(i915, wf) \ + for (wf = intel_runtime_pm_get_if_in_use(i915); wf; \ +intel_runtime_pm_put(i915, wf), wf = 0) total: 0 errors, 0 warnings, 4 checks, 734 lines checked b80423487b07 drm/i915: Markup paired operations on display power domains e1b960f8dd38 drm/i915: Track the wakeref used to initialise display power domains -:214: WARNING:LINE_SPACING: Missing a blank line after declarations #214: FILE: drivers/gpu/drm/i915/intel_runtime_pm.c:4107: + struct i915_power_domains *power_domains = &i915->power_domains; + intel_wakeref_t wakeref __maybe_unused = total: 0 errors, 1 warnings, 0 checks, 324 lines checked 3ca33907833e drm/i915: Combined gt.awake/gt.power wakerefs 2846424a5065 drm/i915/dp: Markup pps lock power well -:58: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'dp' - possible side-effects? #58: FILE: drivers/gpu/drm/i915/intel_dp.c:635: +#define with_pps_lock(dp, wf) \ + for (wf = pps_lock(dp); wf; wf = pps_unlock(dp, wf)) -:58: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'wf' - possible side-effects? #58: FILE: drivers/gpu/drm/i915/intel_dp.c:635: +#define with_pps_lock(dp, wf) \ + for (wf = pps_lock(dp); wf; wf = pps_unlock(dp, wf)) total: 0 errors, 0 warnings, 2 checks, 430 lines checked 2cf475a0e278 drm/i915: Complain if hsw_get_pipe_config acquires the same power well twice 439540e3f554 drm/i915: Mark up Ironlake ips with rpm wakerefs 6888a1eda106 drm/i915: Serialise concurrent calls to i915_gem_set_wedged() -:48: WARNING:MEMORY_BARRIER: memory barrier without comment #48: FILE: drivers/gpu/drm/i915/i915_gem.c:3230: + smp_mb__before_atomic(); total: 0 errors, 1 warnings, 0 checks, 110 lines checked c9872aff5d50 drm/i915: Differentiate between ggtt->mutex and ppgt
[Intel-gfx] [PATCH i-g-t] i915/gem_ctx_isolation: Ignore the low bits of BB_OFFSET
On Skylake, BB_OFFSET seems to be unstable. Since this is an
offset into the batch at the time of CS execution, it should be actively
written to as we read from the register so allow it a qword of
discrepancy (since the CS should be reading in qwords). This still
allows us to detect dirt across the rest of the register field, should
that be required.
Signed-off-by: Chris Wilson
---
tests/i915/gem_ctx_isolation.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/i915/gem_ctx_isolation.c b/tests/i915/gem_ctx_isolation.c
index 058cf3ec1..78a244382 100644
--- a/tests/i915/gem_ctx_isolation.c
+++ b/tests/i915/gem_ctx_isolation.c
@@ -96,7 +96,7 @@ static const struct named_register {
{ "GPGPU_THREADS_DISPATCHED", GEN8, RCS0, 0x2290, 2 },
{ "PS_INVOCATION_COUNT_1", GEN8, RCS0, 0x22f0, 2 },
{ "PS_DEPTH_COUNT_1", GEN8, RCS0, 0x22f8, 2 },
- { "BB_OFFSET", GEN8, RCS0, 0x2158 },
+ { "BB_OFFSET", GEN8, RCS0, 0x2158, .ignore_bits = 0x7 },
{ "MI_PREDICATE_RESULT_1", GEN8, RCS0, 0x241c },
{ "CS_GPR", GEN8, RCS0, 0x2600, 32 },
{ "OA_CTX_CONTROL", GEN8, RCS0, 0x2360 },
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915: Only process VCS2 only when supported
On 05/01/2019 02:39, Carlos Santa wrote:
Not checking for BSD2 causes a segfault on GPU revs
with no h/w support for the extra media engines.
Segfault on ULX GT2 (0x591e) follows:
Patch shared by Michel Thierry on IIRC.
[ 468.625970] BUG: unable to handle kernel NULL pointer dereference at
02c0
[ 468.625978] IP: gen8_cs_irq_handler+0x8d/0xcf
[ 468.625979] PGD 0 P4D 0
[ 468.625983] Oops: 0002 [#1] PREEMPT SMP PTI
[ 468.625987] Dumping ftrace buffer:
[ 468.625990](ftrace buffer empty)
[ 468.627877] gsmi: Log Shutdown Reason 0x03
[ 468.627880] Modules linked in: cmac rfcomm uinput joydev snd_soc_hdac_hdmi
snd_soc_dmic snd_soc_skl snd_soc_skl_ipc lzo lzo_compress snd_soc_sst_ipc
snd_soc_sst_dsp snd_soc_acpi snd_hda_ext_core snd_hda_core zram
snd_soc_max98927 ipt_MASQUERADE nf_nat_masquerade_ipv4 hid_multitouch xt_mark
fuse cdc_ether usbnet btusb btrtl btbcm btintel uvcvideo bluetooth
videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core ecdh_generic
iio_trig_sysfs cros_ec_light_prox cros_ec_sensors_ring cros_ec_sensors
cros_ec_activity cros_ec_sensors_core industrialio_triggered_buffer kfifo_buf
industrialio iwlmvm iwl7000_mac80211 r8152 mii iwlwifi cfg80211
[ 468.627917] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.14.64 #38
[ 468.627919] Hardware name: Google Eve/Eve, BIOS Google_Eve.9584.107.0
11/07/2017
[ 468.627922] task: 96bf35a13c00 task.stack: a7988007
[ 468.627925] RIP: 0010:gen8_cs_irq_handler+0x8d/0xcf
[ 468.627928] RSP: 0018:96bf3ec83df8 EFLAGS: 00010002
[ 468.627931] RAX: 0100 RBX: RCX: 0010
[ 468.627933] RDX: 0010 RSI: 0040 RDI:
[ 468.627936] RBP: 96bf3ec83e20 R08: R09:
[ 468.627938] R10: a79880073dc8 R11: a2a6453d R12: 96bf3ec83e70
[ 468.627940] R13: 0079 R14: R15: 0040
[ 468.627943] FS: () GS:96bf3ec8()
knlGS:
[ 468.627945] CS: 0010 DS: ES: CR0: 80050033
[ 468.627948] CR2: 02c0 CR3: 00016fe12002 CR4: 003606e0
[ 468.627950] DR0: DR1: DR2:
[ 468.627953] DR3: DR6: fffe0ff0 DR7: 0400
[ 468.627955] Call Trace:
[ 468.627959]
[ 468.627963] gen8_gt_irq_handler+0x5e/0xed
[ 468.627968] gen8_irq_handler+0x9f/0x5ce
[ 468.627973] __handle_irq_event_percpu+0xb8/0x1da
[ 468.627977] handle_irq_event_percpu+0x32/0x77
[ 468.627980] handle_irq_event+0x36/0x55
[ 468.627984] handle_edge_irq+0x7d/0xcd
[ 468.627988] handle_irq+0xd9/0x11e
[ 468.627992] do_IRQ+0x4b/0xd0
[ 468.627996] common_interrupt+0x7a/0x7a
[ 468.627999]
[ 468.628003] RIP: 0010:cpuidle_enter_state+0xff/0x177
[ 468.628005] RSP: 0018:a79880073e78 EFLAGS: 0206 ORIG_RAX:
ff5e
[ 468.628008] RAX: 96bf3eca09c0 RBX: 0002b9c3 RCX: 006d1c48c3b5
[ 468.628010] RDX: 0037 RSI: 0001 RDI:
[ 468.628013] RBP: a79880073ec0 R08: 0002 R09: 5000
[ 468.628015] R10: 071c71c71c71c71c R11: a2e42687 R12:
[ 468.628017] R13: 0002 R14: 0002 R15: 96bf3eca7d00
[ 468.628020] ? cpu_idle_poll+0x8e/0x8e
[ 468.628025] ? cpuidle_enter_state+0xe3/0x177
[ 468.628028] do_idle+0x10c/0x19d
[ 468.628033] cpu_startup_entry+0x6d/0x6f
[ 468.628036] start_secondary+0x189/0x1a4
[ 468.628041] secondary_startup_64+0xa5/0xb0
[ 468.628044] Code: c3 84 db 74 20 f0 41 0f ba ae 98 02 00 00 00 0f 92 45 df 80 7d
df 00 75 0c 49 8d be 90 02 00 00 e8 3a 7a c6 ff 41 f6 c7 40 74 23 41 0f ba
ae c0 02 00 00 00 0f 92 45 de 80 7d de 00 75 0f 49
[ 468.628083] RIP: gen8_cs_irq_handler+0x8d/0xcf RSP: 96bf3ec83df8
[ 468.628085] CR2: 02c0
[ 468.628088] ---[ end trace a7a497ddeb44bcf8 ]---
Tested-by: Carlos Santa
Cc: Tvrtko Ursulin
Cc: Antonio Argenziano
Cc: Michel Thierry
Signed-off-by: Carlos Santa
---
drivers/gpu/drm/i915/i915_irq.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 859bbadb752f..953ebe5c85ce 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1554,7 +1554,8 @@ static void gen8_gt_irq_handler(struct drm_i915_private
*i915,
if (master_ctl & (GEN8_GT_VCS1_IRQ | GEN8_GT_VCS2_IRQ)) {
gen8_cs_irq_handler(i915->engine[VCS],
gt_iir[1] >> GEN8_VCS1_IRQ_SHIFT);
- gen8_cs_irq_handler(i915->engine[VCS2],
+ if(HAS_BSD2(i915))
+ gen8_cs_irq_handler(i915->engine[VCS2],
gt_iir[1] >> GEN8_VCS2_IRQ_SHIFT);
}
Why would we be getting interrupts from engines which are not there?
Re: [Intel-gfx] drm/i915: Watchdog timeout: DRM kernel interface to set the timeout
On 05/01/2019 02:39, Carlos Santa wrote:
From: Michel Thierry
Final enablement patch for GPU hang detection using watchdog timeout.
Using the gem_context_setparam ioctl, users can specify the desired
timeout value in microseconds, and the driver will do the conversion to
'timestamps'.
The recommended default watchdog threshold for video engines is 6 us,
since this has been _empirically determined_ to be a good compromise for
low-latency requirements and low rate of false positives. The default
register value is ~106000us and the theoretical max value (all 1s) is
353 seconds.
Note, UABI engine ids and i915 engine ids are different, and this patch
uses the i915 ones. Some kind of mapping table [1] is required if we
decide to use the UABI engine ids.
This paragraphs is not true any more.
[1]
http://patchwork.freedesktop.org/patch/msgid/20170329135831.30254-2-ch...@chris-wilson.co.uk
>> v2: Fixed get api to return values in microseconds. Threshold updated to
be per context engine. Check for u32 overflow. Capture ctx threshold
value in error state.
v3: Add a way to get array size, short-cut to disable all thresholds,
return EFAULT / EINVAL as needed. Move the capture of the threshold
value in the error state into a new patch. BXT has a different
timestamp base (because why not?).
v4: Checking if watchdog is available should be the first thing to
do, instead of giving false hopes to abi users; remove unnecessary & in
set_watchdog; ignore args->size in getparam.
v5: GEN9-LP platforms have a different crystal clock frequency, use the
right timestamp base for them (magic 8-ball predicts this will change
again later on, so future-proof it). (Daniele)
v6: Rebase, no more mutex BLK in getparam_ioctl.
v7: use to_intel_context instead of ctx->engine.
v8: Rebase, remove extra mutex from i915_gem_context_set_watchdog (Tvrtko),
Update UAPI to use engine class while keeping thresholds per
engine class (Michel).
Cc: Antonio Argenziano
Cc: Tvrtko Ursulin
Cc: Daniele Ceraolo Spurio
Signed-off-by: Michel Thierry
Signed-off-by: Carlos Santa
---
drivers/gpu/drm/i915/i915_drv.h | 56 +++
drivers/gpu/drm/i915/i915_gem_context.c | 91 +
drivers/gpu/drm/i915/intel_lrc.c| 5 +-
include/uapi/drm/i915_drm.h | 1 +
4 files changed, 151 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7fa2a405c5fe..96d59c22e2ba 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1552,6 +1552,9 @@ struct drm_i915_private {
struct drm_i915_fence_reg fence_regs[I915_MAX_NUM_FENCES]; /* assume
965 */
int num_fence_regs; /* 8 on pre-965, 16 otherwise */
+ /* Command stream timestamp base - helps define watchdog threshold */
+ u32 cs_timestamp_base;
+
unsigned int fsb_freq, mem_freq, is_ddr3;
unsigned int skl_preferred_vco_freq;
unsigned int max_cdclk_freq;
@@ -3117,6 +3120,59 @@ i915_gem_context_lookup(struct drm_i915_file_private
*file_priv, u32 id)
return ctx;
}
+/*
+ * BDW, CHV & SKL+ Timestamp timer resolution = 0.080 uSec,
+ * or 1250 counts per second, or ~12 counts per microsecond.
+ *
+ * But BXT/GLK Timestamp timer resolution is different, 0.052 uSec,
+ * or 1920 counts per second, or ~19 counts per microsecond.
+ *
+ * Future-proofing, some day it won't be as simple as just GEN & IS_LP.
+ */
+#define GEN8_TIMESTAMP_CNTS_PER_USEC 12
+#define GEN9_LP_TIMESTAMP_CNTS_PER_USEC 19
+static inline u32 cs_timestamp_in_us(struct drm_i915_private *dev_priv)
+{
+ u32 cs_timestamp_base = dev_priv->cs_timestamp_base;
+
+ if (cs_timestamp_base)
+ return cs_timestamp_base;
+
+ switch (INTEL_GEN(dev_priv)) {
+ default:
+ MISSING_CASE(INTEL_GEN(dev_priv));
+ /* fall through */
+ case 9:
+ cs_timestamp_base = IS_GEN9_LP(dev_priv) ?
+ GEN9_LP_TIMESTAMP_CNTS_PER_USEC :
+ GEN8_TIMESTAMP_CNTS_PER_USEC;
+ break;
+ case 8:
+ cs_timestamp_base = GEN8_TIMESTAMP_CNTS_PER_USEC;
+ break;
+ }
+
+ dev_priv->cs_timestamp_base = cs_timestamp_base;
+ return cs_timestamp_base;
+}
We already have RUNTIME_INFO(i915)->cs_timestamp_frequency_khz and
read_timestamp_frequency which sets it.
+
+static inline u32
+watchdog_to_us(struct drm_i915_private *dev_priv, u32 value_in_clock_counts)
+{
+ return value_in_clock_counts / cs_timestamp_in_us(dev_priv);
+}
+
+static inline u32
+watchdog_to_clock_counts(struct drm_i915_private *dev_priv, u64 value_in_us)
+{
+ u64 threshold = value_in_us * cs_timestamp_in_us(dev_priv);
+
+ if (overflows_type(threshold, u32))
+ return -EINVAL;
+
+ return threshold;
+}
+
int i915_perf_open_ioctl(struct drm_device *dev, v
Re: [Intel-gfx] [PATCH 02/46] drm/i915: Report the number of closed vma held by each context in debugfs
Chris Wilson writes:
> Include the total size of closed vma when reporting the per_ctx_stats of
> debugfs/i915_gem_objects.
>
> Whilst adjusting the context tracking, note that we can simply use our
> list of contexts in i915->contexts rather than circumlocute via
> dev->filelist and the per-file context idr, with the result that we can
> show objects allocated to different vm (i.e. contexts within a file).
>
> We change the output to show every context of each client, with its own
> unique set of objects (for full-ppgtt machines, i.e. gen7+, for older
> hardware all objects are in the global gtt and so can not be associated
> with a single context). That should result in no loss of information,
> and for gen7+, no duplication of active objects.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 124 +++-
> 1 file changed, 47 insertions(+), 77 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 193823048f96..c77326a7d058 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -297,11 +297,12 @@ static int i915_gem_stolen_list_info(struct seq_file
> *m, void *data)
> }
>
> struct file_stats {
> - struct drm_i915_file_private *file_priv;
> + struct i915_address_space *vm;
> unsigned long count;
> u64 total, unbound;
> u64 global, shared;
> u64 active, inactive;
> + u64 closed;
> };
>
> static int per_file_stats(int id, void *ptr, void *data)
> @@ -326,9 +327,7 @@ static int per_file_stats(int id, void *ptr, void *data)
> if (i915_vma_is_ggtt(vma)) {
> stats->global += vma->node.size;
> } else {
> - struct i915_hw_ppgtt *ppgtt = i915_vm_to_ppgtt(vma->vm);
> -
> - if (ppgtt->vm.file != stats->file_priv)
> + if (vma->vm != stats->vm)
> continue;
> }
>
> @@ -336,6 +335,9 @@ static int per_file_stats(int id, void *ptr, void *data)
> stats->active += vma->node.size;
> else
> stats->inactive += vma->node.size;
> +
> + if (i915_vma_is_closed(vma))
> + stats->closed += vma->node.size;
> }
>
> return 0;
> @@ -343,7 +345,7 @@ static int per_file_stats(int id, void *ptr, void *data)
>
> #define print_file_stats(m, name, stats) do { \
> if (stats.count) \
> - seq_printf(m, "%s: %lu objects, %llu bytes (%llu active, %llu
> inactive, %llu global, %llu shared, %llu unbound)\n", \
> + seq_printf(m, "%s: %lu objects, %llu bytes (%llu active, %llu
> inactive, %llu global, %llu shared, %llu unbound, %llu closed)\n", \
> name, \
> stats.count, \
> stats.total, \
> @@ -351,20 +353,19 @@ static int per_file_stats(int id, void *ptr, void *data)
> stats.inactive, \
> stats.global, \
> stats.shared, \
> -stats.unbound); \
> +stats.unbound, \
> +stats.closed); \
> } while (0)
>
> static void print_batch_pool_stats(struct seq_file *m,
> struct drm_i915_private *dev_priv)
> {
> struct drm_i915_gem_object *obj;
> - struct file_stats stats;
> struct intel_engine_cs *engine;
> + struct file_stats stats = {};
> enum intel_engine_id id;
> int j;
>
> - memset(&stats, 0, sizeof(stats));
> -
> for_each_engine(engine, dev_priv, id) {
> for (j = 0; j < ARRAY_SIZE(engine->batch_pool.cache_list); j++)
> {
> list_for_each_entry(obj,
> @@ -377,44 +378,47 @@ static void print_batch_pool_stats(struct seq_file *m,
> print_file_stats(m, "[k]batch pool", stats);
> }
>
> -static int per_file_ctx_stats(int idx, void *ptr, void *data)
> +static void print_context_stats(struct seq_file *m,
> + struct drm_i915_private *i915)
> {
> - struct i915_gem_context *ctx = ptr;
> - struct intel_engine_cs *engine;
> - enum intel_engine_id id;
> + struct file_stats kstats = {};
> + struct i915_gem_context *ctx;
>
> - for_each_engine(engine, ctx->i915, id) {
> - struct intel_context *ce = to_intel_context(ctx, engine);
> + list_for_each_entry(ctx, &i915->contexts.list, link) {
> + struct intel_engine_cs *engine;
> + enum intel_engine_id id;
>
> - if (ce->state)
> - per_file_stats(0, ce->state->obj, data);
> - if (ce->ring)
> - per_file_stats(0, ce->ring->vma->obj, data);
> - }
> + for_each_engine(engine, i915, id) {
> + struct intel_context *ce
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] tests/gem_shrink: Exercise OOM and other routes to shrinking in reasonable time
Quoting Michał Winiarski (2019-01-07 12:27:07)
> On Fri, Jan 04, 2019 at 03:37:09PM +, Tvrtko Ursulin wrote:
> > From: Tvrtko Ursulin
> >
> > A set of subtests which exercises different paths to our shrinker code
> > (including the OOM killer) in predictable and reasonable time budget.
> >
> > Signed-off-by: Tvrtko Ursulin
> > ---
> > lib/igt_core.c| 19 ++
> > lib/igt_core.h| 1 +
> > tests/i915/gem_shrink.c | 399 ++
> > tests/intel-ci/blacklist.txt | 1 +
> > tests/intel-ci/fast-feedback.testlist | 3 +
> > 5 files changed, 423 insertions(+)
>
> [snip]
>
> > diff --git a/tests/i915/gem_shrink.c b/tests/i915/gem_shrink.c
> > index c8e05814ee70..7c002de0ef1f 100644
> > --- a/tests/i915/gem_shrink.c
> > +++ b/tests/i915/gem_shrink.c
> > @@ -26,6 +26,10 @@
> > *
> > * Exercise the shrinker by overallocating GEM objects
> > */
> > +#include
> > +#include
> > +#include
> > +#include
> >
> > #include "igt.h"
> > #include "igt_gt.h"
> > @@ -366,6 +370,376 @@ static void reclaim(unsigned engine, int timeout)
> > close(fd);
> > }
> >
> > +static unsigned long get_meminfo(const char *info, const char *tag)
> > +{
> > + const char *str;
> > + unsigned long val;
> > +
> > + str = strstr(info, tag);
> > + if (str && sscanf(str + strlen(tag), " %lu", &val) == 1)
> > + return val >> 10;
> > +
> > + igt_warn("Unrecognised /proc/meminfo field: '%s'\n", tag);
> > + return 0;
> > +}
> > +
> > +static unsigned long get_avail_ram_mb(void)
> > +{
> > + int fd;
> > + int ret;
> > + char buf[4096];
> > + unsigned long ram;
> > +
> > + fd = open("/proc/meminfo", O_RDONLY);
> > + igt_assert_fd(fd);
> > +
> > + ret = read(fd, buf, sizeof(buf));
> > + igt_assert(ret >= 0);
> > +
> > + close(fd);
> > +
> > + ram = get_meminfo(buf, "MemAvailable:");
> > + ram += get_meminfo(buf, "Buffers:");
> > + ram += get_meminfo(buf, "Cached:");
> > + ram += get_meminfo(buf, "SwapCached:");
> > +
> > + return ram;
> > +}
>
> What's wrong with ones from intel_os.c?
They pull in both an i915 and mm purge, which iirc, had to be avoided
here.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] tests/gem_shrink: Exercise OOM and other routes to shrinking in reasonable time
On Fri, Jan 04, 2019 at 03:37:09PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> A set of subtests which exercises different paths to our shrinker code
> (including the OOM killer) in predictable and reasonable time budget.
>
> Signed-off-by: Tvrtko Ursulin
> ---
> lib/igt_core.c| 19 ++
> lib/igt_core.h| 1 +
> tests/i915/gem_shrink.c | 399 ++
> tests/intel-ci/blacklist.txt | 1 +
> tests/intel-ci/fast-feedback.testlist | 3 +
> 5 files changed, 423 insertions(+)
[snip]
> diff --git a/tests/i915/gem_shrink.c b/tests/i915/gem_shrink.c
> index c8e05814ee70..7c002de0ef1f 100644
> --- a/tests/i915/gem_shrink.c
> +++ b/tests/i915/gem_shrink.c
> @@ -26,6 +26,10 @@
> *
> * Exercise the shrinker by overallocating GEM objects
> */
> +#include
> +#include
> +#include
> +#include
>
> #include "igt.h"
> #include "igt_gt.h"
> @@ -366,6 +370,376 @@ static void reclaim(unsigned engine, int timeout)
> close(fd);
> }
>
> +static unsigned long get_meminfo(const char *info, const char *tag)
> +{
> + const char *str;
> + unsigned long val;
> +
> + str = strstr(info, tag);
> + if (str && sscanf(str + strlen(tag), " %lu", &val) == 1)
> + return val >> 10;
> +
> + igt_warn("Unrecognised /proc/meminfo field: '%s'\n", tag);
> + return 0;
> +}
> +
> +static unsigned long get_avail_ram_mb(void)
> +{
> + int fd;
> + int ret;
> + char buf[4096];
> + unsigned long ram;
> +
> + fd = open("/proc/meminfo", O_RDONLY);
> + igt_assert_fd(fd);
> +
> + ret = read(fd, buf, sizeof(buf));
> + igt_assert(ret >= 0);
> +
> + close(fd);
> +
> + ram = get_meminfo(buf, "MemAvailable:");
> + ram += get_meminfo(buf, "Buffers:");
> + ram += get_meminfo(buf, "Cached:");
> + ram += get_meminfo(buf, "SwapCached:");
> +
> + return ram;
> +}
What's wrong with ones from intel_os.c?
-Michał
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/icl: Apply WaEnablePreemptionGranularityControlByUMD
On Mon, Jan 07, 2019 at 01:01:16PM +0200, Joonas Lahtinen wrote:
> Quoting José Roberto de Souza (2019-01-04 19:37:00)
> > According to Workaround database ICL also needs
> > WaEnablePreemptionGranularityControlByUMD, to allow userspace to do
> > fine-granularity preemptions per-context.
>
> I must wonder where is the userspace component that needs this, and why
> it hasn't been noticed earlier?
>
> Or is this one more of the cases when no userspace actually uses the
> register?
It's used:
https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/mesa/drivers/dri/i965/brw_state_upload.c#L64
-Michał
> Regards, Joonas
>
> >
> > BSpec: 11348
> > Cc: Oscar Mateo
> > Cc: Radhakrishna Sripada
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/intel_workarounds.c | 9 ++---
> > 1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
> > b/drivers/gpu/drm/i915/intel_workarounds.c
> > index 480c53a2ecb5..bbc5a66faa07 100644
> > --- a/drivers/gpu/drm/i915/intel_workarounds.c
> > +++ b/drivers/gpu/drm/i915/intel_workarounds.c
> > @@ -1014,7 +1014,7 @@ static void gen9_whitelist_build(struct i915_wa_list
> > *w)
> > /* WaVFEStateAfterPipeControlwithMediaStateClear:skl,bxt,glk,cfl */
> > whitelist_reg(w, GEN9_CTX_PREEMPT_REG);
> >
> > - /* WaEnablePreemptionGranularityControlByUMD:skl,bxt,kbl,cfl,[cnl]
> > */
> > + /*
> > WaEnablePreemptionGranularityControlByUMD:skl,bxt,kbl,cfl,[cnl,icl] */
> > whitelist_reg(w, GEN8_CS_CHICKEN1);
> >
> > /* WaAllowUMDToModifyHDCChicken1:skl,bxt,kbl,glk,cfl */
> > @@ -1068,6 +1068,9 @@ static void icl_whitelist_build(struct i915_wa_list
> > *w)
> >
> > /* WaAllowUMDToModifySamplerMode:icl */
> > whitelist_reg(w, GEN10_SAMPLER_MODE);
> > +
> > + /* WaEnablePreemptionGranularityControlByUMD:icl */
> > + whitelist_reg(w, GEN8_CS_CHICKEN1);
> > }
> >
> > void intel_engine_init_whitelist(struct intel_engine_cs *engine)
> > @@ -1186,8 +1189,8 @@ static void rcs_engine_wa_init(struct intel_engine_cs
> > *engine)
> > GEN7_DISABLE_SAMPLER_PREFETCH);
> > }
> >
> > - if (IS_GEN(i915, 9) || IS_CANNONLAKE(i915)) {
> > - /*
> > WaEnablePreemptionGranularityControlByUMD:skl,bxt,kbl,cfl,cnl */
> > + if (IS_GEN_RANGE(i915, 9, 11)) {
> > + /*
> > WaEnablePreemptionGranularityControlByUMD:skl,bxt,kbl,cfl,cnl,icl */
> > wa_masked_en(wal,
> > GEN7_FF_SLICE_CS_CHICKEN1,
> > GEN9_FFSC_PERCTX_PREEMPT_CTRL);
> > --
> > 2.20.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
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915: Watchdog timeout: Ringbuffer command emission for gen8+
On 05/01/2019 02:39, Carlos Santa wrote:
From: Michel Thierry
Emit the required commands into the ring buffer for starting and
stopping the watchdog timer before/after batch buffer start during
batch buffer submission.
v2: Support watchdog threshold per context engine, merge lri commands,
and move watchdog commands emission to emit_bb_start. Request space of
combined start_watchdog, bb_start and stop_watchdog to avoid any error
after emitting bb_start.
v3: There were too many req->engine in emit_bb_start.
Use GEM_BUG_ON instead of returning a very late EINVAL in the remote
case of watchdog misprogramming; set correct LRI cmd size in
emit_stop_watchdog. (Chris)
v4: Rebase.
v5: use to_intel_context instead of ctx->engine.
v6: Rebase.
Cc: Chris Wilson
Cc: Antonio Argenziano
Cc: Tvrtko Ursulin
Signed-off-by: Michel Thierry
Signed-off-by: Carlos Santa
---
drivers/gpu/drm/i915/i915_gem_context.h | 4 ++
drivers/gpu/drm/i915/intel_lrc.c| 80 -
drivers/gpu/drm/i915/intel_ringbuffer.h | 4 ++
3 files changed, 86 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.h
b/drivers/gpu/drm/i915/i915_gem_context.h
index f6d870b1f73e..62f4eb04985b 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -169,6 +169,10 @@ struct i915_gem_context {
u32 *lrc_reg_state;
u64 lrc_desc;
int pin_count;
+ /** watchdog_threshold: hw watchdog threshold value,
+* in clock counts
+*/
+ u32 watchdog_threshold;
const struct intel_context_ops *ops;
} __engine[I915_NUM_ENGINES];
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index e1dcdf545bee..0ea5a37c3357 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1872,12 +1872,33 @@ static int gen8_emit_bb_start(struct i915_request *rq,
u64 offset, u32 len,
const unsigned int flags)
{
+ struct intel_engine_cs *engine = rq->engine;
u32 *cs;
+ u32 num_dwords;
+ bool watchdog_running = false;
Hm it's not really running but should be running, but ok. I'd just find
something lie 'run_watchdog' or 'enable_watchdog' clearer.
- cs = intel_ring_begin(rq, 6);
+ /* bb_start only */
+ num_dwords = 6;
+
+ /* check if watchdog will be required */
+ if (to_intel_context(rq->gem_context, engine)->watchdog_threshold != 0)
{
+ GEM_BUG_ON(!engine->emit_start_watchdog ||
+ !engine->emit_stop_watchdog);
+
+ /* + start_watchdog (6) + stop_watchdog (4) */
+ num_dwords += 10;
+ watchdog_running = true;
+}
+
+ cs = intel_ring_begin(rq, num_dwords);
if (IS_ERR(cs))
return PTR_ERR(cs);
+ if (watchdog_running) {
+ /* Start watchdog timer */
+ cs = engine->emit_start_watchdog(rq, cs);
+ }
+
/*
* WaDisableCtxRestoreArbitration:bdw,chv
*
@@ -1906,8 +1927,12 @@ static int gen8_emit_bb_start(struct i915_request *rq,
*cs++ = MI_ARB_ON_OFF | MI_ARB_DISABLE;
*cs++ = MI_NOOP;
It could be neater to avoid to many MI_NOOPs. I think if you'd make emit
start/stop not emit it, and moved this line above to be last, a single
MI_MOOP could be emitted conditionally if the total number of emitted
(based on cs pointer) is odd.
- intel_ring_advance(rq, cs);
+ if (watchdog_running) {
+ /* Cancel watchdog timer */
+ cs = engine->emit_stop_watchdog(rq, cs);
+ }
+ intel_ring_advance(rq, cs);
return 0;
}
@@ -2091,6 +2116,49 @@ static void gen8_watchdog_irq_handler(unsigned long data)
intel_uncore_forcewake_put(dev_priv, fw_domains);
}
+static u32 *gen8_emit_start_watchdog(struct i915_request *rq, u32 *cs)
+{
+ struct intel_engine_cs *engine = rq->engine;
+ struct i915_gem_context *ctx = rq->gem_context;
+ struct intel_context *ce = to_intel_context(ctx, engine);
+
+ /* XXX: no watchdog support in BCS engine */
+ GEM_BUG_ON(engine->id == BCS);
+
+ /*
+* watchdog register must never be programmed to zero. This would
+* cause the watchdog counter to exceed and not allow the engine to
Waht does exceed mean here?
+* go into IDLE state
+*/
+ GEM_BUG_ON(ce->watchdog_threshold == 0);
+
+ /* Set counter period */
+ *cs++ = MI_LOAD_REGISTER_IMM(2);
+ *cs++ = i915_mmio_reg_offset(RING_THRESH(engine->mmio_base));
+ *cs++ = ce->watchdog_threshold;
+ /* Start counter */
+ *cs++ = i915_mmio_reg_offset(RING_CNTR(engine->mmio_base));
+ *cs++ = GEN8_WATCHDOG_ENABLE;
+ *cs++ = MI_NOOP;
+
+ return cs;
+}
+
+static u32 *gen8_e
Re: [Intel-gfx] drm/i915: Watchdog timeout: IRQ handler for gen8+
Quoting Tvrtko Ursulin (2019-01-07 11:58:13)
>
> Hi,
>
> This series has not been recognized by Patchwork as such, nor are the
> patches numbered. Have you used git format-patch - --cover-letter and
> git send-email to send it out?
>
> Rest inline.
>
> On 05/01/2019 02:39, Carlos Santa wrote:
> > +static void gen8_watchdog_irq_handler(unsigned long data)
> > +{
> > + struct intel_engine_cs *engine = (struct intel_engine_cs *)data;
> > + struct drm_i915_private *dev_priv = engine->i915;
> > + enum forcewake_domains fw_domains;
> > + u32 current_seqno;
> > +
> > + switch (engine->id) {
> > + default:
> > + MISSING_CASE(engine->id);
> > + /* fall through */
> > + case RCS:
> > + fw_domains = FORCEWAKE_RENDER;
> > + break;
> > + case VCS:
> > + case VCS2:
> > + case VECS:
> > + fw_domains = FORCEWAKE_MEDIA;
> > + break;
> > + }
> > +
> > + intel_uncore_forcewake_get(dev_priv, fw_domains);
>
> I'd be tempted to drop this and just use I915_WRITE. It doesn't feel
> like there is any performance to be gained with it and it embeds too
> much knowledge here.
No, no, no. Let's not reintroduce a fw inside irq context on a frequent
timer again.
Rule of thumb for fw_get:
gen6+: 10us to 50ms.
gen8+: 10us to 500us.
And then we don't release fw for 1ms after the fw_put. So we basically
prevent GT powersaving while the watchdog is active. That strikes me as
hopefully an unintended consequence.
The fw_get will be required if we actually hang, but for the timer
check, we should be able to do without.
And while on the topic of the timer irq, it should be forcibly cleared
along intel_engine_park, so that we ensure it is not raised while the
device/driver is supposed to be asleep. Or something to that effect.
> > + current_seqno = intel_engine_get_seqno(engine);
> > +
> > + /* did the request complete after the timer expired? */
> > + if (intel_engine_last_submit(engine) == current_seqno)
> > + goto fw_put;
> > +
> > + if (engine->hangcheck.watchdog == current_seqno) {
> > + /* Make sure the active request will be marked as guilty */
> > + engine->hangcheck.stalled = true;
> > + engine->hangcheck.acthd =
> > intel_engine_get_active_head(engine);
> > + engine->hangcheck.seqno = current_seqno;
> > +
> > + /* And try to run the hangcheck_work as soon as possible */
> > + set_bit(I915_RESET_WATCHDOG, &dev_priv->gpu_error.flags);
> > + queue_delayed_work(system_long_wq,
> > +&dev_priv->gpu_error.hangcheck_work,
> > +round_jiffies_up_relative(HZ));
> > + } else {
> > + engine->hangcheck.watchdog = current_seqno;
>
> The logic above potentially handles my previous question? Could be if
> batch 2 hangs. But..
Also, DO NOT USE HANGCHECK for this. The whole design was to be able to
do the engine reset right away. (Now guc can't but that's known broken.)
Aside, we have to rewrite this entire logic anyway as the engine seqno
and global_seqno are obsolete.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 24/46] drm/i915: Serialise concurrent calls to i915_gem_set_wedged()
Make i915_gem_set_wedged() and i915_gem_unset_wedged() behaviour more
consistently if called concurrently.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem.c | 32 ++-
drivers/gpu/drm/i915/i915_gpu_error.h | 4 ++-
.../gpu/drm/i915/selftests/mock_gem_device.c | 1 +
3 files changed, 28 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a3dd5bbd6700..6e5546075f17 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3174,10 +3174,15 @@ static void nop_submit_request(struct i915_request
*request)
void i915_gem_set_wedged(struct drm_i915_private *i915)
{
+ struct i915_gpu_error *error = &i915->gpu_error;
struct intel_engine_cs *engine;
enum intel_engine_id id;
- GEM_TRACE("start\n");
+ mutex_lock(&error->wedge_mutex);
+ if (test_bit(I915_WEDGED, &error->flags)) {
+ mutex_unlock(&error->wedge_mutex);
+ return;
+ }
if (GEM_SHOW_DEBUG()) {
struct drm_printer p = drm_debug_printer(__func__);
@@ -3186,8 +3191,7 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
intel_engine_dump(engine, &p, "%s\n", engine->name);
}
- if (test_and_set_bit(I915_WEDGED, &i915->gpu_error.flags))
- goto out;
+ GEM_TRACE("start\n");
/*
* First, stop submission to hw, but do not yet complete requests by
@@ -3223,23 +3227,31 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
intel_engine_wakeup(engine);
}
-out:
+ smp_mb__before_atomic();
+ set_bit(I915_WEDGED, &error->flags);
+
GEM_TRACE("end\n");
+ mutex_unlock(&error->wedge_mutex);
- wake_up_all(&i915->gpu_error.reset_queue);
+ wake_up_all(&error->reset_queue);
}
bool i915_gem_unset_wedged(struct drm_i915_private *i915)
{
+ struct i915_gpu_error *error = &i915->gpu_error;
struct i915_timeline *tl;
+ bool ret = false;
lockdep_assert_held(&i915->drm.struct_mutex);
- if (!test_bit(I915_WEDGED, &i915->gpu_error.flags))
+
+ if (!test_bit(I915_WEDGED, &error->flags))
return true;
if (!i915->gt.scratch) /* Never full initialised, recovery impossible */
return false;
+ mutex_lock(&error->wedge_mutex);
+
GEM_TRACE("start\n");
/*
@@ -3273,7 +3285,7 @@ bool i915_gem_unset_wedged(struct drm_i915_private *i915)
*/
if (dma_fence_default_wait(&rq->fence, true,
MAX_SCHEDULE_TIMEOUT) < 0)
- return false;
+ goto unlock;
}
i915_retire_requests(i915);
GEM_BUG_ON(i915->gt.active_requests);
@@ -3296,8 +3308,11 @@ bool i915_gem_unset_wedged(struct drm_i915_private *i915)
smp_mb__before_atomic(); /* complete takeover before enabling execbuf */
clear_bit(I915_WEDGED, &i915->gpu_error.flags);
+ ret = true;
+unlock:
+ mutex_unlock(&i915->gpu_error.wedge_mutex);
- return true;
+ return ret;
}
static void
@@ -5693,6 +5708,7 @@ int i915_gem_init_early(struct drm_i915_private *dev_priv)
i915_gem_idle_work_handler);
init_waitqueue_head(&dev_priv->gpu_error.wait_queue);
init_waitqueue_head(&dev_priv->gpu_error.reset_queue);
+ mutex_init(&dev_priv->gpu_error.wedge_mutex);
atomic_set(&dev_priv->mm.bsd_engine_dispatch_index, 0);
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.h
b/drivers/gpu/drm/i915/i915_gpu_error.h
index 6d9f45468ac1..604291f7762d 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.h
+++ b/drivers/gpu/drm/i915/i915_gpu_error.h
@@ -271,8 +271,8 @@ struct i915_gpu_error {
#define I915_RESET_BACKOFF 0
#define I915_RESET_HANDOFF 1
#define I915_RESET_MODESET 2
+#define I915_RESET_ENGINE 3
#define I915_WEDGED(BITS_PER_LONG - 1)
-#define I915_RESET_ENGINE (I915_WEDGED - I915_NUM_ENGINES)
/** Number of times an engine has been reset */
u32 reset_engine_count[I915_NUM_ENGINES];
@@ -283,6 +283,8 @@ struct i915_gpu_error {
/** Reason for the current *global* reset */
const char *reason;
+ struct mutex wedge_mutex; /* serialises wedging/unwedging */
+
/**
* Waitqueue to signal when a hang is detected. Used to for waiters
* to release the struct_mutex for the reset to procede.
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index aa4ddae94aca..4a25d2a344f2 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -189,6 +189,7 @@ struct drm_i915_private *mock_gem_device(void)
init_wai
