[Intel-gfx] ✗ Fi.CI.BAT: failure for snd/hda: Balance hda->need_i915_power across runtime_suspend (rev2)
== Series Details == Series: snd/hda: Balance hda->need_i915_power across runtime_suspend (rev2) URL : https://patchwork.freedesktop.org/series/59253/ State : failure == Summary == Applying: snd/hda: Balance hda->need_i915_power across runtime_suspend error: sha1 information is lacking or useless (sound/hda/hdac_component.c). error: could not build fake ancestor hint: Use 'git am --show-current-patch' to see the failed patch Patch failed at 0001 snd/hda: Balance hda->need_i915_power across runtime_suspend When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] snd/hda: Balance hda->need_i915_power across runtime_suspend
On Wed, 10 Apr 2019 00:53:31 +0200,
Chris Wilson wrote:
>
> Quoting Takashi Iwai (2019-04-09 22:35:28)
> > On Tue, 09 Apr 2019 23:27:41 +0200,
> > Chris Wilson wrote:
> > >
> > > In runtime_resume, we release the local display_power wakeref if we can
> > > rely on i915 providing a wakeref along the component. On suspend
> > > therefore, we should only release the display_power if we kept it from
> > > runtime_resume.
> >
> > Hrm, it shouldn't matter. After the recent code rewrite, the control
> > isn't refcount any longer, hence it's fine to call
> > display_power(false) again even if it were already powered off.
>
> That is the puzzle. Have a look at the glk-dsi results,
> https://patchwork.freedesktop.org/series/59253/
> something does appear to go wrong in azx_probe_continue (and seems to be
> avoided by this patch).
>
> Perhaps something like
> https://patchwork.freedesktop.org/patch/297656/?series=59257=1
> if the pm_runtime_autosuspend is occurring from a workqueue at the same
> time as we call display_power(false).
Then how about rather a patch like below?
thanks,
Takashi
--- a/sound/hda/hdac_component.c
+++ b/sound/hda/hdac_component.c
@@ -78,18 +78,16 @@ void snd_hdac_display_power(struct hdac_bus *bus, unsigned
int idx, bool enable)
return;
if (bus->display_power_status) {
- if (!bus->display_power_active) {
+ if (!cmpxchg(>display_power_active, false, true)) {
if (acomp->ops->get_power)
acomp->ops->get_power(acomp->dev);
snd_hdac_set_codec_wakeup(bus, true);
snd_hdac_set_codec_wakeup(bus, false);
- bus->display_power_active = true;
}
} else {
- if (bus->display_power_active) {
+ if (cmpxchg(>display_power_active, true, false)) {
if (acomp->ops->put_power)
acomp->ops->put_power(acomp->dev);
- bus->display_power_active = false;
}
}
}
___
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: Bump ready tasks ahead of busywaits (rev2)
== Series Details == Series: drm/i915: Bump ready tasks ahead of busywaits (rev2) URL : https://patchwork.freedesktop.org/series/59232/ State : success == Summary == CI Bug Log - changes from CI_DRM_5897_full -> Patchwork_12740_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12740_full that come from known issues: ### IGT changes ### Issues hit * igt@kms_atomic_transition@1x-modeset-transitions-nonblocking: - shard-apl: NOTRUN -> FAIL [fdo#109660] * igt@kms_atomic_transition@6x-modeset-transitions-nonblocking: - shard-apl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +22 * igt@kms_atomic_transition@plane-all-modeset-transition: - shard-apl: PASS -> INCOMPLETE [fdo#103927] * igt@kms_content_protection@atomic: - shard-iclb: NOTRUN -> SKIP [fdo#109300] * igt@kms_content_protection@atomic-dpms: - shard-apl: NOTRUN -> FAIL [fdo#110321] / [fdo#110336] +1 * igt@kms_cursor_crc@cursor-256x256-offscreen: - shard-iclb: PASS -> INCOMPLETE [fdo#107713] * igt@kms_cursor_crc@cursor-256x256-suspend: - shard-kbl: PASS -> DMESG-WARN [fdo#108566] +1 * igt@kms_cursor_crc@cursor-64x21-random: - shard-glk: NOTRUN -> FAIL [fdo#103232] * igt@kms_cursor_crc@cursor-64x64-suspend: - shard-skl: NOTRUN -> INCOMPLETE [fdo#104108] * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy: - shard-glk: PASS -> FAIL [fdo#104873] * igt@kms_cursor_legacy@cursor-vs-flip-atomic-transitions: - shard-iclb: PASS -> FAIL [fdo#103355] +1 * igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-indfb-draw-blt: - shard-skl: NOTRUN -> SKIP [fdo#109271] +154 * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-pwrite: - shard-iclb: PASS -> FAIL [fdo#103167] +3 * igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-blt: - shard-glk: NOTRUN -> SKIP [fdo#109271] +7 * igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-shrfb-draw-mmap-gtt: - shard-iclb: PASS -> FAIL [fdo#109247] +15 * igt@kms_lease@atomic_implicit_crtc: - shard-apl: NOTRUN -> FAIL [fdo#110279] * igt@kms_lease@setcrtc_implicit_plane: - shard-apl: NOTRUN -> FAIL [fdo#110281] * igt@kms_panel_fitting@legacy: - shard-skl: NOTRUN -> FAIL [fdo#105456] * igt@kms_pipe_crc_basic@read-crc-pipe-d: - shard-skl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +11 * igt@kms_plane@pixel-format-pipe-a-planes-source-clamping: - shard-glk: PASS -> SKIP [fdo#109271] * 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-alpha-basic: - shard-apl: NOTRUN -> FAIL [fdo#108145] +5 * igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb: - shard-skl: NOTRUN -> FAIL [fdo#108145] +1 * igt@kms_plane_lowres@pipe-a-tiling-y: - shard-iclb: PASS -> FAIL [fdo#103166] * igt@kms_plane_scaling@pipe-b-scaler-with-clipping-clamping: - shard-glk: PASS -> SKIP [fdo#109271] / [fdo#109278] +1 * igt@kms_psr@psr2_cursor_render: - shard-iclb: PASS -> SKIP [fdo#109441] +1 * igt@kms_psr@sprite_mmap_cpu: - shard-iclb: PASS -> FAIL [fdo#107383] / [fdo#110215] +3 * igt@kms_psr@suspend: - shard-skl: PASS -> INCOMPLETE [fdo#107773] * igt@kms_rotation_crc@multiplane-rotation-cropping-bottom: - shard-kbl: PASS -> DMESG-FAIL [fdo#105763] * igt@kms_setmode@basic: - shard-apl: NOTRUN -> FAIL [fdo#99912] * igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend: - shard-apl: NOTRUN -> FAIL [fdo#104894] * igt@kms_vblank@pipe-a-ts-continuation-modeset-hang: - shard-kbl: PASS -> DMESG-WARN [fdo#103558] / [fdo#105602] +10 * igt@kms_vblank@pipe-c-ts-continuation-modeset: - shard-apl: PASS -> FAIL [fdo#104894] * igt@kms_vblank@pipe-c-ts-continuation-suspend: - shard-kbl: PASS -> DMESG-WARN [fdo#103558] / [fdo#103841] / [fdo#105079] / [fdo#105602] - shard-skl: PASS -> INCOMPLETE [fdo#104108] / [fdo#107773] +1 * igt@prime_busy@wait-hang-bsd1: - shard-iclb: NOTRUN -> SKIP [fdo#109276] * igt@prime_vgem@sync-bsd1: - shard-apl: NOTRUN -> SKIP [fdo#109271] +284 * igt@runner@aborted: - shard-kbl: NOTRUN -> FAIL [fdo#103841] / [fdo#109383] Possible fixes * igt@gem_mmap_gtt@forked-big-copy-xy: - shard-iclb: TIMEOUT [fdo#109673] -> PASS * igt@i915_pm_rpm@system-suspend-execbuf: - shard-glk: DMESG-WARN [fdo#109513] -> PASS * igt@kms_cursor_crc@cursor-64x64-suspend: - shard-kbl: DMESG-WARN
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Fix SDVO HDMI audio
== Series Details == Series: drm/i915: Fix SDVO HDMI audio URL : https://patchwork.freedesktop.org/series/59233/ State : failure == Summary == CI Bug Log - changes from CI_DRM_5897_full -> Patchwork_12739_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_12739_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_12739_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_12739_full: ### IGT changes ### Possible regressions * igt@kms_panel_fitting@legacy: - shard-iclb: NOTRUN -> INCOMPLETE * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc: - shard-iclb: PASS -> INCOMPLETE Known issues Here are the changes found in Patchwork_12739_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@in-flight-suspend: - shard-kbl: PASS -> DMESG-WARN [fdo#108566] +1 * igt@gem_eio@suspend: - shard-kbl: PASS -> DMESG-WARN [fdo#103313] / [fdo#103558] / [fdo#105079] / [fdo#105602] * igt@gem_stolen@stolen-clear: - shard-iclb: NOTRUN -> SKIP [fdo#109277] +1 * igt@gem_tiled_fence_blits@normal: - shard-iclb: PASS -> TIMEOUT [fdo#109673] * igt@i915_pm_rpm@gem-execbuf-stress-pc8: - shard-iclb: NOTRUN -> SKIP [fdo#109506] * igt@i915_pm_rpm@modeset-stress-extra-wait: - shard-skl: NOTRUN -> INCOMPLETE [fdo#107807] * igt@i915_suspend@sysfs-reader: - shard-iclb: NOTRUN -> FAIL [fdo#103375] * igt@kms_atomic_transition@6x-modeset-transitions: - shard-iclb: NOTRUN -> SKIP [fdo#109278] +1 * igt@kms_atomic_transition@6x-modeset-transitions-nonblocking: - shard-apl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +13 * igt@kms_chamelium@vga-edid-read: - shard-iclb: NOTRUN -> SKIP [fdo#109284] * igt@kms_content_protection@atomic: - shard-iclb: NOTRUN -> SKIP [fdo#109300] * igt@kms_content_protection@atomic-dpms: - shard-apl: NOTRUN -> FAIL [fdo#110321] / [fdo#110336] * igt@kms_crtc_background_color: - shard-iclb: NOTRUN -> SKIP [fdo#109305] * igt@kms_cursor_crc@cursor-64x21-random: - shard-glk: NOTRUN -> FAIL [fdo#103232] * igt@kms_flip@2x-flip-vs-absolute-wf_vblank-interruptible: - shard-iclb: NOTRUN -> SKIP [fdo#109274] +2 * igt@kms_flip@flip-vs-expired-vblank: - shard-apl: PASS -> FAIL [fdo#102887] / [fdo#105363] * igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-indfb-draw-blt: - shard-skl: NOTRUN -> SKIP [fdo#109271] +154 * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-pwrite: - shard-iclb: PASS -> FAIL [fdo#103167] +6 * igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-blt: - shard-glk: NOTRUN -> SKIP [fdo#109271] +7 * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-fullscreen: - shard-iclb: PASS -> FAIL [fdo#109247] +16 * igt@kms_frontbuffer_tracking@psr-2p-scndscrn-spr-indfb-draw-mmap-gtt: - shard-iclb: NOTRUN -> SKIP [fdo#109280] +4 * igt@kms_lease@setcrtc_implicit_plane: - shard-apl: NOTRUN -> FAIL [fdo#110281] * igt@kms_panel_fitting@legacy: - shard-skl: NOTRUN -> FAIL [fdo#105456] * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c: - shard-kbl: PASS -> DMESG-WARN [fdo#103313] / [fdo#103558] / [fdo#105602] +3 * igt@kms_pipe_crc_basic@read-crc-pipe-d: - shard-skl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +10 * igt@kms_plane@pixel-format-pipe-a-planes-source-clamping: - shard-glk: PASS -> SKIP [fdo#109271] * 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-alpha-opaque-fb: - shard-skl: NOTRUN -> FAIL [fdo#108145] * igt@kms_plane_alpha_blend@pipe-b-alpha-basic: - shard-apl: NOTRUN -> FAIL [fdo#108145] +3 * igt@kms_plane_scaling@pipe-b-scaler-with-clipping-clamping: - shard-glk: PASS -> SKIP [fdo#109271] / [fdo#109278] +1 * igt@kms_psr@psr2_cursor_render: - shard-iclb: PASS -> SKIP [fdo#109441] +1 * igt@kms_psr@sprite_mmap_gtt: - shard-iclb: PASS -> FAIL [fdo#107383] / [fdo#110215] +5 * igt@kms_tv_load_detect@load-detect: - shard-iclb: NOTRUN -> SKIP [fdo#109309] * igt@perf_pmu@busy-accuracy-50-vcs1: - shard-iclb: NOTRUN -> SKIP [fdo#109276] +7 * igt@prime_vgem@sync-bsd1: - shard-apl: NOTRUN -> SKIP [fdo#109271]
Re: [Intel-gfx] [PATCH] drm/i915/ehl: Add support for DPLL4 (v3)
On Mon, 8 Apr 2019 12:11:15 +0300
Ville Syrjälä wrote:
Hi,
> On Fri, Apr 05, 2019 at 04:33:30PM -0700, Vivek Kasireddy wrote:
> > On Fri, 5 Apr 2019 21:39:11 +0300
> > Ville Syrjälä wrote:
> > Hi Ville,
> >
> > > On Fri, Apr 05, 2019 at 09:33:56PM +0300, Ville Syrjälä wrote:
> > > > On Fri, Apr 05, 2019 at 10:59:53AM -0700, Vivek Kasireddy
> > > > wrote:
> > > > > This patch adds support for DPLL4 on EHL that include the
> > > > > following restrictions:
> > > > >
> > > > > - DPLL4 cannot be used with DDIA (combo port A internal eDP
> > > > > usage). DPLL4 can be used with other DDIs, including DDID
> > > > > (combo port A external usage).
> > > > >
> > > > > - DPLL4 cannot be enabled when DC5 or DC6 are enabled.
> > > > >
> > > > > - The DPLL4 enable, lock, power enabled, and power state are
> > > > > connected to the MGPLL1_ENABLE register.
> > > > >
> > > > > v2: (suggestions from Bob Paauwe)
> > > > > - Rework ehl_get_dpll() function to call
> > > > > intel_find_shared_dpll() and iterate twice: once for Combo
> > > > > plls and once for MG plls.
> > > > >
> > > > > - Use MG pll funcs for DPLL4 instead of creating new ones and
> > > > > modify mg_pll_enable to include the restrictions for EHL.
> > > > >
> > > > > v3: Fix compilation error
> > > > >
> > > > > Cc: Lucas De Marchi
> > > > > Signed-off-by: Vivek Kasireddy
> > > > > Reviewed-by: Bob Paauwe
> > > > > ---
> > > > > drivers/gpu/drm/i915/intel_dpll_mgr.c | 60
> > > > > ++- 1 file changed, 59
> > > > > insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > > > > b/drivers/gpu/drm/i915/intel_dpll_mgr.c index
> > > > > e01c057ce50b..c3f0b9720c54 100644 ---
> > > > > a/drivers/gpu/drm/i915/intel_dpll_mgr.c +++
> > > > > b/drivers/gpu/drm/i915/intel_dpll_mgr.c @@ -2870,6 +2870,56 @@
> > > > > icl_get_dpll(struct intel_crtc_state *crtc_state, return pll;
> > > > > }
> > > > >
> > > > > +static struct intel_shared_dpll *
> > > > > +ehl_get_dpll(struct intel_crtc_state *crtc_state,
> > > > > + struct intel_encoder *encoder)
> > > > > +{
> > > > > + struct drm_i915_private *dev_priv =
> > > > > to_i915(crtc_state->base.crtc->dev);
> > > > > + struct intel_shared_dpll *pll;
> > > > > + enum port port = encoder->port;
> > > > > + enum intel_dpll_id min, max;
> > > > > + bool ret;
> > > > > +
> > > > > + if (!intel_port_is_combophy(dev_priv, port)) {
> > > > > + MISSING_CASE(port);
> > > > > + return NULL;
> > > > > + }
> > > > > +
> > > > > + min = DPLL_ID_ICL_DPLL0;
> > > > > + max = DPLL_ID_ICL_DPLL1;
> > > > > + ret = icl_calc_dpll_state(crtc_state, encoder);
> > > > > + if (ret) {
> > > > > + pll = intel_find_shared_dpll(crtc_state, min,
> > > > > max);
> > > > > + if (pll) {
> > > > > + intel_reference_shared_dpll(pll,
> > > > > crtc_state);
> > > > > + return pll;
> > > > > + }
> > > > > + } else {
> > > > > + DRM_DEBUG_KMS("Could not calculate PLL
> > > > > state.\n");
> > > > > + }
> > > > > +
> > > > > + if (encoder->type == INTEL_OUTPUT_EDP) {
> > > > > + DRM_DEBUG_KMS("Cannot use DPLL4 with
> > > > > EDP.\n");
> > > > > + return NULL;
> > > > > + }
> > > > > +
> > > > > + min = max = DPLL_ID_ICL_MGPLL1;
> > > > > + ret = icl_calc_mg_pll_state(crtc_state);
> > > > > + if (!ret) {
> > > > > + DRM_DEBUG_KMS("Could not calculate PLL
> > > > > state.\n");
> > > > > + return NULL;
> > > > > + }
> > > > > +
> > > > > + pll = intel_find_shared_dpll(crtc_state, min, max);
> > > > > + if (!pll) {
> > > > > + DRM_DEBUG_KMS("No PLL selected\n");
> > > > > + return NULL;
> > > > > + }
> > > > > +
> > > > > + intel_reference_shared_dpll(pll, crtc_state);
> > > > > + return pll;
> > > > > +}
> > > > > +
> > > > > static bool mg_pll_get_hw_state(struct drm_i915_private
> > > > > *dev_priv, struct intel_shared_dpll *pll,
> > > > > struct intel_dpll_hw_state
> > > > > *hw_state) @@ -3115,6 +3165,13 @@ static void
> > > > > mg_pll_enable(struct drm_i915_private *dev_priv, i915_reg_t
> > > > > enable_reg =
> > > > > MG_PLL_ENABLE(icl_pll_id_to_tc_port(pll->info->id));
> > > > > + if (IS_ELKHARTLAKE(dev_priv) &&
> > > > > +(I915_READ(DC_STATE_EN) & DC_STATE_EN_UPTO_DC5 ||
> > > > > + I915_READ(DC_STATE_EN) & DC_STATE_EN_UPTO_DC6)) {
> > > > > + DRM_ERROR("Cant enable DPLL4 when DC5 or DC6
> > > > > are enabled\n");
> > > > > + return;
> > > > > + }
> > > >
> > > > This looks like dead code, or we messed up earlier already (in
> > > > which case it should just be some kind of assert IMO).
> > Are you suggesting that I put this in a ->prepare() hook or much
> > earlier in the atomic
Re: [Intel-gfx] [PATCH] drm/i915/ehl: Add support for DPLL4 (v3)
On Fri, 5 Apr 2019 17:46:38 -0700
Lucas De Marchi wrote:
Hi,
> On Fri, Apr 05, 2019 at 10:59:53AM -0700, Vivek Kasireddy wrote:
> >This patch adds support for DPLL4 on EHL that include the
> >following restrictions:
> >
> >- DPLL4 cannot be used with DDIA (combo port A internal eDP usage).
> > DPLL4 can be used with other DDIs, including DDID
> > (combo port A external usage).
> >
> >- DPLL4 cannot be enabled when DC5 or DC6 are enabled.
> >
> >- The DPLL4 enable, lock, power enabled, and power state are
> >connected
> > to the MGPLL1_ENABLE register.
>
> ok
>
> >
> >v2: (suggestions from Bob Paauwe)
> >- Rework ehl_get_dpll() function to call intel_find_shared_dpll() and
> > iterate twice: once for Combo plls and once for MG plls.
> >
> >- Use MG pll funcs for DPLL4 instead of creating new ones and modify
> > mg_pll_enable to include the restrictions for EHL.
>
> these 2 don't match spec.
>
> "3rd PLL for use with combo PHY (DPLL4) and 3rd combo PHY DDI clocks
> (DDIC clock)"
>
> This is a combophy pll, not a mg phy pll. The only thing that is
> hooked to mg registers is the enable. So my understanding is that
> what you need:
>
> - use the dpll calculations
> - make sure intel_find_shared_dpll doesn't this if it's for eDP
> - setup the enable/disable to use MG_ENABLE register
Looks like my interpretation of the spec is different from yours but
your comments make sense. Should I create a new ID for this DPLL
or juse re-use DPLL_ID_ICL_MGPLL1?
>
> >
> >v3: Fix compilation error
> >
> >Cc: Lucas De Marchi
> >Signed-off-by: Vivek Kasireddy
> >Reviewed-by: Bob Paauwe
> >---
> > drivers/gpu/drm/i915/intel_dpll_mgr.c | 60
> > ++- 1 file changed, 59
> > insertions(+), 1 deletion(-)
> >
> >diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> >b/drivers/gpu/drm/i915/intel_dpll_mgr.c index
> >e01c057ce50b..c3f0b9720c54 100644 ---
> >a/drivers/gpu/drm/i915/intel_dpll_mgr.c +++
> >b/drivers/gpu/drm/i915/intel_dpll_mgr.c @@ -2870,6 +2870,56 @@
> >icl_get_dpll(struct intel_crtc_state *crtc_state,
> > return pll;
> > }
> >
> >+static struct intel_shared_dpll *
> >+ehl_get_dpll(struct intel_crtc_state *crtc_state,
> >+ struct intel_encoder *encoder)
> >+{
> >+struct drm_i915_private *dev_priv =
> >to_i915(crtc_state->base.crtc->dev);
> >+struct intel_shared_dpll *pll;
> >+enum port port = encoder->port;
> >+enum intel_dpll_id min, max;
> >+bool ret;
> >+
> >+if (!intel_port_is_combophy(dev_priv, port)) {
> >+MISSING_CASE(port);
> >+return NULL;
> >+}
> >+
> >+min = DPLL_ID_ICL_DPLL0;
> >+max = DPLL_ID_ICL_DPLL1;
> >+ret = icl_calc_dpll_state(crtc_state, encoder);
> >+if (ret) {
> >+pll = intel_find_shared_dpll(crtc_state, min, max);
> >+if (pll) {
> >+intel_reference_shared_dpll(pll,
> >crtc_state);
> >+return pll;
> >+}
> >+} else {
> >+DRM_DEBUG_KMS("Could not calculate PLL state.\n");
>
> the check for ret is swapped and you are missing a return here.
Unless I am reading it utterly wrong, icl_get_dpll has this:
if (!ret) {
DRM_DEBUG_KMS("Could not calculate PLL state.\n");
return NULL;
>
> But given the comments above, I think it would be better to reuse
> icl_get_dpll() rather than what you are doing here.
I could have used icl_get_dpll() but thought it would be much cleaner
to have a separate function for EHL; otherwise, I guess I need to
sprinkle icl_get_dpll with many if(EHL) statements.
>
> >+}
> >+
> >+if (encoder->type == INTEL_OUTPUT_EDP) {
> >+DRM_DEBUG_KMS("Cannot use DPLL4 with EDP.\n");
> >+return NULL;
> >+}
>
> this is already too late
The idea was if we have EDP being used, then we first try to find if
one of the combo PHY DPLLs are available to be used. If they are
not, then we come here and return as we cannot use this one either.
>
> >+
> >+min = max = DPLL_ID_ICL_MGPLL1;
> >+ret = icl_calc_mg_pll_state(crtc_state);
> >+if (!ret) {
> >+DRM_DEBUG_KMS("Could not calculate PLL state.\n");
> >+return NULL;
>
> again... ret == 0 is success, not otherwise
I'll send out a v4 with your suggestions soon.
Thanks,
Vivek
>
> Lucas De Marchi
>
> >+}
> >+
> >+pll = intel_find_shared_dpll(crtc_state, min, max);
> >+if (!pll) {
> >+DRM_DEBUG_KMS("No PLL selected\n");
> >+return NULL;
> >+}
> >+
> >+intel_reference_shared_dpll(pll, crtc_state);
> >+return pll;
> >+}
> >+
> > static bool mg_pll_get_hw_state(struct drm_i915_private *dev_priv,
> > struct intel_shared_dpll *pll,
> > struct intel_dpll_hw_state
> > *hw_state)
> >@@ -3115,6 +3165,13 @@ static void mg_pll_enable(struct
> >drm_i915_private *dev_priv,
> > i915_reg_t enable_reg =
> >
Re: [Intel-gfx] [PATCH 3/4] drm/i915/uc: Place uC firmware in upper range of GGTT
On 4/9/19 3:11 PM, Chris Wilson wrote: > Quoting Fernando Pacheco (2019-04-09 22:31:01) >> diff --git a/drivers/gpu/drm/i915/i915_gem.c >> b/drivers/gpu/drm/i915/i915_gem.c >> index bf3d12f94365..160959785589 100644 >> --- a/drivers/gpu/drm/i915/i915_gem.c >> +++ b/drivers/gpu/drm/i915/i915_gem.c >> @@ -4508,6 +4508,8 @@ void i915_gem_resume(struct drm_i915_private *i915) >> i915_gem_restore_gtt_mappings(i915); >> i915_gem_restore_fences(i915); >> >> + intel_uc_restore_ggtt_mapping(i915); > No need, right? The fw ggtt binding is only temporary for the dma xfer. On resume we re-init the uc hardware and perform the upload again. Since I moved the binding to the uc init phase I had to restore the mapping here. And it should not have been called unconditionally... Fernando > -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915/uc: Place uC firmware in upper range of GGTT
Quoting Fernando Pacheco (2019-04-09 23:53:08)
>
> On 4/9/19 2:53 PM, Chris Wilson wrote:
> > Quoting Fernando Pacheco (2019-04-09 22:31:01)
> >> +int intel_uc_fw_ggtt_pin(struct intel_uc_fw *uc_fw,
> >> +struct i915_ggtt *ggtt, u64 start)
> >> +{
> >> + struct drm_i915_gem_object *obj = uc_fw->obj;
> >> + int err;
> >> +
> >> + err = i915_gem_object_set_to_gtt_domain(obj, false);
> > Currently requires struct_mutex, and is not required as we can ensure
> > the pages are flushed on creation.
>
> My intent was to maintain what was being done before
> but just doing it earlier.
>
> But if it's not required..
More so that it's illegal in the global reset context :)
There are patches on the list that remove the struct_mutex for this
operation (eek, no, ignore that you aren't allowed to take that lock
inside reset either!), but with a bit of care we shouldn't need the
set-to-gtt-domain at all as we can do the flush trivially (if it's even
required).
> >> + if (err) {
> >> + DRM_DEBUG_DRIVER("%s fw set-domain err=%d\n",
> >> +intel_uc_fw_type_repr(uc_fw->type), err);
> >> + return err;
> >> + }
> >> +
> >> + err = i915_gem_object_pin_pages(obj);
> > I'm pretty sure we don't need to pin the pages here, as the caller
> > should be holding the pages already for the duration of the bind.
> >
> > So I think this should just reduce to the ggtt bind.
>
> I might be misunderstanding, so could you please clarify
> what you mean by "should be holding"? Are you stating
> that the caller already holds the pages?
To copy the firmware image into the pages, those pages must exist. To
prevent those pages disappearing, we must have kept them around (i.e
pinned). So we know by construction of the uc_fw object we always have
the pages, and could skip bumping the pin-count around the xfer.
Therefore we only need to bind the existing firmware pages into the GGTT
to perform the dma xfer (after satisfying ourselves that the pages are
indeed flushed).
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for Perma-pin uC firmware and re-enable global reset
== Series Details ==
Series: Perma-pin uC firmware and re-enable global reset
URL : https://patchwork.freedesktop.org/series/59255/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5897 -> Patchwork_12747
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_12747 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_12747, 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/59255/revisions/1/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_12747:
### IGT changes ###
Possible regressions
* igt@gem_exec_suspend@basic-s3:
- fi-bdw-5557u: PASS -> INCOMPLETE
- fi-kbl-r: NOTRUN -> INCOMPLETE
- fi-ilk-650: PASS -> INCOMPLETE
- fi-snb-2520m: PASS -> INCOMPLETE
- fi-pnv-d510:PASS -> INCOMPLETE
- fi-kbl-x1275: PASS -> INCOMPLETE
- fi-kbl-7500u: PASS -> INCOMPLETE
- fi-bsw-kefka: PASS -> INCOMPLETE
- fi-bsw-n3050: NOTRUN -> INCOMPLETE
- fi-ivb-3770:PASS -> INCOMPLETE
- fi-hsw-4770r: PASS -> INCOMPLETE
- fi-hsw-peppy: PASS -> INCOMPLETE
* igt@i915_module_load@reload-with-fault-injection:
- fi-cfl-guc: PASS -> INCOMPLETE
- fi-skl-guc: PASS -> INCOMPLETE
- fi-kbl-guc: PASS -> INCOMPLETE
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-bwr-2160:PASS -> INCOMPLETE
* igt@runner@aborted:
- fi-cfl-guc: NOTRUN -> FAIL
Warnings
* igt@gem_exec_suspend@basic-s3:
- fi-whl-u: FAIL [fdo#103375] -> INCOMPLETE
Known issues
Here are the changes found in Patchwork_12747 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_basic@gtt-bsd1:
- fi-bsw-n3050: NOTRUN -> SKIP [fdo#109271] +10
- fi-icl-u3: NOTRUN -> SKIP [fdo#109276] +7
* igt@gem_exec_parse@basic-rejected:
- fi-icl-u3: NOTRUN -> SKIP [fdo#109289] +1
* igt@gem_exec_store@basic-bsd1:
- fi-kbl-r: NOTRUN -> SKIP [fdo#109271] +9
* igt@gem_exec_store@basic-vebox:
- fi-byt-j1900: NOTRUN -> SKIP [fdo#109271] +11
* igt@gem_exec_suspend@basic-s3:
- fi-skl-6770hq: PASS -> INCOMPLETE [fdo#104108] / [fdo#107773]
- fi-byt-n2820: PASS -> INCOMPLETE [fdo#102657]
- fi-cfl-8109u: PASS -> INCOMPLETE [fdo#108126]
- fi-skl-lmem:PASS -> INCOMPLETE [fdo#104108] / [fdo#107773]
- fi-skl-6260u: PASS -> INCOMPLETE [fdo#104108] / [fdo#107773]
- fi-snb-2600:PASS -> INCOMPLETE [fdo#105411]
- fi-elk-e7500: PASS -> INCOMPLETE [fdo#103989]
- fi-bdw-gvtdvm: PASS -> INCOMPLETE [fdo#105600]
- fi-skl-iommu: PASS -> INCOMPLETE [fdo#104108] / [fdo#107773]
- fi-glk-dsi: PASS -> INCOMPLETE [fdo#103359] / [k.org#198133]
- fi-cfl-8700k: PASS -> INCOMPLETE [fdo#108126]
- fi-kbl-8809g: PASS -> INCOMPLETE [fdo#103665] / [fdo#108126]
- fi-bxt-dsi: PASS -> INCOMPLETE [fdo#103927]
- fi-skl-gvtdvm: PASS -> INCOMPLETE [fdo#104108] / [fdo#105600] /
[fdo#107773]
- fi-icl-u3: NOTRUN -> INCOMPLETE [fdo#107713]
- fi-byt-j1900: NOTRUN -> INCOMPLETE [fdo#102657]
- fi-hsw-4770:PASS -> INCOMPLETE [fdo#103540]
- fi-bxt-j4205: PASS -> INCOMPLETE [fdo#103927]
- fi-skl-6700k2: PASS -> INCOMPLETE [fdo#104108] / [fdo#107773]
- fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
- fi-skl-6600u: PASS -> INCOMPLETE [fdo#104108] / [fdo#107773]
* igt@i915_module_load@reload-with-fault-injection:
- fi-apl-guc: PASS -> INCOMPLETE [fdo#103927]
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-gdg-551: PASS -> INCOMPLETE [fdo#108316]
* igt@runner@aborted:
- fi-skl-guc: NOTRUN -> FAIL [fdo#104108]
- fi-apl-guc: NOTRUN -> FAIL [fdo#105602]
- fi-kbl-guc: NOTRUN -> FAIL [fdo#105602]
Possible fixes
* igt@gem_ctx_exec@basic:
- fi-icl-u3: INCOMPLETE [fdo#107713] -> PASS
* igt@i915_hangman@error-state-basic:
- fi-kbl-guc: SKIP [fdo#109271] -> PASS
- fi-apl-guc: SKIP [fdo#109271] -> PASS +3
* igt@kms_pipe_crc_basic@hang-read-crc-pipe-b:
- fi-skl-guc: SKIP [fdo#109271] -> PASS +3
- fi-cfl-guc: SKIP [fdo#109271] -> PASS +3
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102657]:
Re: [Intel-gfx] [PATCH 3/4] drm/i915/uc: Place uC firmware in upper range of GGTT
On 4/9/19 2:53 PM, Chris Wilson wrote:
> Quoting Fernando Pacheco (2019-04-09 22:31:01)
>> Currently we pin the GuC or HuC firmware image just
>> before uploading. Perma-pin during uC initialization
>> instead and use the range reserved at the top of the
>> address space.
>>
>> Moving the firmware resulted in needing to:
>> - restore the ggtt mapping during the suspend/resume path.
>> - use an additional pinning for the rsa signature which will
>> be used during HuC auth as addresses above GUC_GGTT_TOP
>> do not map through GTT.
>>
>> Signed-off-by: Fernando Pacheco
>> ---
>> @@ -315,3 +287,67 @@ void intel_uc_fw_dump(const struct intel_uc_fw *uc_fw,
>> struct drm_printer *p)
>> drm_printf(p, "\tRSA: offset %u, size %u\n",
>>uc_fw->rsa_offset, uc_fw->rsa_size);
>> }
>> +
>> +void intel_uc_fw_ggtt_bind(struct intel_uc_fw *uc_fw,
>> + struct i915_ggtt *ggtt, u64 start)
>> +{
>> + struct drm_i915_gem_object *obj = uc_fw->obj;
>> + struct i915_vma dummy = {
>> + .node = { .start = start, .size = obj->base.size },
>> + .size = obj->base.size,
>> + .pages = obj->mm.pages,
>> + .obj = obj,
> Shouldn't need .size or .obj, but usually needs .vm.
>
>> + };
>> +
>> + GEM_BUG_ON(!i915_gem_object_has_pinned_pages(obj));
>> + ggtt->vm.insert_entries(>vm, , obj->cache_level, 0);
>> +}
>> +
>> +int intel_uc_fw_ggtt_pin(struct intel_uc_fw *uc_fw,
>> +struct i915_ggtt *ggtt, u64 start)
>> +{
>> + struct drm_i915_gem_object *obj = uc_fw->obj;
>> + int err;
>> +
>> + err = i915_gem_object_set_to_gtt_domain(obj, false);
> Currently requires struct_mutex, and is not required as we can ensure
> the pages are flushed on creation.
My intent was to maintain what was being done before
but just doing it earlier.
But if it's not required..
>> + if (err) {
>> + DRM_DEBUG_DRIVER("%s fw set-domain err=%d\n",
>> +intel_uc_fw_type_repr(uc_fw->type), err);
>> + return err;
>> + }
>> +
>> + err = i915_gem_object_pin_pages(obj);
> I'm pretty sure we don't need to pin the pages here, as the caller
> should be holding the pages already for the duration of the bind.
>
> So I think this should just reduce to the ggtt bind.
I might be misunderstanding, so could you please clarify
what you mean by "should be holding"? Are you stating
that the caller already holds the pages?
>> + if (err) {
>> + DRM_DEBUG_DRIVER("%s fw pin-pages err=%d\n",
>> +intel_uc_fw_type_repr(uc_fw->type), err);
>> + return err;
>> + }
>> +
>> + intel_uc_fw_ggtt_bind(uc_fw, ggtt, start);
>> +
>> + return 0;
>> +}
>> +
>> +void intel_uc_fw_ggtt_unpin(struct intel_uc_fw *uc_fw,
>> + struct i915_ggtt *ggtt, u64 start)
>> +{
>> + struct drm_i915_gem_object *obj = uc_fw->obj;
>> + u64 length = obj->base.size;
>> +
>> + ggtt->vm.clear_range(>vm, start, length);
>> +
>> + if (i915_gem_object_has_pinned_pages(obj))
>> + i915_gem_object_unpin_pages(obj);
> No. You either own the pages, or you do not. Don't guess.
> -Chris
Yeah my bad.
Thanks,
Fernando
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] snd/hda: Balance hda->need_i915_power across runtime_suspend
Quoting Takashi Iwai (2019-04-09 22:35:28) > On Tue, 09 Apr 2019 23:27:41 +0200, > Chris Wilson wrote: > > > > In runtime_resume, we release the local display_power wakeref if we can > > rely on i915 providing a wakeref along the component. On suspend > > therefore, we should only release the display_power if we kept it from > > runtime_resume. > > Hrm, it shouldn't matter. After the recent code rewrite, the control > isn't refcount any longer, hence it's fine to call > display_power(false) again even if it were already powered off. That is the puzzle. Have a look at the glk-dsi results, https://patchwork.freedesktop.org/series/59253/ something does appear to go wrong in azx_probe_continue (and seems to be avoided by this patch). Perhaps something like https://patchwork.freedesktop.org/patch/297656/?series=59257=1 if the pm_runtime_autosuspend is occurring from a workqueue at the same time as we call display_power(false). -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915/uc: Reserve upper range of GGTT
On 4/9/19 2:41 PM, Chris Wilson wrote:
> Quoting Fernando Pacheco (2019-04-09 22:31:00)
>> GuC and HuC depend on struct_mutex for device
>> reinitialization. Moving away from this dependency
>> requires perma-pinning the firmware images in GGTT.
>> The upper portion of the GuC address space has
>> a sizeable hole (several MB) that is inaccessible
>> by GuC. Reserve this range within GGTT as it can
>> comfortably hold GuC/HuC firmware images.
>>
>> Signed-off-by: Fernando Pacheco
>> ---
>> drivers/gpu/drm/i915/i915_gem_gtt.c | 25 ++---
>> drivers/gpu/drm/i915/i915_gem_gtt.h | 1 +
>> drivers/gpu/drm/i915/intel_guc.h| 11 +++
>> 3 files changed, 34 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
>> b/drivers/gpu/drm/i915/i915_gem_gtt.c
>> index 736c845eb77f..30f294a07e6d 100644
>> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
>> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
>> @@ -2747,6 +2747,18 @@ int i915_gem_init_ggtt(struct drm_i915_private
>> *dev_priv)
>> if (ret)
>> return ret;
>>
>> + /* Reserve a mappable slot for our lockless uC firmware load */
>> + if (USES_GUC(dev_priv)) {
>> + ret = drm_mm_insert_node_in_range(>vm.mm, >uc_fw,
>> + GUC_GGTT_FW_SIZE, 0,
>> + I915_COLOR_UNEVICTABLE,
>> + GUC_GGTT_FW_START,
>> + GUC_GGTT_FW_END,
>> + DRM_MM_INSERT_LOW);
> Use drm_mm_reserve_node() as you want an explicit address.
>
> We should be able to push this to guc init, with appropriate bailing if
> something already took the high range.
Makes sense. I'll make these changes and the one below.
-Fernando
>> + if (ret)
>> + goto err_node;
>> + }
>> +
>> /* Clear any non-preallocated blocks */
>> drm_mm_for_each_hole(entry, >vm.mm, hole_start, hole_end) {
>> DRM_DEBUG_KMS("clearing unused GTT space: [%lx, %lx]\n",
>> @@ -2761,12 +2773,15 @@ int i915_gem_init_ggtt(struct drm_i915_private
>> *dev_priv)
>> if (INTEL_PPGTT(dev_priv) == INTEL_PPGTT_ALIASING) {
>> ret = i915_gem_init_aliasing_ppgtt(dev_priv);
>> if (ret)
>> - goto err;
>> + goto err_appgtt;
>> }
>>
>> return 0;
>>
>> -err:
>> +err_appgtt:
>> + if (USES_GUC(dev_priv))
>> + drm_mm_remove_node(>uc_fw);
>> +err_node:
>> drm_mm_remove_node(>error_capture);
>> return ret;
>> }
>> @@ -2792,6 +2807,9 @@ void i915_ggtt_cleanup_hw(struct drm_i915_private
>> *dev_priv)
>> if (drm_mm_node_allocated(>error_capture))
>> drm_mm_remove_node(>error_capture);
>>
>> + if (drm_mm_node_allocated(>uc_fw))
>> + drm_mm_remove_node(>uc_fw);
>> +
>> if (drm_mm_initialized(>vm.mm)) {
>> intel_vgt_deballoon(dev_priv);
>> i915_address_space_fini(>vm);
>> @@ -3370,7 +3388,8 @@ int i915_ggtt_probe_hw(struct drm_i915_private
>> *dev_priv)
>> * restriction!
>> */
>> if (USES_GUC(dev_priv)) {
>> - ggtt->vm.total = min_t(u64, ggtt->vm.total, GUC_GGTT_TOP);
>> + ggtt->vm.total = min_t(u64, ggtt->vm.total,
>> + GUC_GGTT_RESERVED_END);
> Should not be required now as you should have completely reserved the range
> for the guc, by the guc.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Perma-pin uC firmware and re-enable global reset
== Series Details == Series: Perma-pin uC firmware and re-enable global reset URL : https://patchwork.freedesktop.org/series/59255/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915/uc: Rename uC firmware init function Okay! Commit: drm/i915/uc: Reserve upper range of GGTT -O:drivers/gpu/drm/i915/i915_gem_gtt.c:3373:34: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/i915_gem_gtt.c:3375:25: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/i915_gem_gtt.c:3375:25: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_gtt.c:3391:34: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_gtt.c:3394:25: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_gtt.c:3394:25: warning: expression using sizeof(void) Commit: drm/i915/uc: Place uC firmware in upper range of GGTT Okay! Commit: Revert "drm/i915/guc: Disable global reset" Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for snd/hda: Balance hda->need_i915_power across runtime_suspend
== Series Details == Series: snd/hda: Balance hda->need_i915_power across runtime_suspend URL : https://patchwork.freedesktop.org/series/59253/ State : failure == Summary == CI Bug Log - changes from CI_DRM_5897 -> Patchwork_12746 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_12746 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_12746, 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/59253/revisions/1/mbox/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_12746: ### IGT changes ### Possible regressions * igt@kms_pipe_crc_basic@hang-read-crc-pipe-a: - fi-glk-dsi: PASS -> FAIL Known issues Here are the changes found in Patchwork_12746 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@query-info: - fi-glk-dsi: NOTRUN -> SKIP [fdo#109271] +17 * igt@amdgpu/amd_basic@userptr: - fi-kbl-8809g: PASS -> DMESG-WARN [fdo#108965] * igt@gem_exec_store@basic-bsd1: - fi-kbl-r: NOTRUN -> SKIP [fdo#109271] +41 * igt@i915_selftest@live_execlists: - fi-apl-guc: PASS -> INCOMPLETE [fdo#103927] / [fdo#109720] * igt@i915_selftest@live_hangcheck: - fi-bxt-dsi: PASS -> INCOMPLETE [fdo#103927] * igt@kms_busy@basic-flip-a: - fi-bsw-n3050: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +1 * igt@kms_busy@basic-flip-c: - fi-blb-e6850: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] - fi-byt-j1900: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] * igt@kms_chamelium@hdmi-crc-fast: - fi-bsw-n3050: NOTRUN -> SKIP [fdo#109271] +62 - fi-byt-j1900: NOTRUN -> SKIP [fdo#109271] +52 * igt@kms_pipe_crc_basic@hang-read-crc-pipe-c: - fi-blb-e6850: NOTRUN -> SKIP [fdo#109271] +48 * igt@runner@aborted: - fi-apl-guc: NOTRUN -> FAIL [fdo#108622] / [fdo#109720] Possible fixes * igt@gem_exec_suspend@basic-s4-devices: - fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS * igt@i915_pm_rpm@module-reload: - fi-glk-dsi: INCOMPLETE [fdo#103359] / [k.org#198133] -> PASS * igt@i915_selftest@live_contexts: - fi-bdw-gvtdvm: DMESG-FAIL [fdo#110235 ] -> PASS - fi-skl-gvtdvm: DMESG-FAIL [fdo#110235 ] -> PASS [fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359 [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622 [fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278 [fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720 [fdo#110235 ]: https://bugs.freedesktop.org/show_bug.cgi?id=110235 [k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133 Participating hosts (44 -> 39) -- Additional (3): fi-byt-j1900 fi-kbl-r fi-bsw-n3050 Missing(8): fi-byt-squawks fi-icl-u2 fi-bsw-cyan fi-kbl-7500u fi-icl-u3 fi-icl-y fi-bdw-samus fi-snb-2600 Build changes - * Linux: CI_DRM_5897 -> Patchwork_12746 CI_DRM_5897: 7d07e025e78603d6270bc115fdb6c1efea6e66a5 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4934: dc4f45eb6874331daec870dc1e4cfc3ac5c49311 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12746: ded06fca89e4d1bd756e47f9cfdfe798e4ff7977 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == ded06fca89e4 snd/hda: Balance hda->need_i915_power across runtime_suspend == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12746/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915/uc: Place uC firmware in upper range of GGTT
Quoting Fernando Pacheco (2019-04-09 22:31:01)
> diff --git a/drivers/gpu/drm/i915/intel_huc.c
> b/drivers/gpu/drm/i915/intel_huc.c
> index 94c04f16a2ad..89e0b942ae86 100644
> --- a/drivers/gpu/drm/i915/intel_huc.c
> +++ b/drivers/gpu/drm/i915/intel_huc.c
> @@ -40,6 +40,59 @@ int intel_huc_init_misc(struct intel_huc *huc)
> return 0;
> }
>
> +/*
> + * The HuC firmware image now sits above GUC_GGTT_TOP and this
> + * portion does not map through GTT. This means GuC cannot
> + * perform the HuC auth with the rsa signature sitting in that
> + * range. We resort to additionally perma-pinning the rsa signature
> + * below GUC_GGTT_TOP and utilizing this mapping to perform
> + * the authentication.
> + */
> +static int intel_huc_rsa_data_create(struct intel_huc *huc)
> +{
> + struct drm_i915_private *i915 = huc_to_i915(huc);
> + struct intel_guc *guc = >guc;
> + struct i915_vma *vma;
> + void *vaddr;
> +
> + vma = intel_guc_allocate_vma(guc, PAGE_SIZE);
> + if (IS_ERR(vma))
> + return PTR_ERR(vma);
> +
Are we not allocating an object for the dma xfer here that is then bound
to the reserved ggtt node? Why pin it again into the ggtt?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915/uc: Reserve upper range of GGTT
On 4/9/19 2:31 PM, Fernando Pacheco wrote:
GuC and HuC depend on struct_mutex for device
reinitialization. Moving away from this dependency
requires perma-pinning the firmware images in GGTT.
The upper portion of the GuC address space has
a sizeable hole (several MB) that is inaccessible
by GuC. Reserve this range within GGTT as it can
comfortably hold GuC/HuC firmware images.
Signed-off-by: Fernando Pacheco
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 25 ++---
drivers/gpu/drm/i915/i915_gem_gtt.h | 1 +
drivers/gpu/drm/i915/intel_guc.h| 11 +++
3 files changed, 34 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 736c845eb77f..30f294a07e6d 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2747,6 +2747,18 @@ int i915_gem_init_ggtt(struct drm_i915_private *dev_priv)
if (ret)
return ret;
+ /* Reserve a mappable slot for our lockless uC firmware load */
+ if (USES_GUC(dev_priv)) {
We know the the size of the binaries at this point, so maybe we can do
something more accurate, like:
struct drm_mm_node node;
u32 guc_fw_size = ROUND_UP(guc_fw->size, I915_GTT_PAGE_SIZE);
u32 huc_fw_size = ROUND_UP(huc_fw->size, I915_GTT_PAGE_SIZE);
u32 min_reserved_size = guc_fw_size + huc_fw_size;
ggtt->uc_fw.start =
min_t(u32, GUC_GGTT_TOP, vm->total - min_reserved_size);
ggtt->uc_fw.size = ggtt->vm.total - ggtt->uc_fw.start;
drm_mm_reserve_node(>vm.mm, >uc_fw);
+ ret = drm_mm_insert_node_in_range(>vm.mm, >uc_fw,
+ GUC_GGTT_FW_SIZE, 0,
+ I915_COLOR_UNEVICTABLE,
+ GUC_GGTT_FW_START,
+ GUC_GGTT_FW_END,
+ DRM_MM_INSERT_LOW);
+ if (ret)
+ goto err_node;
+ }
+
/* Clear any non-preallocated blocks */
drm_mm_for_each_hole(entry, >vm.mm, hole_start, hole_end) {
DRM_DEBUG_KMS("clearing unused GTT space: [%lx, %lx]\n",
@@ -2761,12 +2773,15 @@ int i915_gem_init_ggtt(struct drm_i915_private
*dev_priv)
if (INTEL_PPGTT(dev_priv) == INTEL_PPGTT_ALIASING) {
ret = i915_gem_init_aliasing_ppgtt(dev_priv);
if (ret)
- goto err;
+ goto err_appgtt;
}
return 0;
-err:
+err_appgtt:
+ if (USES_GUC(dev_priv))
+ drm_mm_remove_node(>uc_fw);
+err_node:
drm_mm_remove_node(>error_capture);
return ret;
}
@@ -2792,6 +2807,9 @@ void i915_ggtt_cleanup_hw(struct drm_i915_private
*dev_priv)
if (drm_mm_node_allocated(>error_capture))
drm_mm_remove_node(>error_capture);
+ if (drm_mm_node_allocated(>uc_fw))
+ drm_mm_remove_node(>uc_fw);
+
if (drm_mm_initialized(>vm.mm)) {
intel_vgt_deballoon(dev_priv);
i915_address_space_fini(>vm);
@@ -3370,7 +3388,8 @@ int i915_ggtt_probe_hw(struct drm_i915_private *dev_priv)
* restriction!
*/
if (USES_GUC(dev_priv)) {
- ggtt->vm.total = min_t(u64, ggtt->vm.total, GUC_GGTT_TOP);
+ ggtt->vm.total = min_t(u64, ggtt->vm.total,
+ GUC_GGTT_RESERVED_END);
No need to leave that extra space at the top, the dma engine can access
all 4GB of the GGTT so we can leave ggtt->vm.total untouched when using
guc. Just make sure you reserve everything above GUC_GGTT_TOP
Daniele
ggtt->mappable_end =
min_t(u64, ggtt->mappable_end, ggtt->vm.total);
}
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index f597f35b109b..b51e779732c3 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -384,6 +384,7 @@ struct i915_ggtt {
u32 pin_bias;
struct drm_mm_node error_capture;
+ struct drm_mm_node uc_fw;
};
struct i915_hw_ppgtt {
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 2c59ff8d9f39..b30cc2642fc4 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -127,6 +127,17 @@ static inline void intel_guc_to_host_event_handler(struct
intel_guc *guc)
/* GuC addresses above GUC_GGTT_TOP also don't map through the GTT */
#define GUC_GGTT_TOP 0xFEE0
+/*
+ * This portion of the address space is inaccessible by GuC,
+ * but still accessible by DMA. We can repurpose this portion
+ * to house the uC firmware images and perform the image upload.
+ */
+#define GUC_GGTT_FW_START GUC_GGTT_TOP
+#define GUC_GGTT_FW_END
Re: [Intel-gfx] [PATCH 3/4] drm/i915/uc: Place uC firmware in upper range of GGTT
Quoting Fernando Pacheco (2019-04-09 22:31:01) > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > index bf3d12f94365..160959785589 100644 > --- a/drivers/gpu/drm/i915/i915_gem.c > +++ b/drivers/gpu/drm/i915/i915_gem.c > @@ -4508,6 +4508,8 @@ void i915_gem_resume(struct drm_i915_private *i915) > i915_gem_restore_gtt_mappings(i915); > i915_gem_restore_fences(i915); > > + intel_uc_restore_ggtt_mapping(i915); No need, right? The fw ggtt binding is only temporary for the dma xfer. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915/uc: Rename uC firmware init function
Quoting Fernando Pacheco (2019-04-09 22:30:59) > static inline > -void intel_uc_fw_init(struct intel_uc_fw *uc_fw, enum intel_uc_fw_type type) > +void intel_uc_fw_init_early(struct intel_uc_fw *uc_fw, > + enum intel_uc_fw_type type) I followed right up until the point it was an inline. At this point does this not mean its just a regular struct initialiser? Hmm. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] Revert "drm/i915/guc: Disable global reset"
Quoting Fernando Pacheco (2019-04-09 22:31:02) > This reverts commit fe62365f9f80a1c1d438c54fba21f5108a182de8. And don't forget the test code that skips guc. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915/uc: Place uC firmware in upper range of GGTT
Quoting Fernando Pacheco (2019-04-09 22:31:01)
> Currently we pin the GuC or HuC firmware image just
> before uploading. Perma-pin during uC initialization
> instead and use the range reserved at the top of the
> address space.
>
> Moving the firmware resulted in needing to:
> - restore the ggtt mapping during the suspend/resume path.
> - use an additional pinning for the rsa signature which will
> be used during HuC auth as addresses above GUC_GGTT_TOP
> do not map through GTT.
>
> Signed-off-by: Fernando Pacheco
> ---
> @@ -315,3 +287,67 @@ void intel_uc_fw_dump(const struct intel_uc_fw *uc_fw,
> struct drm_printer *p)
> drm_printf(p, "\tRSA: offset %u, size %u\n",
>uc_fw->rsa_offset, uc_fw->rsa_size);
> }
> +
> +void intel_uc_fw_ggtt_bind(struct intel_uc_fw *uc_fw,
> + struct i915_ggtt *ggtt, u64 start)
> +{
> + struct drm_i915_gem_object *obj = uc_fw->obj;
> + struct i915_vma dummy = {
> + .node = { .start = start, .size = obj->base.size },
> + .size = obj->base.size,
> + .pages = obj->mm.pages,
> + .obj = obj,
Shouldn't need .size or .obj, but usually needs .vm.
> + };
> +
> + GEM_BUG_ON(!i915_gem_object_has_pinned_pages(obj));
> + ggtt->vm.insert_entries(>vm, , obj->cache_level, 0);
> +}
> +
> +int intel_uc_fw_ggtt_pin(struct intel_uc_fw *uc_fw,
> +struct i915_ggtt *ggtt, u64 start)
> +{
> + struct drm_i915_gem_object *obj = uc_fw->obj;
> + int err;
> +
> + err = i915_gem_object_set_to_gtt_domain(obj, false);
Currently requires struct_mutex, and is not required as we can ensure
the pages are flushed on creation.
> + if (err) {
> + DRM_DEBUG_DRIVER("%s fw set-domain err=%d\n",
> +intel_uc_fw_type_repr(uc_fw->type), err);
> + return err;
> + }
> +
> + err = i915_gem_object_pin_pages(obj);
I'm pretty sure we don't need to pin the pages here, as the caller
should be holding the pages already for the duration of the bind.
So I think this should just reduce to the ggtt bind.
> + if (err) {
> + DRM_DEBUG_DRIVER("%s fw pin-pages err=%d\n",
> +intel_uc_fw_type_repr(uc_fw->type), err);
> + return err;
> + }
> +
> + intel_uc_fw_ggtt_bind(uc_fw, ggtt, start);
> +
> + return 0;
> +}
> +
> +void intel_uc_fw_ggtt_unpin(struct intel_uc_fw *uc_fw,
> + struct i915_ggtt *ggtt, u64 start)
> +{
> + struct drm_i915_gem_object *obj = uc_fw->obj;
> + u64 length = obj->base.size;
> +
> + ggtt->vm.clear_range(>vm, start, length);
> +
> + if (i915_gem_object_has_pinned_pages(obj))
> + i915_gem_object_unpin_pages(obj);
No. You either own the pages, or you do not. Don't guess.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915/uc: Reserve upper range of GGTT
Quoting Chris Wilson (2019-04-09 22:41:40)
> Quoting Fernando Pacheco (2019-04-09 22:31:00)
> > @@ -3370,7 +3388,8 @@ int i915_ggtt_probe_hw(struct drm_i915_private
> > *dev_priv)
> > * restriction!
> > */
> > if (USES_GUC(dev_priv)) {
> > - ggtt->vm.total = min_t(u64, ggtt->vm.total, GUC_GGTT_TOP);
> > + ggtt->vm.total = min_t(u64, ggtt->vm.total,
> > + GUC_GGTT_RESERVED_END);
>
> Should not be required now as you should have completely reserved the range
> for the guc, by the guc.
You can even then remove the comment, as we won't even try and put non
guc data here; guc or no guc is decided at module load.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915/uc: Reserve upper range of GGTT
Quoting Fernando Pacheco (2019-04-09 22:31:00)
> GuC and HuC depend on struct_mutex for device
> reinitialization. Moving away from this dependency
> requires perma-pinning the firmware images in GGTT.
> The upper portion of the GuC address space has
> a sizeable hole (several MB) that is inaccessible
> by GuC. Reserve this range within GGTT as it can
> comfortably hold GuC/HuC firmware images.
>
> Signed-off-by: Fernando Pacheco
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 25 ++---
> drivers/gpu/drm/i915/i915_gem_gtt.h | 1 +
> drivers/gpu/drm/i915/intel_guc.h| 11 +++
> 3 files changed, 34 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 736c845eb77f..30f294a07e6d 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -2747,6 +2747,18 @@ int i915_gem_init_ggtt(struct drm_i915_private
> *dev_priv)
> if (ret)
> return ret;
>
> + /* Reserve a mappable slot for our lockless uC firmware load */
> + if (USES_GUC(dev_priv)) {
> + ret = drm_mm_insert_node_in_range(>vm.mm, >uc_fw,
> + GUC_GGTT_FW_SIZE, 0,
> + I915_COLOR_UNEVICTABLE,
> + GUC_GGTT_FW_START,
> + GUC_GGTT_FW_END,
> + DRM_MM_INSERT_LOW);
Use drm_mm_reserve_node() as you want an explicit address.
We should be able to push this to guc init, with appropriate bailing if
something already took the high range.
> + if (ret)
> + goto err_node;
> + }
> +
> /* Clear any non-preallocated blocks */
> drm_mm_for_each_hole(entry, >vm.mm, hole_start, hole_end) {
> DRM_DEBUG_KMS("clearing unused GTT space: [%lx, %lx]\n",
> @@ -2761,12 +2773,15 @@ int i915_gem_init_ggtt(struct drm_i915_private
> *dev_priv)
> if (INTEL_PPGTT(dev_priv) == INTEL_PPGTT_ALIASING) {
> ret = i915_gem_init_aliasing_ppgtt(dev_priv);
> if (ret)
> - goto err;
> + goto err_appgtt;
> }
>
> return 0;
>
> -err:
> +err_appgtt:
> + if (USES_GUC(dev_priv))
> + drm_mm_remove_node(>uc_fw);
> +err_node:
> drm_mm_remove_node(>error_capture);
> return ret;
> }
> @@ -2792,6 +2807,9 @@ void i915_ggtt_cleanup_hw(struct drm_i915_private
> *dev_priv)
> if (drm_mm_node_allocated(>error_capture))
> drm_mm_remove_node(>error_capture);
>
> + if (drm_mm_node_allocated(>uc_fw))
> + drm_mm_remove_node(>uc_fw);
> +
> if (drm_mm_initialized(>vm.mm)) {
> intel_vgt_deballoon(dev_priv);
> i915_address_space_fini(>vm);
> @@ -3370,7 +3388,8 @@ int i915_ggtt_probe_hw(struct drm_i915_private
> *dev_priv)
> * restriction!
> */
> if (USES_GUC(dev_priv)) {
> - ggtt->vm.total = min_t(u64, ggtt->vm.total, GUC_GGTT_TOP);
> + ggtt->vm.total = min_t(u64, ggtt->vm.total,
> + GUC_GGTT_RESERVED_END);
Should not be required now as you should have completely reserved the range
for the guc, by the guc.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] snd/hda: Balance hda->need_i915_power across runtime_suspend
On Tue, 09 Apr 2019 23:27:41 +0200,
Chris Wilson wrote:
>
> In runtime_resume, we release the local display_power wakeref if we can
> rely on i915 providing a wakeref along the component. On suspend
> therefore, we should only release the display_power if we kept it from
> runtime_resume.
Hrm, it shouldn't matter. After the recent code rewrite, the control
isn't refcount any longer, hence it's fine to call
display_power(false) again even if it were already powered off.
thanks,
Takashi
>
> Fixes: e454ff8e89b6 ("ALSA: hda/intel: Drop superfluous
> AZX_DCAPS_I915_POWERWELL checks")
> Signed-off-by: Chris Wilson
> Cc: Takashi Iwai
> Cc: Imre Deak
> ---
> This appears to fix the glk-dsi as it performs a pm_runtime_suspend in
> the middle of azx_probe_contime(). Hopefully.
> ---
> sound/pci/hda/hda_intel.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
> index 2ec91085fa3e..a9faf95c88b5 100644
> --- a/sound/pci/hda/hda_intel.c
> +++ b/sound/pci/hda/hda_intel.c
> @@ -941,10 +941,14 @@ static bool azx_is_pm_ready(struct snd_card *card)
>
> static void __azx_runtime_suspend(struct azx *chip)
> {
> + struct hda_intel *hda = container_of(chip, struct hda_intel, chip);
> +
> azx_stop_chip(chip);
> azx_enter_link_reset(chip);
> azx_clear_irq_pending(chip);
> - display_power(chip, false);
> +
> + if (hda->need_i915_power)
> + display_power(chip, false);
> }
>
> static void __azx_runtime_resume(struct azx *chip, bool from_rt)
> --
> 2.20.1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] Revert "drm/i915/guc: Disable global reset"
This reverts commit fe62365f9f80a1c1d438c54fba21f5108a182de8.
Signed-off-by: Fernando Pacheco
---
drivers/gpu/drm/i915/i915_reset.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reset.c
b/drivers/gpu/drm/i915/i915_reset.c
index 68875ba43b8d..6f823d81c428 100644
--- a/drivers/gpu/drm/i915/i915_reset.c
+++ b/drivers/gpu/drm/i915/i915_reset.c
@@ -625,9 +625,6 @@ int intel_gpu_reset(struct drm_i915_private *i915,
bool intel_has_gpu_reset(struct drm_i915_private *i915)
{
- if (USES_GUC(i915))
- return false;
-
if (!i915_modparams.reset)
return NULL;
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/i915/uc: Place uC firmware in upper range of GGTT
Currently we pin the GuC or HuC firmware image just
before uploading. Perma-pin during uC initialization
instead and use the range reserved at the top of the
address space.
Moving the firmware resulted in needing to:
- restore the ggtt mapping during the suspend/resume path.
- use an additional pinning for the rsa signature which will
be used during HuC auth as addresses above GUC_GGTT_TOP
do not map through GTT.
Signed-off-by: Fernando Pacheco
---
drivers/gpu/drm/i915/i915_gem.c | 2 +
drivers/gpu/drm/i915/intel_guc.c| 9 ++-
drivers/gpu/drm/i915/intel_guc_fw.c | 43 ++---
drivers/gpu/drm/i915/intel_guc_fw.h | 3 +
drivers/gpu/drm/i915/intel_huc.c| 72 +-
drivers/gpu/drm/i915/intel_huc.h| 4 ++
drivers/gpu/drm/i915/intel_huc_fw.c | 80
drivers/gpu/drm/i915/intel_huc_fw.h | 3 +
drivers/gpu/drm/i915/intel_uc.c | 39 ++--
drivers/gpu/drm/i915/intel_uc.h | 1 +
drivers/gpu/drm/i915/intel_uc_fw.c | 96 -
drivers/gpu/drm/i915/intel_uc_fw.h | 12 +++-
12 files changed, 291 insertions(+), 73 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index bf3d12f94365..160959785589 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4508,6 +4508,8 @@ void i915_gem_resume(struct drm_i915_private *i915)
i915_gem_restore_gtt_mappings(i915);
i915_gem_restore_fences(i915);
+ intel_uc_restore_ggtt_mapping(i915);
+
/*
* As we didn't flush the kernel context before suspend, we cannot
* guarantee that the context image is complete. So let's just reset
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 3aabfa2d9198..418cf6701bf0 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -189,9 +189,13 @@ int intel_guc_init(struct intel_guc *guc)
struct drm_i915_private *dev_priv = guc_to_i915(guc);
int ret;
- ret = guc_shared_data_create(guc);
+ ret = intel_guc_fw_ggtt_pin(guc);
if (ret)
goto err_fetch;
+
+ ret = guc_shared_data_create(guc);
+ if (ret)
+ goto err_fw_pin;
GEM_BUG_ON(!guc->shared_data);
ret = intel_guc_log_create(>log);
@@ -220,6 +224,8 @@ int intel_guc_init(struct intel_guc *guc)
intel_guc_log_destroy(>log);
err_shared:
guc_shared_data_destroy(guc);
+err_fw_pin:
+ intel_guc_fw_ggtt_unpin(guc);
err_fetch:
intel_uc_fw_fini(>fw);
return ret;
@@ -237,6 +243,7 @@ void intel_guc_fini(struct intel_guc *guc)
intel_guc_ads_destroy(guc);
intel_guc_log_destroy(>log);
guc_shared_data_destroy(guc);
+ intel_guc_fw_ggtt_unpin(guc);
intel_uc_fw_fini(>fw);
}
diff --git a/drivers/gpu/drm/i915/intel_guc_fw.c
b/drivers/gpu/drm/i915/intel_guc_fw.c
index 4385d9ef02bb..da73d8747694 100644
--- a/drivers/gpu/drm/i915/intel_guc_fw.c
+++ b/drivers/gpu/drm/i915/intel_guc_fw.c
@@ -27,6 +27,8 @@
*Alex Dai
*/
+#include
+
#include "intel_guc_fw.h"
#include "i915_drv.h"
@@ -122,14 +124,16 @@ static void guc_prepare_xfer(struct intel_guc *guc)
}
/* Copy RSA signature from the fw image to HW for verification */
-static void guc_xfer_rsa(struct intel_guc *guc, struct i915_vma *vma)
+static void guc_xfer_rsa(struct intel_guc *guc)
{
struct drm_i915_private *dev_priv = guc_to_i915(guc);
+ struct intel_uc_fw *fw = >fw;
+ struct sg_table *pages = fw->obj->mm.pages;
u32 rsa[UOS_RSA_SCRATCH_COUNT];
int i;
- sg_pcopy_to_buffer(vma->pages->sgl, vma->pages->nents,
- rsa, sizeof(rsa), guc->fw.rsa_offset);
+ sg_pcopy_to_buffer(pages->sgl, pages->nents,
+ rsa, sizeof(rsa), fw->rsa_offset);
for (i = 0; i < UOS_RSA_SCRATCH_COUNT; i++)
I915_WRITE(UOS_RSA_SCRATCH(i), rsa[i]);
@@ -201,7 +205,7 @@ static int guc_wait_ucode(struct intel_guc *guc)
* transfer between GTT locations. This functionality is left out of the API
* for now as there is no need for it.
*/
-static int guc_xfer_ucode(struct intel_guc *guc, struct i915_vma *vma)
+static int guc_xfer_ucode(struct intel_guc *guc)
{
struct drm_i915_private *dev_priv = guc_to_i915(guc);
struct intel_uc_fw *guc_fw = >fw;
@@ -214,7 +218,7 @@ static int guc_xfer_ucode(struct intel_guc *guc, struct
i915_vma *vma)
I915_WRITE(DMA_COPY_SIZE, guc_fw->header_size + guc_fw->ucode_size);
/* Set the source address for the new blob */
- offset = intel_guc_ggtt_offset(guc, vma) + guc_fw->header_offset;
+ offset = intel_guc_fw_ggtt_offset(guc) + guc_fw->header_offset;
I915_WRITE(DMA_ADDR_0_LOW, lower_32_bits(offset));
I915_WRITE(DMA_ADDR_0_HIGH, upper_32_bits(offset) & 0x);
@@ -233,7 +237,7 @@ static int
[Intel-gfx] [PATCH 1/4] drm/i915/uc: Rename uC firmware init function
The uC firmware init function is called during
GuC/HuC init early phases. Rename to include "_early"
and properly reflect which phase we are at.
Signed-off-by: Fernando Pacheco
---
drivers/gpu/drm/i915/intel_guc_fw.c | 2 +-
drivers/gpu/drm/i915/intel_huc_fw.c | 2 +-
drivers/gpu/drm/i915/intel_uc_fw.h | 3 ++-
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc_fw.c
b/drivers/gpu/drm/i915/intel_guc_fw.c
index 792a551450c7..4385d9ef02bb 100644
--- a/drivers/gpu/drm/i915/intel_guc_fw.c
+++ b/drivers/gpu/drm/i915/intel_guc_fw.c
@@ -90,7 +90,7 @@ void intel_guc_fw_init_early(struct intel_guc *guc)
{
struct intel_uc_fw *guc_fw = >fw;
- intel_uc_fw_init(guc_fw, INTEL_UC_FW_TYPE_GUC);
+ intel_uc_fw_init_early(guc_fw, INTEL_UC_FW_TYPE_GUC);
guc_fw_select(guc_fw);
}
diff --git a/drivers/gpu/drm/i915/intel_huc_fw.c
b/drivers/gpu/drm/i915/intel_huc_fw.c
index 68d47c105939..80a176d91edc 100644
--- a/drivers/gpu/drm/i915/intel_huc_fw.c
+++ b/drivers/gpu/drm/i915/intel_huc_fw.c
@@ -89,7 +89,7 @@ void intel_huc_fw_init_early(struct intel_huc *huc)
{
struct intel_uc_fw *huc_fw = >fw;
- intel_uc_fw_init(huc_fw, INTEL_UC_FW_TYPE_HUC);
+ intel_uc_fw_init_early(huc_fw, INTEL_UC_FW_TYPE_HUC);
huc_fw_select(huc_fw);
}
diff --git a/drivers/gpu/drm/i915/intel_uc_fw.h
b/drivers/gpu/drm/i915/intel_uc_fw.h
index 0e3bd580e267..854c3a383e07 100644
--- a/drivers/gpu/drm/i915/intel_uc_fw.h
+++ b/drivers/gpu/drm/i915/intel_uc_fw.h
@@ -102,7 +102,8 @@ static inline const char *intel_uc_fw_type_repr(enum
intel_uc_fw_type type)
}
static inline
-void intel_uc_fw_init(struct intel_uc_fw *uc_fw, enum intel_uc_fw_type type)
+void intel_uc_fw_init_early(struct intel_uc_fw *uc_fw,
+ enum intel_uc_fw_type type)
{
uc_fw->path = NULL;
uc_fw->fetch_status = INTEL_UC_FIRMWARE_NONE;
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915/uc: Reserve upper range of GGTT
GuC and HuC depend on struct_mutex for device
reinitialization. Moving away from this dependency
requires perma-pinning the firmware images in GGTT.
The upper portion of the GuC address space has
a sizeable hole (several MB) that is inaccessible
by GuC. Reserve this range within GGTT as it can
comfortably hold GuC/HuC firmware images.
Signed-off-by: Fernando Pacheco
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 25 ++---
drivers/gpu/drm/i915/i915_gem_gtt.h | 1 +
drivers/gpu/drm/i915/intel_guc.h| 11 +++
3 files changed, 34 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 736c845eb77f..30f294a07e6d 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2747,6 +2747,18 @@ int i915_gem_init_ggtt(struct drm_i915_private *dev_priv)
if (ret)
return ret;
+ /* Reserve a mappable slot for our lockless uC firmware load */
+ if (USES_GUC(dev_priv)) {
+ ret = drm_mm_insert_node_in_range(>vm.mm, >uc_fw,
+ GUC_GGTT_FW_SIZE, 0,
+ I915_COLOR_UNEVICTABLE,
+ GUC_GGTT_FW_START,
+ GUC_GGTT_FW_END,
+ DRM_MM_INSERT_LOW);
+ if (ret)
+ goto err_node;
+ }
+
/* Clear any non-preallocated blocks */
drm_mm_for_each_hole(entry, >vm.mm, hole_start, hole_end) {
DRM_DEBUG_KMS("clearing unused GTT space: [%lx, %lx]\n",
@@ -2761,12 +2773,15 @@ int i915_gem_init_ggtt(struct drm_i915_private
*dev_priv)
if (INTEL_PPGTT(dev_priv) == INTEL_PPGTT_ALIASING) {
ret = i915_gem_init_aliasing_ppgtt(dev_priv);
if (ret)
- goto err;
+ goto err_appgtt;
}
return 0;
-err:
+err_appgtt:
+ if (USES_GUC(dev_priv))
+ drm_mm_remove_node(>uc_fw);
+err_node:
drm_mm_remove_node(>error_capture);
return ret;
}
@@ -2792,6 +2807,9 @@ void i915_ggtt_cleanup_hw(struct drm_i915_private
*dev_priv)
if (drm_mm_node_allocated(>error_capture))
drm_mm_remove_node(>error_capture);
+ if (drm_mm_node_allocated(>uc_fw))
+ drm_mm_remove_node(>uc_fw);
+
if (drm_mm_initialized(>vm.mm)) {
intel_vgt_deballoon(dev_priv);
i915_address_space_fini(>vm);
@@ -3370,7 +3388,8 @@ int i915_ggtt_probe_hw(struct drm_i915_private *dev_priv)
* restriction!
*/
if (USES_GUC(dev_priv)) {
- ggtt->vm.total = min_t(u64, ggtt->vm.total, GUC_GGTT_TOP);
+ ggtt->vm.total = min_t(u64, ggtt->vm.total,
+ GUC_GGTT_RESERVED_END);
ggtt->mappable_end =
min_t(u64, ggtt->mappable_end, ggtt->vm.total);
}
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index f597f35b109b..b51e779732c3 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -384,6 +384,7 @@ struct i915_ggtt {
u32 pin_bias;
struct drm_mm_node error_capture;
+ struct drm_mm_node uc_fw;
};
struct i915_hw_ppgtt {
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 2c59ff8d9f39..b30cc2642fc4 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -127,6 +127,17 @@ static inline void intel_guc_to_host_event_handler(struct
intel_guc *guc)
/* GuC addresses above GUC_GGTT_TOP also don't map through the GTT */
#define GUC_GGTT_TOP 0xFEE0
+/*
+ * This portion of the address space is inaccessible by GuC,
+ * but still accessible by DMA. We can repurpose this portion
+ * to house the uC firmware images and perform the image upload.
+ */
+#define GUC_GGTT_FW_START GUC_GGTT_TOP
+#define GUC_GGTT_FW_END0xFFE0
+#define GUC_GGTT_RESERVED_END GUC_GGTT_FW_END
+
+#define GUC_GGTT_FW_SIZE (GUC_GGTT_FW_END - GUC_GGTT_FW_START)
+
/**
* intel_guc_ggtt_offset() - Get and validate the GGTT offset of @vma
* @guc: intel_guc structure.
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/4] Perma-pin uC firmware and re-enable global reset
The intent is to move the GuC and HuC firmware images to the top of the address space. This portion is inaccessible during normal GuC operations and should be relatively safe to house both firmware images. By making the move we can re-enable the full gpu reset with GuC enabled. Placing the firmware images above GUC_GGTT_TOP was discussed previously here: https://patchwork.freedesktop.org/patch/273616/ Cc: Chris Wilson Cc: Daniele Ceraolo Spurio Fernando Pacheco (4): drm/i915/uc: Rename uC firmware init function drm/i915/uc: Reserve upper range of GGTT drm/i915/uc: Place uC firmware in upper range of GGTT Revert "drm/i915/guc: Disable global reset" drivers/gpu/drm/i915/i915_gem.c | 2 + drivers/gpu/drm/i915/i915_gem_gtt.c | 25 +++- drivers/gpu/drm/i915/i915_gem_gtt.h | 1 + drivers/gpu/drm/i915/i915_reset.c | 3 - drivers/gpu/drm/i915/intel_guc.c| 9 ++- drivers/gpu/drm/i915/intel_guc.h| 11 drivers/gpu/drm/i915/intel_guc_fw.c | 45 +++--- drivers/gpu/drm/i915/intel_guc_fw.h | 3 + drivers/gpu/drm/i915/intel_huc.c| 72 +- drivers/gpu/drm/i915/intel_huc.h| 4 ++ drivers/gpu/drm/i915/intel_huc_fw.c | 82 drivers/gpu/drm/i915/intel_huc_fw.h | 3 + drivers/gpu/drm/i915/intel_uc.c | 39 ++-- drivers/gpu/drm/i915/intel_uc.h | 1 + drivers/gpu/drm/i915/intel_uc_fw.c | 96 - drivers/gpu/drm/i915/intel_uc_fw.h | 15 - 16 files changed, 329 insertions(+), 82 deletions(-) -- 2.21.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/7] drm/i915: Rename SDVO_AUDIO_ENABLE to HDMI_AUDIO_ENABLE
Quoting Ville Syrjala (2019-04-09 15:40:50) > From: Ville Syrjälä > > The "audio enable" bit on the SDVO/HDMI control register is only meant > for HDMI. Audio is never delivered over the SDVO bus. Rename the define > to reflect this fact. > > Signed-off-by: Ville Syrjälä Just going by that it's only used by the hdmi code :) 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] snd/hda: Balance hda->need_i915_power across runtime_suspend
In runtime_resume, we release the local display_power wakeref if we can
rely on i915 providing a wakeref along the component. On suspend
therefore, we should only release the display_power if we kept it from
runtime_resume.
Fixes: e454ff8e89b6 ("ALSA: hda/intel: Drop superfluous
AZX_DCAPS_I915_POWERWELL checks")
Signed-off-by: Chris Wilson
Cc: Takashi Iwai
Cc: Imre Deak
---
This appears to fix the glk-dsi as it performs a pm_runtime_suspend in
the middle of azx_probe_contime(). Hopefully.
---
sound/pci/hda/hda_intel.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 2ec91085fa3e..a9faf95c88b5 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -941,10 +941,14 @@ static bool azx_is_pm_ready(struct snd_card *card)
static void __azx_runtime_suspend(struct azx *chip)
{
+ struct hda_intel *hda = container_of(chip, struct hda_intel, chip);
+
azx_stop_chip(chip);
azx_enter_link_reset(chip);
azx_clear_irq_pending(chip);
- display_power(chip, false);
+
+ if (hda->need_i915_power)
+ display_power(chip, false);
}
static void __azx_runtime_resume(struct azx *chip, bool from_rt)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/7] drm/i915/sdvo: Fix AVI infoframe TX rate readout
Quoting Ville Syrjala (2019-04-09 15:40:48) > From: Ville Syrjälä > > The AVI infoframe readout code currently issues a > SDVO_CMD_GET_HBUF_TXRATE before SDVO_CMD_SET_HBUF_INDEX, which is > not the correct order for these two operations. So far this wasn't > a problem since we left the index pointing at the AVI infoframe > buffer at the end of the modeset. However once we start to write > to other buffers (namely ELD) that is no longer going to be true. > Fix up the order so that we always read out the TX rate for the > correct buffer. > > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/intel_sdvo.c | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_sdvo.c > b/drivers/gpu/drm/i915/intel_sdvo.c > index 0e3d91d9ef13..61db07244296 100644 > --- a/drivers/gpu/drm/i915/intel_sdvo.c > +++ b/drivers/gpu/drm/i915/intel_sdvo.c > @@ -1001,6 +1001,11 @@ static ssize_t intel_sdvo_read_infoframe(struct > intel_sdvo *intel_sdvo, > if (av_split < if_index) > return 0; > > + if (!intel_sdvo_set_value(intel_sdvo, > + SDVO_CMD_SET_HBUF_INDEX, > + set_buf_index, 2)) > + return -ENXIO; That is consistent with write_infoframe and makes a modicum of sense. Reviewed-by: Chris Wilson Why is the av_split separate from the if_index? What does that mean, at some point I might have to read the docs! -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/7] drm/i915/sdvo: Check that we have space for the infoframe
Quoting Ville Syrjälä (2019-04-09 20:59:43) > On Tue, Apr 09, 2019 at 08:46:42PM +0100, Chris Wilson wrote: > > Quoting Ville Syrjala (2019-04-09 15:40:51) > > > From: Ville Syrjälä > > > > > > Before we go writing the infoframe let's make sure we have > > > the space for it. Not that it really matters since the write > > > loop would just terminate early in that case. > > > > > > Signed-off-by: Ville Syrjälä > > > --- > > > drivers/gpu/drm/i915/intel_sdvo.c | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/drivers/gpu/drm/i915/intel_sdvo.c > > > b/drivers/gpu/drm/i915/intel_sdvo.c > > > index 7f64352a3413..1e0102f1710f 100644 > > > --- a/drivers/gpu/drm/i915/intel_sdvo.c > > > +++ b/drivers/gpu/drm/i915/intel_sdvo.c > > > @@ -970,6 +970,9 @@ static bool intel_sdvo_write_infoframe(struct > > > intel_sdvo *intel_sdvo, > > > _size, 1)) > > > return false; > > > > > > + if (hbuf_size < length) > > > + return false; > > > + > > > > Maybe after reporting the hbuf_size and length in the following > > DRM_DEBUG_KMS? > > Yes, that does seem more sensible. Avoids the off by one as well. Ok, predictive Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 6/6] drm/i915: Set DP min_bpp to 8*3 for non-RGB output formats
On Tue, 2019-04-09 at 23:38 +0300, Ville Syrjälä wrote:
> On Tue, Apr 09, 2019 at 01:28:18PM -0700, Dhinakaran Pandiyan wrote:
> > On Tue, 2019-03-26 at 16:25 +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > 6bpc is only legal for RGB and RAW pixel encodings. For the rest
> > > the minimum is 8bpc. Set our lower limit accordingly.
> >
> > Patch doesn't apply anymore, got a conflict in intel_drv.h.
> >
> >
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/i915/intel_dp.c | 10 +-
> > > drivers/gpu/drm/i915/intel_dp_mst.c | 2 +-
> > > drivers/gpu/drm/i915/intel_drv.h| 1 +
> > > 3 files changed, 11 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index 2aee526ed632..149fdfbcb343 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -2002,6 +2002,14 @@ static int intel_dp_dsc_compute_config(struct
> > > intel_dp
> > > *intel_dp,
> > > return 0;
> > > }
> > >
> > > +int intel_dp_min_bpp(const struct intel_crtc_state *crtc_state)
> > > +{
> > > + if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_RGB)
> > > + return 6 * 3;
> > > + else
> > > + return 8 * 3;
> >
> > Code matches spec, however I think there is a possibility of min_bpp
> > becoming
> > greater than max_bpp. The max_bpc property allows user space to set a value
> > of 6
> > and limits.min_bpp can become 24 because of the code above. Add a check for
> > that
> > in compute_link_config()? Probably would mess up the compute_config() loop
> > too.
>
> The code looks correct. Ie. should just end up with -EINVAL.
Yup, it does now as I read it carefully again :)
Reviewed-by: Dhinakaran Pandiyan
However, I don't like the fact we are hiding the detail that min_bpp can be >
max_bpp. If someone decides add a link config optimization starting from
min_bpp, it's easy to miss this detail.
-DK
>
> >
> >
> > > +}
> > > +
> > > static int
> > > intel_dp_compute_link_config(struct intel_encoder *encoder,
> > >struct intel_crtc_state *pipe_config,
> > > @@ -2025,7 +2033,7 @@ intel_dp_compute_link_config(struct intel_encoder
> > > *encoder,
> > > limits.min_lane_count = 1;
> > > limits.max_lane_count = intel_dp_max_lane_count(intel_dp);
> > >
> > > - limits.min_bpp = 6 * 3;
> > > + limits.min_bpp = intel_dp_min_bpp(pipe_config);
> > > limits.max_bpp = intel_dp_compute_bpp(intel_dp, pipe_config);
> > >
> > > if (intel_dp_is_edp(intel_dp) && intel_dp->edp_dpcd[0] < DP_EDP_14) {
> > > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
> > > b/drivers/gpu/drm/i915/intel_dp_mst.c
> > > index 6d2af7cf48e6..79c229184873 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > > @@ -119,7 +119,7 @@ static int intel_dp_mst_compute_config(struct
> > > intel_encoder *encoder,
> > > limits.min_lane_count =
> > > limits.max_lane_count = intel_dp_max_lane_count(intel_dp);
> > >
> > > - limits.min_bpp = 6 * 3;
> > > + limits.min_bpp = intel_dp_min_bpp(pipe_config);
> > > limits.max_bpp = pipe_config->pipe_bpp;
> > >
> > > intel_dp_adjust_compliance_config(intel_dp, pipe_config, );
> > > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > > b/drivers/gpu/drm/i915/intel_drv.h
> > > index e79954c6271c..13f1b0367287 100644
> > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > @@ -1919,6 +1919,7 @@ void intel_dp_adjust_compliance_config(struct
> > > intel_dp
> > > *intel_dp,
> > > struct link_config_limits *limits);
> > > bool intel_dp_limited_color_range(const struct intel_crtc_state
> > > *crtc_state,
> > > const struct drm_connector_state *conn_state);
> > > +int intel_dp_min_bpp(const struct intel_crtc_state *crtc_state);
> > > bool intel_dp_port_enabled(struct drm_i915_private *dev_priv,
> > > i915_reg_t dp_reg, enum port port,
> > > enum pipe *pipe);
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] i915/gem_ppgtt: Enable libdrm bo reuse
Try papering over the icl memleak with a spot of buffer recycling. Signed-off-by: Chris Wilson --- tests/i915/gem_ppgtt.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tests/i915/gem_ppgtt.c b/tests/i915/gem_ppgtt.c index ae9869c2c..4bff5cf98 100644 --- a/tests/i915/gem_ppgtt.c +++ b/tests/i915/gem_ppgtt.c @@ -107,6 +107,7 @@ static void fork_rcs_copy(int timeout, uint32_t final, bufmgr = drm_intel_bufmgr_gem_init(fd, 4096); igt_assert(bufmgr); + drm_intel_bufmgr_gem_enable_reuse(bufmgr); dst[child] = create_bo(bufmgr, ~0); @@ -179,6 +180,7 @@ static void fork_bcs_copy(int timeout, uint32_t final, bufmgr = drm_intel_bufmgr_gem_init(fd, 4096); igt_assert(bufmgr); + drm_intel_bufmgr_gem_enable_reuse(bufmgr); dst[child] = create_bo(bufmgr, ~0); } -- 2.20.1 ___ 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: Fix setting 10 bit color mode
== Series Details == Series: drm/i915: Fix setting 10 bit color mode URL : https://patchwork.freedesktop.org/series/59246/ State : success == Summary == CI Bug Log - changes from CI_DRM_5897 -> Patchwork_12745 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/59246/revisions/1/mbox/ Known issues Here are the changes found in Patchwork_12745 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@sync-fork-compute0: - fi-icl-u3: NOTRUN -> SKIP [fdo#109315] +17 * igt@gem_exec_basic@gtt-bsd1: - fi-icl-u3: NOTRUN -> SKIP [fdo#109276] +7 * igt@gem_exec_parse@basic-rejected: - fi-icl-u3: NOTRUN -> SKIP [fdo#109289] +1 * igt@gem_exec_store@basic-bsd1: - fi-kbl-r: NOTRUN -> SKIP [fdo#109271] +41 * 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] / [fdo#109720] * igt@kms_busy@basic-flip-a: - fi-bsw-n3050: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +1 * igt@kms_busy@basic-flip-c: - fi-blb-e6850: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] - fi-byt-j1900: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] * igt@kms_chamelium@hdmi-crc-fast: - fi-bsw-n3050: NOTRUN -> SKIP [fdo#109271] +62 - fi-byt-j1900: NOTRUN -> SKIP [fdo#109271] +52 * igt@kms_chamelium@hdmi-edid-read: - fi-icl-u3: NOTRUN -> SKIP [fdo#109284] +8 * igt@kms_force_connector_basic@prune-stale-modes: - fi-icl-u3: NOTRUN -> SKIP [fdo#109285] +3 * igt@kms_frontbuffer_tracking@basic: - fi-icl-u3: NOTRUN -> FAIL [fdo#103167] * igt@kms_pipe_crc_basic@hang-read-crc-pipe-c: - fi-blb-e6850: NOTRUN -> SKIP [fdo#109271] +48 Possible fixes * igt@gem_ctx_exec@basic: - fi-icl-u3: INCOMPLETE [fdo#107713] -> PASS * igt@gem_exec_suspend@basic-s4-devices: - fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS * igt@i915_selftest@live_contexts: - fi-bdw-gvtdvm: DMESG-FAIL [fdo#110235 ] -> PASS [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276 [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278 [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284 [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285 [fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289 [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315 [fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720 [fdo#110235 ]: https://bugs.freedesktop.org/show_bug.cgi?id=110235 Participating hosts (44 -> 44) -- Additional (3): fi-byt-j1900 fi-kbl-r fi-bsw-n3050 Missing(3): fi-byt-squawks fi-bsw-cyan fi-bdw-samus Build changes - * Linux: CI_DRM_5897 -> Patchwork_12745 CI_DRM_5897: 7d07e025e78603d6270bc115fdb6c1efea6e66a5 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4934: dc4f45eb6874331daec870dc1e4cfc3ac5c49311 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12745: d76f6b458d074fd8559cf0f8e235e3550085bfc7 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == d76f6b458d07 drm/i915: Fix setting 10 bit color mode == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12745/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 6/6] drm/i915: Set DP min_bpp to 8*3 for non-RGB output formats
On Tue, Apr 09, 2019 at 01:28:18PM -0700, Dhinakaran Pandiyan wrote:
> On Tue, 2019-03-26 at 16:25 +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > 6bpc is only legal for RGB and RAW pixel encodings. For the rest
> > the minimum is 8bpc. Set our lower limit accordingly.
>
> Patch doesn't apply anymore, got a conflict in intel_drv.h.
>
>
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 10 +-
> > drivers/gpu/drm/i915/intel_dp_mst.c | 2 +-
> > drivers/gpu/drm/i915/intel_drv.h| 1 +
> > 3 files changed, 11 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 2aee526ed632..149fdfbcb343 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -2002,6 +2002,14 @@ static int intel_dp_dsc_compute_config(struct
> > intel_dp
> > *intel_dp,
> > return 0;
> > }
> >
> > +int intel_dp_min_bpp(const struct intel_crtc_state *crtc_state)
> > +{
> > + if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_RGB)
> > + return 6 * 3;
> > + else
> > + return 8 * 3;
> Code matches spec, however I think there is a possibility of min_bpp becoming
> greater than max_bpp. The max_bpc property allows user space to set a value
> of 6
> and limits.min_bpp can become 24 because of the code above. Add a check for
> that
> in compute_link_config()? Probably would mess up the compute_config() loop
> too.
The code looks correct. Ie. should just end up with -EINVAL.
>
>
> > +}
> > +
> > static int
> > intel_dp_compute_link_config(struct intel_encoder *encoder,
> > struct intel_crtc_state *pipe_config,
> > @@ -2025,7 +2033,7 @@ intel_dp_compute_link_config(struct intel_encoder
> > *encoder,
> > limits.min_lane_count = 1;
> > limits.max_lane_count = intel_dp_max_lane_count(intel_dp);
> >
> > - limits.min_bpp = 6 * 3;
> > + limits.min_bpp = intel_dp_min_bpp(pipe_config);
> > limits.max_bpp = intel_dp_compute_bpp(intel_dp, pipe_config);
> >
> > if (intel_dp_is_edp(intel_dp) && intel_dp->edp_dpcd[0] < DP_EDP_14) {
> > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
> > b/drivers/gpu/drm/i915/intel_dp_mst.c
> > index 6d2af7cf48e6..79c229184873 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > @@ -119,7 +119,7 @@ static int intel_dp_mst_compute_config(struct
> > intel_encoder *encoder,
> > limits.min_lane_count =
> > limits.max_lane_count = intel_dp_max_lane_count(intel_dp);
> >
> > - limits.min_bpp = 6 * 3;
> > + limits.min_bpp = intel_dp_min_bpp(pipe_config);
> > limits.max_bpp = pipe_config->pipe_bpp;
> >
> > intel_dp_adjust_compliance_config(intel_dp, pipe_config, );
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index e79954c6271c..13f1b0367287 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1919,6 +1919,7 @@ void intel_dp_adjust_compliance_config(struct intel_dp
> > *intel_dp,
> >struct link_config_limits *limits);
> > bool intel_dp_limited_color_range(const struct intel_crtc_state
> > *crtc_state,
> > const struct drm_connector_state *conn_state);
> > +int intel_dp_min_bpp(const struct intel_crtc_state *crtc_state);
> > bool intel_dp_port_enabled(struct drm_i915_private *dev_priv,
> >i915_reg_t dp_reg, enum port port,
> >enum pipe *pipe);
--
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 7/7] drm/i915/sdvo: Actually print the reason why the SDVO command failed
On Tue, Apr 09, 2019 at 08:44:26PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjala (2019-04-09 15:40:54)
> > From: Ville Syrjälä
> >
> > It's much easier to figure out why the SDVO encoder refuses to cooperate
> > if we can see what status we got back.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_sdvo.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
> > b/drivers/gpu/drm/i915/intel_sdvo.c
> > index d5a95eca23ba..5d928f6d0028 100644
> > --- a/drivers/gpu/drm/i915/intel_sdvo.c
> > +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> > @@ -516,7 +516,7 @@ static bool intel_sdvo_read_response(struct intel_sdvo
> > *intel_sdvo,
> > u8 status;
> > int i, pos = 0;
> > #define BUF_LEN 256
> > - char buffer[BUF_LEN];
> > + char buffer[BUF_LEN] = {};
>
> I should stop quibbling over a 256b memset.
Hmm. I wonder if 256 bytes isn't a bit excessive actually.
Max 8 responses 3 chars each, and 21 or so bytes for the status string.
Comes to a total of 45 chars. A bit more for intel_sdvo_debug_write()
since it wants to print the command name.
>
> > /*
> > @@ -581,7 +581,8 @@ static bool intel_sdvo_read_response(struct intel_sdvo
> > *intel_sdvo,
> > return true;
> >
> > log_fail:
> > - DRM_DEBUG_KMS("%s: R: ... failed\n", SDVO_NAME(intel_sdvo));
> > + DRM_DEBUG_KMS("%s: R: ... failed %s\n",
> > + SDVO_NAME(intel_sdvo), buffer);
>
> Reviewed-by: Chris Wilson
> -Chris
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 6/6] drm/i915: Set DP min_bpp to 8*3 for non-RGB output formats
On Tue, 2019-03-26 at 16:25 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> 6bpc is only legal for RGB and RAW pixel encodings. For the rest
> the minimum is 8bpc. Set our lower limit accordingly.
Patch doesn't apply anymore, got a conflict in intel_drv.h.
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_dp.c | 10 +-
> drivers/gpu/drm/i915/intel_dp_mst.c | 2 +-
> drivers/gpu/drm/i915/intel_drv.h| 1 +
> 3 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 2aee526ed632..149fdfbcb343 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -2002,6 +2002,14 @@ static int intel_dp_dsc_compute_config(struct intel_dp
> *intel_dp,
> return 0;
> }
>
> +int intel_dp_min_bpp(const struct intel_crtc_state *crtc_state)
> +{
> + if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_RGB)
> + return 6 * 3;
> + else
> + return 8 * 3;
Code matches spec, however I think there is a possibility of min_bpp becoming
greater than max_bpp. The max_bpc property allows user space to set a value of 6
and limits.min_bpp can become 24 because of the code above. Add a check for that
in compute_link_config()? Probably would mess up the compute_config() loop too.
> +}
> +
> static int
> intel_dp_compute_link_config(struct intel_encoder *encoder,
>struct intel_crtc_state *pipe_config,
> @@ -2025,7 +2033,7 @@ intel_dp_compute_link_config(struct intel_encoder
> *encoder,
> limits.min_lane_count = 1;
> limits.max_lane_count = intel_dp_max_lane_count(intel_dp);
>
> - limits.min_bpp = 6 * 3;
> + limits.min_bpp = intel_dp_min_bpp(pipe_config);
> limits.max_bpp = intel_dp_compute_bpp(intel_dp, pipe_config);
>
> if (intel_dp_is_edp(intel_dp) && intel_dp->edp_dpcd[0] < DP_EDP_14) {
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index 6d2af7cf48e6..79c229184873 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -119,7 +119,7 @@ static int intel_dp_mst_compute_config(struct
> intel_encoder *encoder,
> limits.min_lane_count =
> limits.max_lane_count = intel_dp_max_lane_count(intel_dp);
>
> - limits.min_bpp = 6 * 3;
> + limits.min_bpp = intel_dp_min_bpp(pipe_config);
> limits.max_bpp = pipe_config->pipe_bpp;
>
> intel_dp_adjust_compliance_config(intel_dp, pipe_config, );
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index e79954c6271c..13f1b0367287 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1919,6 +1919,7 @@ void intel_dp_adjust_compliance_config(struct intel_dp
> *intel_dp,
> struct link_config_limits *limits);
> bool intel_dp_limited_color_range(const struct intel_crtc_state *crtc_state,
> const struct drm_connector_state *conn_state);
> +int intel_dp_min_bpp(const struct intel_crtc_state *crtc_state);
> bool intel_dp_port_enabled(struct drm_i915_private *dev_priv,
> i915_reg_t dp_reg, enum port port,
> enum pipe *pipe);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: fully convert the IRQ initialization macros to intel_uncore
On Mon, Apr 08, 2019 at 05:37:29PM -0700, Paulo Zanoni wrote:
> Make them take the uncore argument from the caller instead of passing
> the implicit _priv->uncore directly. This will allow us to finally
> pass something that's not dev_priv->uncore in the future, and gets rid
> of the implicit variables in register macros.
I've not been paying much attention to the uncore developments,
so I'm not sure this matches what other people think we should
do. But techinally these look OK to me.
Patches 2 and 3 are
Reviewed-by: Ville Syrjälä
But I guess give other people a bit of time to complain before
pushing :)
>
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_irq.c | 144 +++-
> 1 file changed, 88 insertions(+), 56 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 99a6527568cf..b6361bab1086 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -166,15 +166,15 @@ static void gen2_irq_reset(struct intel_uncore *uncore,
> i915_reg_t imr,
> intel_uncore_posting_read16(uncore, iir);
> }
>
> -#define GEN8_IRQ_RESET_NDX(type, which) \
> - gen3_irq_reset(_priv->uncore, GEN8_##type##_IMR(which), \
> +#define GEN8_IRQ_RESET_NDX(uncore, type, which) \
> + gen3_irq_reset((uncore), GEN8_##type##_IMR(which), \
> GEN8_##type##_IIR(which), GEN8_##type##_IER(which))
>
> -#define GEN3_IRQ_RESET(type) \
> - gen3_irq_reset(_priv->uncore, type##IMR, type##IIR, type##IER)
> +#define GEN3_IRQ_RESET(uncore, type) \
> + gen3_irq_reset((uncore), type##IMR, type##IIR, type##IER)
>
> -#define GEN2_IRQ_RESET(type) \
> - gen2_irq_reset(_priv->uncore, type##IMR, type##IIR, type##IER)
> +#define GEN2_IRQ_RESET(uncore, type) \
> + gen2_irq_reset((uncore), type##IMR, type##IIR, type##IER)
>
> /*
> * We should clear IMR at preinstall/uninstall, and just check at
> postinstall.
> @@ -233,17 +233,17 @@ static void gen2_irq_init(struct intel_uncore *uncore,
> i915_reg_t imr,
> intel_uncore_posting_read16(uncore, imr);
> }
>
> -#define GEN8_IRQ_INIT_NDX(type, which, imr_val, ier_val) \
> - gen3_irq_init(_priv->uncore, GEN8_##type##_IMR(which), \
> +#define GEN8_IRQ_INIT_NDX(uncore, type, which, imr_val, ier_val) \
> + gen3_irq_init((uncore), GEN8_##type##_IMR(which), \
> GEN8_##type##_IIR(which), GEN8_##type##_IER(which), \
> imr_val, ier_val)
>
> -#define GEN3_IRQ_INIT(type, imr_val, ier_val) \
> - gen3_irq_init(_priv->uncore, type##IMR, type##IIR, type##IER, \
> +#define GEN3_IRQ_INIT(uncore, type, imr_val, ier_val) \
> + gen3_irq_init((uncore), type##IMR, type##IIR, type##IER, \
> imr_val, ier_val)
>
> -#define GEN2_IRQ_INIT(type, imr_val, ier_val) \
> - gen2_irq_init(_priv->uncore, type##IMR, type##IIR, type##IER, \
> +#define GEN2_IRQ_INIT(uncore, type, imr_val, ier_val) \
> + gen2_irq_init((uncore), type##IMR, type##IIR, type##IER, \
> imr_val, ier_val)
>
> static void gen6_rps_irq_handler(struct drm_i915_private *dev_priv, u32
> pm_iir);
> @@ -3331,10 +3331,12 @@ static void i945gm_vblank_work_fini(struct
> drm_i915_private *dev_priv)
>
> static void ibx_irq_reset(struct drm_i915_private *dev_priv)
> {
> + struct intel_uncore *uncore = _priv->uncore;
> +
> if (HAS_PCH_NOP(dev_priv))
> return;
>
> - GEN3_IRQ_RESET(SDE);
> + GEN3_IRQ_RESET(uncore, SDE);
>
> if (HAS_PCH_CPT(dev_priv) || HAS_PCH_LPT(dev_priv))
> I915_WRITE(SERR_INT, 0x);
> @@ -3362,13 +3364,17 @@ static void ibx_irq_pre_postinstall(struct drm_device
> *dev)
>
> static void gen5_gt_irq_reset(struct drm_i915_private *dev_priv)
> {
> - GEN3_IRQ_RESET(GT);
> + struct intel_uncore *uncore = _priv->uncore;
> +
> + GEN3_IRQ_RESET(uncore, GT);
> if (INTEL_GEN(dev_priv) >= 6)
> - GEN3_IRQ_RESET(GEN6_PM);
> + GEN3_IRQ_RESET(uncore, GEN6_PM);
> }
>
> static void vlv_display_irq_reset(struct drm_i915_private *dev_priv)
> {
> + struct intel_uncore *uncore = _priv->uncore;
> +
> if (IS_CHERRYVIEW(dev_priv))
> I915_WRITE(DPINVGTT, DPINVGTT_STATUS_MASK_CHV);
> else
> @@ -3379,12 +3385,14 @@ static void vlv_display_irq_reset(struct
> drm_i915_private *dev_priv)
>
> i9xx_pipestat_irq_reset(dev_priv);
>
> - GEN3_IRQ_RESET(VLV_);
> + GEN3_IRQ_RESET(uncore, VLV_);
> dev_priv->irq_mask = ~0u;
> }
>
> static void vlv_display_irq_postinstall(struct drm_i915_private *dev_priv)
> {
> + struct intel_uncore *uncore = _priv->uncore;
> +
> u32 pipestat_mask;
> u32 enable_mask;
> enum pipe pipe;
> @@ -3409,7 +3417,7 @@ static void vlv_display_irq_postinstall(struct
> drm_i915_private *dev_priv)
>
> dev_priv->irq_mask = ~enable_mask;
>
> - GEN3_IRQ_INIT(VLV_,
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Fix setting 10 bit color mode
== Series Details ==
Series: drm/i915: Fix setting 10 bit color mode
URL : https://patchwork.freedesktop.org/series/59246/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d76f6b458d07 drm/i915: Fix setting 10 bit color mode
-:22: WARNING:BAD_SIGN_OFF: Non-standard signature: Co-authored-by:
#22:
Co-authored-by: Clint Taylor
-:49: ERROR:SPACING: space required before the open parenthesis '('
#49: FILE: drivers/gpu/drm/i915/intel_hdmi.c:2328:
+ if(pipe_config->pipe_bpp == 36) {
-:49: CHECK:BRACES: braces {} should be used on all arms of this statement
#49: FILE: drivers/gpu/drm/i915/intel_hdmi.c:2328:
+ if(pipe_config->pipe_bpp == 36) {
[...]
+ } else if (pipe_config->pipe_bpp == 30) {
[...]
+ } else
[...]
-:55: CHECK:BRACES: Unbalanced braces around else statement
#55: FILE: drivers/gpu/drm/i915/intel_hdmi.c:2334:
+ } else
-:62: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#62: FILE: drivers/gpu/drm/i915/intel_hdmi.c:2341:
+ hdmi_port_clock_valid(intel_hdmi, clock_bpc,
true, force_dvi) == MODE_OK) {
-:79: WARNING:LONG_LINE: line over 100 characters
#79: FILE: drivers/gpu/drm/i915/intel_hdmi.c:2342:
+ DRM_DEBUG_KMS("picking bpc to %d for HDMI
output\n",pipe_config->pipe_bpp/3);
-:79: ERROR:SPACING: space required after that ',' (ctx:VxV)
#79: FILE: drivers/gpu/drm/i915/intel_hdmi.c:2342:
+ DRM_DEBUG_KMS("picking bpc to %d for HDMI
output\n",pipe_config->pipe_bpp/3);
^
-:79: CHECK:SPACING: spaces preferred around that '/' (ctx:VxV)
#79: FILE: drivers/gpu/drm/i915/intel_hdmi.c:2342:
+ DRM_DEBUG_KMS("picking bpc to %d for HDMI
output\n",pipe_config->pipe_bpp/3);
^
total: 2 errors, 2 warnings, 4 checks, 60 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix setting 10 bit color mode
On Tue, Apr 09, 2019 at 12:58:58PM -0700, Aditya Swarup wrote:
> Currently, we cannot set 10 bit color mode in
> intel_hdmi_compute_config() because desired_bpp is always set to 12
> which makes pipe_bpp = 36.(As most platforms support 12 bit color which
> always returns true for hdmi_deep_color_possible() in the if block for
> 12 bit color)
>
> pipe_bpp value is always current and we don't need to determine the
> correct settings again using desired_bpp in intel_hdmi_compute_config().
> So, use the value of pipe_bpp to determine whether the current settings
> for color are applicable for the platform and change the port clock
> accordingly. This makes the code generic and handles each case with a
> single call to hdmi_deep_color_possible().
>
> Co-authored-by: Clint Taylor
> Signed-off-by: Aditya Swarup
> Signed-off-by: Clint Taylor
> Cc: Clint Taylor
> Cc: Ville Syrjälä
> Cc: Jani Nikula
> Cc: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_hdmi.c | 45 +++
> 1 file changed, 21 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index f2c0aba4371b..dba0ec079ba2 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -2263,7 +2263,7 @@ int intel_hdmi_compute_config(struct intel_encoder
> *encoder,
> int clock_8bpc = pipe_config->base.adjusted_mode.crtc_clock;
> int clock_10bpc = clock_8bpc * 5 / 4;
> int clock_12bpc = clock_8bpc * 3 / 2;
> - int desired_bpp;
> + int clock_bpc;
> bool force_dvi = intel_conn_state->force_audio == HDMI_AUDIO_OFF_DVI;
>
> if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
> @@ -2317,32 +2317,29 @@ int intel_hdmi_compute_config(struct intel_encoder
> *encoder,
>* Note that g4x/vlv don't support 12bpc hdmi outputs. We also need
>* to check that the higher clock still fits within limits.
>*/
> - if (hdmi_deep_color_possible(pipe_config, 12) &&
> - hdmi_port_clock_valid(intel_hdmi, clock_12bpc,
> + if(pipe_config->pipe_bpp == 36) {
> + /* Need to adjust clock by 1.5x for 12bpc. */
> + clock_bpc = clock_12bpc;
> + } else if (pipe_config->pipe_bpp == 30) {
> + /* Need to adjust clock by 1.25x for 10bpc. */
> + clock_bpc = clock_10bpc;
> + } else
> + clock_bpc = clock_8bpc;
This doesn't seem to allow graceful fallback from 12 to 10 to 8.
Did you try the oneliner I suggested?
> +
> + if (!pipe_config->bw_constrained) {
> + if (pipe_config->pipe_bpp > 24 &&
> + hdmi_deep_color_possible(pipe_config,
> pipe_config->pipe_bpp) &&
> + hdmi_port_clock_valid(intel_hdmi, clock_bpc,
> true, force_dvi) == MODE_OK) {
> - DRM_DEBUG_KMS("picking bpc to 12 for HDMI output\n");
> - desired_bpp = 12*3;
> -
> - /* Need to adjust the port link by 1.5x for 12bpc. */
> - pipe_config->port_clock = clock_12bpc;
> - } else if (hdmi_deep_color_possible(pipe_config, 10) &&
> -hdmi_port_clock_valid(intel_hdmi, clock_10bpc,
> - true, force_dvi) == MODE_OK) {
> - DRM_DEBUG_KMS("picking bpc to 10 for HDMI output\n");
> - desired_bpp = 10 * 3;
> -
> - /* Need to adjust the port link by 1.25x for 10bpc. */
> - pipe_config->port_clock = clock_10bpc;
> - } else {
> - DRM_DEBUG_KMS("picking bpc to 8 for HDMI output\n");
> - desired_bpp = 8*3;
> + DRM_DEBUG_KMS("picking bpc to %d for HDMI
> output\n",pipe_config->pipe_bpp/3);
>
> - pipe_config->port_clock = clock_8bpc;
> - }
> + pipe_config->port_clock = clock_bpc;
> + } else {
> + DRM_DEBUG_KMS("picking bpc to 8 for HDMI output\n");
> + pipe_config->pipe_bpp = 24;
>
> - if (!pipe_config->bw_constrained) {
> - DRM_DEBUG_KMS("forcing pipe bpp to %i for HDMI\n", desired_bpp);
> - pipe_config->pipe_bpp = desired_bpp;
> + pipe_config->port_clock = clock_8bpc;
> + }
> }
>
> if (hdmi_port_clock_valid(intel_hdmi, pipe_config->port_clock,
> --
> 2.17.1
--
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: Fix setting 10 bit color mode
Currently, we cannot set 10 bit color mode in
intel_hdmi_compute_config() because desired_bpp is always set to 12
which makes pipe_bpp = 36.(As most platforms support 12 bit color which
always returns true for hdmi_deep_color_possible() in the if block for
12 bit color)
pipe_bpp value is always current and we don't need to determine the
correct settings again using desired_bpp in intel_hdmi_compute_config().
So, use the value of pipe_bpp to determine whether the current settings
for color are applicable for the platform and change the port clock
accordingly. This makes the code generic and handles each case with a
single call to hdmi_deep_color_possible().
Co-authored-by: Clint Taylor
Signed-off-by: Aditya Swarup
Signed-off-by: Clint Taylor
Cc: Clint Taylor
Cc: Ville Syrjälä
Cc: Jani Nikula
Cc: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_hdmi.c | 45 +++
1 file changed, 21 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index f2c0aba4371b..dba0ec079ba2 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -2263,7 +2263,7 @@ int intel_hdmi_compute_config(struct intel_encoder
*encoder,
int clock_8bpc = pipe_config->base.adjusted_mode.crtc_clock;
int clock_10bpc = clock_8bpc * 5 / 4;
int clock_12bpc = clock_8bpc * 3 / 2;
- int desired_bpp;
+ int clock_bpc;
bool force_dvi = intel_conn_state->force_audio == HDMI_AUDIO_OFF_DVI;
if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
@@ -2317,32 +2317,29 @@ int intel_hdmi_compute_config(struct intel_encoder
*encoder,
* Note that g4x/vlv don't support 12bpc hdmi outputs. We also need
* to check that the higher clock still fits within limits.
*/
- if (hdmi_deep_color_possible(pipe_config, 12) &&
- hdmi_port_clock_valid(intel_hdmi, clock_12bpc,
+ if(pipe_config->pipe_bpp == 36) {
+ /* Need to adjust clock by 1.5x for 12bpc. */
+ clock_bpc = clock_12bpc;
+ } else if (pipe_config->pipe_bpp == 30) {
+ /* Need to adjust clock by 1.25x for 10bpc. */
+ clock_bpc = clock_10bpc;
+ } else
+ clock_bpc = clock_8bpc;
+
+ if (!pipe_config->bw_constrained) {
+ if (pipe_config->pipe_bpp > 24 &&
+ hdmi_deep_color_possible(pipe_config,
pipe_config->pipe_bpp) &&
+ hdmi_port_clock_valid(intel_hdmi, clock_bpc,
true, force_dvi) == MODE_OK) {
- DRM_DEBUG_KMS("picking bpc to 12 for HDMI output\n");
- desired_bpp = 12*3;
-
- /* Need to adjust the port link by 1.5x for 12bpc. */
- pipe_config->port_clock = clock_12bpc;
- } else if (hdmi_deep_color_possible(pipe_config, 10) &&
- hdmi_port_clock_valid(intel_hdmi, clock_10bpc,
-true, force_dvi) == MODE_OK) {
- DRM_DEBUG_KMS("picking bpc to 10 for HDMI output\n");
- desired_bpp = 10 * 3;
-
- /* Need to adjust the port link by 1.25x for 10bpc. */
- pipe_config->port_clock = clock_10bpc;
- } else {
- DRM_DEBUG_KMS("picking bpc to 8 for HDMI output\n");
- desired_bpp = 8*3;
+ DRM_DEBUG_KMS("picking bpc to %d for HDMI
output\n",pipe_config->pipe_bpp/3);
- pipe_config->port_clock = clock_8bpc;
- }
+ pipe_config->port_clock = clock_bpc;
+ } else {
+ DRM_DEBUG_KMS("picking bpc to 8 for HDMI output\n");
+ pipe_config->pipe_bpp = 24;
- if (!pipe_config->bw_constrained) {
- DRM_DEBUG_KMS("forcing pipe bpp to %i for HDMI\n", desired_bpp);
- pipe_config->pipe_bpp = desired_bpp;
+ pipe_config->port_clock = clock_8bpc;
+ }
}
if (hdmi_port_clock_valid(intel_hdmi, pipe_config->port_clock,
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/7] drm/i915/sdvo: Check that we have space for the infoframe
On Tue, Apr 09, 2019 at 08:46:42PM +0100, Chris Wilson wrote: > Quoting Ville Syrjala (2019-04-09 15:40:51) > > From: Ville Syrjälä > > > > Before we go writing the infoframe let's make sure we have > > the space for it. Not that it really matters since the write > > loop would just terminate early in that case. > > > > Signed-off-by: Ville Syrjälä > > --- > > drivers/gpu/drm/i915/intel_sdvo.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/intel_sdvo.c > > b/drivers/gpu/drm/i915/intel_sdvo.c > > index 7f64352a3413..1e0102f1710f 100644 > > --- a/drivers/gpu/drm/i915/intel_sdvo.c > > +++ b/drivers/gpu/drm/i915/intel_sdvo.c > > @@ -970,6 +970,9 @@ static bool intel_sdvo_write_infoframe(struct > > intel_sdvo *intel_sdvo, > > _size, 1)) > > return false; > > > > + if (hbuf_size < length) > > + return false; > > + > > Maybe after reporting the hbuf_size and length in the following > DRM_DEBUG_KMS? Yes, that does seem more sensible. Avoids the off by one as well. -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/7] drm/i915/sdvo: Implement proper HDMI audio support for SDVO
On Tue, Apr 09, 2019 at 05:40:49PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Our SDVO audio support is pretty bogus. We can't push audio over the
> SDVO bus, so trying to enable audio in the SDVO control register doesn't
> do anything. In fact it looks like the SDVO encoder will always mix in
> the audio coming over HDA, and there's no (at least documented) way to
> disable that from our side. So HDMI audio does work currently but only by
> luck really. What is missing though is the ELD.
Hmm. Looks like I forgot to update this text after the gen3 bug was
reported. The situation is that audio works on gen4 by luck. On gen3
it got broken by the referenced commit since we no longer enable
HDMI encoding on the SDVO device (that will stop audio transmission
entirely).
>
> To pass the ELD to the audio driver we need to write it to magic buffer
> in the SDVO encoder hardware which then gets pulled out via HDA in the
> other end. Ie. pretty much the same thing we had for native HDMI before
> we started to just pass the ELD between the drivers. This sort of
> explains why we even have that silly hardware buffer with native HDMI.
>
> $ cat /proc/asound/card0/eld#1.0
> -monitor_present 0
> -eld_valid0
> +monitor_present 1
> +eld_valid1
> +monitor_name LG TV
> +connection_type HDMI
> +...
>
> This also fixes our state readout since we can now query the SDVO
> encoder about the state of the "ELD valid" and "presence detect"
> bits. As mentioned those don't actually control whether audio
> gets sent over the HDMI cable, but it's the best we can do.
>
> Cc: sta...@vger.kernel.org
> Cc: Daniel Vetter
> Cc: zar...@gmail.com
> Tested-by: zar...@gmail.com
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108976
> Fixes: de44e256b92c ("drm/i915/sdvo: Shut up state checker with hdmi cards on
> gen3")
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_sdvo.c | 58 +-
> drivers/gpu/drm/i915/intel_sdvo_regs.h | 3 ++
> 2 files changed, 50 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
> b/drivers/gpu/drm/i915/intel_sdvo.c
> index 61db07244296..7f64352a3413 100644
> --- a/drivers/gpu/drm/i915/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> @@ -916,6 +916,13 @@ static bool intel_sdvo_set_colorimetry(struct intel_sdvo
> *intel_sdvo,
> return intel_sdvo_set_value(intel_sdvo, SDVO_CMD_SET_COLORIMETRY,
> , 1);
> }
>
> +static bool intel_sdvo_set_audio_state(struct intel_sdvo *intel_sdvo,
> +u8 audio_state)
> +{
> + return intel_sdvo_set_value(intel_sdvo, SDVO_CMD_SET_AUDIO_STAT,
> + _state, 1);
> +}
> +
> #if 0
> static void intel_sdvo_dump_hdmi_buf(struct intel_sdvo *intel_sdvo)
> {
> @@ -1487,11 +1494,6 @@ static void intel_sdvo_pre_enable(struct intel_encoder
> *intel_encoder,
> else
> sdvox |= SDVO_PIPE_SEL(crtc->pipe);
>
> - if (crtc_state->has_audio) {
> - WARN_ON_ONCE(INTEL_GEN(dev_priv) < 4);
> - sdvox |= SDVO_AUDIO_ENABLE;
> - }
> -
> if (INTEL_GEN(dev_priv) >= 4) {
> /* done in crtc_mode_set as the dpll_md reg must be written
> early */
> } else if (IS_I945G(dev_priv) || IS_I945GM(dev_priv) ||
> @@ -1635,8 +1637,13 @@ static void intel_sdvo_get_config(struct intel_encoder
> *encoder,
> if (sdvox & HDMI_COLOR_RANGE_16_235)
> pipe_config->limited_color_range = true;
>
> - if (sdvox & SDVO_AUDIO_ENABLE)
> - pipe_config->has_audio = true;
> + if (intel_sdvo_get_value(intel_sdvo, SDVO_CMD_GET_AUDIO_STAT,
> + , 1)) {
> + u8 mask = SDVO_AUDIO_ELD_VALID | SDVO_AUDIO_PRESENCE_DETECT;
> +
> + if ((val & mask) == mask)
> + pipe_config->has_audio = true;
> + }
>
> if (intel_sdvo_get_value(intel_sdvo, SDVO_CMD_GET_ENCODE,
>, 1)) {
> @@ -1647,6 +1654,32 @@ static void intel_sdvo_get_config(struct intel_encoder
> *encoder,
> intel_sdvo_get_avi_infoframe(intel_sdvo, pipe_config);
> }
>
> +static void intel_sdvo_disable_audio(struct intel_sdvo *intel_sdvo)
> +{
> + intel_sdvo_set_audio_state(intel_sdvo, 0);
> +}
> +
> +static void intel_sdvo_enable_audio(struct intel_sdvo *intel_sdvo,
> + const struct intel_crtc_state *crtc_state,
> + const struct drm_connector_state
> *conn_state)
> +{
> + const struct drm_display_mode *adjusted_mode =
> + _state->base.adjusted_mode;
> + struct drm_connector *connector = conn_state->connector;
> + u8 *eld = connector->eld;
> +
> + eld[6] = drm_av_sync_delay(connector, adjusted_mode) / 2;
> +
> + intel_sdvo_set_audio_state(intel_sdvo, 0);
> +
> + intel_sdvo_write_infoframe(intel_sdvo,
Re: [Intel-gfx] [PATCH 4/7] drm/i915/sdvo: Check that we have space for the infoframe
Quoting Ville Syrjala (2019-04-09 15:40:51) > From: Ville Syrjälä > > Before we go writing the infoframe let's make sure we have > the space for it. Not that it really matters since the write > loop would just terminate early in that case. > > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/intel_sdvo.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_sdvo.c > b/drivers/gpu/drm/i915/intel_sdvo.c > index 7f64352a3413..1e0102f1710f 100644 > --- a/drivers/gpu/drm/i915/intel_sdvo.c > +++ b/drivers/gpu/drm/i915/intel_sdvo.c > @@ -970,6 +970,9 @@ static bool intel_sdvo_write_infoframe(struct intel_sdvo > *intel_sdvo, > _size, 1)) > return false; > > + if (hbuf_size < length) > + return false; > + Maybe after reporting the hbuf_size and length in the following DRM_DEBUG_KMS? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm/i915/sdvo: Actually print the reason why the SDVO command failed
Quoting Ville Syrjala (2019-04-09 15:40:54)
> From: Ville Syrjälä
>
> It's much easier to figure out why the SDVO encoder refuses to cooperate
> if we can see what status we got back.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_sdvo.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
> b/drivers/gpu/drm/i915/intel_sdvo.c
> index d5a95eca23ba..5d928f6d0028 100644
> --- a/drivers/gpu/drm/i915/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> @@ -516,7 +516,7 @@ static bool intel_sdvo_read_response(struct intel_sdvo
> *intel_sdvo,
> u8 status;
> int i, pos = 0;
> #define BUF_LEN 256
> - char buffer[BUF_LEN];
> + char buffer[BUF_LEN] = {};
I should stop quibbling over a 256b memset.
> /*
> @@ -581,7 +581,8 @@ static bool intel_sdvo_read_response(struct intel_sdvo
> *intel_sdvo,
> return true;
>
> log_fail:
> - DRM_DEBUG_KMS("%s: R: ... failed\n", SDVO_NAME(intel_sdvo));
> + DRM_DEBUG_KMS("%s: R: ... failed %s\n",
> + SDVO_NAME(intel_sdvo), buffer);
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] colorkey support for intel i915 gpu driver
On Tue, Apr 09, 2019 at 07:15:20PM +, Jim Zhang wrote: > Ville: > > Yes, if this patch is needed by kernel 3.10.61, please get somebody to > review it. What do I need do to speed up the review process? > Please generate a patch against kernel 3.10.61 if possible. 3.10 is so ancient I don't even remember what it contains. I have a feeling it's pre-atomic, in which case there is no point in even thinking about a backport. It would simply be too painful. > > Thanks, > > Jim > > > Caterpillar: Confidential Green > > -Original Message- > From: Jim Zhang > Sent: Tuesday, April 9, 2019 10:18 AM > To: 'Ville Syrjälä' > Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org > Subject: RE: [Intel-gfx] colorkey support for intel i915 gpu driver > > If I go with pre-configured colorkey, do I need port your kernel patch to > i915 driver at kernel 3.10.61 ? > > Thanks, > > Jim > > > > Caterpillar: Confidential Green > > -Original Message- > From: Ville Syrjälä > Sent: Tuesday, April 9, 2019 10:02 AM > To: Jim Zhang > Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org > Subject: Re: [Intel-gfx] colorkey support for intel i915 gpu driver > > On Tue, Apr 09, 2019 at 02:24:03PM +, Jim Zhang wrote: > > What about if I disable interrupt when changing the colorkey? This > > will solve the atomic issue. I think we only change colorkey or > > enable/disable colorkey once a while. If disabling interrupt work, I > > will disable interrupt and change colorkey. That performance affection > > could be acceptable > > Interrupts don't matter for this. > > > > > Thanks > > > > Jim > > > > Caterpillar: Confidential Green > > > > -Original Message- > > From: Ville Syrjälä > > Sent: Tuesday, April 9, 2019 9:19 AM > > To: Jim Zhang > > Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org > > Subject: Re: [Intel-gfx] colorkey support for intel i915 gpu driver > > > > On Tue, Apr 09, 2019 at 02:14:49PM +, Jim Zhang wrote: > > > Once I pre-configure the colorkey, am I able to enable and disable it? > > > If colorkey can be enabled/disabled after that might meet my > > > requirement > > > > Not atomically with other updates. > > > > > > > > Thanks, > > > > > > Jim > > > > > > > > > Caterpillar: Confidential Green > > > > > > -Original Message- > > > From: Ville Syrjälä > > > Sent: Tuesday, April 9, 2019 8:57 AM > > > To: Jim Zhang > > > Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org > > > Subject: Re: [Intel-gfx] colorkey support for intel i915 gpu driver > > > > > > On Tue, Apr 09, 2019 at 04:46:24PM +0300, Ville Syrjälä wrote: > > > > On Tue, Apr 09, 2019 at 01:29:41PM +, Jim Zhang wrote: > > > > > Villie: > > > > > > > > > > What is Intel's plan for the colorkey patch? Does Intel have any > > > > > plan to review and release? > > > > > > > > There is no real plan at this time. But if you have a use case for > > > > it I can try to harass people until someone reviews it :) > > > > > > > > > If I go with custom ioctl, and my custom ioctl will only used in > > > > > Baytrail product, could it be atomic for Baytrail only? > > > > > > > > No. We would need to define a new api for it. > > > > > > I should clarify that you can pre-configure the colorkey before turning > > > on the sprite plane(s). So unless you really need to change the colorkey > > > while the sprite plane(s) are already enabled you may not even need an > > > atomic api for this. > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > Jim > > > > > > > > > > > > > > > Caterpillar: Confidential Green > > > > > > > > > > -Original Message- > > > > > From: Ville Syrjälä > > > > > Sent: Tuesday, April 2, 2019 7:32 AM > > > > > To: Jim Zhang > > > > > Cc: dri-de...@lists.freedesktop.org; > > > > > intel-gfx@lists.freedesktop.org > > > > > Subject: Re: colorkey support for intel i915 gpu driver > > > > > > > > > > On Mon, Apr 01, 2019 at 08:18:13PM +, Jim Zhang wrote: > > > > > > Hi Sir/Madam: > > > > > > > > > > > > I am using the open source Baytrail gpu drm driver. > > > > > > > > > > > > Linux kernel version 3.10.61: > > > > > > Libdrm package: 2.4.97 > > > > > > > > > > > > When calling function > > > > > > properties = drmModeObjectGetProperties(drmfd, plane_id, > > > > > > DRM_MODE_OBJECT_PLANE); it only returns only one property: > > > > > > > > > > > > This property is: > > > > > > property->name = "rotation", property->prop_id =4 It looks > > > > > > like that the Baytrail gpu drm driver does not support colorkey. > > > > > > > > > > There are two problems currently: > > > > > - Destination colorkey is not implemented on BYT/CHV. I have > > > > > patches for it but they have not been reviewed by anyone: > > > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.f > > > > > re > > > > > ed > > > > >
Re: [Intel-gfx] [PATCH 6/7] drm/i915/sdvo: Don't write stack garbage into the hbuf
Quoting Ville Syrjala (2019-04-09 15:40:53) > From: Ville Syrjälä > > Pass the length returned by hdmi_infoframe_pack_only() to > intel_sdvo_write_infoframe() so that we don't end up writing > stack garbage into the hbuf. > > Signed-off-by: Ville Syrjälä Ok, write_infoframe 0 extends if len is too short. Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/7] drm/i915/sdvo: Don't unpack stack garbage
Quoting Ville Syrjala (2019-04-09 15:40:52) > From: Ville Syrjälä > > Pass the length returned by intel_sdvo_read_infoframe() to > hdmi_infoframe_unpack() so that we don't try to unpack any > leftover stack garbage. > > Signed-off-by: Ville Syrjälä Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Avoiding reclaim tainting from runtime-pm debug
== Series Details == Series: drm/i915: Avoiding reclaim tainting from runtime-pm debug URL : https://patchwork.freedesktop.org/series/59242/ State : success == Summary == CI Bug Log - changes from CI_DRM_5897 -> Patchwork_12744 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/59242/revisions/1/mbox/ Known issues Here are the changes found in Patchwork_12744 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@sync-fork-compute0: - fi-icl-u3: NOTRUN -> SKIP [fdo#109315] +17 * igt@gem_exec_basic@gtt-bsd1: - fi-icl-u3: NOTRUN -> SKIP [fdo#109276] +7 * igt@gem_exec_parse@basic-rejected: - fi-icl-u3: NOTRUN -> SKIP [fdo#109289] +1 * igt@i915_pm_rpm@module-reload: - fi-skl-6770hq: PASS -> FAIL [fdo#108511] * igt@i915_selftest@live_contexts: - fi-icl-u3: NOTRUN -> DMESG-FAIL [fdo#108569] * igt@kms_busy@basic-flip-a: - fi-bsw-n3050: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +1 * igt@kms_busy@basic-flip-c: - fi-blb-e6850: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] * igt@kms_chamelium@hdmi-crc-fast: - fi-bsw-n3050: NOTRUN -> SKIP [fdo#109271] +62 * igt@kms_chamelium@hdmi-edid-read: - fi-icl-u3: NOTRUN -> SKIP [fdo#109284] +8 * igt@kms_force_connector_basic@prune-stale-modes: - fi-icl-u3: NOTRUN -> SKIP [fdo#109285] +3 * igt@kms_frontbuffer_tracking@basic: - fi-icl-u3: NOTRUN -> FAIL [fdo#103167] * igt@kms_pipe_crc_basic@hang-read-crc-pipe-c: - fi-blb-e6850: NOTRUN -> SKIP [fdo#109271] +48 * igt@runner@aborted: - fi-glk-dsi: NOTRUN -> FAIL [k.org#202321] Possible fixes * igt@gem_ctx_exec@basic: - fi-icl-u3: INCOMPLETE [fdo#107713] -> PASS * igt@gem_exec_suspend@basic-s4-devices: - fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS * igt@i915_selftest@live_contexts: - fi-skl-gvtdvm: DMESG-FAIL [fdo#110235 ] -> PASS Warnings * igt@i915_pm_rpm@module-reload: - fi-glk-dsi: INCOMPLETE [fdo#103359] / [k.org#198133] -> DMESG-WARN [fdo#105538] / [fdo#107732] / [fdo#109513] [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359 [fdo#105538]: https://bugs.freedesktop.org/show_bug.cgi?id=105538 [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#107732]: https://bugs.freedesktop.org/show_bug.cgi?id=107732 [fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511 [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276 [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278 [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284 [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285 [fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289 [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315 [fdo#109513]: https://bugs.freedesktop.org/show_bug.cgi?id=109513 [fdo#110235 ]: https://bugs.freedesktop.org/show_bug.cgi?id=110235 [k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133 [k.org#202321]: https://bugzilla.kernel.org/show_bug.cgi?id=202321 Participating hosts (44 -> 40) -- Additional (1): fi-bsw-n3050 Missing(5): fi-byt-squawks fi-bsw-cyan fi-apl-guc fi-icl-y fi-bdw-samus Build changes - * Linux: CI_DRM_5897 -> Patchwork_12744 CI_DRM_5897: 7d07e025e78603d6270bc115fdb6c1efea6e66a5 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4934: dc4f45eb6874331daec870dc1e4cfc3ac5c49311 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12744: 8a7f63e2f75d2923a70f5e2f4e4734013e60a68a @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 8a7f63e2f75d drm/i915: Avoiding reclaim tainting from runtime-pm debug == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12744/ ___ 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: Avoiding reclaim tainting from runtime-pm debug
== Series Details ==
Series: drm/i915: Avoiding reclaim tainting from runtime-pm debug
URL : https://patchwork.freedesktop.org/series/59242/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
8a7f63e2f75d drm/i915: Avoiding reclaim tainting from runtime-pm debug
-:15: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#15:
<4> [435.339456] 4505c39b (wakeref#3){+.+.}, at:
intel_engine_pm_put+0x1b/0x40 [i915]
total: 0 errors, 1 warnings, 0 checks, 26 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: add immutable zpos plane properties
Hi Jani,
git blame says you are familiar with intel_primary_plane_create! Would
you have some time to review this patch?
Thanks!
--
Simon Ser
https://emersion.fr
> From: Ville Syrjälä
>
> This adds basic immutable support for the zpos property. The zpos increases
> from bottom to top: primary, sprites, cursor.
>
> Signed-off-by: Ville Syrjälä
> [cont...@emersion.fr: adapted for latest drm-tip]
> Signed-off-by: Simon Ser
> ---
>
> Changes in v2: set correct author and S-o-b tags
>
> drivers/gpu/drm/i915/intel_display.c | 10 --
> drivers/gpu/drm/i915/intel_sprite.c | 5 -
> 2 files changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 8576a7f799..f0a85a75bd 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14323,7 +14323,7 @@ intel_primary_plane_create(struct drm_i915_private
> *dev_priv, enum pipe pipe)
> const u64 *modifiers;
> const u32 *formats;
> int num_formats;
> - int ret;
> + int ret, zpos;
>
> if (INTEL_GEN(dev_priv) >= 9)
> return skl_universal_plane_create(dev_priv, pipe,
> @@ -14412,6 +14412,9 @@ intel_primary_plane_create(struct drm_i915_private
> *dev_priv, enum pipe pipe)
> DRM_MODE_ROTATE_0,
> supported_rotations);
>
> + zpos = 0;
> + drm_plane_create_zpos_immutable_property(>base, zpos);
> +
> drm_plane_helper_add(>base, _plane_helper_funcs);
>
> return plane;
> @@ -14428,7 +14431,7 @@ intel_cursor_plane_create(struct drm_i915_private
> *dev_priv,
> {
> unsigned int possible_crtcs;
> struct intel_plane *cursor;
> - int ret;
> + int ret, zpos;
>
> cursor = intel_plane_alloc();
> if (IS_ERR(cursor))
> @@ -14477,6 +14480,9 @@ intel_cursor_plane_create(struct drm_i915_private
> *dev_priv,
> DRM_MODE_ROTATE_0 |
> DRM_MODE_ROTATE_180);
>
> + zpos = RUNTIME_INFO(dev_priv)->num_sprites[pipe] + 1;
> + drm_plane_create_zpos_immutable_property(>base, zpos);
> +
> drm_plane_helper_add(>base, _plane_helper_funcs);
>
> return cursor;
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> b/drivers/gpu/drm/i915/intel_sprite.c
> index 65de7387bf..48bd8f9079 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -2354,7 +2354,7 @@ intel_sprite_plane_create(struct drm_i915_private
> *dev_priv,
> const u64 *modifiers;
> const u32 *formats;
> int num_formats;
> - int ret;
> + int ret, zpos;
>
> if (INTEL_GEN(dev_priv) >= 9)
> return skl_universal_plane_create(dev_priv, pipe,
> @@ -2444,6 +2444,9 @@ intel_sprite_plane_create(struct drm_i915_private
> *dev_priv,
> DRM_COLOR_YCBCR_BT709,
> DRM_COLOR_YCBCR_LIMITED_RANGE);
>
> + zpos = sprite + 1;
> + drm_plane_create_zpos_immutable_property(>base, zpos);
> +
> drm_plane_helper_add(>base, _plane_helper_funcs);
>
> return plane;
> --
> 2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Add HDR Metadata Parsing and handling in DRM layer (rev8)
== Series Details == Series: Add HDR Metadata Parsing and handling in DRM layer (rev8) URL : https://patchwork.freedesktop.org/series/25091/ State : success == Summary == CI Bug Log - changes from CI_DRM_5897 -> Patchwork_12743 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/25091/revisions/8/mbox/ Known issues Here are the changes found in Patchwork_12743 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@sync-fork-compute0: - fi-icl-u3: NOTRUN -> SKIP [fdo#109315] +17 * igt@gem_exec_basic@gtt-bsd1: - fi-icl-u3: NOTRUN -> SKIP [fdo#109276] +7 * igt@gem_exec_parse@basic-rejected: - fi-icl-u3: NOTRUN -> SKIP [fdo#109289] +1 * igt@gem_exec_store@basic-bsd1: - fi-kbl-r: NOTRUN -> SKIP [fdo#109271] +41 * 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] / [fdo#109720] * igt@kms_busy@basic-flip-a: - fi-bsw-n3050: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +1 * igt@kms_busy@basic-flip-c: - fi-blb-e6850: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] - fi-byt-j1900: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] * igt@kms_chamelium@hdmi-crc-fast: - fi-bsw-n3050: NOTRUN -> SKIP [fdo#109271] +62 - fi-byt-j1900: NOTRUN -> SKIP [fdo#109271] +52 * igt@kms_chamelium@hdmi-edid-read: - fi-icl-u3: NOTRUN -> SKIP [fdo#109284] +8 * igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size: - fi-glk-dsi: PASS -> INCOMPLETE [fdo#103359] / [k.org#198133] * igt@kms_force_connector_basic@prune-stale-modes: - fi-icl-u3: NOTRUN -> SKIP [fdo#109285] +3 * igt@kms_frontbuffer_tracking@basic: - fi-icl-u3: NOTRUN -> FAIL [fdo#103167] * igt@kms_pipe_crc_basic@hang-read-crc-pipe-c: - fi-blb-e6850: NOTRUN -> SKIP [fdo#109271] +48 * igt@runner@aborted: - fi-apl-guc: NOTRUN -> FAIL [fdo#108622] / [fdo#109720] Possible fixes * igt@gem_ctx_exec@basic: - fi-icl-u3: INCOMPLETE [fdo#107713] -> PASS * igt@gem_exec_suspend@basic-s4-devices: - fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS * igt@i915_selftest@live_contexts: - fi-bdw-gvtdvm: DMESG-FAIL [fdo#110235 ] -> PASS - fi-skl-gvtdvm: DMESG-FAIL [fdo#110235 ] -> PASS [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359 [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569 [fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276 [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278 [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284 [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285 [fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289 [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315 [fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720 [fdo#110235 ]: https://bugs.freedesktop.org/show_bug.cgi?id=110235 [k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133 Participating hosts (44 -> 43) -- Additional (3): fi-byt-j1900 fi-kbl-r fi-bsw-n3050 Missing(4): fi-bsw-cyan fi-byt-squawks fi-icl-dsi fi-bdw-samus Build changes - * Linux: CI_DRM_5897 -> Patchwork_12743 CI_DRM_5897: 7d07e025e78603d6270bc115fdb6c1efea6e66a5 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4934: dc4f45eb6874331daec870dc1e4cfc3ac5c49311 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12743: d3c9dc75502d87094374ac0b5173c0df2e17d31b @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == d3c9dc75502d drm/i915: Added DRM Infoframe handling for BYT/CHT 969c71e2025d drm/i915: Set Infoframe for non modeset case for HDR 1350e7754205 drm/i915:Enabled Modeset when HDR Infoframe changes a0b33e2a5181 drm/i915: Enable infoframes on GLK+ for HDR ca7165d040c9 drm/i915: Add HLG EOTF a48b441df6b7 drm/i915: Write HDR infoframe and send to panel 40ad900cccee drm/i915: Attach HDR metadata property to connector 93c6dce2ad71 drm: Enable HDR infoframe support ef782728fcdc drm: Parse HDR metadata info from EDID 6f71d6db5493 drm: Add HDR source metadata property == Logs == For more details see:
Re: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for IRQ initialization debloat and conversion to uncore
On Tue, Apr 09, 2019 at 10:34:22AM -0700, Paulo Zanoni wrote: > Em ter, 2019-04-09 às 00:44 +, Patchwork escreveu: > > == Series Details == > > > > Series: IRQ initialization debloat and conversion to uncore > > URL : https://patchwork.freedesktop.org/series/59202/ > > State : warning > > > > == Summary == > > > > $ dim checkpatch origin/drm-tip > > 7f73d1fe31bb drm/i915: refactor the IRQ init/reset macros > > -:114: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'which' - possible > > side-effects? > > #114: FILE: drivers/gpu/drm/i915/i915_irq.c:169: > > +#define GEN8_IRQ_RESET_NDX(type, which) \ > > + gen3_irq_reset(dev_priv, GEN8_##type##_IMR(which), \ > > + GEN8_##type##_IIR(which), GEN8_##type##_IER(which)) > > > > -:172: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'which' - possible > > side-effects? > > #172: FILE: drivers/gpu/drm/i915/i915_irq.c:236: > > +#define GEN8_IRQ_INIT_NDX(type, which, imr_val, ier_val) \ > > + gen3_irq_init(dev_priv, GEN8_##type##_IMR(which), \ > > + GEN8_##type##_IIR(which), GEN8_##type##_IER(which), \ > > + imr_val, ier_val) > > > > total: 0 errors, 0 warnings, 2 checks, 135 lines checked > > 82160241d80f drm/i915: convert the IRQ initialization functions to > > intel_uncore > > 8c1c76059a41 drm/i915: fully convert the IRQ initialization macros to > > intel_uncore > > -:24: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'which' - possible > > side-effects? > > #24: FILE: drivers/gpu/drm/i915/i915_irq.c:169: > > +#define GEN8_IRQ_RESET_NDX(uncore, type, which) \ > > + gen3_irq_reset((uncore), GEN8_##type##_IMR(which), \ > >GEN8_##type##_IIR(which), GEN8_##type##_IER(which)) > > > > -:46: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'which' - possible > > side-effects? > > #46: FILE: drivers/gpu/drm/i915/i915_irq.c:236: > > +#define GEN8_IRQ_INIT_NDX(uncore, type, which, imr_val, ier_val) \ > > + gen3_irq_init((uncore), GEN8_##type##_IMR(which), \ > > GEN8_##type##_IIR(which), GEN8_##type##_IER(which), \ > > imr_val, ier_val) > > The whiches are not really a regression, but OK we can deal with them > to make the robots happy. > > > > > -:401: ERROR:SPACING: space prohibited before that close parenthesis ')' > > #401: FILE: drivers/gpu/drm/i915/i915_irq.c:4228: > > + GEN2_IRQ_RESET(uncore, ); > > > > -:416: ERROR:SPACING: space prohibited before that ',' (ctx:WxW) > > #416: FILE: drivers/gpu/drm/i915/i915_irq.c:4252: > > + GEN2_IRQ_INIT(uncore, , dev_priv->irq_mask, enable_mask); > > ^ > > > > -:433: ERROR:SPACING: space prohibited before that close parenthesis ')' > > #433: FILE: drivers/gpu/drm/i915/i915_irq.c:4397: > > + GEN3_IRQ_RESET(uncore, ); > > > > -:448: ERROR:SPACING: space prohibited before that ',' (ctx:WxW) > > #448: FILE: drivers/gpu/drm/i915/i915_irq.c:4430: > > + GEN3_IRQ_INIT(uncore, , dev_priv->irq_mask, enable_mask); > > ^ > > > > -:464: ERROR:SPACING: space prohibited before that close parenthesis ')' > > #464: FILE: drivers/gpu/drm/i915/i915_irq.c:4508: > > + GEN3_IRQ_RESET(uncore, ); > > > > -:479: ERROR:SPACING: space prohibited before that ',' (ctx:WxW) > > #479: FILE: drivers/gpu/drm/i915/i915_irq.c:4552: > > + GEN3_IRQ_INIT(uncore, , dev_priv->irq_mask, enable_mask); > > For these ones I really think the spaces help. I would love to read > some opinions. Perhaps some comment like /* paste token here */ would > help make the code more readable and could help silence checkpatch. > Opinions? Or maybe rename the registers to eg. I9XX_IIR? > > > ^ > > > > total: 6 errors, 0 warnings, 2 checks, 432 lines checked > > > > ___ > > 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 -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: refactor the IRQ init/reset macros
On Mon, Apr 08, 2019 at 05:37:27PM -0700, Paulo Zanoni wrote:
> The whole point of having macros here is for the token pasting
> necessary to automatically have IMR, IIR and IER selected. We don't
> really need or want all the inlining that happens as a consequence.
> The good thing about the current code is that it works regardless of
> the relative offsets between these registers (they change after gen3).
Did you mean "after gen4"? The DE/GT split happened at ilk, and I
guess that's when the four registers also got reshuffled for some
reason. Ignoring the funkyness of vlv/chv or course :)
>
> One thing which we can do is to split the logic of what we do with
> imr/ier/iir to functions separate from the macros that pick them.
> That's what we do in this commit. This allows us to get rid of the
> gen8 duplicates and also all the inlining:
>
> add/remove: 2/0 grow/shrink: 0/21 up/down: 383/-6006 (-5623)
> Function old new delta
> gen3_irq_reset - 233+233
> gen3_irq_init - 150+150
> i8xx_irq_postinstall 459 442 -17
> gen11_irq_postinstall804 744 -60
> ironlake_irq_postinstall 450 353 -97
> vlv_display_irq_postinstall 348 245-103
> i965_irq_postinstall 378 275-103
> i915_irq_postinstall 333 228-105
> gen8_irq_power_well_post_enable 374 210-164
> ironlake_irq_reset 397 218-179
> vlv_display_irq_reset616 433-183
> i965_irq_reset 374 180-194
> cherryview_irq_reset 379 185-194
> i915_irq_reset 407 209-198
> ibx_irq_reset332 133-199
> gen5_gt_irq_postinstall 533 332-201
> gen8_irq_power_well_pre_disable 434 204-230
> gen8_gt_irq_postinstall 469 196-273
> gen8_de_irq_postinstall 1200 805-395
> gen5_gt_irq_reset471 76-395
> gen8_gt_irq_reset775 99-676
> gen8_irq_reset 1100 333-767
> gen11_irq_reset 1959 686 -1273
> Total: Before=2262051, After=2256428, chg -0.25%
>
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_irq.c | 123 +++-
> 1 file changed, 73 insertions(+), 50 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 6454ddc37f8b..a1e7944fb5d0 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -136,36 +136,45 @@ static const u32 hpd_icp[HPD_NUM_PINS] = {
> [HPD_PORT_F] = SDE_TC4_HOTPLUG_ICP
> };
>
> -/* IIR can theoretically queue up two events. Be paranoid. */
> -#define GEN8_IRQ_RESET_NDX(type, which) do { \
> - I915_WRITE(GEN8_##type##_IMR(which), 0x); \
> - POSTING_READ(GEN8_##type##_IMR(which)); \
> - I915_WRITE(GEN8_##type##_IER(which), 0); \
> - I915_WRITE(GEN8_##type##_IIR(which), 0x); \
> - POSTING_READ(GEN8_##type##_IIR(which)); \
> - I915_WRITE(GEN8_##type##_IIR(which), 0x); \
> - POSTING_READ(GEN8_##type##_IIR(which)); \
> -} while (0)
> -
> -#define GEN3_IRQ_RESET(type) do { \
> - I915_WRITE(type##IMR, 0x); \
> - POSTING_READ(type##IMR); \
> - I915_WRITE(type##IER, 0); \
> - I915_WRITE(type##IIR, 0x); \
> - POSTING_READ(type##IIR); \
> - I915_WRITE(type##IIR, 0x); \
> - POSTING_READ(type##IIR); \
> -} while (0)
> -
> -#define GEN2_IRQ_RESET(type) do { \
> - I915_WRITE16(type##IMR, 0x); \
> - POSTING_READ16(type##IMR); \
> - I915_WRITE16(type##IER, 0); \
> - I915_WRITE16(type##IIR, 0x); \
> - POSTING_READ16(type##IIR); \
> - I915_WRITE16(type##IIR, 0x); \
> - POSTING_READ16(type##IIR); \
> -} while (0)
> +static void gen3_irq_reset(struct drm_i915_private *dev_priv, i915_reg_t imr,
> +i915_reg_t iir, i915_reg_t ier)
> +{
> + I915_WRITE(imr, 0x);
> + POSTING_READ(imr);
> +
> + I915_WRITE(ier, 0);
> +
> + /* IIR can theoretically queue up two events. Be paranoid. */
> + I915_WRITE(iir, 0x);
> + POSTING_READ(iir);
> + I915_WRITE(iir, 0x);
> + POSTING_READ(iir);
> +}
> +
> +static void gen2_irq_reset(struct drm_i915_private *dev_priv, i915_reg_t imr,
> +i915_reg_t iir, i915_reg_t ier)
> +{
> + I915_WRITE16(imr, 0x);
> + POSTING_READ16(imr);
> +
> + I915_WRITE16(ier, 0);
> +
> + /* IIR can theoretically queue up two
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add HDR Metadata Parsing and handling in DRM layer (rev8)
== Series Details == Series: Add HDR Metadata Parsing and handling in DRM layer (rev8) URL : https://patchwork.freedesktop.org/series/25091/ State : warning == Summary == $ dim checkpatch origin/drm-tip 6f71d6db5493 drm: Add HDR source metadata property -:67: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #67: FILE: drivers/gpu/drm/drm_atomic_uapi.c:728: + ret = drm_atomic_replace_property_blob_from_id(dev, + >hdr_output_metadata_blob_ptr, total: 0 errors, 0 warnings, 1 checks, 147 lines checked ef782728fcdc drm: Parse HDR metadata info from EDID 93c6dce2ad71 drm: Enable HDR infoframe support 40ad900cccee drm/i915: Attach HDR metadata property to connector a48b441df6b7 drm/i915: Write HDR infoframe and send to panel ca7165d040c9 drm/i915: Add HLG EOTF a0b33e2a5181 drm/i915: Enable infoframes on GLK+ for HDR -:54: WARNING:LONG_LINE: line over 100 characters #54: FILE: drivers/gpu/drm/i915/i915_reg.h:8187: +#define GLK_TVIDEO_DIP_DRM_DATA(trans, i) _MMIO_TRANS2(trans, _GLK_VIDEO_DIP_DRM_DATA_A + (i) * 4) total: 0 errors, 1 warnings, 0 checks, 81 lines checked 1350e7754205 drm/i915:Enabled Modeset when HDR Infoframe changes 969c71e2025d drm/i915: Set Infoframe for non modeset case for HDR d3c9dc75502d drm/i915: Added DRM Infoframe handling for BYT/CHT ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/7] drm/i915: Use dedicated rc6 enabling sequence for gen11
== Series Details == Series: series starting with [1/7] drm/i915: Use dedicated rc6 enabling sequence for gen11 URL : https://patchwork.freedesktop.org/series/59237/ State : success == Summary == CI Bug Log - changes from CI_DRM_5897 -> Patchwork_12742 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/59237/revisions/1/mbox/ Known issues Here are the changes found in Patchwork_12742 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@sync-fork-compute0: - fi-icl-u3: NOTRUN -> SKIP [fdo#109315] +17 * igt@gem_exec_basic@gtt-bsd1: - fi-icl-u3: NOTRUN -> SKIP [fdo#109276] +7 * igt@gem_exec_parse@basic-rejected: - fi-icl-u3: NOTRUN -> SKIP [fdo#109289] +1 * igt@gem_exec_store@basic-bsd1: - fi-kbl-r: NOTRUN -> SKIP [fdo#109271] +41 * igt@gem_mmap_gtt@basic-copy: - fi-icl-y: PASS -> DMESG-WARN [fdo#109638] * 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] / [fdo#109720] * igt@i915_selftest@live_hangcheck: - fi-bxt-dsi: PASS -> INCOMPLETE [fdo#103927] - fi-icl-y: PASS -> INCOMPLETE [fdo#108569] * igt@kms_busy@basic-flip-a: - fi-bsw-n3050: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +1 * igt@kms_busy@basic-flip-c: - fi-blb-e6850: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] - fi-byt-j1900: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] * igt@kms_chamelium@hdmi-crc-fast: - fi-bsw-n3050: NOTRUN -> SKIP [fdo#109271] +62 - fi-byt-j1900: NOTRUN -> SKIP [fdo#109271] +52 * igt@kms_chamelium@hdmi-edid-read: - fi-icl-u3: NOTRUN -> SKIP [fdo#109284] +8 * igt@kms_force_connector_basic@prune-stale-modes: - fi-icl-u3: NOTRUN -> SKIP [fdo#109285] +3 * igt@kms_frontbuffer_tracking@basic: - fi-icl-u3: NOTRUN -> FAIL [fdo#103167] * igt@kms_pipe_crc_basic@hang-read-crc-pipe-c: - fi-blb-e6850: NOTRUN -> SKIP [fdo#109271] +48 * igt@runner@aborted: - fi-glk-dsi: NOTRUN -> FAIL [k.org#202321] - fi-apl-guc: NOTRUN -> FAIL [fdo#108622] / [fdo#109720] Possible fixes * igt@gem_ctx_exec@basic: - fi-icl-u3: INCOMPLETE [fdo#107713] -> PASS * igt@gem_exec_suspend@basic-s4-devices: - fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS * igt@i915_selftest@live_contexts: - fi-skl-gvtdvm: DMESG-FAIL [fdo#110235 ] -> PASS Warnings * igt@i915_pm_rpm@module-reload: - fi-glk-dsi: INCOMPLETE [fdo#103359] / [k.org#198133] -> DMESG-WARN [fdo#105538] / [fdo#107732] / [fdo#109513] [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359 [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#105538]: https://bugs.freedesktop.org/show_bug.cgi?id=105538 [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#107732]: https://bugs.freedesktop.org/show_bug.cgi?id=107732 [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569 [fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276 [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278 [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284 [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285 [fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289 [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315 [fdo#109513]: https://bugs.freedesktop.org/show_bug.cgi?id=109513 [fdo#109638]: https://bugs.freedesktop.org/show_bug.cgi?id=109638 [fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720 [fdo#110235 ]: https://bugs.freedesktop.org/show_bug.cgi?id=110235 [k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133 [k.org#202321]: https://bugzilla.kernel.org/show_bug.cgi?id=202321 Participating hosts (44 -> 43) -- Additional (3): fi-byt-j1900 fi-kbl-r fi-bsw-n3050 Missing(4): fi-hsw-peppy fi-byt-squawks fi-bsw-cyan fi-bdw-samus Build changes - * Linux: CI_DRM_5897 -> Patchwork_12742 CI_DRM_5897: 7d07e025e78603d6270bc115fdb6c1efea6e66a5 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4934: dc4f45eb6874331daec870dc1e4cfc3ac5c49311 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12742: 92c211e3d49dcaed6a8394855321a33a5007f930 @
[Intel-gfx] [PATCH] drm/i915: Avoiding reclaim tainting from runtime-pm debug
As intel_runtime_pm_get/_put may be called from any blockable context,
we need to avoid allowing reclaim from our mallocs, as we need to
avoid tainting any mutexes held by the callers (as they may themselves
not allow for allocations as they are taken in the shrinker).
<4> [435.339331] WARNING: possible circular locking dependency detected
<4> [435.339364] 5.1.0-rc4-CI-Trybot_4116+ #1 Tainted: G U
<4> [435.339395] --
<4> [435.339426] gem_caching/1334 is trying to acquire lock:
<4> [435.339456] 4505c39b (wakeref#3){+.+.}, at:
intel_engine_pm_put+0x1b/0x40 [i915]
<4> [435.339788]
but task is already holding lock:
<4> [435.339819] ee77b4ed (fs_reclaim){+.+.}, at:
fs_reclaim_acquire.part.24+0x0/0x30
<4> [435.339879]
which lock already depends on the new lock.
<4> [435.339918]
the existing dependency chain (in reverse order) is:
<4> [435.339952]
-> #1 (fs_reclaim){+.+.}:
<4> [435.339998]fs_reclaim_acquire.part.24+0x24/0x30
<4> [435.340035]kmem_cache_alloc_trace+0x2a/0x290
<4> [435.340311]__print_intel_runtime_pm_wakeref+0x24/0x160 [i915]
<4> [435.340590]untrack_intel_runtime_pm_wakeref+0x16e/0x1d0 [i915]
<4> [435.340869]intel_runtime_pm_put_unchecked+0xd/0x30 [i915]
<4> [435.341147]__intel_wakeref_put_once+0x22/0x40 [i915]
<4> [435.341508]i915_request_retire+0x477/0xaf0 [i915]
<4> [435.341871]ring_retire_requests+0x86/0x160 [i915]
<4> [435.342226]i915_retire_requests+0x58/0xc0 [i915]
<4> [435.342576]retire_work_handler+0x5b/0x70 [i915]
<4> [435.342615]process_one_work+0x245/0x610
<4> [435.342646]worker_thread+0x37/0x380
<4> [435.342679]kthread+0x119/0x130
<4> [435.342714]ret_from_fork+0x3a/0x50
<4> [435.342739]
-> #0 (wakeref#3){+.+.}:
<4> [435.342788]lock_acquire+0xa6/0x1c0
<4> [435.342822]__mutex_lock+0x8c/0x960
<4> [435.342853]atomic_dec_and_mutex_lock+0x33/0x50
<4> [435.343151]intel_engine_pm_put+0x1b/0x40 [i915]
<4> [435.343501]i915_request_retire+0x477/0xaf0 [i915]
<4> [435.343851]ring_retire_requests+0x86/0x160 [i915]
<4> [435.344202]i915_retire_requests+0x58/0xc0 [i915]
<4> [435.344543]i915_gem_shrink+0xd8/0x5b0 [i915]
<4> [435.344835]i915_drop_caches_set+0x17b/0x250 [i915]
<4> [435.344877]simple_attr_write+0xb0/0xd0
<4> [435.344911]full_proxy_write+0x51/0x80
<4> [435.344943]vfs_write+0xbd/0x1b0
<4> [435.344972]ksys_write+0x55/0xe0
<4> [435.345002]do_syscall_64+0x55/0x190
<4> [435.345040]entry_SYSCALL_64_after_hwframe+0x49/0xbe
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index e6d1e592225b..3107a742d8ad 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -162,7 +162,7 @@ static void cancel_intel_runtime_pm_wakeref(struct
drm_i915_private *i915,
rpm->debug.count, atomic_read(>wakeref_count))) {
char *buf;
- buf = kmalloc(PAGE_SIZE, GFP_KERNEL);
+ buf = kmalloc(PAGE_SIZE, GFP_NOWAIT | __GFP_NOWARN);
if (!buf)
return;
@@ -198,7 +198,7 @@ __print_intel_runtime_pm_wakeref(struct drm_printer *p,
unsigned long i;
char *buf;
- buf = kmalloc(PAGE_SIZE, GFP_KERNEL);
+ buf = kmalloc(PAGE_SIZE, GFP_NOWAIT | __GFP_NOWARN);
if (!buf)
return;
@@ -282,7 +282,9 @@ void print_intel_runtime_pm_wakeref(struct drm_i915_private
*i915,
if (dbg.count <= alloc)
break;
- s = krealloc(dbg.owners, dbg.count * sizeof(*s), GFP_KERNEL);
+ s = krealloc(dbg.owners,
+dbg.count * sizeof(*s),
+GFP_NOWAIT | __GFP_NOWARN);
if (!s)
goto out;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for IRQ initialization debloat and conversion to uncore
Em ter, 2019-04-09 às 00:44 +, Patchwork escreveu: > == Series Details == > > Series: IRQ initialization debloat and conversion to uncore > URL : https://patchwork.freedesktop.org/series/59202/ > State : warning > > == Summary == > > $ dim checkpatch origin/drm-tip > 7f73d1fe31bb drm/i915: refactor the IRQ init/reset macros > -:114: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'which' - possible > side-effects? > #114: FILE: drivers/gpu/drm/i915/i915_irq.c:169: > +#define GEN8_IRQ_RESET_NDX(type, which) \ > + gen3_irq_reset(dev_priv, GEN8_##type##_IMR(which), \ > +GEN8_##type##_IIR(which), GEN8_##type##_IER(which)) > > -:172: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'which' - possible > side-effects? > #172: FILE: drivers/gpu/drm/i915/i915_irq.c:236: > +#define GEN8_IRQ_INIT_NDX(type, which, imr_val, ier_val) \ > + gen3_irq_init(dev_priv, GEN8_##type##_IMR(which), \ > + GEN8_##type##_IIR(which), GEN8_##type##_IER(which), \ > + imr_val, ier_val) > > total: 0 errors, 0 warnings, 2 checks, 135 lines checked > 82160241d80f drm/i915: convert the IRQ initialization functions to > intel_uncore > 8c1c76059a41 drm/i915: fully convert the IRQ initialization macros to > intel_uncore > -:24: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'which' - possible > side-effects? > #24: FILE: drivers/gpu/drm/i915/i915_irq.c:169: > +#define GEN8_IRQ_RESET_NDX(uncore, type, which) \ > + gen3_irq_reset((uncore), GEN8_##type##_IMR(which), \ > GEN8_##type##_IIR(which), GEN8_##type##_IER(which)) > > -:46: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'which' - possible > side-effects? > #46: FILE: drivers/gpu/drm/i915/i915_irq.c:236: > +#define GEN8_IRQ_INIT_NDX(uncore, type, which, imr_val, ier_val) \ > + gen3_irq_init((uncore), GEN8_##type##_IMR(which), \ > GEN8_##type##_IIR(which), GEN8_##type##_IER(which), \ > imr_val, ier_val) The whiches are not really a regression, but OK we can deal with them to make the robots happy. > > -:401: ERROR:SPACING: space prohibited before that close parenthesis ')' > #401: FILE: drivers/gpu/drm/i915/i915_irq.c:4228: > + GEN2_IRQ_RESET(uncore, ); > > -:416: ERROR:SPACING: space prohibited before that ',' (ctx:WxW) > #416: FILE: drivers/gpu/drm/i915/i915_irq.c:4252: > + GEN2_IRQ_INIT(uncore, , dev_priv->irq_mask, enable_mask); > ^ > > -:433: ERROR:SPACING: space prohibited before that close parenthesis ')' > #433: FILE: drivers/gpu/drm/i915/i915_irq.c:4397: > + GEN3_IRQ_RESET(uncore, ); > > -:448: ERROR:SPACING: space prohibited before that ',' (ctx:WxW) > #448: FILE: drivers/gpu/drm/i915/i915_irq.c:4430: > + GEN3_IRQ_INIT(uncore, , dev_priv->irq_mask, enable_mask); > ^ > > -:464: ERROR:SPACING: space prohibited before that close parenthesis ')' > #464: FILE: drivers/gpu/drm/i915/i915_irq.c:4508: > + GEN3_IRQ_RESET(uncore, ); > > -:479: ERROR:SPACING: space prohibited before that ',' (ctx:WxW) > #479: FILE: drivers/gpu/drm/i915/i915_irq.c:4552: > + GEN3_IRQ_INIT(uncore, , dev_priv->irq_mask, enable_mask); For these ones I really think the spaces help. I would love to read some opinions. Perhaps some comment like /* paste token here */ would help make the code more readable and could help silence checkpatch. Opinions? > ^ > > total: 6 errors, 0 warnings, 2 checks, 432 lines checked > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/7] drm/i915: Use dedicated rc6 enabling sequence for gen11
== Series Details == Series: series starting with [1/7] drm/i915: Use dedicated rc6 enabling sequence for gen11 URL : https://patchwork.freedesktop.org/series/59237/ State : warning == Summary == $ dim checkpatch origin/drm-tip 18e95bd1432c drm/i915: Use dedicated rc6 enabling sequence for gen11 -:29: WARNING:BLOCK_COMMENT_STYLE: Block comments use a trailing */ on a separate line #29: FILE: drivers/gpu/drm/i915/intel_pm.c:7132: +* hasn't enabled a state yet where we need forcewake, BIOS may have.*/ total: 0 errors, 1 warnings, 0 checks, 84 lines checked c8793cae22c1 drm/i915/icl: Apply a recommended rc6 threshold aa62d29fe1ae drm/i915/icl: Apply recommended rc6 idle hysteresis 1b904b5fd577 drm/i915/icl: Enable media sampler powergate 265eaf609bc8 drm/i915/icl: Disable video turbo mode for rp control b8d222eef36b drm/i915/icl: Handle rps interrupts without irq lock 92c211e3d49d drm/i915: Use Engine1 instance for gen11 pm interrupts ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Update HDMI max TMDS data rate definition for VBT (rev2)
== Series Details == Series: drm/i915: Update HDMI max TMDS data rate definition for VBT (rev2) URL : https://patchwork.freedesktop.org/series/59220/ State : failure == Summary == Applying: drm/i915: Update HDMI max TMDS data rate definition for VBT error: corrupt patch at line 13 error: could not build fake ancestor hint: Use 'git am --show-current-patch' to see the failed patch Patch failed at 0001 drm/i915: Update HDMI max TMDS data rate definition for VBT When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ 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: Bump ready tasks ahead of busywaits (rev2)
== Series Details ==
Series: drm/i915: Bump ready tasks ahead of busywaits (rev2)
URL : https://patchwork.freedesktop.org/series/59232/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5897 -> Patchwork_12740
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/59232/revisions/2/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_12740:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_create@basic:
- {fi-icl-u2}:PASS -> INCOMPLETE
Known issues
Here are the changes found in Patchwork_12740 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-icl-u3: NOTRUN -> SKIP [fdo#109315] +17
* igt@gem_exec_basic@gtt-bsd1:
- fi-icl-u3: NOTRUN -> SKIP [fdo#109276] +7
* igt@gem_exec_parse@basic-rejected:
- fi-icl-u3: NOTRUN -> SKIP [fdo#109289] +1
* igt@gem_exec_store@basic-bsd1:
- fi-kbl-r: NOTRUN -> SKIP [fdo#109271] +41
* 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] / [fdo#109720]
* igt@i915_selftest@live_hangcheck:
- fi-bxt-dsi: PASS -> INCOMPLETE [fdo#103927]
* igt@kms_busy@basic-flip-a:
- fi-bsw-n3050: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +1
* igt@kms_busy@basic-flip-c:
- fi-blb-e6850: NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
- fi-byt-j1900: NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
* igt@kms_chamelium@hdmi-crc-fast:
- fi-bsw-n3050: NOTRUN -> SKIP [fdo#109271] +62
- fi-byt-j1900: NOTRUN -> SKIP [fdo#109271] +52
* igt@kms_chamelium@hdmi-edid-read:
- fi-icl-u3: NOTRUN -> SKIP [fdo#109284] +8
* igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size:
- fi-glk-dsi: PASS -> INCOMPLETE [fdo#103359] / [k.org#198133]
* igt@kms_force_connector_basic@prune-stale-modes:
- fi-icl-u3: NOTRUN -> SKIP [fdo#109285] +3
* igt@kms_pipe_crc_basic@hang-read-crc-pipe-c:
- fi-blb-e6850: NOTRUN -> SKIP [fdo#109271] +48
* igt@runner@aborted:
- fi-apl-guc: NOTRUN -> FAIL [fdo#108622] / [fdo#109720]
Possible fixes
* igt@gem_ctx_exec@basic:
- fi-icl-u3: INCOMPLETE [fdo#107713] -> PASS
* igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS
* igt@i915_selftest@live_contexts:
- fi-bdw-gvtdvm: DMESG-FAIL [fdo#110235 ] -> PASS
- fi-skl-gvtdvm: DMESG-FAIL [fdo#110235 ] -> PASS
Warnings
* igt@i915_selftest@live_contexts:
- fi-icl-y: DMESG-FAIL [fdo#108569] -> INCOMPLETE [fdo#108569]
{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#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720
[fdo#110235 ]: https://bugs.freedesktop.org/show_bug.cgi?id=110235
[k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133
Participating hosts (44 -> 44)
--
Additional (3): fi-byt-j1900 fi-kbl-r fi-bsw-n3050
Missing(3): fi-byt-squawks fi-bsw-cyan fi-bdw-samus
Build changes
-
* Linux: CI_DRM_5897 -> Patchwork_12740
CI_DRM_5897: 7d07e025e78603d6270bc115fdb6c1efea6e66a5 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4934: dc4f45eb6874331daec870dc1e4cfc3ac5c49311 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12740: 585e504f873e2457cb860f42d76a8c7a47297277 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
585e504f873e drm/i915: Bump ready
Re: [Intel-gfx] [PATCH 1/7] drm/i915: Use dedicated rc6 enabling sequence for gen11
Quoting Michal Wajdeczko (2019-04-09 17:57:58) > On Tue, 09 Apr 2019 18:13:04 +0200, Mika Kuoppala > wrote: > > [snip] > > > + > > + /* > > + * 2c: Program Coarse Power Gating Policies. > > + * > > + * Bspec's guidance is to use 25us (really 25 * 1280ns) here. What we > > + * use instead is a more conservative estimate for the maximum time > > + * it takes us to service a CS interrupt and submit a new ELSP - that > > + * is the time which the GPU is idle waiting for the CPU to select the > > + * next request to execute. If the idle hysteresis is less than that > > + * interrupt service latency, the hardware will automatically gate > > + * the power well and we will then incur the wake up cost on top of > > + * the service latency. A similar guide from intel_pstate is that we > > + * do not want the enable hysteresis to less than the wakeup latency. > > + * > > + * igt/gem_exec_nop/sequential provides a rough estimate for the > > + * service latency, and puts it around 10us for Broadwell (and other > > + * big core) and around 40us for Broxton (and other low power cores). > > + * [Note that for legacy ringbuffer submission, this is less than > > 1us!] > > + * However, the wakeup latency on Broxton is closer to 100us. To be > > + * conservative, we have to factor in a context switch on top (due > > + * to ksoftirqd). > > + */ > > Do we want to copy legacy comments to Gen11 specific function ? The comment isn't legacy until you crunch through the measurements to work out the minimum tolerances that are sensible for us. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/7] drm/i915: Use dedicated rc6 enabling sequence for gen11
On Tue, 09 Apr 2019 18:13:04 +0200, Mika Kuoppala wrote: [snip] + + /* +* 2c: Program Coarse Power Gating Policies. +* +* Bspec's guidance is to use 25us (really 25 * 1280ns) here. What we +* use instead is a more conservative estimate for the maximum time +* it takes us to service a CS interrupt and submit a new ELSP - that +* is the time which the GPU is idle waiting for the CPU to select the +* next request to execute. If the idle hysteresis is less than that +* interrupt service latency, the hardware will automatically gate +* the power well and we will then incur the wake up cost on top of +* the service latency. A similar guide from intel_pstate is that we +* do not want the enable hysteresis to less than the wakeup latency. +* +* igt/gem_exec_nop/sequential provides a rough estimate for the +* service latency, and puts it around 10us for Broadwell (and other +* big core) and around 40us for Broxton (and other low power cores). +* [Note that for legacy ringbuffer submission, this is less than 1us!] +* However, the wakeup latency on Broxton is closer to 100us. To be +* conservative, we have to factor in a context switch on top (due +* to ksoftirqd). +*/ Do we want to copy legacy comments to Gen11 specific function ? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/7] drm/i915/icl: Apply a recommended rc6 threshold
On Tue, 09 Apr 2019 18:13:05 +0200, Mika Kuoppala wrote: On gen11 the recommended rc6 threshold differs from previous gens, apply it. References: bspec#52070 Is this correct number? I found it at 33149 And note that we are using different tag: Bspec: 33149 Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/intel_pm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 43ec0fb4c197..30ef507b88a4 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -7174,7 +7174,7 @@ static void gen11_enable_rc6(struct drm_i915_private *dev_priv) I915_WRITE(GEN9_RENDER_PG_IDLE_HYSTERESIS, 250); /* 3a: Enable RC6 */ - I915_WRITE(GEN6_RC6_THRESHOLD, 37500); /* 37.5/125ms per EI */ + I915_WRITE(GEN6_RC6_THRESHOLD, 5); /* 50/125ms per EI */ Btw, in bspec this is done at the end of step 2b. Shall we reorder whole function to match the spec? ~Michal ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/7] drm/i915/icl: Enable media sampler powergate
Quoting Mika Kuoppala (2019-04-09 17:13:07)
> Enable media sampler powergate as recommended.
>
> Signed-off-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_reg.h | 5 +++--
> drivers/gpu/drm/i915/intel_pm.c | 4 +++-
> 2 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 9c206e803ab3..20f5850c52f8 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -8687,8 +8687,9 @@ enum {
> #define GEN9_MEDIA_PG_IDLE_HYSTERESIS _MMIO(0xA0C4)
> #define GEN9_RENDER_PG_IDLE_HYSTERESIS _MMIO(0xA0C8)
> #define GEN9_PG_ENABLE _MMIO(0xA210)
> -#define GEN9_RENDER_PG_ENABLE (1 << 0)
> -#define GEN9_MEDIA_PG_ENABLE (1 << 1)
> +#define GEN9_RENDER_PG_ENABLE BIT(0)
> +#define GEN9_MEDIA_PG_ENABLE BIT(1)
> +#define GEN11_MEDIA_SAMPLER_PG_ENABLE BIT(2)
REG_BIT(foo)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/7] drm/i915/icl: Disable video turbo mode for rp control
Quoting Mika Kuoppala (2019-04-09 17:13:08) > There is no video turbo mode for gen11, so don't set it. > > Signed-off-by: Mika Kuoppala > --- > drivers/gpu/drm/i915/intel_pm.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c > index 47f98e064de5..d6abba5c0b32 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -6548,6 +6548,7 @@ static void rps_set_power(struct drm_i915_private > *dev_priv, int new_power) > struct intel_rps *rps = _priv->gt_pm.rps; > u32 threshold_up = 0, threshold_down = 0; /* in % */ > u32 ei_up = 0, ei_down = 0; > + u32 media_turbo; > > lockdep_assert_held(>power.mutex); > > @@ -6605,8 +6606,10 @@ static void rps_set_power(struct drm_i915_private > *dev_priv, int new_power) >GT_INTERVAL_FROM_US(dev_priv, >ei_down * threshold_down / 100)); > > + media_turbo = INTEL_GEN(dev_priv) > 9 ? 0 : GEN6_RP_MEDIA_TURBO; > + > I915_WRITE(GEN6_RP_CONTROL, > - GEN6_RP_MEDIA_TURBO | > + media_turbo | Looks short enough to fit inline? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/7] drm/i915: Use dedicated rc6 enabling sequence for gen11
Quoting Mika Kuoppala (2019-04-09 17:13:04) > In order not to inflate gen9 rc6 enabling sequence with > gen11 specifics, use a separate function for it. And disable_rc6 remains as simple as before. > Signed-off-by: Mika Kuoppala Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm/i915: Use Engine1 instance for gen11 pm interrupts
Quoting Mika Kuoppala (2019-04-09 17:13:10) > With gen11 the interrupt registers are shared between 2 engines, > with Engine1 instance being upper word and Engine0 instance being > lower. Annoyingly gen11 selected the pm interrupts to be in the > Engine1 instance. Sounds weird, but I can't fault the solution. The choice would either to have been shift pm_rps_events andadd gen11_pm_imr/_ier, so this patch looks to be the smaller delta. -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: Fix SDVO HDMI audio
== Series Details == Series: drm/i915: Fix SDVO HDMI audio URL : https://patchwork.freedesktop.org/series/59233/ State : success == Summary == CI Bug Log - changes from CI_DRM_5897 -> Patchwork_12739 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/59233/revisions/1/mbox/ Known issues Here are the changes found in Patchwork_12739 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@sync-fork-compute0: - fi-icl-u3: NOTRUN -> SKIP [fdo#109315] +17 * igt@gem_exec_basic@gtt-bsd1: - fi-icl-u3: NOTRUN -> SKIP [fdo#109276] +7 * igt@gem_exec_parse@basic-rejected: - fi-icl-u3: NOTRUN -> SKIP [fdo#109289] +1 * igt@gem_exec_store@basic-bsd1: - fi-kbl-r: NOTRUN -> SKIP [fdo#109271] +41 * 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] / [fdo#109720] * igt@i915_selftest@live_hangcheck: - fi-bxt-dsi: PASS -> INCOMPLETE [fdo#103927] * igt@kms_busy@basic-flip-a: - fi-bsw-n3050: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +1 * igt@kms_busy@basic-flip-c: - fi-byt-j1900: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] * igt@kms_chamelium@hdmi-crc-fast: - fi-bsw-n3050: NOTRUN -> SKIP [fdo#109271] +62 - fi-byt-j1900: NOTRUN -> SKIP [fdo#109271] +52 * igt@kms_chamelium@hdmi-edid-read: - fi-icl-u3: NOTRUN -> SKIP [fdo#109284] +8 * igt@kms_force_connector_basic@prune-stale-modes: - fi-icl-u3: NOTRUN -> SKIP [fdo#109285] +3 * igt@kms_frontbuffer_tracking@basic: - fi-icl-u3: NOTRUN -> FAIL [fdo#103167] * igt@runner@aborted: - fi-glk-dsi: NOTRUN -> FAIL [k.org#202321] - fi-apl-guc: NOTRUN -> FAIL [fdo#108622] / [fdo#109720] Possible fixes * igt@gem_ctx_exec@basic: - fi-icl-u3: INCOMPLETE [fdo#107713] -> PASS * igt@i915_selftest@live_contexts: - fi-bdw-gvtdvm: DMESG-FAIL [fdo#110235 ] -> PASS - fi-skl-gvtdvm: DMESG-FAIL [fdo#110235 ] -> PASS Warnings * igt@i915_pm_rpm@module-reload: - fi-glk-dsi: INCOMPLETE [fdo#103359] / [k.org#198133] -> DMESG-WARN [fdo#105538] / [fdo#107732] / [fdo#109513] [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359 [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#105538]: https://bugs.freedesktop.org/show_bug.cgi?id=105538 [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#107732]: https://bugs.freedesktop.org/show_bug.cgi?id=107732 [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569 [fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276 [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278 [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284 [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285 [fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289 [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315 [fdo#109513]: https://bugs.freedesktop.org/show_bug.cgi?id=109513 [fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720 [fdo#110235 ]: https://bugs.freedesktop.org/show_bug.cgi?id=110235 [k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133 [k.org#202321]: https://bugzilla.kernel.org/show_bug.cgi?id=202321 Participating hosts (44 -> 44) -- Additional (3): fi-byt-j1900 fi-kbl-r fi-bsw-n3050 Missing(3): fi-byt-squawks fi-bsw-cyan fi-bdw-samus Build changes - * Linux: CI_DRM_5897 -> Patchwork_12739 CI_DRM_5897: 7d07e025e78603d6270bc115fdb6c1efea6e66a5 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4934: dc4f45eb6874331daec870dc1e4cfc3ac5c49311 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12739: 35b215101d202bb3f213620d23029e0e09f5c65b @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 35b215101d20 drm/i915/sdvo: Actually print the reason why the SDVO command failed f283258eaf5e drm/i915/sdvo: Don't write stack garbage into the hbuf 780194ab786d drm/i915/sdvo: Don't unpack stack garbage acff651b8dfc drm/i915/sdvo: Check that we have space for the infoframe a1c898c367ad drm/i915: Rename SDVO_AUDIO_ENABLE to HDMI_AUDIO_ENABLE 366debf8e447 drm/i915/sdvo: Implement proper HDMI audio support for SDVO eaaa5efcbbc1 drm/i915/sdvo: Fix AVI infoframe TX rate readout == Logs == For more details see:
Re: [Intel-gfx] [PATCH 6/7] drm/i915/icl: Handle rps interrupts without irq lock
Quoting Mika Kuoppala (2019-04-09 17:13:09)
> Unlike previous gens, we already hold the irq_lock on
> entering the rps handler so we can't use it as it is.
>
> Make a gen11 specific rps interrupt handler without
> locking.
>
> Signed-off-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_irq.c | 18 +-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 6454ddc37f8b..619e6ab273e7 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1796,6 +1796,22 @@ static void i9xx_pipe_crc_irq_handler(struct
> drm_i915_private *dev_priv,
> /* The RPS events need forcewake, so we add them to a work queue and mask
> their
> * IMR bits until the work is done. Other interrupts can be processed without
> * the work queue. */
> +static void gen11_rps_irq_handler(struct drm_i915_private *i915, u32 pm_iir)
> +{
> + struct intel_rps *rps = >gt_pm.rps;
> + const u32 events = i915->pm_rps_events & pm_iir;
> +
> + lockdep_assert_held(>irq_lock);
> +
> + if (events) {
if (!events)
return;
?
Maybe you have reason for the indent later.
> + gen6_mask_pm_irq(i915, events);
> + if (rps->interrupts_enabled) {
> + rps->pm_iir |= events;
> + schedule_work(>work);
> + }
> + }
All I can say is that this is evidence that we've never had an rps
interrupt!
I guess this patch needs to be first just in case an interrupt is sent.
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v8 09/10] drm/i915: Set Infoframe for non modeset case for HDR
HDR metadata requires a infoframe to be set. Due to fastset,
full modeset is not performed hence adding it to update_pipe
to handle that.
Signed-off-by: Uma Shankar
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_ddi.c | 13 +
drivers/gpu/drm/i915/intel_hdmi.c | 7 +--
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 0ab3a8a..49b384d 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3545,6 +3545,10 @@ static void intel_ddi_update_pipe(struct intel_encoder
*encoder,
const struct intel_crtc_state *crtc_state,
const struct drm_connector_state *conn_state)
{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ struct intel_digital_port *intel_dig_port =
+ enc_to_dig_port(>base);
+
if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
intel_ddi_update_pipe_dp(encoder, crtc_state, conn_state);
@@ -3554,6 +3558,15 @@ static void intel_ddi_update_pipe(struct intel_encoder
*encoder,
else if (conn_state->content_protection ==
DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
intel_hdcp_disable(to_intel_connector(conn_state->connector));
+
+ /* Set the infoframe for NON modeset cases as well */
+ if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI)) {
+ if ((INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) &&
+ conn_state->hdr_metadata_changed)
+ intel_dig_port->set_infoframes(encoder,
+
crtc_state->has_infoframe,
+ crtc_state, conn_state);
+ }
}
static void intel_ddi_set_fia_lane_count(struct intel_encoder *encoder,
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 85333a7..56a36b5 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1219,8 +1219,11 @@ static void hsw_set_infoframes(struct intel_encoder
*encoder,
i915_reg_t reg = HSW_TVIDEO_DIP_CTL(crtc_state->cpu_transcoder);
u32 val = I915_READ(reg);
- assert_hdmi_transcoder_func_disabled(dev_priv,
-crtc_state->cpu_transcoder);
+ /* DRM Infoframe can be send with transcoder enabled */
+ if (!((INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) &&
+ conn_state->hdr_metadata_changed))
+ assert_hdmi_transcoder_func_disabled(dev_priv,
+
crtc_state->cpu_transcoder);
val &= ~(VIDEO_DIP_ENABLE_VSC_HSW | VIDEO_DIP_ENABLE_AVI_HSW |
VIDEO_DIP_ENABLE_GCP_HSW | VIDEO_DIP_ENABLE_VS_HSW |
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v8 10/10] drm/i915: Added DRM Infoframe handling for BYT/CHT
BYT/CHT doesn't support DRM Infoframe. This caused a WARN_ON due to a missing CASE while executing intel_hdmi_infoframes_enabled function. This patch fixes the same. 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 56a36b5..34f9805 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -122,6 +122,8 @@ static u32 g4x_infoframe_enable(unsigned int type) return VIDEO_DIP_ENABLE_SPD; case HDMI_INFOFRAME_TYPE_VENDOR: return VIDEO_DIP_ENABLE_VENDOR; + case HDMI_INFOFRAME_TYPE_DRM: + return 0; default: MISSING_CASE(type); return 0; -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v8 00/10] Add HDR Metadata Parsing and handling in DRM layer
This patch series enables HDR support in drm. It basically defines HDR metadata structures, property to pass content (after blending) metadata from user space compositors to driver. Dynamic Range and Mastering infoframe creation and sending. ToDo: 1. We need to get the color framework in place for all planes which support HDR content in hardware. This is already in progres and patches are out for review in mailing list. 2. UserSpace/Compositors: Blending policies and metadata blob creation and passing to driver. Work is already in progress by Intel's middleware teams on wayland and the patches for the same are in review. Please review and share your feedbacks/suggestions. Note: The intention for these patches is to get a design feedback on the uapi changes, generic property design and infoframe handling. This cannot get merged as of now without the userspace support in place. A POC has already been developed by Ville based on wayland. Please refer below link to see the component interactions and usage: https://lists.freedesktop.org/archives/wayland-devel/2017-December/036403.html v2: Updated Ville's POC changes to the patch series.Incorporated cleanups and fixes from Ville. Rebase on latest drm-tip. v3: Fixed a warning causing builds to break on CI. No major change. v4: Addressed Shashank's review comments. v5: Rebase on top of Ville's infoframe refactoring changes. Fixed non modeset case for HDR metadata update. Dropped a redundant patch. v6: Addressed Shashank's review comments and added RB's received. v7: Squashed 2 patches, dropped 1 change and addressed Brian Starkey's and Shashank's review comments. v8: Addressed Jonas Karlman review comments. Added Shashank's RB to the series, fixed a WARN_ON on BYT/CHT. Note: Media driver and VAAPI changes for HDR are already out, with compositors changes also expected to land soon. Weston changes already floated and reviews started in community and is in active development along with GL efforts. Uma Shankar (8): drm: Add HDR source metadata property drm: Parse HDR metadata info from EDID drm: Enable HDR infoframe support drm/i915: Attach HDR metadata property to connector drm/i915: Write HDR infoframe and send to panel drm/i915:Enabled Modeset when HDR Infoframe changes drm/i915: Set Infoframe for non modeset case for HDR drm/i915: Added DRM Infoframe handling for BYT/CHT Ville Syrjälä (2): drm/i915: Add HLG EOTF drm/i915: Enable infoframes on GLK+ for HDR drivers/gpu/drm/drm_atomic.c| 2 + drivers/gpu/drm/drm_atomic_uapi.c | 13 +++ drivers/gpu/drm/drm_connector.c | 6 ++ drivers/gpu/drm/drm_edid.c | 101 drivers/gpu/drm/i915/i915_reg.h | 4 + drivers/gpu/drm/i915/intel_atomic.c | 14 ++- drivers/gpu/drm/i915/intel_ddi.c| 13 +++ drivers/gpu/drm/i915/intel_drv.h| 1 + drivers/gpu/drm/i915/intel_hdmi.c | 105 ++-- drivers/video/hdmi.c| 186 include/drm/drm_connector.h | 11 +++ include/drm/drm_edid.h | 5 + include/drm/drm_mode_config.h | 6 ++ include/linux/hdmi.h| 38 include/uapi/drm/drm_mode.h | 39 15 files changed, 537 insertions(+), 7 deletions(-) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v8 08/10] drm/i915:Enabled Modeset when HDR Infoframe changes
This patch enables modeset whenever HDR metadata
needs to be updated to sink.
v2: Addressed Shashank's review comments.
v3: Added Shashank's RB.
Signed-off-by: Ville Syrjälä
Signed-off-by: Uma Shankar
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_atomic.c | 14 +-
drivers/gpu/drm/i915/intel_hdmi.c | 26 ++
2 files changed, 39 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index 8c8fae3..e8b5f84 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -104,6 +104,16 @@ int intel_digital_connector_atomic_set_property(struct
drm_connector *connector,
return -EINVAL;
}
+static bool blob_equal(const struct drm_property_blob *a,
+ const struct drm_property_blob *b)
+{
+ if (a && b)
+ return a->length == b->length &&
+ !memcmp(a->data, b->data, a->length);
+
+ return !a == !b;
+}
+
int intel_digital_connector_atomic_check(struct drm_connector *conn,
struct drm_connector_state *new_state)
{
@@ -131,7 +141,9 @@ int intel_digital_connector_atomic_check(struct
drm_connector *conn,
new_conn_state->base.colorspace != old_conn_state->base.colorspace
||
new_conn_state->base.picture_aspect_ratio !=
old_conn_state->base.picture_aspect_ratio ||
new_conn_state->base.content_type !=
old_conn_state->base.content_type ||
- new_conn_state->base.scaling_mode !=
old_conn_state->base.scaling_mode)
+ new_conn_state->base.scaling_mode !=
old_conn_state->base.scaling_mode ||
+ !blob_equal(new_conn_state->base.hdr_output_metadata_blob_ptr,
+ old_conn_state->base.hdr_output_metadata_blob_ptr))
crtc_state->mode_changed = true;
return 0;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 0ecfda0..85333a7 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -799,6 +799,20 @@ void intel_read_infoframe(struct intel_encoder *encoder,
return true;
}
+static bool is_eotf_supported(u8 output_eotf, u8 sink_eotf)
+{
+ if (output_eotf == 0)
+ return (sink_eotf & (1 << 0));
+ if (output_eotf == 1)
+ return (sink_eotf & (1 << 1));
+ if (output_eotf == 2)
+ return (sink_eotf & (1 << 2));
+ if (output_eotf == 3)
+ return (sink_eotf & (1 << 3));
+
+ return false;
+}
+
static bool
intel_hdmi_compute_drm_infoframe(struct intel_encoder *encoder,
struct intel_crtc_state *crtc_state,
@@ -806,11 +820,23 @@ void intel_read_infoframe(struct intel_encoder *encoder,
{
struct hdmi_drm_infoframe *frame = _state->infoframes.drm.drm;
struct hdr_output_metadata *hdr_metadata;
+ struct drm_connector *connector = conn_state->connector;
int ret;
+ if (!conn_state->hdr_output_metadata_blob_ptr ||
+ conn_state->hdr_output_metadata_blob_ptr->length == 0)
+ return true;
+
hdr_metadata = (struct hdr_output_metadata *)
conn_state->hdr_output_metadata_blob_ptr->data;
+ /* Sink EOTF is Bit map while infoframe is absolute values */
+ if (!is_eotf_supported(hdr_metadata->hdmi_metadata_type1.eotf,
+ connector->hdr_sink_metadata.hdmi_type1.eotf)) {
+ DRM_ERROR("EOTF Not Supported\n");
+ return true;
+ }
+
ret = drm_hdmi_infoframe_set_hdr_metadata(frame, hdr_metadata);
if (ret < 0) {
DRM_ERROR("couldn't set HDR metadata in infoframe\n");
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v8 04/10] drm/i915: Attach HDR metadata property to connector
Attach HDR metadata property to connector object. v2: Rebase v3: Updated the property name as per updated name while creating hdr metadata property Signed-off-by: Uma Shankar Reviewed-by: Shashank Sharma --- 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 e1005d7..d9851da 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -2730,6 +2730,8 @@ static void intel_hdmi_destroy(struct drm_connector *connector) drm_connector_attach_content_type_property(connector); connector->state->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE; + drm_object_attach_property(>base, + connector->dev->mode_config.hdr_output_metadata_property, 0); if (!HAS_GMCH(dev_priv)) drm_connector_attach_max_bpc_property(connector, 8, 12); -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v8 02/10] drm: Parse HDR metadata info from EDID
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.
v3: No Change
v4: Addressed Shashank's review comments
v5: Addressed Shashank's comment and added his RB.
v6: Addressed Jonas Karlman review comments.
Signed-off-by: Uma Shankar
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/drm_edid.c | 52 ++
1 file changed, 52 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 2c22ea4..1fc371b 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2830,6 +2830,7 @@ static int drm_cvt_modes(struct drm_connector *connector,
#define VIDEO_BLOCK 0x02
#define VENDOR_BLOCK0x03
#define SPEAKER_BLOCK 0x04
+#define HDR_STATIC_METADATA_BLOCK 0x6
#define USE_EXTENDED_TAG 0x07
#define EXT_VIDEO_CAPABILITY_BLOCK 0x00
#define EXT_VIDEO_DATA_BLOCK_420 0x0E
@@ -3577,6 +3578,12 @@ static int add_3d_struct_modes(struct drm_connector
*connector, u16 structure,
}
static int
+cea_db_payload_len_ext(const u8 *db)
+{
+ return (db[0] & 0x1f) - 1;
+}
+
+static int
cea_db_extended_tag(const u8 *db)
{
return db[1];
@@ -3812,6 +3819,49 @@ static void fixup_detailed_cea_mode_clock(struct
drm_display_mode *mode)
mode->clock = clock;
}
+static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db)
+{
+ if (cea_db_tag(db) != USE_EXTENDED_TAG)
+ return false;
+
+ if (db[1] != HDR_STATIC_METADATA_BLOCK)
+ return false;
+
+ return true;
+}
+
+static uint8_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));
+}
+
+static uint8_t hdr_metadata_type(const u8 *edid_ext)
+{
+ return edid_ext[3] &
+ BIT(HDMI_STATIC_METADATA_TYPE1);
+}
+
+static void
+drm_parse_hdr_metadata_block(struct drm_connector *connector, const u8 *db)
+{
+ u16 len;
+
+ len = cea_db_payload_len_ext(db);
+ connector->hdr_sink_metadata.hdmi_type1.eotf = eotf_supported(db);
+ connector->hdr_sink_metadata.hdmi_type1.metadata_type =
+ hdr_metadata_type(db);
+
+ if (len >= 4)
+ connector->hdr_sink_metadata.hdmi_type1.max_cll = db[4];
+ if (len >= 5)
+ connector->hdr_sink_metadata.hdmi_type1.max_fall = db[5];
+ if (len >= 6)
+ connector->hdr_sink_metadata.hdmi_type1.min_cll = db[6];
+}
+
static void
drm_parse_hdmi_vsdb_audio(struct drm_connector *connector, const u8 *db)
{
@@ -4439,6 +4489,8 @@ static void drm_parse_cea_ext(struct drm_connector
*connector,
drm_parse_y420cmdb_bitmap(connector, db);
if (cea_db_is_vcdb(db))
drm_parse_vcdb(connector, db);
+ if (cea_db_is_hdmi_hdr_metadata_block(db))
+ drm_parse_hdr_metadata_block(connector, db);
}
}
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v8 03/10] drm: Enable HDR infoframe support
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.
Added the const version of infoframe for DRM metadata
for HDR.
v2: Rebase and added Ville's POC changes.
v3: No Change
v4: Addressed Shashank's review comments and merged the
patch making drm infoframe function arguments as constant.
v5: Rebase
v6: Fixed checkpatch warnings with --strict option. Addressed
Shashank's review comments and added his RB.
v7: Addressed Brian Starkey's review comments. Merged 2 patches
into one.
v8: Addressed Jonas Karlman review comments.
Signed-off-by: Uma Shankar
Signed-off-by: Ville Syrjälä
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/drm_edid.c | 48
drivers/video/hdmi.c | 186 +
include/drm/drm_edid.h | 5 ++
include/linux/hdmi.h | 27 +++
4 files changed, 266 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 1fc371b..9b71a64 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4884,6 +4884,54 @@ static bool is_hdmi2_sink(struct drm_connector
*connector)
}
/**
+ * 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,
+ struct hdr_output_metadata *hdr_metadata)
+{
+ int err;
+
+ if (!frame || !hdr_metadata)
+ return true;
+
+ err = hdmi_drm_infoframe_init(frame);
+ if (err < 0)
+ return err;
+
+ DRM_DEBUG_KMS("type = %x\n", frame->type);
+
+ frame->length = sizeof(struct hdr_metadata_infoframe);
+
+ frame->eotf = hdr_metadata->hdmi_metadata_type1.eotf;
+ frame->metadata_type = hdr_metadata->hdmi_metadata_type1.metadata_type;
+
+ memcpy(>display_primaries,
+ _metadata->hdmi_metadata_type1.display_primaries, 12);
+
+ memcpy(>white_point,
+ _metadata->hdmi_metadata_type1.white_point, 4);
+
+ frame->max_display_mastering_luminance =
+
hdr_metadata->hdmi_metadata_type1.max_display_mastering_luminance;
+ frame->min_display_mastering_luminance =
+
hdr_metadata->hdmi_metadata_type1.min_display_mastering_luminance;
+ frame->max_fall = hdr_metadata->hdmi_metadata_type1.max_fall;
+ frame->max_cll = hdr_metadata->hdmi_metadata_type1.max_cll;
+
+ 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..717ed7fb 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -650,6 +650,146 @@ 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);
+
+static int hdmi_drm_infoframe_check_only(const struct hdmi_drm_infoframe
*frame)
+{
+ if (frame->type != HDMI_INFOFRAME_TYPE_DRM ||
+ frame->version != 1)
+ return -EINVAL;
+
+ return 0;
+}
+
+/**
+ * hdmi_drm_infoframe_check() - check a HDMI DRM infoframe
+ * @frame: HDMI DRM infoframe
+ *
+ * Validates that the infoframe is consistent.
+ * Returns 0 on success or a negative error code on failure.
+ */
+int hdmi_drm_infoframe_check(struct hdmi_drm_infoframe *frame)
+{
+ return hdmi_drm_infoframe_check_only(frame);
+}
+EXPORT_SYMBOL(hdmi_drm_infoframe_check);
+
+/**
+ * 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
[Intel-gfx] [v8 07/10] drm/i915: Enable infoframes on GLK+ for HDR
From: Ville Syrjälä
This patch enables infoframes on GLK+ to be
used to send HDR metadata to HDMI sink.
v2: Addressed Shashank's review comment.
v3: Addressed Shashank's review comment.
v4: Added Shashank's RB.
Signed-off-by: Ville Syrjälä
Signed-off-by: Uma Shankar
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/i915/i915_reg.h | 4
drivers/gpu/drm/i915/intel_hdmi.c | 22 +-
2 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 9c206e8..6cd250d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4692,6 +4692,7 @@ enum {
#define VIDEO_DIP_FREQ_MASK (3 << 16)
/* HSW and later: */
#define DRM_DIP_ENABLE (1 << 28)
+#define VIDEO_DIP_ENABLE_DRM_GLK (1 << 28)
#define PSR_VSC_BIT_7_SET(1 << 27)
#define VSC_SELECT_MASK (0x3 << 25)
#define VSC_SELECT_SHIFT 25
@@ -8143,6 +8144,7 @@ enum {
#define _HSW_VIDEO_DIP_SPD_DATA_A 0x602A0
#define _HSW_VIDEO_DIP_GMP_DATA_A 0x602E0
#define _HSW_VIDEO_DIP_VSC_DATA_A 0x60320
+#define _GLK_VIDEO_DIP_DRM_DATA_A 0x60440
#define _HSW_VIDEO_DIP_AVI_ECC_A 0x60240
#define _HSW_VIDEO_DIP_VS_ECC_A0x60280
#define _HSW_VIDEO_DIP_SPD_ECC_A 0x602C0
@@ -8156,6 +8158,7 @@ enum {
#define _HSW_VIDEO_DIP_SPD_DATA_B 0x612A0
#define _HSW_VIDEO_DIP_GMP_DATA_B 0x612E0
#define _HSW_VIDEO_DIP_VSC_DATA_B 0x61320
+#define _GLK_VIDEO_DIP_DRM_DATA_B 0x61440
#define _HSW_VIDEO_DIP_BVI_ECC_B 0x61240
#define _HSW_VIDEO_DIP_VS_ECC_B0x61280
#define _HSW_VIDEO_DIP_SPD_ECC_B 0x612C0
@@ -8181,6 +8184,7 @@ enum {
#define HSW_TVIDEO_DIP_SPD_DATA(trans, i) _MMIO_TRANS2(trans,
_HSW_VIDEO_DIP_SPD_DATA_A + (i) * 4)
#define HSW_TVIDEO_DIP_GMP_DATA(trans, i) _MMIO_TRANS2(trans,
_HSW_VIDEO_DIP_GMP_DATA_A + (i) * 4)
#define HSW_TVIDEO_DIP_VSC_DATA(trans, i) _MMIO_TRANS2(trans,
_HSW_VIDEO_DIP_VSC_DATA_A + (i) * 4)
+#define GLK_TVIDEO_DIP_DRM_DATA(trans, i) _MMIO_TRANS2(trans,
_GLK_VIDEO_DIP_DRM_DATA_A + (i) * 4)
#define ICL_VIDEO_DIP_PPS_DATA(trans, i) _MMIO_TRANS2(trans,
_ICL_VIDEO_DIP_PPS_DATA_A + (i) * 4)
#define ICL_VIDEO_DIP_PPS_ECC(trans, i)_MMIO_TRANS2(trans,
_ICL_VIDEO_DIP_PPS_ECC_A + (i) * 4)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 40d55b0..0ecfda0 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -145,6 +145,8 @@ static u32 hsw_infoframe_enable(unsigned int type)
return VIDEO_DIP_ENABLE_SPD_HSW;
case HDMI_INFOFRAME_TYPE_VENDOR:
return VIDEO_DIP_ENABLE_VS_HSW;
+ case HDMI_INFOFRAME_TYPE_DRM:
+ return VIDEO_DIP_ENABLE_DRM_GLK;
default:
MISSING_CASE(type);
return 0;
@@ -170,6 +172,8 @@ static u32 hsw_infoframe_enable(unsigned int type)
return HSW_TVIDEO_DIP_SPD_DATA(cpu_transcoder, i);
case HDMI_INFOFRAME_TYPE_VENDOR:
return HSW_TVIDEO_DIP_VS_DATA(cpu_transcoder, i);
+ case HDMI_INFOFRAME_TYPE_DRM:
+ return GLK_TVIDEO_DIP_DRM_DATA(cpu_transcoder, i);
default:
MISSING_CASE(type);
return INVALID_MMIO_REG;
@@ -553,10 +557,16 @@ static u32 hsw_infoframes_enabled(struct intel_encoder
*encoder,
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
u32 val = I915_READ(HSW_TVIDEO_DIP_CTL(pipe_config->cpu_transcoder));
+ u32 mask;
- return val & (VIDEO_DIP_ENABLE_VSC_HSW | VIDEO_DIP_ENABLE_AVI_HSW |
- VIDEO_DIP_ENABLE_GCP_HSW | VIDEO_DIP_ENABLE_VS_HSW |
- VIDEO_DIP_ENABLE_GMP_HSW | VIDEO_DIP_ENABLE_SPD_HSW);
+ mask = (VIDEO_DIP_ENABLE_VSC_HSW | VIDEO_DIP_ENABLE_AVI_HSW |
+ VIDEO_DIP_ENABLE_GCP_HSW | VIDEO_DIP_ENABLE_VS_HSW |
+ VIDEO_DIP_ENABLE_GMP_HSW | VIDEO_DIP_ENABLE_SPD_HSW);
+
+ if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
+ mask |= VIDEO_DIP_ENABLE_DRM_GLK;
+
+ return val & mask;
}
static const u8 infoframe_type_to_idx[] = {
@@ -1188,7 +1198,8 @@ static void hsw_set_infoframes(struct intel_encoder
*encoder,
val &= ~(VIDEO_DIP_ENABLE_VSC_HSW | VIDEO_DIP_ENABLE_AVI_HSW |
VIDEO_DIP_ENABLE_GCP_HSW | VIDEO_DIP_ENABLE_VS_HSW |
-VIDEO_DIP_ENABLE_GMP_HSW | VIDEO_DIP_ENABLE_SPD_HSW);
+VIDEO_DIP_ENABLE_GMP_HSW | VIDEO_DIP_ENABLE_SPD_HSW |
+VIDEO_DIP_ENABLE_DRM_GLK);
if (!enable) {
I915_WRITE(reg, val);
@@ -1217,7 +1228,8 @@ static void hsw_set_infoframes(struct intel_encoder
*encoder,
* ToDo: Gen9 also can support HDR with LSPCON.
* Support for the same to be enabled later.
[Intel-gfx] [v8 01/10] drm: Add HDR source metadata property
This patch adds a blob property to get HDR metadata
information from userspace. This will be send as part
of AVI Infoframe to panel.
It also implements get() and set() functions for HDR output
metadata property.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 modified the metadata structure elements
as per Ville's POC changes.
v3: No Change
v4: Addressed Shashank's review comments
v5: Rebase.
v6: Addressed Brian Starkey's review comments, defined
new structure with header for dynamic metadata scalability.
Merge get/set property functions for metadata in this patch.
v7: Addressed Jonas Karlman review comments and defined separate
structure for infoframe to better align with CTA 861.G spec. Added
Shashank's RB.
Signed-off-by: Uma Shankar
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/drm_atomic.c | 2 ++
drivers/gpu/drm/drm_atomic_uapi.c | 13 +
drivers/gpu/drm/drm_connector.c | 6 ++
include/drm/drm_connector.h | 11 +++
include/drm/drm_mode_config.h | 6 ++
include/linux/hdmi.h | 10 ++
include/uapi/drm/drm_mode.h | 39 +++
7 files changed, 87 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 5eb4013..8b9c126 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);
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 ea797d4..6d0d161 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -673,6 +673,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
{
struct drm_device *dev = connector->dev;
struct drm_mode_config *config = >mode_config;
+ bool replaced = false;
+ int ret;
if (property == config->prop_crtc_id) {
struct drm_crtc *crtc = drm_crtc_find(dev, NULL, val);
@@ -721,6 +723,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_output_metadata_property) {
+ ret = drm_atomic_replace_property_blob_from_id(dev,
+ >hdr_output_metadata_blob_ptr,
+ val,
+ -1, sizeof(struct hdr_output_metadata),
+ );
+ 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) {
@@ -807,6 +817,9 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
*val = state->colorspace;
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
+ } else if (property == config->hdr_output_metadata_property) {
+ *val = (state->hdr_output_metadata_blob_ptr) ?
+ state->hdr_output_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) {
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 2355124..0bdae90 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1058,6 +1058,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_OUTPUT_METADATA", 0);
+ if (!prop)
+ return -ENOMEM;
+ dev->mode_config.hdr_output_metadata_property = prop;
+
return 0;
}
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 02a1312..5343f60 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -599,6 +599,13 @@ struct drm_connector_state {
* and the connector bpc limitations obtained from edid.
*/
u8 max_bpc;
+
+ /**
+
[Intel-gfx] [v8 06/10] drm/i915: Add HLG EOTF
From: Ville Syrjälä
ADD HLG EOTF to the list of EOTF transfer functions supported.
Hybrid Log-Gamma (HLG) is a high dynamic range (HDR) standard.
HLG defines a nonlinear transfer function in which the lower
half of the signal values use a gamma curve and the upper half
of the signal values use a logarithmic curve.
v2: Rebase
v3: Fixed a warning message
v4: Addressed Shashank's review comments
Signed-off-by: Ville Syrjälä
Signed-off-by: Uma Shankar
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/drm_edid.c | 3 ++-
include/linux/hdmi.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 9b71a64..f88c0c7 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3835,7 +3835,8 @@ static uint8_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 uint8_t hdr_metadata_type(const u8 *edid_ext)
diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index 3927d88..daf7a37 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -161,6 +161,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 {
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v8 05/10] drm/i915: Write HDR infoframe and send to panel
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
v3: Fixed a warning message
v4: Addressed Shashank's review comments
v5: Rebase. Added infoframe calculation in compute config.
v6: Addressed Shashank's review comment. Added HDR metadata
support from GEN10 onwards as per Shashank's recommendation.
v7: Addressed Shashank's review comments
v8: Added Shashank's RB.
Signed-off-by: Uma Shankar
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_hdmi.c | 48 +++
2 files changed, 49 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a38b9cf..6a9d132 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1051,6 +1051,7 @@ struct intel_crtc_state {
union hdmi_infoframe avi;
union hdmi_infoframe spd;
union hdmi_infoframe hdmi;
+ union hdmi_infoframe drm;
} infoframes;
/* HDMI scrambling status */
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index d9851da..40d55b0 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -566,6 +566,7 @@ static u32 hsw_infoframes_enabled(struct intel_encoder
*encoder,
HDMI_INFOFRAME_TYPE_AVI,
HDMI_INFOFRAME_TYPE_SPD,
HDMI_INFOFRAME_TYPE_VENDOR,
+ HDMI_INFOFRAME_TYPE_DRM,
};
u32 intel_hdmi_infoframe_enable(unsigned int type)
@@ -788,6 +789,30 @@ void intel_read_infoframe(struct intel_encoder *encoder,
return true;
}
+static bool
+intel_hdmi_compute_drm_infoframe(struct intel_encoder *encoder,
+struct intel_crtc_state *crtc_state,
+struct drm_connector_state *conn_state)
+{
+ struct hdmi_drm_infoframe *frame = _state->infoframes.drm.drm;
+ struct hdr_output_metadata *hdr_metadata;
+ int ret;
+
+ hdr_metadata = (struct hdr_output_metadata *)
+ conn_state->hdr_output_metadata_blob_ptr->data;
+
+ ret = drm_hdmi_infoframe_set_hdr_metadata(frame, hdr_metadata);
+ if (ret < 0) {
+ DRM_ERROR("couldn't set HDR metadata in infoframe\n");
+ return false;
+ }
+
+ crtc_state->infoframes.enable |=
+ intel_hdmi_infoframe_enable(HDMI_INFOFRAME_TYPE_DRM);
+
+ return true;
+}
+
static void g4x_set_infoframes(struct intel_encoder *encoder,
bool enable,
const struct intel_crtc_state *crtc_state,
@@ -1186,6 +1211,16 @@ static void hsw_set_infoframes(struct intel_encoder
*encoder,
intel_write_infoframe(encoder, crtc_state,
HDMI_INFOFRAME_TYPE_VENDOR,
_state->infoframes.hdmi);
+
+ /*
+* Support HDR Metadata from Gen10 onwards
+* ToDo: Gen9 also can support HDR with LSPCON.
+* Support for the same to be enabled later.
+*/
+ if (INTEL_GEN(dev_priv) >= 10)
+ intel_write_infoframe(encoder, crtc_state,
+ HDMI_INFOFRAME_TYPE_DRM,
+ _state->infoframes.drm);
}
void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi *hdmi, bool enable)
@@ -2392,6 +2427,19 @@ int intel_hdmi_compute_config(struct intel_encoder
*encoder,
return -EINVAL;
}
+ /*
+* Support HDR Metadata from Gen10 onwards
+* ToDo: Gen9 also can support HDR with LSPCON.
+* Support for the same to be enabled later.
+*/
+ if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) {
+ if (!intel_hdmi_compute_drm_infoframe(encoder, pipe_config,
+ conn_state)) {
+ DRM_DEBUG_KMS("bad DRM infoframe\n");
+ return -EINVAL;
+ }
+ }
+
return 0;
}
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v7 1/9] drm: Add HDR source metadata property
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Jonas
>Karlman
>Sent: Monday, April 8, 2019 3:51 PM
>To: Shankar, Uma ; intel-gfx@lists.freedesktop.org; dri-
>de...@lists.freedesktop.org
>Cc: seanp...@chromium.org; emil.l.veli...@gmail.com; dcasta...@chromium.org;
>Lankhorst, Maarten ; Syrjala, Ville
>
>Subject: Re: [v7 1/9] drm: Add HDR source metadata property
>
>On 2019-04-02 22:20, 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.
>>
>> It also implements get() and set() functions for HDR output metadata
>> property.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 modified the metadata structure elements as per Ville's
>> POC changes.
>>
>> v3: No Change
>>
>> v4: Addressed Shashank's review comments
>>
>> v5: Rebase.
>>
>> v6: Addressed Brian Starkey's review comments, defined new structure
>> with header for dynamic metadata scalability.
>> Merge get/set property functions for metadata in this patch.
>>
>> Signed-off-by: Uma Shankar
>> ---
>> drivers/gpu/drm/drm_atomic.c | 2 ++
>> drivers/gpu/drm/drm_atomic_uapi.c | 13 +
>> 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 | 22 ++
>> 7 files changed, 69 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic.c
>> b/drivers/gpu/drm/drm_atomic.c index 5eb4013..8b9c126 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);
>>
>> 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 ea797d4..6d0d161 100644
>> --- a/drivers/gpu/drm/drm_atomic_uapi.c
>> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
>> @@ -673,6 +673,8 @@ static int
>> drm_atomic_connector_set_property(struct drm_connector *connector, {
>> struct drm_device *dev = connector->dev;
>> struct drm_mode_config *config = >mode_config;
>> +bool replaced = false;
>> +int ret;
>>
>> if (property == config->prop_crtc_id) {
>> struct drm_crtc *crtc = drm_crtc_find(dev, NULL, val); @@ -721,6
>> +723,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_output_metadata_property) {
>> +ret = drm_atomic_replace_property_blob_from_id(dev,
>> +>hdr_output_metadata_blob_ptr,
>> +val,
>> +-1, sizeof(struct hdr_output_metadata),
>> +);
>> +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) { @@ -807,6
>> +817,9 @@ static int drm_atomic_connector_set_property(struct drm_connector
>*connector,
>> *val = state->colorspace;
>> } else if (property == connector->scaling_mode_property) {
>> *val = state->scaling_mode;
>> +} else if (property == config->hdr_output_metadata_property) {
>> +*val = (state->hdr_output_metadata_blob_ptr) ?
>> +state->hdr_output_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) { diff
>> --git a/drivers/gpu/drm/drm_connector.c
>> b/drivers/gpu/drm/drm_connector.c index 2355124..0bdae90 100644
>> --- a/drivers/gpu/drm/drm_connector.c
>> +++ b/drivers/gpu/drm/drm_connector.c
>> @@ -1058,6 +1058,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_OUTPUT_METADATA", 0);
>> +if (!prop)
>> +return
Re: [Intel-gfx] [PATCH 3/7] drm/i915/icl: Apply recommended rc6 idle hysteresis
Quoting Mika Kuoppala (2019-04-09 17:13:06) > Use a recommended idle hysteresis for media and render powergates. > > References: bspec#52070 > Signed-off-by: Mika Kuoppala > --- > drivers/gpu/drm/i915/intel_pm.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c > index 30ef507b88a4..b9be9ea5fc18 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -7170,8 +7170,8 @@ static void gen11_enable_rc6(struct drm_i915_private > *dev_priv) > * conservative, we have to factor in a context switch on top (due > * to ksoftirqd). > */ > - I915_WRITE(GEN9_MEDIA_PG_IDLE_HYSTERESIS, 250); > - I915_WRITE(GEN9_RENDER_PG_IDLE_HYSTERESIS, 250); > + I915_WRITE(GEN9_MEDIA_PG_IDLE_HYSTERESIS, 25); > + I915_WRITE(GEN9_RENDER_PG_IDLE_HYSTERESIS, 25); We were using higher than recommended for the simple reason of not allowing it to powergate while signaling between engines. We are much faster now (though be sure to disable semaphores to put us in worse case) and since we use one value, we need to measure on the slow platform. Anyway, just pointing out there was a reason for a relatively large hysteresis. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/7] drm/i915: Use dedicated rc6 enabling sequence for gen11
In order not to inflate gen9 rc6 enabling sequence with
gen11 specifics, use a separate function for it.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_pm.c | 72 +
1 file changed, 72 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index bba477e62a12..43ec0fb4c197 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -7120,6 +7120,76 @@ static void gen9_enable_rps(struct drm_i915_private
*dev_priv)
intel_uncore_forcewake_put(_priv->uncore, FORCEWAKE_ALL);
}
+static void gen11_enable_rc6(struct drm_i915_private *dev_priv)
+{
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+
+ /* 1a: Software RC state - RC0 */
+ I915_WRITE(GEN6_RC_STATE, 0);
+
+ /* 1b: Get forcewake during program sequence. Although the driver
+* hasn't enabled a state yet where we need forcewake, BIOS may have.*/
+ intel_uncore_forcewake_get(_priv->uncore, FORCEWAKE_ALL);
+
+ /* 2a: Disable RC states. */
+ I915_WRITE(GEN6_RC_CONTROL, 0);
+
+ /* 2b: Program RC6 thresholds.*/
+ I915_WRITE(GEN6_RC6_WAKE_RATE_LIMIT, 54 << 16 | 85);
+ I915_WRITE(GEN10_MEDIA_WAKE_RATE_LIMIT, 150);
+
+ I915_WRITE(GEN6_RC_EVALUATION_INTERVAL, 125000); /* 12500 * 1280ns */
+ I915_WRITE(GEN6_RC_IDLE_HYSTERSIS, 25); /* 25 * 1280ns */
+ for_each_engine(engine, dev_priv, id)
+ I915_WRITE(RING_MAX_IDLE(engine->mmio_base), 10);
+
+ if (HAS_GUC(dev_priv))
+ I915_WRITE(GUC_MAX_IDLE_COUNT, 0xA);
+
+ I915_WRITE(GEN6_RC_SLEEP, 0);
+
+ /*
+* 2c: Program Coarse Power Gating Policies.
+*
+* Bspec's guidance is to use 25us (really 25 * 1280ns) here. What we
+* use instead is a more conservative estimate for the maximum time
+* it takes us to service a CS interrupt and submit a new ELSP - that
+* is the time which the GPU is idle waiting for the CPU to select the
+* next request to execute. If the idle hysteresis is less than that
+* interrupt service latency, the hardware will automatically gate
+* the power well and we will then incur the wake up cost on top of
+* the service latency. A similar guide from intel_pstate is that we
+* do not want the enable hysteresis to less than the wakeup latency.
+*
+* igt/gem_exec_nop/sequential provides a rough estimate for the
+* service latency, and puts it around 10us for Broadwell (and other
+* big core) and around 40us for Broxton (and other low power cores).
+* [Note that for legacy ringbuffer submission, this is less than 1us!]
+* However, the wakeup latency on Broxton is closer to 100us. To be
+* conservative, we have to factor in a context switch on top (due
+* to ksoftirqd).
+*/
+ I915_WRITE(GEN9_MEDIA_PG_IDLE_HYSTERESIS, 250);
+ I915_WRITE(GEN9_RENDER_PG_IDLE_HYSTERESIS, 250);
+
+ /* 3a: Enable RC6 */
+ I915_WRITE(GEN6_RC6_THRESHOLD, 37500); /* 37.5/125ms per EI */
+
+ I915_WRITE(GEN6_RC_CONTROL,
+ GEN6_RC_CTL_HW_ENABLE |
+ GEN6_RC_CTL_RC6_ENABLE |
+ GEN6_RC_CTL_EI_MODE(1));
+
+ /*
+* 3b: Enable Coarse Power Gating only when RC6 is enabled.
+*/
+ I915_WRITE(GEN9_PG_ENABLE,
+ GEN9_RENDER_PG_ENABLE | GEN9_MEDIA_PG_ENABLE);
+
+ intel_uncore_forcewake_put(_priv->uncore, FORCEWAKE_ALL);
+}
+
static void gen9_enable_rc6(struct drm_i915_private *dev_priv)
{
struct intel_engine_cs *engine;
@@ -8596,6 +8666,8 @@ static void intel_enable_rc6(struct drm_i915_private
*dev_priv)
cherryview_enable_rc6(dev_priv);
else if (IS_VALLEYVIEW(dev_priv))
valleyview_enable_rc6(dev_priv);
+ else if (INTEL_GEN(dev_priv) >= 11)
+ gen11_enable_rc6(dev_priv);
else if (INTEL_GEN(dev_priv) >= 9)
gen9_enable_rc6(dev_priv);
else if (IS_BROADWELL(dev_priv))
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/7] drm/i915/icl: Disable video turbo mode for rp control
There is no video turbo mode for gen11, so don't set it. Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/intel_pm.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 47f98e064de5..d6abba5c0b32 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -6548,6 +6548,7 @@ static void rps_set_power(struct drm_i915_private *dev_priv, int new_power) struct intel_rps *rps = _priv->gt_pm.rps; u32 threshold_up = 0, threshold_down = 0; /* in % */ u32 ei_up = 0, ei_down = 0; + u32 media_turbo; lockdep_assert_held(>power.mutex); @@ -6605,8 +6606,10 @@ static void rps_set_power(struct drm_i915_private *dev_priv, int new_power) GT_INTERVAL_FROM_US(dev_priv, ei_down * threshold_down / 100)); + media_turbo = INTEL_GEN(dev_priv) > 9 ? 0 : GEN6_RP_MEDIA_TURBO; + I915_WRITE(GEN6_RP_CONTROL, - GEN6_RP_MEDIA_TURBO | + media_turbo | GEN6_RP_MEDIA_HW_NORMAL_MODE | GEN6_RP_MEDIA_IS_GFX | GEN6_RP_ENABLE | -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/7] drm/i915/icl: Apply recommended rc6 idle hysteresis
Use a recommended idle hysteresis for media and render powergates. References: bspec#52070 Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/intel_pm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 30ef507b88a4..b9be9ea5fc18 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -7170,8 +7170,8 @@ static void gen11_enable_rc6(struct drm_i915_private *dev_priv) * conservative, we have to factor in a context switch on top (due * to ksoftirqd). */ - I915_WRITE(GEN9_MEDIA_PG_IDLE_HYSTERESIS, 250); - I915_WRITE(GEN9_RENDER_PG_IDLE_HYSTERESIS, 250); + I915_WRITE(GEN9_MEDIA_PG_IDLE_HYSTERESIS, 25); + I915_WRITE(GEN9_RENDER_PG_IDLE_HYSTERESIS, 25); /* 3a: Enable RC6 */ I915_WRITE(GEN6_RC6_THRESHOLD, 5); /* 50/125ms per EI */ -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/7] drm/i915/icl: Handle rps interrupts without irq lock
Unlike previous gens, we already hold the irq_lock on
entering the rps handler so we can't use it as it is.
Make a gen11 specific rps interrupt handler without
locking.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_irq.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 6454ddc37f8b..619e6ab273e7 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1796,6 +1796,22 @@ static void i9xx_pipe_crc_irq_handler(struct
drm_i915_private *dev_priv,
/* The RPS events need forcewake, so we add them to a work queue and mask their
* IMR bits until the work is done. Other interrupts can be processed without
* the work queue. */
+static void gen11_rps_irq_handler(struct drm_i915_private *i915, u32 pm_iir)
+{
+ struct intel_rps *rps = >gt_pm.rps;
+ const u32 events = i915->pm_rps_events & pm_iir;
+
+ lockdep_assert_held(>irq_lock);
+
+ if (events) {
+ gen6_mask_pm_irq(i915, events);
+ if (rps->interrupts_enabled) {
+ rps->pm_iir |= events;
+ schedule_work(>work);
+ }
+ }
+}
+
static void gen6_rps_irq_handler(struct drm_i915_private *dev_priv, u32 pm_iir)
{
struct intel_rps *rps = _priv->gt_pm.rps;
@@ -2949,7 +2965,7 @@ gen11_other_irq_handler(struct drm_i915_private * const
i915,
const u8 instance, const u16 iir)
{
if (instance == OTHER_GTPM_INSTANCE)
- return gen6_rps_irq_handler(i915, iir);
+ return gen11_rps_irq_handler(i915, iir);
WARN_ONCE(1, "unhandled other interrupt instance=0x%x, iir=0x%x\n",
instance, iir);
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/7] drm/i915: Use Engine1 instance for gen11 pm interrupts
With gen11 the interrupt registers are shared between 2 engines,
with Engine1 instance being upper word and Engine0 instance being
lower. Annoyingly gen11 selected the pm interrupts to be in the
Engine1 instance.
Rectify the situation by shifting the access accordingly,
based on gen.
Bugzilla: https://bugzilla.freedesktop.org/show_bug.cgi?id=108059
Testcase: igt/i915_pm_rps@min-max-config-loaded
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_irq.c | 50 +
1 file changed, 32 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 619e6ab273e7..be501e069b60 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -369,24 +369,39 @@ static i915_reg_t gen6_pm_iir(struct drm_i915_private
*dev_priv)
return INTEL_GEN(dev_priv) >= 8 ? GEN8_GT_IIR(2) : GEN6_PMIIR;
}
-static i915_reg_t gen6_pm_imr(struct drm_i915_private *dev_priv)
+static void write_pm_imr(struct drm_i915_private *dev_priv)
{
- if (INTEL_GEN(dev_priv) >= 11)
- return GEN11_GPM_WGBOXPERF_INTR_MASK;
- else if (INTEL_GEN(dev_priv) >= 8)
- return GEN8_GT_IMR(2);
- else
- return GEN6_PMIMR;
+ i915_reg_t reg;
+ u32 mask = dev_priv->pm_imr;
+
+ if (INTEL_GEN(dev_priv) >= 11) {
+ reg = GEN11_GPM_WGBOXPERF_INTR_MASK;
+ mask = mask << 16;
+ } else if (INTEL_GEN(dev_priv) >= 8) {
+ reg = GEN8_GT_IMR(2);
+ } else {
+ reg = GEN6_PMIMR;
+ }
+
+ I915_WRITE(reg, mask);
+ POSTING_READ(reg);
}
-static i915_reg_t gen6_pm_ier(struct drm_i915_private *dev_priv)
+static void write_pm_ier(struct drm_i915_private *dev_priv)
{
- if (INTEL_GEN(dev_priv) >= 11)
- return GEN11_GPM_WGBOXPERF_INTR_ENABLE;
- else if (INTEL_GEN(dev_priv) >= 8)
- return GEN8_GT_IER(2);
- else
- return GEN6_PMIER;
+ i915_reg_t reg;
+ u32 mask = dev_priv->pm_ier;
+
+ if (INTEL_GEN(dev_priv) >= 11) {
+ reg = GEN11_GPM_WGBOXPERF_INTR_ENABLE;
+ mask = mask << 16;
+ } else if (INTEL_GEN(dev_priv) >= 8) {
+ reg = GEN8_GT_IER(2);
+ } else {
+ reg = GEN6_PMIER;
+ }
+
+ I915_WRITE(reg, mask);
}
/**
@@ -411,8 +426,7 @@ static void snb_update_pm_irq(struct drm_i915_private
*dev_priv,
if (new_val != dev_priv->pm_imr) {
dev_priv->pm_imr = new_val;
- I915_WRITE(gen6_pm_imr(dev_priv), dev_priv->pm_imr);
- POSTING_READ(gen6_pm_imr(dev_priv));
+ write_pm_imr(dev_priv);
}
}
@@ -453,7 +467,7 @@ static void gen6_enable_pm_irq(struct drm_i915_private
*dev_priv, u32 enable_mas
lockdep_assert_held(_priv->irq_lock);
dev_priv->pm_ier |= enable_mask;
- I915_WRITE(gen6_pm_ier(dev_priv), dev_priv->pm_ier);
+ write_pm_ier(dev_priv);
gen6_unmask_pm_irq(dev_priv, enable_mask);
/* unmask_pm_irq provides an implicit barrier (POSTING_READ) */
}
@@ -464,7 +478,7 @@ static void gen6_disable_pm_irq(struct drm_i915_private
*dev_priv, u32 disable_m
dev_priv->pm_ier &= ~disable_mask;
__gen6_mask_pm_irq(dev_priv, disable_mask);
- I915_WRITE(gen6_pm_ier(dev_priv), dev_priv->pm_ier);
+ write_pm_ier(dev_priv);
/* though a barrier is missing here, but don't really need a one */
}
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/7] drm/i915/icl: Apply a recommended rc6 threshold
On gen11 the recommended rc6 threshold differs from previous gens, apply it. References: bspec#52070 Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/intel_pm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 43ec0fb4c197..30ef507b88a4 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -7174,7 +7174,7 @@ static void gen11_enable_rc6(struct drm_i915_private *dev_priv) I915_WRITE(GEN9_RENDER_PG_IDLE_HYSTERESIS, 250); /* 3a: Enable RC6 */ - I915_WRITE(GEN6_RC6_THRESHOLD, 37500); /* 37.5/125ms per EI */ + I915_WRITE(GEN6_RC6_THRESHOLD, 5); /* 50/125ms per EI */ I915_WRITE(GEN6_RC_CONTROL, GEN6_RC_CTL_HW_ENABLE | -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/7] drm/i915/icl: Enable media sampler powergate
Enable media sampler powergate as recommended.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_reg.h | 5 +++--
drivers/gpu/drm/i915/intel_pm.c | 4 +++-
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 9c206e803ab3..20f5850c52f8 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8687,8 +8687,9 @@ enum {
#define GEN9_MEDIA_PG_IDLE_HYSTERESIS _MMIO(0xA0C4)
#define GEN9_RENDER_PG_IDLE_HYSTERESIS _MMIO(0xA0C8)
#define GEN9_PG_ENABLE _MMIO(0xA210)
-#define GEN9_RENDER_PG_ENABLE (1 << 0)
-#define GEN9_MEDIA_PG_ENABLE (1 << 1)
+#define GEN9_RENDER_PG_ENABLE BIT(0)
+#define GEN9_MEDIA_PG_ENABLE BIT(1)
+#define GEN11_MEDIA_SAMPLER_PG_ENABLE BIT(2)
#define GEN8_PUSHBUS_CONTROL _MMIO(0xA248)
#define GEN8_PUSHBUS_ENABLE_MMIO(0xA250)
#define GEN8_PUSHBUS_SHIFT _MMIO(0xA25C)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index b9be9ea5fc18..47f98e064de5 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -7185,7 +7185,9 @@ static void gen11_enable_rc6(struct drm_i915_private
*dev_priv)
* 3b: Enable Coarse Power Gating only when RC6 is enabled.
*/
I915_WRITE(GEN9_PG_ENABLE,
- GEN9_RENDER_PG_ENABLE | GEN9_MEDIA_PG_ENABLE);
+ GEN9_RENDER_PG_ENABLE |
+ GEN9_MEDIA_PG_ENABLE |
+ GEN11_MEDIA_SAMPLER_PG_ENABLE);
intel_uncore_forcewake_put(_priv->uncore, FORCEWAKE_ALL);
}
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Update HDMI max TMDS data rate definition for VBT
On Tue, Apr 09, 2019 at 03:46:20PM +, Chiou, Cooper wrote:
> Hi Ville,
>
> The bits is 5-7 means it’s 001x for 2.97Gbps, and 010x for 1.65Gbps.
> So correct value should be 2 not 1 for HDMI_MAX_DATA_RATE_297.
No. The bitfield is defined as something:3.
> And HDMI_MAX_DATA_RATE_165 is 4 not 2.
>
> I checked kernel i915 log and modified VBT to limit HDMI 1.4 from HDMI 2.0
> then found this error. And I run CrOS on GLK with changed VBT to validate it.
> Thanks,
>
> Best Regards,
> Cooper
>
> On Apr 9, 2019, at 8:45 PM, Ville Syrjälä
> mailto:ville.syrj...@linux.intel.com>> wrote:
>
> On Tue, Apr 09, 2019 at 06:07:08PM +0800, Chiou, Cooper wrote:
> VBT version 212 defined HDMI max. bit-rate 2.97Gbps is 0x02 and 1.65Gbps
> is 0x04, so changed HDMI_MAX_DATA_RATE_297/HDMI_MAX_DATA_RATE_165 to map
> correct values
>
> Eh what? Did someone just change the interpretation of these bits?
>
> Per VBT BSpec definition in HDMI max. data rate, Bits7-5 is HDMI max. data
> rate 000=Default, 001=2.97Gbps, 010=1.65Gbps,
>
> Here you're quoting the values we already use...
>
> so HDMI_MAX_DATA_RATE_297
> should be 2 and HDMI_MAX_DATA_RATE_165 should be 4
>
> ...but here you're using different values again? Which way is it?
>
>
> TEST: Validated PASS on GLK RVP platform
>
> Cc: Jani Nikula mailto:jani.nik...@intel.com>>
> Signed-off-by: Chiou, Cooper
> mailto:cooper.ch...@intel.com>>
> ---
> drivers/gpu/drm/i915/intel_vbt_defs.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h
> b/drivers/gpu/drm/i915/intel_vbt_defs.h
> index bf3662ad5fed..e2b8d042912b 100644
> --- a/drivers/gpu/drm/i915/intel_vbt_defs.h
> +++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
> @@ -307,8 +307,8 @@ struct bdb_general_features {
> #define DVO_PORT_MIPID24/* 171 */
>
> #define HDMI_MAX_DATA_RATE_PLATFORM0/* 204 */
> -#define HDMI_MAX_DATA_RATE_2971/* 204 */
> -#define HDMI_MAX_DATA_RATE_1652/* 204 */
> +#define HDMI_MAX_DATA_RATE_2972/* 212 */
> +#define HDMI_MAX_DATA_RATE_1654/* 212 */
>
> #define LEGACY_CHILD_DEVICE_CONFIG_SIZE33
>
> --
> 2.7.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Ville Syrjälä
> Intel
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: adding state checker for gamma lut values (rev3)
== Series Details == Series: drm/i915: adding state checker for gamma lut values (rev3) URL : https://patchwork.freedesktop.org/series/58039/ State : failure == Summary == Applying: drm/i915: Introduce vfunc intel_get_color_config to create hw lut Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_drv.h M drivers/gpu/drm/i915/intel_color.c M drivers/gpu/drm/i915/intel_drv.h Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/intel_drv.h CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_drv.h Auto-merging drivers/gpu/drm/i915/intel_color.c Auto-merging drivers/gpu/drm/i915/i915_drv.h error: Failed to merge in the changes. hint: Use 'git am --show-current-patch' to see the failed patch Patch failed at 0001 drm/i915: Introduce vfunc intel_get_color_config to create hw lut When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for adding state checker for gamma lut values
== Series Details == Series: adding state checker for gamma lut values URL : https://patchwork.freedesktop.org/series/59226/ State : failure == Summary == Applying: drm/i915: Introduce vfunc intel_get_color_config to create hw lut Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_drv.h M drivers/gpu/drm/i915/intel_color.c M drivers/gpu/drm/i915/intel_drv.h Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/intel_drv.h CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_drv.h Auto-merging drivers/gpu/drm/i915/intel_color.c Auto-merging drivers/gpu/drm/i915/i915_drv.h error: Failed to merge in the changes. hint: Use 'git am --show-current-patch' to see the failed patch Patch failed at 0001 drm/i915: Introduce vfunc intel_get_color_config to create hw lut When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] Core-for-CI:ICL_only Disable ACPI idle driver
On 4/9/2019 8:29 AM, Anshuman Gupta wrote:
There were few system hung observed while running i915_pm_rpm igt test.
FDO https://bugs.freedesktop.org/show_bug.cgi?id=108840
Root cause is believed to due to page fault in ACPI idle driver.
(FDO comment 18).
It has been suggested by Daniel Vetter to disable ACPI idle
driver for Core-for-CI, only for ICL.
This hacky patch is only for ICL processor and for Core-for-CI branch.
v2: Fixed compilation errors raised by lkp.
commit message improvement.
Cc: martin.pe...@intel.com
Cc: daniel.vet...@intel.com
Signed-off-by: Anshuman Gupta
This is fine only as long as it doesn't anywhere close to the mainline.
If ACPI idle crashes on new Intel HW, it needs to be fixed to work with
it instead of refusing to work on it.
---
drivers/acpi/processor_driver.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
index 9d6aff2..ee842a2f 100644
--- a/drivers/acpi/processor_driver.c
+++ b/drivers/acpi/processor_driver.c
@@ -35,6 +35,12 @@
#include
+/* Only for Core-for-CI so don't want ia64 to fail compilation.*/
+#ifdef CONFIG_X86
+#include
+#include
+#endif
+
#include "internal.h"
#define ACPI_PROCESSOR_NOTIFY_PERFORMANCE 0x80
@@ -58,6 +64,13 @@ static const struct acpi_device_id processor_device_ids[] = {
};
MODULE_DEVICE_TABLE(acpi, processor_device_ids);
+#define ICPU(model) { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, }
+static const struct x86_cpu_id intel_cpu_ids[] = {
+ ICPU(INTEL_FAM6_ICELAKE_MOBILE),/* ICL */
+ {}
+};
+MODULE_DEVICE_TABLE(x86cpu, intel_cpu_ids);
+
static struct device_driver acpi_processor_driver = {
.name = "processor",
.bus = _subsys,
@@ -226,6 +239,7 @@ static inline void acpi_pss_perf_exit(struct acpi_processor
*pr,
static int __acpi_processor_start(struct acpi_device *device)
{
struct acpi_processor *pr = acpi_driver_data(device);
+ const struct x86_cpu_id *id;
acpi_status status;
int result = 0;
@@ -239,7 +253,9 @@ static int __acpi_processor_start(struct acpi_device *device)
if (result && !IS_ENABLED(CONFIG_ACPI_CPU_FREQ_PSS))
dev_dbg(>dev, "CPPC data invalid or not present\n");
- if (!cpuidle_get_driver() || cpuidle_get_driver() == _idle_driver)
+ id = x86_match_cpu(intel_cpu_ids);
+ if (!id && (!cpuidle_get_driver() || cpuidle_get_driver() ==
+ _idle_driver))
acpi_processor_power_init(pr);
result = acpi_pss_perf_init(pr, device);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Update HDMI max TMDS data rate definition for VBT
Hi Ville,
The bits is 5-7 means it’s 001x for 2.97Gbps, and 010x for 1.65Gbps.
So correct value should be 2 not 1 for HDMI_MAX_DATA_RATE_297.
And HDMI_MAX_DATA_RATE_165 is 4 not 2.
I checked kernel i915 log and modified VBT to limit HDMI 1.4 from HDMI 2.0 then
found this error. And I run CrOS on GLK with changed VBT to validate it. Thanks,
Best Regards,
Cooper
On Apr 9, 2019, at 8:45 PM, Ville Syrjälä
mailto:ville.syrj...@linux.intel.com>> wrote:
On Tue, Apr 09, 2019 at 06:07:08PM +0800, Chiou, Cooper wrote:
VBT version 212 defined HDMI max. bit-rate 2.97Gbps is 0x02 and 1.65Gbps
is 0x04, so changed HDMI_MAX_DATA_RATE_297/HDMI_MAX_DATA_RATE_165 to map
correct values
Eh what? Did someone just change the interpretation of these bits?
Per VBT BSpec definition in HDMI max. data rate, Bits7-5 is HDMI max. data
rate 000=Default, 001=2.97Gbps, 010=1.65Gbps,
Here you're quoting the values we already use...
so HDMI_MAX_DATA_RATE_297
should be 2 and HDMI_MAX_DATA_RATE_165 should be 4
...but here you're using different values again? Which way is it?
TEST: Validated PASS on GLK RVP platform
Cc: Jani Nikula mailto:jani.nik...@intel.com>>
Signed-off-by: Chiou, Cooper
mailto:cooper.ch...@intel.com>>
---
drivers/gpu/drm/i915/intel_vbt_defs.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h
b/drivers/gpu/drm/i915/intel_vbt_defs.h
index bf3662ad5fed..e2b8d042912b 100644
--- a/drivers/gpu/drm/i915/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
@@ -307,8 +307,8 @@ struct bdb_general_features {
#define DVO_PORT_MIPID24/* 171 */
#define HDMI_MAX_DATA_RATE_PLATFORM0/* 204 */
-#define HDMI_MAX_DATA_RATE_2971/* 204 */
-#define HDMI_MAX_DATA_RATE_1652/* 204 */
+#define HDMI_MAX_DATA_RATE_2972/* 212 */
+#define HDMI_MAX_DATA_RATE_1654/* 212 */
#define LEGACY_CHILD_DEVICE_CONFIG_SIZE33
--
2.7.4
___
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 v2] drm/i915: Bump ready tasks ahead of busywaits
Quoting Tvrtko Ursulin (2019-04-09 16:38:37) > > On 09/04/2019 16:29, Chris Wilson wrote: > > Consider two tasks that are running in parallel on a pair of engines > > (vcs0, vcs1), but then must complete on a shared engine (rcs0). To > > maximise throughput, we want to run the first ready task on rcs0 (i.e. > > the first task that completes on either of vcs0 or vcs1). When using > > semaphores, however, we will instead queue onto rcs in submission order. > > > > To resolve this incorrect ordering, we want to re-evaluate the priority > > queue when each of the request is ready. Normally this happens because > > we only insert into the priority queue requests that are ready, but with > > semaphores we are inserting ahead of their readiness and to compensate > > we penalize those tasks with reduced priority (so that tasks that do not > > need to busywait should naturally be run first). However, given a series > > of tasks that each use semaphores, the queue degrades into submission > > fifo rather than readiness fifo, and so to counter this we give a small > > boost to semaphore users as their dependent tasks are completed (and so > > we no longer require any busywait prior to running the user task as they > > are then ready themselves). > > > > v2: Fixup irqsave for schedule_lock (Tvrtko) > > > > Testcase: igt/gem_exec_schedule/semaphore-codependency > > Signed-off-by: Chris Wilson > > Cc: Tvrtko Ursulin > > Cc: Dmitry Rogozhkin > > Cc: Dmitry Ermilov > > --- [snip] > Looks fine to me. Provisional r-b: > > Reviewed-by: Tvrtko Ursulin > > But let's wait for a media benchmarking run to see if you have nailed > the regression. Aye, but we need something like this regardless as introducing a trivial dos is not good behaviour either. Hopefully, this will evolve into something a lot more elegant. For now, it is just another lesson learnt. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] i915/gem_exec_schedule: Trick semaphores into a GPU hang
On 09/04/2019 14:56, Chris Wilson wrote:
If we have two tasks running on xcs0 and xcs1 independently, but who
queue subsequent work onto rcs, we may insert semaphores before the rcs
work and pick unwisely which task to run first. To maximise throughput,
we want to run on rcs whichever task is ready first. Conversely, if we
pick wrongly that can be used to trigger a GPU hang with unaware
userspace.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tests/i915/gem_exec_schedule.c | 61 ++
1 file changed, 61 insertions(+)
diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/gem_exec_schedule.c
index 3df319bcc..d6f109540 100644
--- a/tests/i915/gem_exec_schedule.c
+++ b/tests/i915/gem_exec_schedule.c
@@ -404,6 +404,65 @@ static void semaphore_userlock(int i915)
igt_spin_batch_free(i915, spin);
}
+static void semaphore_codependency(int i915)
+{
+ struct {
+ igt_spin_t *xcs, *rcs;
+ } task[2];
+ unsigned int engine;
+ int i;
+
+ /*
+* Consider two tasks, task A runs on (xcs0, rcs0) and task B
+* on (xcs1, rcs0). That is they must both run a dependent
+* batch on rcs0, after first running in parallel on separate
+* engines. To maximise throughput, we want the shorter xcs task
+* to start on rcs first. However, if we insert semaphores we may
+* pick wrongly and end up running the requests in the least
+* optimal order.
+*/
+
+ i = 0;
+ for_each_physical_engine(i915, engine) {
+ uint32_t ctx;
+
+ if (engine == I915_EXEC_RENDER)
+ continue;
+
+ ctx = gem_context_create(i915);
+
+ task[i].xcs =
+ __igt_spin_batch_new(i915,
+.ctx = ctx,
+.engine = engine,
+.flags = IGT_SPIN_POLL_RUN);
+ igt_spin_busywait_until_running(task[i].xcs);
+
+ /* Common rcs tasks will be queued in FIFO */
+ task[i].rcs =
+ __igt_spin_batch_new(i915,
+.ctx = ctx,
+.engine = I915_EXEC_RENDER,
+.dependency = task[i].xcs->handle);
+
+ gem_context_destroy(i915, ctx);
+
+ if (++i == ARRAY_SIZE(task))
+ break;
+ }
+ igt_require(i == ARRAY_SIZE(task));
+
+ /* Since task[0] was queued first, it will be first in queue for rcs */
+ igt_spin_batch_end(task[1].xcs);
+ igt_spin_batch_end(task[1].rcs);
+ gem_sync(i915, task[1].rcs->handle); /* to hang if task[0] hogs rcs */
+
+ for (i = 0; i < ARRAY_SIZE(task); i++) {
+ igt_spin_batch_free(i915, task[i].xcs);
+ igt_spin_batch_free(i915, task[i].rcs);
+ }
+}
+
static void reorder(int fd, unsigned ring, unsigned flags)
#define EQUAL 1
{
@@ -1393,6 +1452,8 @@ igt_main
igt_subtest("semaphore-user")
semaphore_userlock(fd);
+ igt_subtest("semaphore-codependency")
+ semaphore_codependency(fd);
igt_subtest("smoketest-all")
smoketest(fd, ALL_ENGINES, 30);
Just need can_store_dword for code correctness before IGT_SPIN_POLL_RUN
and with that:
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Bump ready tasks ahead of busywaits
On 09/04/2019 16:29, Chris Wilson wrote:
Consider two tasks that are running in parallel on a pair of engines
(vcs0, vcs1), but then must complete on a shared engine (rcs0). To
maximise throughput, we want to run the first ready task on rcs0 (i.e.
the first task that completes on either of vcs0 or vcs1). When using
semaphores, however, we will instead queue onto rcs in submission order.
To resolve this incorrect ordering, we want to re-evaluate the priority
queue when each of the request is ready. Normally this happens because
we only insert into the priority queue requests that are ready, but with
semaphores we are inserting ahead of their readiness and to compensate
we penalize those tasks with reduced priority (so that tasks that do not
need to busywait should naturally be run first). However, given a series
of tasks that each use semaphores, the queue degrades into submission
fifo rather than readiness fifo, and so to counter this we give a small
boost to semaphore users as their dependent tasks are completed (and so
we no longer require any busywait prior to running the user task as they
are then ready themselves).
v2: Fixup irqsave for schedule_lock (Tvrtko)
Testcase: igt/gem_exec_schedule/semaphore-codependency
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Dmitry Rogozhkin
Cc: Dmitry Ermilov
---
drivers/gpu/drm/i915/i915_request.c | 40 +++
drivers/gpu/drm/i915/i915_request.h | 1 +
drivers/gpu/drm/i915/i915_scheduler.c | 21 +++---
3 files changed, 52 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 96a9e8bcd805..a7d87cfaabcb 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -552,6 +552,36 @@ submit_notify(struct i915_sw_fence *fence, enum
i915_sw_fence_notify state)
return NOTIFY_DONE;
}
+static int __i915_sw_fence_call
+semaphore_notify(struct i915_sw_fence *fence, enum i915_sw_fence_notify state)
+{
+ struct i915_request *request =
+ container_of(fence, typeof(*request), semaphore);
+
+ switch (state) {
+ case FENCE_COMPLETE:
+ /*
+* We only check a small portion of our dependencies
+* and so cannot guarantee that there remains no
+* semaphore chain across all. Instead of opting
+* for the full NOSEMAPHORE boost, we go for the
+* smaller (but still preempting) boost of
+* NEWCLIENT. This will be enough to boost over
+* a busywaiting request (as that cannot be
+* NEWCLIENT) without accidentally boosting
+* a busywait over real work elsewhere.
+*/
+ i915_schedule_bump_priority(request, I915_PRIORITY_NEWCLIENT);
+ break;
+
+ case FENCE_FREE:
+ i915_request_put(request);
+ break;
+ }
+
+ return NOTIFY_DONE;
+}
+
static void ring_retire_requests(struct intel_ring *ring)
{
struct i915_request *rq, *rn;
@@ -702,6 +732,7 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
/* We bump the ref for the fence chain */
i915_sw_fence_init(_request_get(rq)->submit, submit_notify);
+ i915_sw_fence_init(_request_get(rq)->semaphore, semaphore_notify);
i915_sched_node_init(>sched);
@@ -784,6 +815,12 @@ emit_semaphore_wait(struct i915_request *to,
>fence, 0,
I915_FENCE_GFP);
+ err = i915_sw_fence_await_dma_fence(>semaphore,
+ >fence, 0,
+ I915_FENCE_GFP);
+ if (err < 0)
+ return err;
+
/* We need to pin the signaler's HWSP until we are finished reading. */
err = i915_timeline_read_hwsp(from, to, _offset);
if (err)
@@ -1114,6 +1151,7 @@ void i915_request_add(struct i915_request *request)
* run at the earliest possible convenience.
*/
local_bh_disable();
+ i915_sw_fence_commit(>semaphore);
rcu_read_lock(); /* RCU serialisation for set-wedged protection */
if (engine->schedule) {
struct i915_sched_attr attr = request->gem_context->sched;
@@ -1320,7 +1358,9 @@ long i915_request_wait(struct i915_request *rq,
if (flags & I915_WAIT_PRIORITY) {
if (!i915_request_started(rq) && INTEL_GEN(rq->i915) >= 6)
gen6_rps_boost(rq);
+ local_bh_disable(); /* suspend tasklets for reprioritisation */
i915_schedule_bump_priority(rq, I915_PRIORITY_WAIT);
+ local_bh_enable(); /* kick tasklets en masse */
}
wait.tsk = current;
diff --git a/drivers/gpu/drm/i915/i915_request.h
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Update HDMI max TMDS data rate definition for VBT
== Series Details == Series: drm/i915: Update HDMI max TMDS data rate definition for VBT URL : https://patchwork.freedesktop.org/series/59220/ State : success == Summary == CI Bug Log - changes from CI_DRM_5895_full -> Patchwork_12736_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12736_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_busy@extended-bsd1: - shard-iclb: NOTRUN -> SKIP [fdo#109276] +8 * igt@gem_exec_parse@oacontrol-tracking: - shard-iclb: NOTRUN -> SKIP [fdo#109289] +1 * igt@gem_ppgtt@blt-vs-render-ctx0: - shard-iclb: PASS -> INCOMPLETE [fdo#109801] * igt@gem_pwrite@huge-cpu-backwards: - shard-iclb: NOTRUN -> SKIP [fdo#109290] * igt@i915_pm_rpm@modeset-non-lpsp-stress: - shard-iclb: NOTRUN -> SKIP [fdo#109308] * igt@i915_suspend@forcewake: - shard-skl: PASS -> INCOMPLETE [fdo#104108] / [fdo#107773] - shard-kbl: PASS -> DMESG-WARN [fdo#108566] * igt@kms_atomic_transition@6x-modeset-transitions: - shard-iclb: NOTRUN -> SKIP [fdo#109278] +3 * igt@kms_busy@extended-modeset-hang-oldfb-render-f: - shard-skl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +7 * igt@kms_chamelium@hdmi-hpd-after-suspend: - shard-iclb: NOTRUN -> SKIP [fdo#109284] +1 * igt@kms_content_protection@atomic-dpms: - shard-apl: NOTRUN -> FAIL [fdo#110321] / [fdo#110336] * igt@kms_cursor_crc@cursor-128x42-onscreen: - shard-apl: NOTRUN -> FAIL [fdo#103232] * igt@kms_cursor_crc@cursor-256x256-random: - shard-skl: NOTRUN -> FAIL [fdo#103232] * igt@kms_cursor_legacy@cursor-vs-flip-varying-size: - shard-iclb: PASS -> FAIL [fdo#103355] * igt@kms_fbcon_fbt@psr: - shard-skl: NOTRUN -> FAIL [fdo#103833] * igt@kms_flip@2x-plain-flip-ts-check: - shard-apl: NOTRUN -> SKIP [fdo#109271] +156 * igt@kms_flip@2x-plain-flip-ts-check-interruptible: - shard-iclb: NOTRUN -> SKIP [fdo#109274] +6 * igt@kms_force_connector_basic@prune-stale-modes: - shard-iclb: NOTRUN -> SKIP [fdo#109285] * igt@kms_frontbuffer_tracking@basic: - shard-iclb: NOTRUN -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-rgb565-draw-pwrite: - shard-iclb: PASS -> FAIL [fdo#103167] +1 * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-mmap-gtt: - shard-iclb: PASS -> FAIL [fdo#109247] +7 * igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-cur-indfb-onoff: - shard-iclb: NOTRUN -> SKIP [fdo#109280] +12 * igt@kms_lease@atomic_implicit_crtc: - shard-kbl: NOTRUN -> FAIL [fdo#110279] * igt@kms_lease@setcrtc_implicit_plane: - shard-kbl: NOTRUN -> FAIL [fdo#110281] * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-d: - shard-apl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +13 * igt@kms_plane_alpha_blend@pipe-a-alpha-basic: - shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145] - shard-kbl: NOTRUN -> FAIL [fdo#108145] / [fdo#108590] * igt@kms_plane_alpha_blend@pipe-b-alpha-7efc: - shard-apl: NOTRUN -> FAIL [fdo#108145] +2 * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min: - shard-skl: NOTRUN -> FAIL [fdo#108145] +1 * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: PASS -> FAIL [fdo#107815] * igt@kms_plane_scaling@pipe-b-scaler-with-clipping-clamping: - shard-glk: PASS -> SKIP [fdo#109271] / [fdo#109278] * igt@kms_psr2_su@frontbuffer: - shard-iclb: PASS -> SKIP [fdo#109642] * igt@kms_psr@primary_mmap_cpu: - shard-iclb: PASS -> FAIL [fdo#107383] / [fdo#110215] +2 * igt@kms_psr@psr2_dpms: - shard-iclb: NOTRUN -> SKIP [fdo#109441] * igt@kms_psr@psr2_primary_mmap_gtt: - shard-iclb: PASS -> SKIP [fdo#109441] +1 * igt@kms_rotation_crc@multiplane-rotation-cropping-bottom: - shard-kbl: PASS -> DMESG-FAIL [fdo#105763] * igt@kms_setmode@basic: - shard-kbl: PASS -> FAIL [fdo#99912] * igt@kms_universal_plane@disable-primary-vs-flip-pipe-d: - shard-kbl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +12 * igt@kms_vblank@pipe-b-ts-continuation-dpms-suspend: - shard-skl: PASS -> INCOMPLETE [fdo#104108] * igt@kms_vblank@pipe-c-ts-continuation-suspend: - shard-iclb: PASS -> FAIL [fdo#104894] * igt@perf_pmu@busy-accuracy-50-vcs1: - shard-skl: NOTRUN -> SKIP [fdo#109271] +104 * igt@tools_test@sysfs_l3_parity: - shard-iclb: NOTRUN -> SKIP [fdo#109307] * igt@v3d_get_param@get-bad-param: - shard-iclb: NOTRUN -> SKIP [fdo#109315] *
