[Intel-gfx] [PATCH] drm/i915: If the first pin in map_ggtt doesn't success, try again
Being unable to find a hole in the mappable aperture, should only be
possible if the entire aperture is *pinned*. Our pins are shortlived,
only taken while binding and constructing batches/mappings, so if we
find no room try again. There are a few semi-permanent pins for rings,
contexts, page tables which take a little longer to be released, but for
our Haswell failure case, should not be the issue.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111530
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index e0bfc021ec6f..3c046803fc61 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -280,7 +280,9 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
}
/* The entire mappable GGTT is pinned? Unexpected! */
- GEM_BUG_ON(vma == ERR_PTR(-ENOSPC));
+ if (unlikely(vma == ERR_PTR(-ENOSPC)))
+ /* Pins *should* be transient, so try again */
+ vma = ERR_PTR(-EAGAIN);
}
if (IS_ERR(vma)) {
ret = PTR_ERR(vma);
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: adding state checker for gamma lut values (rev14)
== Series Details == Series: drm/i915: adding state checker for gamma lut values (rev14) URL : https://patchwork.freedesktop.org/series/58039/ State : success == Summary == CI Bug Log - changes from CI_DRM_6829_full -> Patchwork_14271_full Summary --- **WARNING** Minor unknown changes coming with Patchwork_14271_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_14271_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_14271_full: ### IGT changes ### Warnings * igt@kms_chamelium@hdmi-audio: - shard-kbl: [SKIP][1] ([fdo#109271]) -> [TIMEOUT][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6829/shard-kbl3/igt@kms_chamel...@hdmi-audio.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14271/shard-kbl6/igt@kms_chamel...@hdmi-audio.html Known issues Here are the changes found in Patchwork_14271_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_switch@queue-light: - shard-apl: [PASS][3] -> [INCOMPLETE][4] ([fdo#103927]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6829/shard-apl5/igt@gem_ctx_swi...@queue-light.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14271/shard-apl7/igt@gem_ctx_swi...@queue-light.html * igt@gem_exec_schedule@preemptive-hang-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#111325]) +7 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6829/shard-iclb3/igt@gem_exec_sched...@preemptive-hang-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14271/shard-iclb4/igt@gem_exec_sched...@preemptive-hang-bsd.html * igt@gem_exec_schedule@promotion-bsd1: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109276]) +12 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6829/shard-iclb2/igt@gem_exec_sched...@promotion-bsd1.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14271/shard-iclb3/igt@gem_exec_sched...@promotion-bsd1.html * igt@gem_workarounds@suspend-resume-fd: - shard-skl: [PASS][9] -> [INCOMPLETE][10] ([fdo#104108]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6829/shard-skl4/igt@gem_workarou...@suspend-resume-fd.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14271/shard-skl9/igt@gem_workarou...@suspend-resume-fd.html * igt@i915_pm_rc6_residency@rc6-accuracy: - shard-kbl: [PASS][11] -> [SKIP][12] ([fdo#109271]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6829/shard-kbl4/igt@i915_pm_rc6_reside...@rc6-accuracy.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14271/shard-kbl7/igt@i915_pm_rc6_reside...@rc6-accuracy.html * igt@kms_cursor_crc@pipe-a-cursor-128x128-random: - shard-skl: [PASS][13] -> [FAIL][14] ([fdo#103232]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6829/shard-skl8/igt@kms_cursor_...@pipe-a-cursor-128x128-random.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14271/shard-skl1/igt@kms_cursor_...@pipe-a-cursor-128x128-random.html * igt@kms_flip@2x-flip-vs-suspend: - shard-hsw: [PASS][15] -> [INCOMPLETE][16] ([fdo#103540]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6829/shard-hsw6/igt@kms_f...@2x-flip-vs-suspend.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14271/shard-hsw2/igt@kms_f...@2x-flip-vs-suspend.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-render: - shard-iclb: [PASS][17] -> [FAIL][18] ([fdo#103167]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6829/shard-iclb3/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-shrfb-draw-render.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14271/shard-iclb4/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-shrfb-draw-render.html * igt@kms_frontbuffer_tracking@fbc-suspend: - shard-apl: [PASS][19] -> [DMESG-WARN][20] ([fdo#108566]) +4 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6829/shard-apl5/igt@kms_frontbuffer_track...@fbc-suspend.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14271/shard-apl1/igt@kms_frontbuffer_track...@fbc-suspend.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-fullscreen: - shard-skl: [PASS][21] -> [FAIL][22] ([fdo#108040]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6829/shard-skl8/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-spr-indfb-fullscreen.html [22]:
Re: [Intel-gfx] [RFC 0/2] Enable Nearest-neighbor for Integer mode scaling
Hello Ville, On 9/3/2019 10:50 PM, Ville Syrjälä wrote: On Tue, Sep 03, 2019 at 10:22:25PM +0530, Shashank Sharma wrote: Blurry outputs during upscaling the buffer, is a generic problem of gfx industry. One of the major reason behind this blurriness is the interpolation of pixel values used by most of the upscaling hardwares. Nearest-neighbor is a scaling mode, which works by filling in the missing color values in the upscaled image with that of the coordinate-mapped nearest source pixel value. Nearest-neighbor can produce (almost) non-blurry scaling outputs when the scaling ratio is complete integer. For example: - input buffer resolution: 1280x720(HD) - output buffer resolution: 3840x2160(UHD/4K) - scaling ratio (h) = 3840/1280 = 3 scaling ratio (v) = 2160/720 = 3 In such scenarios, we should try to pick Nearest-neighbor as scaling method when possible. Many gaming communities have been asking for integer-mode scaling support, some links and background: https://software.intel.com/en-us/articles/integer-scaling-support-on-intel-graphics http://tanalin.com/en/articles/lossless-scaling/ https://community.amd.com/thread/209107 https://www.nvidia.com/en-us/geforce/forums/game-ready-drivers/13/1002/feature-request-nonblurry-upscaling-at-integer-rat/ This patch series enables NN scaling on Intel display (ICL), when the upscaling ratio is integer. I think we'd probably want a property for this sort of stuff. igt could perhaps also use it to enable crc based scaling tests. I was initially planning to attach this to scaling mode property, probably create a new option in there called "Integer mode scaling" or we can use the "maintain aspect ratio" sub-option too. Do you think it would make sense ? Or should we create a new property altogether ? Another problem is that we currently don't expose the panel fitter for external displays so this would be limited to eDP/DSI only. I have a branch that implements borders (for underscan) for DP/HDMI which is at least moving the code a little bit into a direction where we could consider exposing the panel fitter for external displays. This would be very interesting, do you have any plans to publish this soon ? - Shashank ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 3/7] drm/i915: protect access to DP_TP_* on non-dp
On Tue, 2019-09-03 at 10:16 -0700, Matt Roper wrote:
> On Thu, Aug 29, 2019 at 01:37:55PM +0300, Ville Syrjälä wrote:
> > On Thu, Aug 29, 2019 at 02:25:50AM -0700, Lucas De Marchi wrote:
> > > DP_TP_{CTL,STATUS} should only be programmed when the encoder is
> > > intel_dp.
> > > Checking its current usages intel_disable_ddi_buf() is the only
> > > offender, with other places being protected by checks like
> > > pipe_config->fec_enable that is only set by intel_dp.
> > >
> > > Cc: Ville Syrjälä
> > > Signed-off-by: Lucas De Marchi
> > > ---
> > > drivers/gpu/drm/i915/display/intel_ddi.c | 10 ++
> > > 1 file changed, 6 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > index 3180dacb5be4..df3e4fe7e3e9 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > @@ -3462,10 +3462,12 @@ static void intel_disable_ddi_buf(struct
> > > intel_encoder *encoder,
> > > wait = true;
> > > }
> > >
> > > - val = I915_READ(DP_TP_CTL(port));
> > > - val &= ~(DP_TP_CTL_ENABLE | DP_TP_CTL_LINK_TRAIN_MASK);
> > > - val |= DP_TP_CTL_LINK_TRAIN_PAT1;
> > > - I915_WRITE(DP_TP_CTL(port), val);
> > > + if (intel_encoder_is_dp(encoder)) {
> >
> > Doesn't really make sense to me. Either we just do it (because a
> > DDI is
> > just a DDI so DP_TP_CTL does exist always), or we only do it when
> > driving
> > DP and not when driving HDMI.
>
> I agree; I don't think there's a need to avoid program programming
> the
> register just because we weren't previously in DP mode.
The problem of always programing DP_TP_CTL comes with TGL, when
DP_TP_CTL() moves to transcoder, see next patch: drm/i915/tgl: move
DP_TP_* to transcoder.
We are adding intel_dp->regs.dp_tp_ctl and initializing(this is
necessary for MST for SST we could keep the current approach) it in DP
paths, we could move it to intel_encoder or intel_digital_port and
initialized it for HDMI too but it would not make any sense for someone
reading HDMI sequences.
And to move this to a DP specific function would force us to create
another function to execute the last "wait DDI_BUF_CTL to idle".
BSpec: 53339 and 22243
Personally I prefer this patch solution but let me know your thoughts
after this explanation.
>
> But I do question whether a RMW is necessary; it seems like just
> writing
> a constant 0 to this register would be sufficient for the disable
> sequence.
>
>
> Matt
>
> > For the latter I would perhaps suggest moving all this extra junk
> > out
> > from intel_disable_ddi_buf() into the DP specific code paths,
> > leaving
> > just the actual DDI_BUF_CTL disable here.
> >
> > > + val = I915_READ(DP_TP_CTL(port));
> > > + val &= ~(DP_TP_CTL_ENABLE | DP_TP_CTL_LINK_TRAIN_MASK);
> > > + val |= DP_TP_CTL_LINK_TRAIN_PAT1;
> > > + I915_WRITE(DP_TP_CTL(port), val);
> > > + }
> > >
> > > /* Disable FEC in DP Sink */
> > > intel_ddi_disable_fec_state(encoder, crtc_state);
> > > --
> > > 2.23.0
> >
> > --
> > 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.IGT: success for series starting with [1/3] drm/atomic: Take the atomic toys away from X
== Series Details == Series: series starting with [1/3] drm/atomic: Take the atomic toys away from X URL : https://patchwork.freedesktop.org/series/66180/ State : success == Summary == CI Bug Log - changes from CI_DRM_6828_full -> Patchwork_14270_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14270_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_balancer@smoke: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#110854]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6828/shard-iclb1/igt@gem_exec_balan...@smoke.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14270/shard-iclb6/igt@gem_exec_balan...@smoke.html * igt@gem_exec_schedule@pi-ringfull-render: - shard-apl: [PASS][3] -> [FAIL][4] ([fdo#111547]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6828/shard-apl4/igt@gem_exec_sched...@pi-ringfull-render.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14270/shard-apl8/igt@gem_exec_sched...@pi-ringfull-render.html * igt@gem_exec_schedule@preempt-self-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#111325]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6828/shard-iclb5/igt@gem_exec_sched...@preempt-self-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14270/shard-iclb4/igt@gem_exec_sched...@preempt-self-bsd.html * igt@gem_exec_suspend@basic-s3: - shard-skl: [PASS][7] -> [INCOMPLETE][8] ([fdo#104108]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6828/shard-skl8/igt@gem_exec_susp...@basic-s3.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14270/shard-skl1/igt@gem_exec_susp...@basic-s3.html * igt@gem_ppgtt@blt-vs-render-ctxn: - shard-iclb: [PASS][9] -> [INCOMPLETE][10] ([fdo#107713] / [fdo#109801]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6828/shard-iclb8/igt@gem_pp...@blt-vs-render-ctxn.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14270/shard-iclb7/igt@gem_pp...@blt-vs-render-ctxn.html * igt@i915_pm_rpm@gem-evict-pwrite: - shard-hsw: [PASS][11] -> [FAIL][12] ([fdo#111548]) +3 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6828/shard-hsw7/igt@i915_pm_...@gem-evict-pwrite.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14270/shard-hsw7/igt@i915_pm_...@gem-evict-pwrite.html * igt@kms_cursor_crc@pipe-b-cursor-suspend: - shard-skl: [PASS][13] -> [INCOMPLETE][14] ([fdo#110741]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6828/shard-skl2/igt@kms_cursor_...@pipe-b-cursor-suspend.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14270/shard-skl9/igt@kms_cursor_...@pipe-b-cursor-suspend.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-hsw: [PASS][15] -> [FAIL][16] ([fdo#103375]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6828/shard-hsw4/igt@kms_cursor_...@pipe-c-cursor-suspend.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14270/shard-hsw7/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_cursor_edge_walk@pipe-b-64x64-top-edge: - shard-snb: [PASS][17] -> [SKIP][18] ([fdo#109271] / [fdo#109278]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6828/shard-snb2/igt@kms_cursor_edge_w...@pipe-b-64x64-top-edge.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14270/shard-snb1/igt@kms_cursor_edge_w...@pipe-b-64x64-top-edge.html * igt@kms_cursor_legacy@short-flip-after-cursor-atomic-transitions-varying-size: - shard-hsw: [PASS][19] -> [INCOMPLETE][20] ([fdo#103540]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6828/shard-hsw6/igt@kms_cursor_leg...@short-flip-after-cursor-atomic-transitions-varying-size.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14270/shard-hsw5/igt@kms_cursor_leg...@short-flip-after-cursor-atomic-transitions-varying-size.html * igt@kms_draw_crc@draw-method-rgb565-mmap-wc-ytiled: - shard-iclb: [PASS][21] -> [FAIL][22] ([fdo#103184] / [fdo#103232]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6828/shard-iclb8/igt@kms_draw_...@draw-method-rgb565-mmap-wc-ytiled.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14270/shard-iclb8/igt@kms_draw_...@draw-method-rgb565-mmap-wc-ytiled.html * igt@kms_draw_crc@draw-method-xrgb-mmap-gtt-xtiled: - shard-snb: [PASS][23] -> [SKIP][24] ([fdo#109271]) +2 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6828/shard-snb2/igt@kms_draw_...@draw-method-xrgb-mmap-gtt-xtiled.html [24]:
[Intel-gfx] [BACKPORT 4.14.y 0/8] Candidates from Spreadtrum 4.14 product kernel
With Arnd's script [1] help, I found some bugfixes in Spreadtrum 4.14 product kernel, but missing in v4.14.141: 86fda90ab588 net: sctp: fix warning "NULL check before some freeing functions is not needed" 25a09ce79639 ppp: mppe: Revert "ppp: mppe: Add softdep to arc4" d9b308b1f8a1 drm/i915/fbdev: Actually configure untiled displays 47d3d7fdb10a ip6: fix skb leak in ip6frag_expire_frag_queue() 5b9cea15a3de serial: sprd: Modify the baud rate calculation formula 513e1073d52e locking/lockdep: Add debug_locks check in __lock_downgrade() 957063c92473 pinctrl: sprd: Use define directive for sprd_pinconf_params values 87a2b65fc855 power: supply: sysfs: ratelimit property read error message [1] https://lore.kernel.org/lkml/20190322154425.3852517-19-a...@arndb.de/T/ Chris Wilson (1): drm/i915/fbdev: Actually configure untiled displays David Lechner (1): power: supply: sysfs: ratelimit property read error message Eric Biggers (1): ppp: mppe: Revert "ppp: mppe: Add softdep to arc4" Eric Dumazet (1): ip6: fix skb leak in ip6frag_expire_frag_queue() Hariprasad Kelam (1): net: sctp: fix warning "NULL check before some freeing functions is not needed" Lanqing Liu (1): serial: sprd: Modify the baud rate calculation formula Nathan Chancellor (1): pinctrl: sprd: Use define directive for sprd_pinconf_params values Waiman Long (1): locking/lockdep: Add debug_locks check in __lock_downgrade() drivers/gpu/drm/i915/intel_fbdev.c| 12 +++- drivers/net/ppp/ppp_mppe.c|1 - drivers/pinctrl/sprd/pinctrl-sprd.c |6 ++ drivers/power/supply/power_supply_sysfs.c |3 ++- drivers/tty/serial/sprd_serial.c |2 +- include/net/ipv6_frag.h |1 - kernel/locking/lockdep.c |3 +++ net/sctp/sm_make_chunk.c | 12 8 files changed, 19 insertions(+), 21 deletions(-) -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [BACKPORT 4.14.y 1/8] drm/i915/fbdev: Actually configure untiled displays
From: Chris Wilson
If we skipped all the connectors that were not part of a tile, we would
leave conn_seq=0 and conn_configured=0, convincing ourselves that we
had stagnated in our configuration attempts. Avoid this situation by
starting conn_seq=ALL_CONNECTORS, and repeating until we find no more
connectors to configure.
Fixes: 754a76591b12 ("drm/i915/fbdev: Stop repeating tile configuration on
stagnation")
Reported-by: Maarten Lankhorst
Signed-off-by: Chris Wilson
Cc: Maarten Lankhorst
Reviewed-by: Maarten Lankhorst
Link:
https://patchwork.freedesktop.org/patch/msgid/20190215123019.32283-1-ch...@chris-wilson.co.uk
Cc: # v3.19+
Signed-off-by: Baolin Wang
---
drivers/gpu/drm/i915/intel_fbdev.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index da2d309..14eb8a0 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -326,8 +326,8 @@ static bool intel_fb_initial_config(struct drm_fb_helper
*fb_helper,
bool *enabled, int width, int height)
{
struct drm_i915_private *dev_priv = to_i915(fb_helper->dev);
- unsigned long conn_configured, conn_seq, mask;
unsigned int count = min(fb_helper->connector_count, BITS_PER_LONG);
+ unsigned long conn_configured, conn_seq;
int i, j;
bool *save_enabled;
bool fallback = true, ret = true;
@@ -345,10 +345,9 @@ static bool intel_fb_initial_config(struct drm_fb_helper
*fb_helper,
drm_modeset_backoff();
memcpy(save_enabled, enabled, count);
- mask = GENMASK(count - 1, 0);
+ conn_seq = GENMASK(count - 1, 0);
conn_configured = 0;
retry:
- conn_seq = conn_configured;
for (i = 0; i < count; i++) {
struct drm_fb_helper_connector *fb_conn;
struct drm_connector *connector;
@@ -361,7 +360,8 @@ static bool intel_fb_initial_config(struct drm_fb_helper
*fb_helper,
if (conn_configured & BIT(i))
continue;
- if (conn_seq == 0 && !connector->has_tile)
+ /* First pass, only consider tiled connectors */
+ if (conn_seq == GENMASK(count - 1, 0) && !connector->has_tile)
continue;
if (connector->status == connector_status_connected)
@@ -465,8 +465,10 @@ static bool intel_fb_initial_config(struct drm_fb_helper
*fb_helper,
conn_configured |= BIT(i);
}
- if ((conn_configured & mask) != mask && conn_configured != conn_seq)
+ if (conn_configured != conn_seq) { /* repeat until no more are found */
+ conn_seq = conn_configured;
goto retry;
+ }
/*
* If the BIOS didn't enable everything it could, fall back to have the
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 5/7] drm/i915/tgl: disable SAGV temporarily
On Tue, 2019-09-03 at 15:05 -0700, Matt Roper wrote:
> On Thu, Aug 29, 2019 at 02:25:52AM -0700, Lucas De Marchi wrote:
> > SAGV is not currently working for Tiger Lake. We better disable it
> > until
> > the implementation is stabilized and we can enable it.
>
> Does "not currently working" refer to the hardware not working in the
> current stepping, or is it just a matter of us not having proper
> sequences documented yet in the bspec (and gen11's sequences not
> being
> sufficient)?
>
> Something more descriptive than "HACK!" in the comment below might be
> a
> good idea since we're trying to land this upstream.
The information that I had was that in the current stepping it would
not work but doing some searching I found this HSD: 2208191909 So looks
like it was fixed 15 days ago and a new BIOS should fix the issue.
I guess for now we could go with this patch and the revert it when we
confirm that a reliable released BIOS has the fix and adding the HSD to
the commit message.
>
>
> Matt
>
> > Signed-off-by: Lucas De Marchi
> > ---
> > drivers/gpu/drm/i915/intel_pm.c | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 4fa9bc83c8b4..7294fcf05323 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -3654,6 +3654,10 @@ static bool skl_needs_memory_bw_wa(struct
> > drm_i915_private *dev_priv)
> > static bool
> > intel_has_sagv(struct drm_i915_private *dev_priv)
> > {
> > + /* HACK! */
> > + if (IS_GEN(dev_priv, 12))
> > + return false;
> > +
> > return (IS_GEN9_BC(dev_priv) || INTEL_GEN(dev_priv) >= 10) &&
> > dev_priv->sagv_status != I915_SAGV_NOT_CONTROLLED;
> > }
> > --
> > 2.23.0
> >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] PR - HuC Updates and ICL DMC v1.09
Sending PR for HUC Updates and ICl DMC. The following changes since commit 7307a29961ad2765ebcad162da699d2497c5c3f8: brcm: Add 43455 based AP6255 NVRAM for the Minix Neo Z83-4 Mini PC (2019-08-27 08:04:55 -0400) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-firmware gen9_huc_icl_dmc for you to fetch changes up to d258974f18273e3e37b34686c3b8ecc7bb2902bc: drm/i915/firmware: Add v9.0.0 of HuC for Icelake (2019-09-03 14:27:25 -0700) Anusha Srivatsa (7): drm/i915/firmware: Add v1.09 of DMC for ICL drm/i915/firmware: Add v2.0.0 of HuC for Skylake drm/i915/firmware: Add v4.0.0 of HuC for Kabylake drm/i915/firmware: Add v2.0.0 of HuC for Broxton drm/i915/firmware: Add v4.0.0 of HuC for Geminilake drm/i915/firmware: Add v4.0.0 of HuC for Cometlake drm/i915/firmware: Add v9.0.0 of HuC for Icelake WHENCE| 22 ++ i915/bxt_huc_ver2_0_0.bin | Bin 0 -> 149824 bytes i915/cml_huc_ver4_0_0.bin | Bin 0 -> 226048 bytes i915/glk_huc_ver4_0_0.bin | Bin 0 -> 226048 bytes i915/icl_dmc_ver1_09.bin | Bin 0 -> 25952 bytes i915/icl_huc_ver9_0_0.bin | Bin 0 -> 498880 bytes i915/kbl_huc_ver4_0_0.bin | Bin 0 -> 226048 bytes i915/skl_huc_ver2_0_0.bin | Bin 0 -> 136320 bytes 8 files changed, 22 insertions(+) create mode 100644 i915/bxt_huc_ver2_0_0.bin create mode 100644 i915/cml_huc_ver4_0_0.bin create mode 100644 i915/glk_huc_ver4_0_0.bin create mode 100644 i915/icl_dmc_ver1_09.bin create mode 100644 i915/icl_huc_ver9_0_0.bin create mode 100644 i915/kbl_huc_ver4_0_0.bin create mode 100644 i915/skl_huc_ver2_0_0.bin Regards, Anusha ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 6/7] drm/i915/tgl: add gen12 to stolen initialization
On Thu, Aug 29, 2019 at 02:25:53AM -0700, Lucas De Marchi wrote: > Add case for gen == 12 and add MISSING_CASE() for future gens. We were > already handling gen12 as the default, so this doesn't change the > current behavior. > > Cc: CQ Tang > Signed-off-by: Lucas De Marchi Another approach would be to just convert the switch to a more traditional if/else ladder as we use pretty much everywhere else in the driver (which would also allow us to handle stuff like vlv and chv without an extra level of nesting). But this works too, so Reviewed-by: Matt Roper > --- > drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c > b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c > index aa533b4ab5f5..7ce5259d73d6 100644 > --- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c > +++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c > @@ -425,8 +425,11 @@ int i915_gem_init_stolen(struct drm_i915_private > *dev_priv) > bdw_get_stolen_reserved(dev_priv, > _base, _size); > break; > - case 11: > default: > + MISSING_CASE(INTEL_GEN(dev_priv)); > + /* fall-through */ > + case 11: > + case 12: > icl_get_stolen_reserved(dev_priv, _base, > _size); > break; > -- > 2.23.0 > -- Matt Roper Graphics Software Engineer VTT-OSGC Platform Enablement Intel Corporation (916) 356-2795 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 5/7] drm/i915/tgl: disable SAGV temporarily
On Thu, Aug 29, 2019 at 02:25:52AM -0700, Lucas De Marchi wrote:
> SAGV is not currently working for Tiger Lake. We better disable it until
> the implementation is stabilized and we can enable it.
Does "not currently working" refer to the hardware not working in the
current stepping, or is it just a matter of us not having proper
sequences documented yet in the bspec (and gen11's sequences not being
sufficient)?
Something more descriptive than "HACK!" in the comment below might be a
good idea since we're trying to land this upstream.
Matt
>
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/intel_pm.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 4fa9bc83c8b4..7294fcf05323 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3654,6 +3654,10 @@ static bool skl_needs_memory_bw_wa(struct
> drm_i915_private *dev_priv)
> static bool
> intel_has_sagv(struct drm_i915_private *dev_priv)
> {
> + /* HACK! */
> + if (IS_GEN(dev_priv, 12))
> + return false;
> +
> return (IS_GEN9_BC(dev_priv) || INTEL_GEN(dev_priv) >= 10) &&
> dev_priv->sagv_status != I915_SAGV_NOT_CONTROLLED;
> }
> --
> 2.23.0
>
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
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: adding state checker for gamma lut values (rev14)
== Series Details == Series: drm/i915: adding state checker for gamma lut values (rev14) URL : https://patchwork.freedesktop.org/series/58039/ State : success == Summary == CI Bug Log - changes from CI_DRM_6829 -> Patchwork_14271 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14271/ Known issues Here are the changes found in Patchwork_14271 that come from known issues: ### IGT changes ### Warnings * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [FAIL][1] ([fdo#111407]) -> [FAIL][2] ([fdo#111096]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6829/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14271/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096 [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407 Participating hosts (53 -> 45) -- Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-j1900 fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_6829 -> Patchwork_14271 CI-20190529: 20190529 CI_DRM_6829: f079fd4ac5dcc7e76550a7068f655d3e665088d1 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5167: 81f7a49bc80e6d9f27e33859fd94fd11e13cafa0 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_14271: b2aefcd3a19b12de0e844f800841a7acc7946d3c @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == b2aefcd3a19b FOR_TESTING_ONLY: Print rgb values of hw and sw blobs 51f505e22c73 drm/i915/display: Extract glk_read_luts() aac65c8c33e5 drm/i915/display: Extract ilk_read_luts() 0ee282955ff1 drm/i915/display: Extract i9xx_read_luts() 6206ac8d1f9c drm/i915/display: Add macro to compare gamma hw/sw lut 8352876a8f80 drm/i915/display: Add func to compare hw/sw gamma lut ad9f91835ee7 drm/i915/display: Add debug log for color parameters 122b0ae456db drm/i915/display: Add func to get gamma bit precision == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14271/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/7] drm/i915/psr: Only handle interruptions of the transcoder in use
On Tue, Sep 03, 2019 at 02:53:04PM -0700, Souza, Jose wrote:
> On Tue, 2019-09-03 at 14:42 -0700, Matt Roper wrote:
> > On Thu, Aug 29, 2019 at 02:25:48AM -0700, Lucas De Marchi wrote:
> > > From: José Roberto de Souza
> > >
> > > It was enabling and checking PSR interruptions in every transcoder
> > > while it should keep the interruptions on the non-used transcoders
> > > masked.
> > >
> > > While doing this it gives us trouble on Tiger Lake if we are
> > > reading/writing to registers of disabled transcoders since from
> > > gen12
> > > onwards the registers are relative to the transcoder. Instead of
> > > forcing
> > > them ON to access those registers, just avoid the accesses as they
> > > are
> > > not needed.
> > >
> > > v2 (Lucas):
> > > - Explain why we can't keep accessing all transcoders
> > > - Remove TODO about extending the irq handling to multiple
> > > instances:
> > > when/if implementing multiple instances it's pretty clear by
> > > the
> > > singleton psr that it needs to be extended
> > > - Fix intel_psr_debug_set() calling psr_irq_control() with
> > > psr.transcoder not set yet (from Imre). Now we only set the
> > > debug
> > > register right away if psr is already enabled. Otherwise we
> > > just
> > > record the value to be set when enabling the source.
> > > - Do not depend on the value of TRANSCODER_A. Just be relative to
> > > it
> > > (from Imre)
> > > - handle psr error last so we don't schedule the work before
> > > handling
> > > the other flags
> > >
> > > Cc: Imre Deak
> > > Cc: Dhinakaran Pandiyan
> > > Signed-off-by: José Roberto de Souza
> > > Signed-off-by: Lucas De Marchi
> > > ---
> > > drivers/gpu/drm/i915/display/intel_psr.c | 137 +
> > > --
> > > drivers/gpu/drm/i915/i915_reg.h | 13 +--
> > > 2 files changed, 57 insertions(+), 93 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > > b/drivers/gpu/drm/i915/display/intel_psr.c
> > > index 629b8b98a97f..6f2bf50b6d80 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > > @@ -88,48 +88,19 @@ static bool intel_psr2_enabled(struct
> > > drm_i915_private *dev_priv,
> > > }
> > > }
> > >
> > > -static int edp_psr_shift(enum transcoder cpu_transcoder)
> > > +static void psr_irq_control(struct drm_i915_private *dev_priv)
> > > {
> > > - switch (cpu_transcoder) {
> > > - case TRANSCODER_A:
> > > - return EDP_PSR_TRANSCODER_A_SHIFT;
> > > - case TRANSCODER_B:
> > > - return EDP_PSR_TRANSCODER_B_SHIFT;
> > > - case TRANSCODER_C:
> > > - return EDP_PSR_TRANSCODER_C_SHIFT;
> > > - default:
> > > - MISSING_CASE(cpu_transcoder);
> > > - /* fallthrough */
> > > - case TRANSCODER_EDP:
> > > - return EDP_PSR_TRANSCODER_EDP_SHIFT;
> > > - }
> > > -}
> > > -
> > > -static void psr_irq_control(struct drm_i915_private *dev_priv, u32
> > > debug)
> > > -{
> > > - u32 debug_mask, mask;
> > > - enum transcoder cpu_transcoder;
> > > - u32 transcoders = BIT(TRANSCODER_EDP);
> > > -
> > > - if (INTEL_GEN(dev_priv) >= 8)
> > > - transcoders |= BIT(TRANSCODER_A) |
> > > -BIT(TRANSCODER_B) |
> > > -BIT(TRANSCODER_C);
> > > -
> > > - debug_mask = 0;
> > > - mask = 0;
> > > - for_each_cpu_transcoder_masked(dev_priv, cpu_transcoder,
> > > transcoders) {
> > > - int shift = edp_psr_shift(cpu_transcoder);
> > > -
> > > - mask |= EDP_PSR_ERROR(shift);
> > > - debug_mask |= EDP_PSR_POST_EXIT(shift) |
> > > - EDP_PSR_PRE_ENTRY(shift);
> > > - }
> > > + enum transcoder trans = dev_priv->psr.transcoder;
> > > + u32 val, mask;
> > >
> > > - if (debug & I915_PSR_DEBUG_IRQ)
> > > - mask |= debug_mask;
> > > + mask = EDP_PSR_ERROR(trans);
> > > + if (dev_priv->psr.debug & I915_PSR_DEBUG_IRQ)
> > > + mask |= EDP_PSR_POST_EXIT(trans) |
> > > EDP_PSR_PRE_ENTRY(trans);
> > >
> > > - I915_WRITE(EDP_PSR_IMR, ~mask);
> > > + val = I915_READ(EDP_PSR_IMR);
> > > + val &= ~EDP_PSR_TRANS_MASK(trans);
> > > + val |= ~mask;
> > > + I915_WRITE(EDP_PSR_IMR, val);
> >
> > I guess we've done this all along, but it jumped out at me during the
> > review here that we're setting a bunch of bits to 1 that I don't
> > think
> > have a defined meaning. I.e., the bspec explicitly indicates that
> > 0x07070707 would be "all interrupts masked" whereas we're setting
> > something more along the lines of 0xBFF (for an example with PSR
> > on
> > transcoder A).
> >
> > That's apparently fine for current platforms (since it's what we've
> > been
> > doing all along), but it makes me slightly more nervous on TGL and
> > beyond given that the next patch switches to the per-transcoder
> > PSR_IMR
> > registers and those explicitly say that bits 31:4 are reserved and
> > must-be-zero. Maybe we should add a code comment about this just in
>
Re: [Intel-gfx] [PATCH v3 1/7] drm/i915/psr: Only handle interruptions of the transcoder in use
On Tue, 2019-09-03 at 14:42 -0700, Matt Roper wrote:
> On Thu, Aug 29, 2019 at 02:25:48AM -0700, Lucas De Marchi wrote:
> > From: José Roberto de Souza
> >
> > It was enabling and checking PSR interruptions in every transcoder
> > while it should keep the interruptions on the non-used transcoders
> > masked.
> >
> > While doing this it gives us trouble on Tiger Lake if we are
> > reading/writing to registers of disabled transcoders since from
> > gen12
> > onwards the registers are relative to the transcoder. Instead of
> > forcing
> > them ON to access those registers, just avoid the accesses as they
> > are
> > not needed.
> >
> > v2 (Lucas):
> > - Explain why we can't keep accessing all transcoders
> > - Remove TODO about extending the irq handling to multiple
> > instances:
> > when/if implementing multiple instances it's pretty clear by
> > the
> > singleton psr that it needs to be extended
> > - Fix intel_psr_debug_set() calling psr_irq_control() with
> > psr.transcoder not set yet (from Imre). Now we only set the
> > debug
> > register right away if psr is already enabled. Otherwise we
> > just
> > record the value to be set when enabling the source.
> > - Do not depend on the value of TRANSCODER_A. Just be relative to
> > it
> > (from Imre)
> > - handle psr error last so we don't schedule the work before
> > handling
> > the other flags
> >
> > Cc: Imre Deak
> > Cc: Dhinakaran Pandiyan
> > Signed-off-by: José Roberto de Souza
> > Signed-off-by: Lucas De Marchi
> > ---
> > drivers/gpu/drm/i915/display/intel_psr.c | 137 +
> > --
> > drivers/gpu/drm/i915/i915_reg.h | 13 +--
> > 2 files changed, 57 insertions(+), 93 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > b/drivers/gpu/drm/i915/display/intel_psr.c
> > index 629b8b98a97f..6f2bf50b6d80 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -88,48 +88,19 @@ static bool intel_psr2_enabled(struct
> > drm_i915_private *dev_priv,
> > }
> > }
> >
> > -static int edp_psr_shift(enum transcoder cpu_transcoder)
> > +static void psr_irq_control(struct drm_i915_private *dev_priv)
> > {
> > - switch (cpu_transcoder) {
> > - case TRANSCODER_A:
> > - return EDP_PSR_TRANSCODER_A_SHIFT;
> > - case TRANSCODER_B:
> > - return EDP_PSR_TRANSCODER_B_SHIFT;
> > - case TRANSCODER_C:
> > - return EDP_PSR_TRANSCODER_C_SHIFT;
> > - default:
> > - MISSING_CASE(cpu_transcoder);
> > - /* fallthrough */
> > - case TRANSCODER_EDP:
> > - return EDP_PSR_TRANSCODER_EDP_SHIFT;
> > - }
> > -}
> > -
> > -static void psr_irq_control(struct drm_i915_private *dev_priv, u32
> > debug)
> > -{
> > - u32 debug_mask, mask;
> > - enum transcoder cpu_transcoder;
> > - u32 transcoders = BIT(TRANSCODER_EDP);
> > -
> > - if (INTEL_GEN(dev_priv) >= 8)
> > - transcoders |= BIT(TRANSCODER_A) |
> > - BIT(TRANSCODER_B) |
> > - BIT(TRANSCODER_C);
> > -
> > - debug_mask = 0;
> > - mask = 0;
> > - for_each_cpu_transcoder_masked(dev_priv, cpu_transcoder,
> > transcoders) {
> > - int shift = edp_psr_shift(cpu_transcoder);
> > -
> > - mask |= EDP_PSR_ERROR(shift);
> > - debug_mask |= EDP_PSR_POST_EXIT(shift) |
> > - EDP_PSR_PRE_ENTRY(shift);
> > - }
> > + enum transcoder trans = dev_priv->psr.transcoder;
> > + u32 val, mask;
> >
> > - if (debug & I915_PSR_DEBUG_IRQ)
> > - mask |= debug_mask;
> > + mask = EDP_PSR_ERROR(trans);
> > + if (dev_priv->psr.debug & I915_PSR_DEBUG_IRQ)
> > + mask |= EDP_PSR_POST_EXIT(trans) |
> > EDP_PSR_PRE_ENTRY(trans);
> >
> > - I915_WRITE(EDP_PSR_IMR, ~mask);
> > + val = I915_READ(EDP_PSR_IMR);
> > + val &= ~EDP_PSR_TRANS_MASK(trans);
> > + val |= ~mask;
> > + I915_WRITE(EDP_PSR_IMR, val);
>
> I guess we've done this all along, but it jumped out at me during the
> review here that we're setting a bunch of bits to 1 that I don't
> think
> have a defined meaning. I.e., the bspec explicitly indicates that
> 0x07070707 would be "all interrupts masked" whereas we're setting
> something more along the lines of 0xBFF (for an example with PSR
> on
> transcoder A).
>
> That's apparently fine for current platforms (since it's what we've
> been
> doing all along), but it makes me slightly more nervous on TGL and
> beyond given that the next patch switches to the per-transcoder
> PSR_IMR
> registers and those explicitly say that bits 31:4 are reserved and
> must-be-zero. Maybe we should add a code comment about this just in
> case it comes back to bite us on a future platform?
Like you said we do it for all other platforms and for all other
interruption registers but anyways I can add a comment on top:
/* Masking/setting reserved bits too */
It is enough?
Re: [Intel-gfx] [PATCH v3 6/7] drm/i915/tgl: add gen12 to stolen initialization
On Thu, 2019-08-29 at 02:25 -0700, Lucas De Marchi wrote: > Add case for gen == 12 and add MISSING_CASE() for future gens. We > were > already handling gen12 as the default, so this doesn't change the > current behavior. With: BSpec: 19481 and 44980 Reviewed-by: José Roberto de Souza > > Cc: CQ Tang > Signed-off-by: Lucas De Marchi > --- > drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c > b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c > index aa533b4ab5f5..7ce5259d73d6 100644 > --- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c > +++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c > @@ -425,8 +425,11 @@ int i915_gem_init_stolen(struct drm_i915_private > *dev_priv) > bdw_get_stolen_reserved(dev_priv, > _base, > _size); > break; > - case 11: > default: > + MISSING_CASE(INTEL_GEN(dev_priv)); > + /* fall-through */ > + case 11: > + case 12: > icl_get_stolen_reserved(dev_priv, _base, > _size); > break; ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/7] drm/i915/psr: Only handle interruptions of the transcoder in use
On Thu, Aug 29, 2019 at 02:25:48AM -0700, Lucas De Marchi wrote:
> From: José Roberto de Souza
>
> It was enabling and checking PSR interruptions in every transcoder
> while it should keep the interruptions on the non-used transcoders
> masked.
>
> While doing this it gives us trouble on Tiger Lake if we are
> reading/writing to registers of disabled transcoders since from gen12
> onwards the registers are relative to the transcoder. Instead of forcing
> them ON to access those registers, just avoid the accesses as they are
> not needed.
>
> v2 (Lucas):
> - Explain why we can't keep accessing all transcoders
> - Remove TODO about extending the irq handling to multiple instances:
> when/if implementing multiple instances it's pretty clear by the
> singleton psr that it needs to be extended
> - Fix intel_psr_debug_set() calling psr_irq_control() with
> psr.transcoder not set yet (from Imre). Now we only set the debug
> register right away if psr is already enabled. Otherwise we just
> record the value to be set when enabling the source.
> - Do not depend on the value of TRANSCODER_A. Just be relative to it
> (from Imre)
> - handle psr error last so we don't schedule the work before handling
> the other flags
>
> Cc: Imre Deak
> Cc: Dhinakaran Pandiyan
> Signed-off-by: José Roberto de Souza
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/display/intel_psr.c | 137 +--
> drivers/gpu/drm/i915/i915_reg.h | 13 +--
> 2 files changed, 57 insertions(+), 93 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 629b8b98a97f..6f2bf50b6d80 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -88,48 +88,19 @@ static bool intel_psr2_enabled(struct drm_i915_private
> *dev_priv,
> }
> }
>
> -static int edp_psr_shift(enum transcoder cpu_transcoder)
> +static void psr_irq_control(struct drm_i915_private *dev_priv)
> {
> - switch (cpu_transcoder) {
> - case TRANSCODER_A:
> - return EDP_PSR_TRANSCODER_A_SHIFT;
> - case TRANSCODER_B:
> - return EDP_PSR_TRANSCODER_B_SHIFT;
> - case TRANSCODER_C:
> - return EDP_PSR_TRANSCODER_C_SHIFT;
> - default:
> - MISSING_CASE(cpu_transcoder);
> - /* fallthrough */
> - case TRANSCODER_EDP:
> - return EDP_PSR_TRANSCODER_EDP_SHIFT;
> - }
> -}
> -
> -static void psr_irq_control(struct drm_i915_private *dev_priv, u32 debug)
> -{
> - u32 debug_mask, mask;
> - enum transcoder cpu_transcoder;
> - u32 transcoders = BIT(TRANSCODER_EDP);
> -
> - if (INTEL_GEN(dev_priv) >= 8)
> - transcoders |= BIT(TRANSCODER_A) |
> -BIT(TRANSCODER_B) |
> -BIT(TRANSCODER_C);
> -
> - debug_mask = 0;
> - mask = 0;
> - for_each_cpu_transcoder_masked(dev_priv, cpu_transcoder, transcoders) {
> - int shift = edp_psr_shift(cpu_transcoder);
> -
> - mask |= EDP_PSR_ERROR(shift);
> - debug_mask |= EDP_PSR_POST_EXIT(shift) |
> - EDP_PSR_PRE_ENTRY(shift);
> - }
> + enum transcoder trans = dev_priv->psr.transcoder;
> + u32 val, mask;
>
> - if (debug & I915_PSR_DEBUG_IRQ)
> - mask |= debug_mask;
> + mask = EDP_PSR_ERROR(trans);
> + if (dev_priv->psr.debug & I915_PSR_DEBUG_IRQ)
> + mask |= EDP_PSR_POST_EXIT(trans) | EDP_PSR_PRE_ENTRY(trans);
>
> - I915_WRITE(EDP_PSR_IMR, ~mask);
> + val = I915_READ(EDP_PSR_IMR);
> + val &= ~EDP_PSR_TRANS_MASK(trans);
> + val |= ~mask;
> + I915_WRITE(EDP_PSR_IMR, val);
I guess we've done this all along, but it jumped out at me during the
review here that we're setting a bunch of bits to 1 that I don't think
have a defined meaning. I.e., the bspec explicitly indicates that
0x07070707 would be "all interrupts masked" whereas we're setting
something more along the lines of 0xBFF (for an example with PSR on
transcoder A).
That's apparently fine for current platforms (since it's what we've been
doing all along), but it makes me slightly more nervous on TGL and
beyond given that the next patch switches to the per-transcoder PSR_IMR
registers and those explicitly say that bits 31:4 are reserved and
must-be-zero. Maybe we should add a code comment about this just in
case it comes back to bite us on a future platform?
Matt
> }
>
> static void psr_event_print(u32 val, bool psr2_enabled)
> @@ -171,60 +142,48 @@ static void psr_event_print(u32 val, bool psr2_enabled)
>
> void intel_psr_irq_handler(struct drm_i915_private *dev_priv, u32 psr_iir)
> {
> - u32 transcoders = BIT(TRANSCODER_EDP);
> - enum transcoder cpu_transcoder;
> + enum transcoder cpu_transcoder = dev_priv->psr.transcoder;
> ktime_t time_ns = ktime_get();
>
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: adding state checker for gamma lut values (rev14)
== Series Details ==
Series: drm/i915: adding state checker for gamma lut values (rev14)
URL : https://patchwork.freedesktop.org/series/58039/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
122b0ae456db drm/i915/display: Add func to get gamma bit precision
ad9f91835ee7 drm/i915/display: Add debug log for color parameters
8352876a8f80 drm/i915/display: Add func to compare hw/sw gamma lut
6206ac8d1f9c drm/i915/display: Add macro to compare gamma hw/sw lut
-:36: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'name1' - possible
side-effects?
#36: FILE: drivers/gpu/drm/i915/display/intel_display.c:12686:
+#define PIPE_CONF_CHECK_COLOR_LUT(name1, name2, bit_precision) do { \
+ if (current_config->name1 != pipe_config->name1) { \
+ pipe_config_mismatch(fastset, __stringify(name1), \
+ "(expected %i, found %i, won't compare lut
values)\n", \
+ current_config->name1, \
+ pipe_config->name1); \
+ ret = false;\
+ } else { \
+ if (!intel_color_lut_equal(current_config->name2, \
+ pipe_config->name2, pipe_config->name1,
\
+ bit_precision)) { \
+ pipe_config_mismatch(fastset, __stringify(name2), \
+ "hw_state doesn't match sw_state\n"); \
+ ret = false; \
+ } \
+ } \
+} while (0)
-:36: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'name1' may be better as
'(name1)' to avoid precedence issues
#36: FILE: drivers/gpu/drm/i915/display/intel_display.c:12686:
+#define PIPE_CONF_CHECK_COLOR_LUT(name1, name2, bit_precision) do { \
+ if (current_config->name1 != pipe_config->name1) { \
+ pipe_config_mismatch(fastset, __stringify(name1), \
+ "(expected %i, found %i, won't compare lut
values)\n", \
+ current_config->name1, \
+ pipe_config->name1); \
+ ret = false;\
+ } else { \
+ if (!intel_color_lut_equal(current_config->name2, \
+ pipe_config->name2, pipe_config->name1,
\
+ bit_precision)) { \
+ pipe_config_mismatch(fastset, __stringify(name2), \
+ "hw_state doesn't match sw_state\n"); \
+ ret = false; \
+ } \
+ } \
+} while (0)
-:36: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'name2' - possible
side-effects?
#36: FILE: drivers/gpu/drm/i915/display/intel_display.c:12686:
+#define PIPE_CONF_CHECK_COLOR_LUT(name1, name2, bit_precision) do { \
+ if (current_config->name1 != pipe_config->name1) { \
+ pipe_config_mismatch(fastset, __stringify(name1), \
+ "(expected %i, found %i, won't compare lut
values)\n", \
+ current_config->name1, \
+ pipe_config->name1); \
+ ret = false;\
+ } else { \
+ if (!intel_color_lut_equal(current_config->name2, \
+ pipe_config->name2, pipe_config->name1,
\
+ bit_precision)) { \
+ pipe_config_mismatch(fastset, __stringify(name2), \
+ "hw_state doesn't match sw_state\n"); \
+ ret = false; \
+ } \
+ } \
+} while (0)
-:36: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'name2' may be better as
'(name2)' to avoid precedence issues
#36: FILE: drivers/gpu/drm/i915/display/intel_display.c:12686:
+#define PIPE_CONF_CHECK_COLOR_LUT(name1, name2, bit_precision) do { \
+ if (current_config->name1 != pipe_config->name1) { \
+ pipe_config_mismatch(fastset, __stringify(name1), \
+ "(expected %i, found %i, won't compare lut
values)\n", \
+ current_config->name1, \
+ pipe_config->name1); \
+ ret = false;\
+ } else { \
+ if (!intel_color_lut_equal(current_config->name2, \
+ pipe_config->name2, pipe_config->name1,
\
+ bit_precision)) { \
+ pipe_config_mismatch(fastset, __stringify(name2), \
+ "hw_state doesn't match sw_state\n"); \
+ ret = false; \
+ } \
+ } \
+} while (0)
total: 0 errors, 0 warnings, 4 checks, 49 lines checked
0ee282955ff1 drm/i915/display: Extract i9xx_read_luts()
-:71: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#71: FILE: drivers/gpu/drm/i915/display/intel_color.c:1543:
+
[Intel-gfx] ✗ Fi.CI.IGT: failure for Revert "drm/i915: Fix DP-MST crtc_mask"
== Series Details == Series: Revert "drm/i915: Fix DP-MST crtc_mask" URL : https://patchwork.freedesktop.org/series/66173/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6828_full -> Patchwork_14266_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_14266_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_14266_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_14266_full: ### Piglit changes ### Possible regressions * spec@ext_framebuffer_multisample@alpha-to-coverage-no-draw-buffer-zero 4 (NEW): - pig-hsw-4770r: NOTRUN -> [CRASH][1] +52 similar issues [1]: None New tests - New tests have been introduced between CI_DRM_6828_full and Patchwork_14266_full: ### New Piglit tests (53) ### * spec@ext_framebuffer_multisample@alpha-to-coverage-dual-src-blend 2: - Statuses : 1 crash(s) - Exec time: [0.11] s * spec@ext_framebuffer_multisample@alpha-to-coverage-dual-src-blend 4: - Statuses : 1 crash(s) - Exec time: [0.16] s * spec@ext_framebuffer_multisample@alpha-to-coverage-dual-src-blend 6: - Statuses : 1 crash(s) - Exec time: [0.16] s * spec@ext_framebuffer_multisample@alpha-to-coverage-dual-src-blend 8: - Statuses : 1 crash(s) - Exec time: [0.15] s * spec@ext_framebuffer_multisample@alpha-to-coverage-no-draw-buffer-zero 2: - Statuses : 1 crash(s) - Exec time: [0.12] s * spec@ext_framebuffer_multisample@alpha-to-coverage-no-draw-buffer-zero 4: - Statuses : 1 crash(s) - Exec time: [0.11] s * spec@ext_framebuffer_multisample@alpha-to-coverage-no-draw-buffer-zero 6: - Statuses : 1 crash(s) - Exec time: [0.11] s * spec@ext_framebuffer_multisample@alpha-to-coverage-no-draw-buffer-zero 8: - Statuses : 1 crash(s) - Exec time: [0.13] s * spec@ext_framebuffer_multisample@alpha-to-coverage-no-draw-buffer-zero-write 2: - Statuses : 1 crash(s) - Exec time: [0.14] s * spec@ext_framebuffer_multisample@alpha-to-coverage-no-draw-buffer-zero-write 4: - Statuses : 1 crash(s) - Exec time: [0.14] s * spec@ext_framebuffer_multisample@alpha-to-coverage-no-draw-buffer-zero-write 6: - Statuses : 1 crash(s) - Exec time: [0.12] s * spec@ext_framebuffer_multisample@alpha-to-coverage-no-draw-buffer-zero-write 8: - Statuses : 1 crash(s) - Exec time: [0.17] s * spec@ext_framebuffer_multisample@alpha-to-one-dual-src-blend 2: - Statuses : 1 crash(s) - Exec time: [0.12] s * spec@ext_framebuffer_multisample@alpha-to-one-dual-src-blend 4: - Statuses : 1 crash(s) - Exec time: [0.11] s * spec@ext_framebuffer_multisample@alpha-to-one-dual-src-blend 6: - Statuses : 1 crash(s) - Exec time: [0.15] s * spec@ext_framebuffer_multisample@alpha-to-one-dual-src-blend 8: - Statuses : 1 crash(s) - Exec time: [0.18] s * spec@ext_framebuffer_multisample@alpha-to-one-msaa-disabled 2: - Statuses : 1 crash(s) - Exec time: [0.13] s * spec@ext_framebuffer_multisample@alpha-to-one-msaa-disabled 4: - Statuses : 1 crash(s) - Exec time: [0.11] s * spec@ext_framebuffer_multisample@alpha-to-one-msaa-disabled 6: - Statuses : 1 crash(s) - Exec time: [0.15] s * spec@ext_framebuffer_multisample@alpha-to-one-single-sample-buffer 2: - Statuses : 1 crash(s) - Exec time: [0.13] s * spec@ext_framebuffer_multisample@alpha-to-one-single-sample-buffer 4: - Statuses : 1 crash(s) - Exec time: [0.12] s * spec@ext_framebuffer_multisample@alpha-to-one-single-sample-buffer 6: - Statuses : 1 crash(s) - Exec time: [0.15] s * spec@ext_framebuffer_multisample@draw-buffers-alpha-to-coverage 2: - Statuses : 1 crash(s) - Exec time: [0.15] s * spec@ext_framebuffer_multisample@draw-buffers-alpha-to-coverage 4: - Statuses : 1 crash(s) - Exec time: [0.13] s * spec@ext_framebuffer_multisample@draw-buffers-alpha-to-coverage 6: - Statuses : 1 crash(s) - Exec time: [0.22] s * spec@ext_framebuffer_multisample@draw-buffers-alpha-to-coverage 8: - Statuses : 1 crash(s) - Exec time: [0.18] s * spec@ext_framebuffer_multisample@draw-buffers-alpha-to-one 2: - Statuses : 1 crash(s) - Exec time: [0.13] s * spec@ext_framebuffer_multisample@draw-buffers-alpha-to-one 4: - Statuses : 1 crash(s) - Exec time: [0.12] s * spec@ext_framebuffer_multisample@draw-buffers-alpha-to-one 6: - Statuses : 1 crash(s) - Exec time: [0.15] s * spec@ext_framebuffer_multisample@draw-buffers-alpha-to-one 8: - Statuses : 1 crash(s) - Exec time: [0.20] s *
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/atomic: Take the atomic toys away from X
== Series Details ==
Series: series starting with [1/3] drm/atomic: Take the atomic toys away from X
URL : https://patchwork.freedesktop.org/series/66180/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6828 -> Patchwork_14270
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14270/
Known issues
Here are the changes found in Patchwork_14270 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_exec@basic:
- fi-icl-u3: [PASS][1] -> [INCOMPLETE][2] ([fdo#107713])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6828/fi-icl-u3/igt@gem_ctx_e...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14270/fi-icl-u3/igt@gem_ctx_e...@basic.html
* igt@gem_ctx_switch@legacy-render:
- fi-bxt-dsi: [PASS][3] -> [INCOMPLETE][4] ([fdo#103927] /
[fdo#111381])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6828/fi-bxt-dsi/igt@gem_ctx_swi...@legacy-render.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14270/fi-bxt-dsi/igt@gem_ctx_swi...@legacy-render.html
* igt@i915_selftest@live_execlists:
- fi-skl-gvtdvm: [PASS][5] -> [DMESG-FAIL][6] ([fdo#08])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6828/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14270/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
* igt@kms_chamelium@dp-crc-fast:
- fi-cml-u2: [PASS][7] -> [FAIL][8] ([fdo#110627])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6828/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14270/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_chamelium@dp-edid-read:
- fi-icl-u2: [PASS][9] -> [FAIL][10] ([fdo#109483] / [fdo#109635 ])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6828/fi-icl-u2/igt@kms_chamel...@dp-edid-read.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14270/fi-icl-u2/igt@kms_chamel...@dp-edid-read.html
Possible fixes
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: [INCOMPLETE][11] ([fdo#107718]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6828/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14270/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
* igt@gem_exec_suspend@basic-s4-devices:
- fi-kbl-7500u: [DMESG-WARN][13] ([fdo#105128] / [fdo#107139]) ->
[PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6828/fi-kbl-7500u/igt@gem_exec_susp...@basic-s4-devices.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14270/fi-kbl-7500u/igt@gem_exec_susp...@basic-s4-devices.html
* igt@kms_chamelium@hdmi-crc-fast:
- fi-icl-u2: [FAIL][15] ([fdo#109635 ]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6828/fi-icl-u2/igt@kms_chamel...@hdmi-crc-fast.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14270/fi-icl-u2/igt@kms_chamel...@hdmi-crc-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#105128]: https://bugs.freedesktop.org/show_bug.cgi?id=105128
[fdo#107139]: https://bugs.freedesktop.org/show_bug.cgi?id=107139
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#109483]: https://bugs.freedesktop.org/show_bug.cgi?id=109483
[fdo#109635 ]: https://bugs.freedesktop.org/show_bug.cgi?id=109635
[fdo#110627]: https://bugs.freedesktop.org/show_bug.cgi?id=110627
[fdo#08]: https://bugs.freedesktop.org/show_bug.cgi?id=08
[fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381
Participating hosts (53 -> 46)
--
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y
fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6828 -> Patchwork_14270
CI-20190529: 20190529
CI_DRM_6828: 6e043dde15a1b2b97d908d0467e9197ffa8934c2 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5164: 90babd3f12707dfabaa58bb18f6b8e22636b6895 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14270: a705142c4deb47ede8d6765c5da0fe74fa48a77e @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
a705142c4deb drm/atomic: Rename crtc_state->pageflip_flags to async_flip
94ce77c000f1 drm/atomic: Reject FLIP_ASYNC unconditionally
6ca9335b74af drm/atomic: Take the atomic toys away from X
== Logs ==
For more details
[Intel-gfx] [PATCH v2 25/27] drm/dp_mst: Add basic topology reprobing when resuming
Finally! For a very long time, our MST helpers have had one very
annoying issue: They don't know how to reprobe the topology state when
coming out of suspend. This means that if a user has a machine connected
to an MST topology and decides to suspend their machine, we lose all
topology changes that happened during that period. That can be a big
problem if the machine was connected to a different topology on the same
port before resuming, as we won't bother reprobing any of the ports and
likely cause the user's monitors not to come back up as expected.
So, we start fixing this by teaching our MST helpers how to reprobe the
link addresses of each connected topology when resuming. As it turns
out, the behavior that we want here is identical to the behavior we want
when initially probing a newly connected MST topology, with a couple of
important differences:
- We need to be more careful about handling the potential races between
events from the MST hub that could change the topology state as we're
performing the link address reprobe
- We need to be more careful about handling unlikely state changes on
ports - such as an input port turning into an output port, something
that would be far more likely to happen in situations like the MST hub
we're connected to being changed while we're suspend
Both of which have been solved by previous commits. That leaves one
requirement:
- We need to prune any MST ports in our in-memory topology state that
were present when suspending, but have not appeared in the post-resume
link address response from their parent branch device
Which we can now handle in this commit by modifying
drm_dp_send_link_address(). We then introduce suspend/resume reprobing
by introducing drm_dp_mst_topology_mgr_invalidate_mstb(), which we call
in drm_dp_mst_topology_mgr_suspend() to traverse the in-memory topology
state to indicate that each mstb needs it's link address resent and PBN
resources reprobed.
On resume, we start back up >work and have it reprobe the topology
in the same way we would on a hotplug, removing any leftover ports that
no longer appear in the topology state.
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Cc: Daniel Vetter
Signed-off-by: Lyude Paul
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
drivers/gpu/drm/drm_dp_mst_topology.c | 138 +-
drivers/gpu/drm/i915/display/intel_dp.c | 3 +-
drivers/gpu/drm/nouveau/dispnv50/disp.c | 6 +-
include/drm/drm_dp_mst_helper.h | 3 +-
5 files changed, 112 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 4d3c8bff77da..27ee3e045b86 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -973,7 +973,7 @@ static void s3_handle_mst(struct drm_device *dev, bool
suspend)
if (suspend) {
drm_dp_mst_topology_mgr_suspend(mgr);
} else {
- ret = drm_dp_mst_topology_mgr_resume(mgr);
+ ret = drm_dp_mst_topology_mgr_resume(mgr, true);
if (ret < 0) {
drm_dp_mst_topology_mgr_set_mst(mgr, false);
need_hotplug = true;
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index e407aba1fbd2..2fe24e366925 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2020,6 +2020,14 @@ drm_dp_mst_handle_link_address_port(struct
drm_dp_mst_branch *mstb,
goto fail_unlock;
}
+ /*
+* If this port wasn't just created, then we're reprobing because
+* we're coming out of suspend. In this case, always resend the link
+* address if there's an MSTB on this port
+*/
+ if (!created && port->pdt == DP_PEER_DEVICE_MST_BRANCHING)
+ send_link_addr = true;
+
if (send_link_addr) {
mutex_lock(>lock);
if (port->mstb) {
@@ -2530,7 +2538,8 @@ static void drm_dp_send_link_address(struct
drm_dp_mst_topology_mgr *mgr,
{
struct drm_dp_sideband_msg_tx *txmsg;
struct drm_dp_link_address_ack_reply *reply;
- int i, len, ret;
+ struct drm_dp_mst_port *port, *tmp;
+ int i, len, ret, port_mask = 0;
txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
if (!txmsg)
@@ -2560,9 +2569,28 @@ static void drm_dp_send_link_address(struct
drm_dp_mst_topology_mgr *mgr,
drm_dp_check_mstb_guid(mstb, reply->guid);
- for (i = 0; i < reply->nports; i++)
+ for (i = 0; i < reply->nports; i++) {
+ port_mask |= BIT(reply->ports[i].port_number);
drm_dp_mst_handle_link_address_port(mstb, mgr->dev,
[Intel-gfx] [PATCH v2 00/27] DP MST Refactors + debugging tools + suspend/resume reprobing
This is the large series for adding MST suspend/resume reprobing that
I've been working on for quite a while now. In addition, I:
- Refactored and cleaned up any code I ended up digging through in the
process of understanding how some parts of these helpers worked.
- Added some debugging tools along the way that I ended up needing to
figure out some issues in my own code
Note that there's still one important part of this process missing
that's not included in this patch series: EDID reprobing, which I
believe Stanislav Lisovskiy from Intel is currently working on. The main
purpose of this series is to fix the issue of the in-memory topology
state (e.g. connectors connected to an MST hub, branch devices, etc.)
going out of sync if a topology connected to a connector is swapped out
with a different topology while the system is resumed, or while the
device housing said connector is in runtime suspend.
As well, the debugging tools that are added in this include:
- A limited debugging utility for dumping the list of topology
references on an MST port or branch connector whose topology reference
count has reached 0
- Sideband down request dumping, along with some basic selftests for
testing our encoding/decoding functions
Patchseries wide changes since v1
- Add "Combine redundant cases in drm_dp_encode_sideband_req()" to
fulfill some of the danvet's review requests
Lyude Paul (27):
drm/dp_mst: Move link address dumping into a function
drm/dp_mst: Get rid of list clear in destroy_connector_work
drm/dp_mst: Destroy MSTBs asynchronously
drm/dp_mst: Move test_calc_pbn_mode() into an actual selftest
drm/print: Add drm_err_printer()
drm/dp_mst: Combine redundant cases in drm_dp_encode_sideband_req()
drm/dp_mst: Add sideband down request tracing + selftests
drm/dp_mst: Remove PDT teardown in drm_dp_destroy_port() and refactor
drm/dp_mst: Refactor drm_dp_send_enum_path_resources
drm/dp_mst: Remove huge conditional in drm_dp_mst_handle_up_req()
drm/dp_mst: Constify guid in drm_dp_get_mst_branch_by_guid()
drm/dp_mst: Refactor drm_dp_mst_handle_up_req()
drm/dp_mst: Refactor drm_dp_mst_handle_down_rep()
drm/dp_mst: Destroy topology_mgr mutexes
drm/dp_mst: Cleanup drm_dp_send_link_address() a bit
drm/dp_mst: Refactor pdt setup/teardown, add more locking
drm/dp_mst: Rename drm_dp_add_port and drm_dp_update_port
drm/dp_mst: Remove lies in {up,down}_rep_recv documentation
drm/dp_mst: Handle UP requests asynchronously
drm/dp_mst: Protect drm_dp_mst_port members with connection_mutex
drm/dp_mst: Don't forget to update port->input in
drm_dp_mst_handle_conn_stat()
drm/nouveau: Don't grab runtime PM refs for HPD IRQs
drm/amdgpu: Iterate through DRM connectors correctly
drm/amdgpu/dm: Resume short HPD IRQs before resuming MST topology
drm/dp_mst: Add basic topology reprobing when resuming
drm/dp_mst: Also print unhashed pointers for malloc/topology
references
drm/dp_mst: Add topology ref history tracking for debugging
drivers/gpu/drm/Kconfig | 14 +
.../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 13 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 20 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c |5 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_encoders.c | 40 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c |5 +-
drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 34 +-
drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 34 +-
drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 40 +-
drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 34 +-
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 41 +-
.../drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c | 10 +-
drivers/gpu/drm/drm_dp_mst_topology.c | 1633 +
.../gpu/drm/drm_dp_mst_topology_internal.h| 24 +
drivers/gpu/drm/drm_print.c |6 +
drivers/gpu/drm/i915/display/intel_dp.c |3 +-
drivers/gpu/drm/nouveau/dispnv50/disp.c |6 +-
drivers/gpu/drm/nouveau/nouveau_connector.c | 33 +-
drivers/gpu/drm/selftests/Makefile|2 +-
.../gpu/drm/selftests/drm_modeset_selftests.h |2 +
.../drm/selftests/test-drm_dp_mst_helper.c| 238 +++
.../drm/selftests/test-drm_modeset_common.h |2 +
include/drm/drm_dp_mst_helper.h | 143 +-
include/drm/drm_print.h | 17 +
24 files changed, 1873 insertions(+), 526 deletions(-)
create mode 100644 drivers/gpu/drm/drm_dp_mst_topology_internal.h
create mode 100644 drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Revert "drm/i915: Fix DP-MST crtc_mask"
On Tue, 2019-09-03 at 18:40 +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > This reverts commit 4eaceea3a00f8e936a7f48dcd0c975a57f88930f. > > Several userspace clients (modesetting ddx and mutter+wayland at > least) > handle encoder.possible_crtcs incorrectly. What they essentially do > is > the following: > > possible_crtcs = ~0; > for_each_possible_encoder(connector) > possible_crtcs &= encoder->possible_crtcs; > > Ie. they calculate the intersection of the possible_crtcs > for the connector when they really should be calculating the > union instead. > > In our case each MST encoder now has just one unique bit set, > and so the intersection is always zero. The end result is that > MST connectors can't be lit up because no crtc can be found to > drive them. > > I've submitted a fix for the modesetting ddx [1], and complained > on #wayland about mutter, so hopefully the situation will improve > in the future. In the meantime we have regression, and so must go > back to the old way of misconfiguring possible_crtcs in the kernel. In the meantime are you planing to send a patch doing: for_each_pipe(dev_priv, pipe) intel_encoder->crtc_mask |= BIT(pipe); We had a patch doing that in one of the TGL enabling series but it was dropped because of your patch looked better, I can bring it back if you are not planning. > > [1] https://gitlab.freedesktop.org/xorg/xserver/merge_requests/277 Just looked to the merge request above, not to the other userspace clients Reviewed-by: José Roberto de Souza > > Cc: Jonas Ådahl > Cc: Stanislav Lisovskiy > Cc: Lionel Landwerlin > Cc: Dhinakaran Pandiyan > Cc: Lucas De Marchi > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111507 > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c > b/drivers/gpu/drm/i915/display/intel_dp_mst.c > index 6df240a01b8c..37366f81255b 100644 > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c > @@ -615,7 +615,7 @@ intel_dp_create_fake_mst_encoder(struct > intel_digital_port *intel_dig_port, enum > intel_encoder->type = INTEL_OUTPUT_DP_MST; > intel_encoder->power_domain = intel_dig_port- > >base.power_domain; > intel_encoder->port = intel_dig_port->base.port; > - intel_encoder->crtc_mask = BIT(pipe); > + intel_encoder->crtc_mask = 0x7; > intel_encoder->cloneable = 0; > > intel_encoder->compute_config = intel_dp_mst_compute_config; ___ 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/3] drm/atomic: Take the atomic toys away from X
== Series Details == Series: series starting with [1/3] drm/atomic: Take the atomic toys away from X URL : https://patchwork.freedesktop.org/series/66180/ State : warning == Summary == $ dim checkpatch origin/drm-tip 6ca9335b74af drm/atomic: Take the atomic toys away from X -:51: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 9 lines checked 94ce77c000f1 drm/atomic: Reject FLIP_ASYNC unconditionally -:38: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 9 lines checked a705142c4deb drm/atomic: Rename crtc_state->pageflip_flags to async_flip -:125: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 65 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/3] drm/atomic: Reject FLIP_ASYNC unconditionally
== Series Details == Series: series starting with [1/3] drm/atomic: Reject FLIP_ASYNC unconditionally URL : https://patchwork.freedesktop.org/series/66178/ State : failure == Summary == Applying: drm/atomic: Reject FLIP_ASYNC unconditionally Applying: drm/atomic: Rename crtc_state->pageflip_flags to async_flip Applying: fixup error: sha1 information is lacking or useless (drivers/gpu/drm/drm_ioctl.c). error: could not build fake ancestor hint: Use 'git am --show-current-patch' to see the failed patch Patch failed at 0003 fixup 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] [v10][PATCH 7/8] drm/i915/display: Extract glk_read_luts()
For glk, add hw read out to create hw blob of gamma
lut values.
v4: -No need to initialize *blob [Jani]
-Removed right shifts [Jani]
-Dropped dev local var [Jani]
v5: -Returned blob instead of assigning it internally within the
function [Ville]
-Renamed glk_get_color_config() to glk_read_luts() [Ville]
-Added degamma validation [Ville]
v9: -80 character limit [Uma]
-Made read func para as const [Ville, Uma]
Signed-off-by: Swati Sharma
---
drivers/gpu/drm/i915/display/intel_color.c | 51 --
drivers/gpu/drm/i915/i915_reg.h| 3 ++
2 files changed, 52 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index 80f82b2..6d641e1 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -1597,6 +1597,52 @@ static void ilk_read_luts(struct intel_crtc_state
*crtc_state)
crtc_state->base.gamma_lut = ilk_read_lut_10(crtc_state);
}
+static struct drm_property_blob *
+glk_read_lut_10(const struct intel_crtc_state *crtc_state, u32 prec_index)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ int hw_lut_size = ivb_lut_10_size(prec_index);
+ enum pipe pipe = crtc->pipe;
+ struct drm_property_blob *blob;
+ struct drm_color_lut *blob_data;
+ u32 i, val;
+
+ I915_WRITE(PREC_PAL_INDEX(pipe), prec_index |
+ PAL_PREC_AUTO_INCREMENT);
+
+ blob = drm_property_create_blob(_priv->drm,
+ sizeof(struct drm_color_lut) *
hw_lut_size,
+ NULL);
+ if (IS_ERR(blob))
+ return NULL;
+
+ blob_data = blob->data;
+
+ for (i = 0; i < hw_lut_size; i++) {
+ val = I915_READ(PREC_PAL_DATA(pipe));
+
+ blob_data[i].red = intel_color_lut_pack(REG_FIELD_GET(
+ PREC_PAL_DATA_RED_MASK,
val), 10);
+ blob_data[i].green = intel_color_lut_pack(REG_FIELD_GET(
+
PREC_PAL_DATA_GREEN_MASK, val), 10);
+ blob_data[i].blue = intel_color_lut_pack(REG_FIELD_GET(
+
PREC_PAL_DATA_BLUE_MASK, val), 10);
+ }
+
+ I915_WRITE(PREC_PAL_INDEX(pipe), 0);
+
+ return blob;
+}
+
+static void glk_read_luts(struct intel_crtc_state *crtc_state)
+{
+ if (crtc_state->gamma_mode == GAMMA_MODE_MODE_8BIT)
+ crtc_state->base.gamma_lut = i9xx_read_lut_8(crtc_state);
+ else
+ crtc_state->base.gamma_lut = glk_read_lut_10(crtc_state,
PAL_PREC_INDEX_VALUE(0));
+}
+
void intel_color_init(struct intel_crtc *crtc)
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
@@ -1638,9 +1684,10 @@ void intel_color_init(struct intel_crtc *crtc)
if (INTEL_GEN(dev_priv) >= 11)
dev_priv->display.load_luts = icl_load_luts;
- else if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv))
+ else if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv)) {
dev_priv->display.load_luts = glk_load_luts;
- else if (INTEL_GEN(dev_priv) >= 8)
+ dev_priv->display.read_luts = glk_read_luts;
+ } else if (INTEL_GEN(dev_priv) >= 8)
dev_priv->display.load_luts = bdw_load_luts;
else if (INTEL_GEN(dev_priv) >= 7)
dev_priv->display.load_luts = ivb_load_luts;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 67d8cad..c584d0e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -10259,6 +10259,9 @@ enum skl_power_gate {
#define _PAL_PREC_GC_MAX_A 0x4A410
#define _PAL_PREC_GC_MAX_B 0x4AC10
#define _PAL_PREC_GC_MAX_C 0x4B410
+#define PREC_PAL_DATA_RED_MASK REG_GENMASK(29, 20)
+#define PREC_PAL_DATA_GREEN_MASK REG_GENMASK(19, 10)
+#define PREC_PAL_DATA_BLUE_MASK REG_GENMASK(9, 0)
#define _PAL_PREC_EXT_GC_MAX_A 0x4A420
#define _PAL_PREC_EXT_GC_MAX_B 0x4AC20
#define _PAL_PREC_EXT_GC_MAX_C 0x4B420
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v10][PATCH 8/8] FOR_TESTING_ONLY: Print rgb values of hw and sw blobs
Signed-off-by: Swati Sharma
---
drivers/gpu/drm/i915/display/intel_color.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index 6d641e1..78608a5 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -1434,6 +1434,8 @@ int intel_color_get_gamma_bit_precision(const struct
intel_crtc_state *crtc_stat
static bool err_check(struct drm_color_lut *lut1,
struct drm_color_lut *lut2, u32 err)
{
+ DRM_DEBUG_KMS("hw_lut->red=0x%x sw_lut->red=0x%x hw_lut->blue=0x%x
sw_lut->blue=0x%x hw_lut->green=0x%x sw_lut->green=0x%x", lut2->red, lut1->red,
lut2->blue, lut1->blue, lut2->green, lut1->green);
+
return ((abs((long)lut2->red - lut1->red)) <= err) &&
((abs((long)lut2->blue - lut1->blue)) <= err) &&
((abs((long)lut2->green - lut1->green)) <= err);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v10][PATCH 1/8] drm/i915/display: Add func to get gamma bit precision
Each platform supports different gamma modes and each gamma mode
has different bit precision. Here bit precision corresponds
to number of bits the hw LUT supports.
Add func per platform to return bit precision corresponding to gamma mode
which will be later used as a parameter in lut comparison function
intel_color_lut_equal().
This is done for legacy, ilk, glk and their variant platforms.
v6: -Added func intel_color_get_bit_precision() to get bit precision for
gamma and degamma lut readout depending upon platform and
corresponding to load_luts() [Ankit]
-Made patch11 as patch3 [Jani]
v7: -Renamed func intel_color_get_bit_precision() to
intel_color_get_gamma_bit_precision()
-Added separate function/platform for gamma bit precision [Ville]
-Corrected checkpatch warnings
v8: -Split patch 3 into 4 separate patches
v9: -Changed commit message, gave more info [Uma]
-Added precision func for icl+ platform
v10: -Removed precision func for chv and icl+ platforms [Jani]
-Added gamma_enable check once [Jani]
Signed-off-by: Swati Sharma
---
drivers/gpu/drm/i915/display/intel_color.c | 60 ++
drivers/gpu/drm/i915/display/intel_color.h | 1 +
2 files changed, 61 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index 71a0201..b5c0c65 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -1371,6 +1371,66 @@ static int icl_color_check(struct intel_crtc_state
*crtc_state)
return 0;
}
+static int i9xx_gamma_precision(const struct intel_crtc_state *crtc_state)
+{
+ switch (crtc_state->gamma_mode) {
+ case GAMMA_MODE_MODE_8BIT:
+ return 8;
+ case GAMMA_MODE_MODE_10BIT:
+ return 16;
+ default:
+ MISSING_CASE(crtc_state->gamma_mode);
+ return 0;
+ }
+}
+
+static int ilk_gamma_precision(const struct intel_crtc_state *crtc_state)
+{
+ if ((crtc_state->csc_mode & CSC_POSITION_BEFORE_GAMMA) == 0)
+ return 0;
+
+ switch (crtc_state->gamma_mode) {
+ case GAMMA_MODE_MODE_8BIT:
+ return 8;
+ case GAMMA_MODE_MODE_10BIT:
+ return 10;
+ default:
+ MISSING_CASE(crtc_state->gamma_mode);
+ return 0;
+ }
+}
+
+static int glk_gamma_precision(const struct intel_crtc_state *crtc_state)
+{
+ switch (crtc_state->gamma_mode) {
+ case GAMMA_MODE_MODE_8BIT:
+ return 8;
+ case GAMMA_MODE_MODE_10BIT:
+ return 10;
+ default:
+ MISSING_CASE(crtc_state->gamma_mode);
+ return 0;
+ }
+}
+
+int intel_color_get_gamma_bit_precision(const struct intel_crtc_state
*crtc_state)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+
+ if (!crtc_state->gamma_enable)
+ return 0;
+
+ if (HAS_GMCH(dev_priv) && !IS_CHERRYVIEW(dev_priv))
+ return i9xx_gamma_precision(crtc_state);
+ else if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv))
+ return glk_gamma_precision(crtc_state);
+ else if (IS_IRONLAKE(dev_priv))
+ return ilk_gamma_precision(crtc_state);
+
+ return 0;
+}
+
void intel_color_init(struct intel_crtc *crtc)
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
diff --git a/drivers/gpu/drm/i915/display/intel_color.h
b/drivers/gpu/drm/i915/display/intel_color.h
index 057e8ac..0226d3a 100644
--- a/drivers/gpu/drm/i915/display/intel_color.h
+++ b/drivers/gpu/drm/i915/display/intel_color.h
@@ -14,5 +14,6 @@
void intel_color_commit(const struct intel_crtc_state *crtc_state);
void intel_color_load_luts(const struct intel_crtc_state *crtc_state);
void intel_color_get_config(struct intel_crtc_state *crtc_state);
+int intel_color_get_gamma_bit_precision(const struct intel_crtc_state
*crtc_state);
#endif /* __INTEL_COLOR_H__ */
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v10][PATCH 3/8] drm/i915/display: Add func to compare hw/sw gamma lut
Add func intel_color_lut_equal() to compare hw/sw gamma
lut values. Since hw/sw gamma lut sizes and lut entries comparison
will be different for different gamma modes, add gamma mode dependent
checks.
v3: -Rebase
v4: -Renamed intel_compare_color_lut() to intel_color_lut_equal() [Jani]
-Added the default label above the correct label [Jani]
-Corrected smatch warn "variable dereferenced before check"
[Dan Carpenter]
v5: -Added condition (!blob1 && !blob2) return true [Jani]
v6: -Made patch11 as patch3 [Jani]
v8: -Split patch 3 into 4 patches
-Optimized blob check condition [Ville]
v9: -Exclude spilt gamma mode (bdw and ivb platforms)
as there is exception in way gamma values are written in
hardware [Ville]
-Added exception made in commit [Uma]
-Dropped else, character limit and indentation [Uma]
-Added multi segmented gama mode for icl+ platforms [Uma]
v10: -Dropped multi segmented mode for icl+ platforms [Jani]
-Removed references of sw and hw state in compare code [Jani]
-Dropped inline from func [Jani]
Signed-off-by: Swati Sharma
---
drivers/gpu/drm/i915/display/intel_color.c | 72 ++
drivers/gpu/drm/i915/display/intel_color.h | 6 +++
2 files changed, 78 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index b5c0c65..1ab561d 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -1431,6 +1431,78 @@ int intel_color_get_gamma_bit_precision(const struct
intel_crtc_state *crtc_stat
return 0;
}
+static bool err_check(struct drm_color_lut *lut1,
+ struct drm_color_lut *lut2, u32 err)
+{
+ return ((abs((long)lut2->red - lut1->red)) <= err) &&
+ ((abs((long)lut2->blue - lut1->blue)) <= err) &&
+ ((abs((long)lut2->green - lut1->green)) <= err);
+}
+
+static bool intel_color_lut_entry_equal(struct drm_color_lut *lut1,
+ struct drm_color_lut *lut2,
+ int lut_size, u32 err)
+{
+ int i;
+
+ for (i = 0; i < lut_size; i++) {
+ if (!err_check([i], [i], err))
+ return false;
+ }
+
+ return true;
+}
+
+bool intel_color_lut_equal(struct drm_property_blob *blob1,
+ struct drm_property_blob *blob2,
+ u32 gamma_mode, u32 bit_precision)
+{
+ struct drm_color_lut *lut1, *lut2;
+ int lut_size1, lut_size2;
+ u32 err;
+
+ if (!blob1 != !blob2)
+ return false;
+
+ if (!blob1)
+ return true;
+
+ lut_size1 = drm_color_lut_size(blob1);
+ lut_size2 = drm_color_lut_size(blob2);
+
+ /* check sw and hw lut size */
+ switch (gamma_mode) {
+ case GAMMA_MODE_MODE_8BIT:
+ case GAMMA_MODE_MODE_10BIT:
+ if (lut_size1 != lut_size2)
+ return false;
+ break;
+ default:
+ MISSING_CASE(gamma_mode);
+ return false;
+ }
+
+ lut1 = blob1->data;
+ lut2 = blob2->data;
+
+ err = 0x >> bit_precision;
+
+ /* check sw and hw lut entry to be equal */
+ switch (gamma_mode) {
+ case GAMMA_MODE_MODE_8BIT:
+ case GAMMA_MODE_MODE_10BIT:
+ if (!intel_color_lut_entry_equal(lut1, lut2,
+lut_size2, err))
+ return false;
+ break;
+ default:
+ MISSING_CASE(gamma_mode);
+ return false;
+ }
+
+ return true;
+}
+
void intel_color_init(struct intel_crtc *crtc)
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
diff --git a/drivers/gpu/drm/i915/display/intel_color.h
b/drivers/gpu/drm/i915/display/intel_color.h
index 0226d3a..173727a 100644
--- a/drivers/gpu/drm/i915/display/intel_color.h
+++ b/drivers/gpu/drm/i915/display/intel_color.h
@@ -6,8 +6,11 @@
#ifndef __INTEL_COLOR_H__
#define __INTEL_COLOR_H__
+#include
+
struct intel_crtc_state;
struct intel_crtc;
+struct drm_property_blob;
void intel_color_init(struct intel_crtc *crtc);
int intel_color_check(struct intel_crtc_state *crtc_state);
@@ -15,5 +18,8 @@
void intel_color_load_luts(const struct intel_crtc_state *crtc_state);
void intel_color_get_config(struct intel_crtc_state *crtc_state);
int intel_color_get_gamma_bit_precision(const struct intel_crtc_state
*crtc_state);
+bool intel_color_lut_equal(struct drm_property_blob *blob1,
+ struct drm_property_blob *blob2,
+ u32 gamma_mode, u32 bit_precision);
#endif /* __INTEL_COLOR_H__ */
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
[Intel-gfx] [v10][PATCH 0/8] drm/i915: adding state checker for gamma lut values
In this patch series, added state checker to validate gamma (8BIT and 10BIT).This reads hardware state, and compares the originally requested state(s/w) to the state read from the hardware. This is done for legacy, ilk, glk and their variant platforms. Rest of the platforms will be enabled on top of this later. Intentionally, excluded bdw and ivb since they have spilt gamma mode; for which degamma read outs are required (which I think shouldn't be included in this patch series). Will include after degamma state checker is completed. v1: -Implementation done for legacy platforms (removed all the placeholders) (Jani) v2: -Restructured code and created platform specific patch series for gamma validation v3: -Rebase v4: -Minor changes-function name changes mainly v5: -Added degamma validation (Ville) v6: -Removed degamma changes, debugging was becoming difficult -Added function to assign bit_precision for gamma/degamma lut values /platform -Added debug info into intel_dump_pipe_config() (Jani) v7: -Added platform specific functions to compute gamma bit precision on the basis of GAMMA_MODE (Ville) -Corrected checkpatch warnings v8: -Restructured code -Removed bdw and ivb platform state checker v9: -Obliged 80 character word limit [Uma] -Added state checker for icl -Added bit precision func for icl v10: -Dropped multi-seg gamma mode [Jani] -Enabled basic infrastructure only [Jani] -Minor fixes [Jani] Swati Sharma (8): drm/i915/display: Add func to get gamma bit precision drm/i915/display: Add debug log for color parameters drm/i915/display: Add func to compare hw/sw gamma lut drm/i915/display: Add macro to compare gamma hw/sw lut drm/i915/display: Extract i9xx_read_luts() drm/i915/display: Extract ilk_read_luts() drm/i915/display: Extract glk_read_luts() FOR_TESTING_ONLY: Print rgb values of hw and sw blobs drivers/gpu/drm/i915/display/intel_color.c | 284 ++- drivers/gpu/drm/i915/display/intel_color.h | 7 + drivers/gpu/drm/i915/display/intel_display.c | 34 drivers/gpu/drm/i915/i915_reg.h | 9 + 4 files changed, 331 insertions(+), 3 deletions(-) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v10][PATCH 6/8] drm/i915/display: Extract ilk_read_luts()
For ilk, add hw read out to create hw blob of gamma
lut values.
v4: -No need to initialize *blob [Jani]
-Removed right shifts [Jani]
-Dropped dev local var [Jani]
v5: -Returned blob instead of assigning it internally within the
function [Ville]
-Renamed ilk_get_color_config() to ilk_read_luts() [Ville]
v9: -80 character limit [Uma]
-Made read func para as const [Ville, Uma]
-Renamed ilk_read_gamma_lut() to ilk_read_lut_10() [Uma, Ville]
v10: -Made ilk_read_luts() static [Jani]
-ilk_load_lut_10 has lut_size, not (lut_size - 1) [Jani]
Signed-off-by: Swati Sharma
Reviewed-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_color.c | 45 +-
drivers/gpu/drm/i915/i915_reg.h| 3 ++
2 files changed, 47 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index 55076de..80f82b2 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -1556,6 +1556,47 @@ static void i9xx_read_luts(struct intel_crtc_state
*crtc_state)
crtc_state->base.gamma_lut = i9xx_read_lut_8(crtc_state);
}
+static struct drm_property_blob *
+ilk_read_lut_10(const struct intel_crtc_state *crtc_state)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ u32 lut_size = INTEL_INFO(dev_priv)->color.gamma_lut_size;
+ enum pipe pipe = crtc->pipe;
+ struct drm_property_blob *blob;
+ struct drm_color_lut *blob_data;
+ u32 i, val;
+
+ blob = drm_property_create_blob(_priv->drm,
+ sizeof(struct drm_color_lut) * lut_size,
+ NULL);
+ if (IS_ERR(blob))
+ return NULL;
+
+ blob_data = blob->data;
+
+ for (i = 0; i < lut_size; i++) {
+ val = I915_READ(PREC_PALETTE(pipe, i));
+
+ blob_data[i].red = intel_color_lut_pack(REG_FIELD_GET(
+ PREC_PALETTE_RED_MASK,
val), 10);
+ blob_data[i].green = intel_color_lut_pack(REG_FIELD_GET(
+
PREC_PALETTE_GREEN_MASK, val), 10);
+ blob_data[i].blue = intel_color_lut_pack(REG_FIELD_GET(
+
PREC_PALETTE_BLUE_MASK, val), 10);
+ }
+
+ return blob;
+}
+
+static void ilk_read_luts(struct intel_crtc_state *crtc_state)
+{
+ if (crtc_state->gamma_mode == GAMMA_MODE_MODE_8BIT)
+ crtc_state->base.gamma_lut = i9xx_read_lut_8(crtc_state);
+ else
+ crtc_state->base.gamma_lut = ilk_read_lut_10(crtc_state);
+}
+
void intel_color_init(struct intel_crtc *crtc)
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
@@ -1603,8 +1644,10 @@ void intel_color_init(struct intel_crtc *crtc)
dev_priv->display.load_luts = bdw_load_luts;
else if (INTEL_GEN(dev_priv) >= 7)
dev_priv->display.load_luts = ivb_load_luts;
- else
+ else {
dev_priv->display.load_luts = ilk_load_luts;
+ dev_priv->display.read_luts = ilk_read_luts;
+ }
}
drm_crtc_enable_color_mgmt(>base,
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 09ea5b1..67d8cad 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7200,6 +7200,9 @@ enum {
/* ilk/snb precision palette */
#define _PREC_PALETTE_A 0x4b000
#define _PREC_PALETTE_B 0x4c000
+#define PREC_PALETTE_RED_MASK REG_GENMASK(29, 20)
+#define PREC_PALETTE_GREEN_MASK REG_GENMASK(19, 10)
+#define PREC_PALETTE_BLUE_MASK REG_GENMASK(9, 0)
#define PREC_PALETTE(pipe, i) _MMIO(_PIPE(pipe, _PREC_PALETTE_A,
_PREC_PALETTE_B) + (i) * 4)
#define _PREC_PIPEAGCMAX 0x4d000
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v10][PATCH 5/8] drm/i915/display: Extract i9xx_read_luts()
For the legacy(gen < 4) gamma, add hw read out to create hw blob of gamma
lut values. Also, add function intel_color_lut_pack to convert hw value
with given bit precision to lut property val.
v4: -No need to initialize *blob [Jani]
-Removed right shifts [Jani]
-Dropped dev local var [Jani]
v5: -Returned blob instead of assigning it internally within the
function [Ville]
-Renamed function i9xx_get_color_config() to i9xx_read_luts()
-Renamed i9xx_get_config_internal() to i9xx_read_lut_8() [Ville]
v9: -Change in commit message [Jani, Uma]
-Wrap commit within 75 characters [Uma]
-Use macro for 256 [Uma]
-Made read func para as const [Ville, Uma]
v10: -Made i9xx_read_luts() static [Jani]
Signed-off-by: Swati Sharma
Reviewed-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_color.c | 54 ++
drivers/gpu/drm/i915/i915_reg.h| 3 ++
2 files changed, 57 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index 1ab561d..55076de 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -1503,6 +1503,59 @@ bool intel_color_lut_equal(struct drm_property_blob
*blob1,
return true;
}
+/* convert hw value with given bit_precision to lut property val */
+static u32 intel_color_lut_pack(u32 val, u32 bit_precision)
+{
+ u32 max = 0x >> (16 - bit_precision);
+
+ val = clamp_val(val, 0, max);
+
+ if (bit_precision < 16)
+ val <<= 16 - bit_precision;
+
+ return val;
+}
+
+static struct drm_property_blob *
+i9xx_read_lut_8(const struct intel_crtc_state *crtc_state)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum pipe pipe = crtc->pipe;
+ struct drm_property_blob *blob;
+ struct drm_color_lut *blob_data;
+ u32 i, val;
+
+ blob = drm_property_create_blob(_priv->drm,
+ sizeof(struct drm_color_lut) *
LEGACY_LUT_LENGTH,
+ NULL);
+ if (IS_ERR(blob))
+ return NULL;
+
+ blob_data = blob->data;
+
+ for (i = 0; i < LEGACY_LUT_LENGTH; i++) {
+ if (HAS_GMCH(dev_priv))
+ val = I915_READ(PALETTE(pipe, i));
+ else
+ val = I915_READ(LGC_PALETTE(pipe, i));
+
+ blob_data[i].red = intel_color_lut_pack(REG_FIELD_GET(
+ LGC_PALETTE_RED_MASK,
val), 8);
+ blob_data[i].green = intel_color_lut_pack(REG_FIELD_GET(
+
LGC_PALETTE_GREEN_MASK, val), 8);
+ blob_data[i].blue = intel_color_lut_pack(REG_FIELD_GET(
+LGC_PALETTE_BLUE_MASK,
val), 8);
+ }
+
+ return blob;
+}
+
+static void i9xx_read_luts(struct intel_crtc_state *crtc_state)
+{
+ crtc_state->base.gamma_lut = i9xx_read_lut_8(crtc_state);
+}
+
void intel_color_init(struct intel_crtc *crtc)
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
@@ -1523,6 +1576,7 @@ void intel_color_init(struct intel_crtc *crtc)
dev_priv->display.color_check = i9xx_color_check;
dev_priv->display.color_commit = i9xx_color_commit;
dev_priv->display.load_luts = i9xx_load_luts;
+ dev_priv->display.read_luts = i9xx_read_luts;
}
} else {
if (INTEL_GEN(dev_priv) >= 11)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 02e1ef1..09ea5b1 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7192,6 +7192,9 @@ enum {
/* legacy palette */
#define _LGC_PALETTE_A 0x4a000
#define _LGC_PALETTE_B 0x4a800
+#define LGC_PALETTE_RED_MASK REG_GENMASK(23, 16)
+#define LGC_PALETTE_GREEN_MASK REG_GENMASK(15, 8)
+#define LGC_PALETTE_BLUE_MASKREG_GENMASK(7, 0)
#define LGC_PALETTE(pipe, i) _MMIO(_PIPE(pipe, _LGC_PALETTE_A, _LGC_PALETTE_B)
+ (i) * 4)
/* ilk/snb precision palette */
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v10][PATCH 4/8] drm/i915/display: Add macro to compare gamma hw/sw lut
Add macro to compare hw/sw gamma lut values. First need to
check whether hw/sw gamma mode matches or not. If not
no need to compare lut values, if matches then only compare
lut entries.
v5: -Called PIPE_CONF_CHECK_COLOR_LUT inside if (!adjust) [Jani]
-Added #undef PIPE_CONF_CHECK_COLOR_LUT [Jani]
v8: -Added check for gamma mode before gamma lut entry comparison
[Jani]
-Split patch 3 into 4 patches
Signed-off-by: Swati Sharma
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_display.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index f9c0842..776b365 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -12529,6 +12529,7 @@ static bool fastboot_enabled(struct drm_i915_private
*dev_priv)
{
struct drm_i915_private *dev_priv =
to_i915(current_config->base.crtc->dev);
bool ret = true;
+ u32 bp_gamma = 0;
bool fixup_inherited = fastset &&
(current_config->base.mode.private_flags &
I915_MODE_FLAG_INHERITED) &&
!(pipe_config->base.mode.private_flags &
I915_MODE_FLAG_INHERITED);
@@ -12680,6 +12681,24 @@ static bool fastboot_enabled(struct drm_i915_private
*dev_priv)
} \
} while (0)
+#define PIPE_CONF_CHECK_COLOR_LUT(name1, name2, bit_precision) do { \
+ if (current_config->name1 != pipe_config->name1) { \
+ pipe_config_mismatch(fastset, __stringify(name1), \
+ "(expected %i, found %i, won't compare lut
values)\n", \
+ current_config->name1, \
+ pipe_config->name1); \
+ ret = false;\
+ } else { \
+ if (!intel_color_lut_equal(current_config->name2, \
+ pipe_config->name2, pipe_config->name1,
\
+ bit_precision)) { \
+ pipe_config_mismatch(fastset, __stringify(name2), \
+ "hw_state doesn't match sw_state\n"); \
+ ret = false; \
+ } \
+ } \
+} while (0)
+
#define PIPE_CONF_QUIRK(quirk) \
((current_config->quirks | pipe_config->quirks) & (quirk))
@@ -12775,6 +12794,11 @@ static bool fastboot_enabled(struct drm_i915_private
*dev_priv)
PIPE_CONF_CHECK_X(csc_mode);
PIPE_CONF_CHECK_BOOL(gamma_enable);
PIPE_CONF_CHECK_BOOL(csc_enable);
+
+ bp_gamma = intel_color_get_gamma_bit_precision(pipe_config);
+ if (bp_gamma)
+ PIPE_CONF_CHECK_COLOR_LUT(gamma_mode, base.gamma_lut,
bp_gamma);
+
}
PIPE_CONF_CHECK_BOOL(double_wide);
@@ -12837,6 +12861,7 @@ static bool fastboot_enabled(struct drm_i915_private
*dev_priv)
#undef PIPE_CONF_CHECK_P
#undef PIPE_CONF_CHECK_FLAGS
#undef PIPE_CONF_CHECK_CLOCK_FUZZY
+#undef PIPE_CONF_CHECK_COLOR_LUT
#undef PIPE_CONF_QUIRK
return ret;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v10][PATCH 2/8] drm/i915/display: Add debug log for color parameters
Add debug log for color related parameters like gamma_mode, gamma_enable,
csc_enable, etc inside intel_dump_pipe_config().
v6: -Added debug log for color para in intel_dump_pipe_config [Jani]
v7: -Split patch 3 into 4 patches
v8: -Corrected alignment [Uma]
Signed-off-by: Swati Sharma
Reviewed-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index ea2915d..f9c0842 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -12138,6 +12138,15 @@ static void intel_dump_pipe_config(const struct
intel_crtc_state *pipe_config,
intel_dpll_dump_hw_state(dev_priv, _config->dpll_hw_state);
+ if (IS_CHERRYVIEW(dev_priv))
+ DRM_DEBUG_KMS("cgm_mode: 0x%x gamma_mode: 0x%x gamma_enable: %d
csc_enable: %d\n",
+ pipe_config->cgm_mode, pipe_config->gamma_mode,
+ pipe_config->gamma_enable,
pipe_config->csc_enable);
+ else
+ DRM_DEBUG_KMS("csc_mode: 0x%x gamma_mode: 0x%x gamma_enable: %d
csc_enable: %d\n",
+ pipe_config->csc_mode, pipe_config->gamma_mode,
+ pipe_config->gamma_enable,
pipe_config->csc_enable);
+
dump_planes:
if (!state)
return;
--
1.9.1
___
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_tiled_swapping: Tweak mlocked size
On my systems with lots of memdebug enabled, we would hit the oomkiller
90% of the time during the initial mlock prior to allocating any objects
(and about 20% of the time lockup / panic). Tweak the target allocation
sizes, and include a few more breadcrumbs tracing the allocations so
that we can reliably start the tests. We still do hit our shrinker and
even the oom notifier, so still achieving its goal of exercising low
memory and swap pressure.
To slightly compensate for the reduced mempressure (albeit we do not
remove the swapping, the raison d'etre of the test), we increase the
number of threads to force the system to reuse active fences, making it
more stressful on the fence code.
Signed-off-by: Chris Wilson
Cc: Andi Shyti
---
tests/i915/gem_tiled_swapping.c | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/tests/i915/gem_tiled_swapping.c b/tests/i915/gem_tiled_swapping.c
index ddf2a748f..1b70c1e51 100644
--- a/tests/i915/gem_tiled_swapping.c
+++ b/tests/i915/gem_tiled_swapping.c
@@ -165,8 +165,9 @@ static void check_memory_layout(int fd)
igt_main
{
+ unsigned long n, count;
struct thread *threads;
- int fd, n, count, num_threads;
+ int fd, num_threads;
igt_fixture {
size_t lock_size;
@@ -179,23 +180,30 @@ igt_main
check_memory_layout(fd);
/* lock RAM, leaving only 512MB available */
- lock_size = max(0, intel_get_total_ram_mb() - AVAIL_RAM);
+ count = intel_get_total_ram_mb() - intel_get_avail_ram_mb();
+ count = max(count + 64, AVAIL_RAM);
+ lock_size = max(0, intel_get_total_ram_mb() - count);
+ igt_info("Mlocking %zdMiB of %ld/%ldMiB\n",
+lock_size,
+(long)intel_get_avail_ram_mb(),
+(long)intel_get_total_ram_mb());
igt_lock_mem(lock_size);
/* need slightly more than available memory */
- count = min(intel_get_total_ram_mb(), AVAIL_RAM) * 1.25;
+ count = intel_get_avail_ram_mb() + 128;
+ igt_info("Using %lu 1MiB objects (available RAM: %ld/%ld, swap:
%ld)\n",
+count,
+(long)intel_get_avail_ram_mb(),
+(long)intel_get_total_ram_mb(),
+(long)intel_get_total_swap_mb());
bo_handles = calloc(count, sizeof(uint32_t));
igt_assert(bo_handles);
- num_threads = gem_available_fences(fd);
+ num_threads = gem_available_fences(fd) + 1;
+ igt_info("Using up to %d fences/threads\n", num_threads);
threads = calloc(num_threads, sizeof(struct thread));
igt_assert(threads);
- igt_info("Using %d 1MiB objects (available RAM: %ld/%ld, swap:
%ld)\n",
-count,
-(long)intel_get_avail_ram_mb(),
-(long)intel_get_total_ram_mb(),
-(long)intel_get_total_swap_mb());
intel_require_memory(count, 1024*1024, CHECK_RAM | CHECK_SWAP);
for (n = 0; n < count; n++) {
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: disable set/get_tiling ioctl on gen12+
On Thu, 2019-08-29 at 08:50 +0200, Daniel Vetter wrote: > On Wed, Aug 28, 2019 at 08:31:27PM +, Souza, Jose wrote: > > On Wed, 2019-08-28 at 21:13 +0100, Chris Wilson wrote: > > > Quoting Souza, Jose (2019-08-28 21:11:53) > > > > Reviewed-by: José Roberto de Souza > > > > > > It's using a non-standard for i915 error code, and get_tiling is > > > not > > > > Huum should it use ENOTSUPP then?! > > https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#recommended-ioctl-return-values > > Per above "feature not supported" -> EOPNOTSUPP. But like Chris said we are not using EOPNOTSUPP in i915, i915_perf_open_ioctl() and other 2 perf ioctl uses ENOSUPP, should we convert those to EOPNOTSUPP? > > > > affected, it will always return LINEAR. You cannot set tiling as > > > > Following this set_tiling() LINEAR should be allowed too. > > I prefer the current approach of returning error. > > I'm not seeing the value in keeping get_tiling supported. Either > userspace > still uses the legacy backhannel and dri2, in which case it needs to > be > fixed no matter what. Or it's using modifiers, in which case this is > dead > code. Only other user I can think of is takeover for fastboot, but if > you > get anything else than untiled it's also broken (we don't have an > ioctl to > read out the modifiers, heck even all the planes, there's no getfb2). > > So really not seeing the point in keeping that working. > -Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/atomic: Reject FLIP_ASYNC unconditionally
It's never been wired up. Only userspace that tried to use it (and didn't actually check whether anything works, but hey it builds) is the -modesetting atomic implementation. And we just shut that up. If there's anyone else then we need to silently accept this flag no matter what, and find a new one. Because once a flag is tainted, it's lost. Cc: Maarten Lankhorst Cc: Michel Dänzer Cc: Alex Deucher Cc: Adam Jackson Cc: Sean Paul Cc: David Airlie Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_atomic_uapi.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c index 5a5b42db6f2a..7a26bfb5329c 100644 --- a/drivers/gpu/drm/drm_atomic_uapi.c +++ b/drivers/gpu/drm/drm_atomic_uapi.c @@ -1305,8 +1305,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev, if (arg->reserved) return -EINVAL; - if ((arg->flags & DRM_MODE_PAGE_FLIP_ASYNC) && - !dev->mode_config.async_page_flip) + if (arg->flags & DRM_MODE_PAGE_FLIP_ASYNC) return -EINVAL; /* can't test and expect an event at the same time. */ -- 2.23.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/atomic: Rename crtc_state->pageflip_flags to async_flip
It's the only flag anyone actually cares about. Plus if we're unlucky,
the atomic ioctl might need a different flag for async flips. So
better to abstract this away from the uapi a bit.
Cc: Maarten Lankhorst
Cc: Michel Dänzer
Cc: Alex Deucher
Cc: Adam Jackson
Cc: Sean Paul
Cc: David Airlie
Signed-off-by: Daniel Vetter
Cc: Maxime Ripard
Cc: Daniel Vetter
Cc: Nicholas Kazlauskas
Cc: Leo Li
Cc: Harry Wentland
Cc: David Francis
Cc: Mario Kleiner
Cc: Bhawanpreet Lakha
Cc: Ben Skeggs
Cc: "Christian König"
Cc: Ilia Mirkin
Cc: Sam Ravnborg
Cc: Chris Wilson
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 ++---
drivers/gpu/drm/drm_atomic_helper.c | 2 +-
drivers/gpu/drm/drm_atomic_state_helper.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 4 ++--
include/drm/drm_crtc.h| 8
5 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 0a71ed1e7762..2f0ef0820f00 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5756,8 +5756,7 @@ static void amdgpu_dm_commit_planes(struct
drm_atomic_state *state,
* change FB pitch, DCC state, rotation or mirroing.
*/
bundle->flip_addrs[planes_count].flip_immediate =
- (crtc->state->pageflip_flags &
-DRM_MODE_PAGE_FLIP_ASYNC) != 0 &&
+ crtc->state->async_flip &&
acrtc_state->update_type == UPDATE_TYPE_FAST;
timestamp_ns = ktime_get_ns();
@@ -6334,7 +6333,7 @@ static void amdgpu_dm_atomic_commit_tail(struct
drm_atomic_state *state)
amdgpu_dm_enable_crtc_interrupts(dev, state, true);
for_each_new_crtc_in_state(state, crtc, new_crtc_state, j)
- if (new_crtc_state->pageflip_flags & DRM_MODE_PAGE_FLIP_ASYNC)
+ if (new_crtc_state->async_flip)
wait_for_vblank = false;
/* update planes when needed per crtc*/
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index e9c6112e7f73..1e5293eb66e3 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3263,7 +3263,7 @@ static int page_flip_common(struct drm_atomic_state
*state,
return PTR_ERR(crtc_state);
crtc_state->event = event;
- crtc_state->pageflip_flags = flags;
+ crtc_state->async_flip = flags & DRM_MODE_PAGE_FLIP_ASYNC;
plane_state = drm_atomic_get_plane_state(state, plane);
if (IS_ERR(plane_state))
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
b/drivers/gpu/drm/drm_atomic_state_helper.c
index 46dc264a248b..d0a937fb0c56 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -128,7 +128,7 @@ void __drm_atomic_helper_crtc_duplicate_state(struct
drm_crtc *crtc,
state->zpos_changed = false;
state->commit = NULL;
state->event = NULL;
- state->pageflip_flags = 0;
+ state->async_flip = false;
/* Self refresh should be canceled when a new update is available */
state->active = drm_atomic_crtc_effectively_active(state);
diff --git a/drivers/gpu/drm/nouveau/dispnv50/wndw.c
b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
index 2db029371c91..5193b6257061 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/wndw.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
@@ -267,7 +267,7 @@ nv50_wndw_atomic_check_acquire(struct nv50_wndw *wndw, bool
modeset,
asyw->image.pitch[0] = fb->base.pitches[0];
}
- if (!(asyh->state.pageflip_flags & DRM_MODE_PAGE_FLIP_ASYNC))
+ if (!asyh->state.async_flip)
asyw->image.interval = 1;
else
asyw->image.interval = 0;
@@ -383,7 +383,7 @@ nv50_wndw_atomic_check_lut(struct nv50_wndw *wndw,
}
/* Can't do an immediate flip while changing the LUT. */
- asyh->state.pageflip_flags &= ~DRM_MODE_PAGE_FLIP_ASYNC;
+ asyh->state.async_flip = false;
}
static int
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 7e2963cad543..900ae8d452b8 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -284,12 +284,12 @@ struct drm_crtc_state {
u32 target_vblank;
/**
-* @pageflip_flags:
+* @async_flip:
*
-* DRM_MODE_PAGE_FLIP_* flags, as passed to the page flip ioctl.
-* Zero in any other case.
+* This is set when DRM_MODE_PAGE_FLIP_ASYNC is set in the legacy
+* PAGE_FLIP IOCTL. It's not wired up for the atomic IOCTL itself yet.
*/
- u32 pageflip_flags;
+ bool async_flip;
/**
*
[Intel-gfx] [PATCH 1/3] drm/atomic: Take the atomic toys away from X
The -modesetting ddx has a totally broken idea of how atomic works: - doesn't disable old connectors, assuming they get auto-disable like with the legacy setcrtc - assumes ASYNC_FLIP is wired through for the atomic ioctl - not a single call to TEST_ONLY Iow the implementation is a 1:1 translation of legacy ioctls to atomic, which is a) broken b) pointless. We already have bugs in both i915 and amdgpu-DC where this prevents us from enabling neat features. If anyone ever cares about atomic in X we can easily add a new atomic level (req->value == 2) for X to get back the shiny toys. Since these broken versions of -modesetting have been shipping, there's really no other way to get out of this bind. References: https://gitlab.freedesktop.org/xorg/xserver/issues/629 References: https://gitlab.freedesktop.org/xorg/xserver/merge_requests/180 Cc: Maarten Lankhorst Cc: Michel Dänzer Cc: Alex Deucher Cc: Adam Jackson Cc: Sean Paul Cc: David Airlie Cc: sta...@vger.kernel.org Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_ioctl.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c index 2c120c58f72d..1cb7b4c3c87c 100644 --- a/drivers/gpu/drm/drm_ioctl.c +++ b/drivers/gpu/drm/drm_ioctl.c @@ -334,6 +334,9 @@ drm_setclientcap(struct drm_device *dev, void *data, struct drm_file *file_priv) file_priv->universal_planes = req->value; break; case DRM_CLIENT_CAP_ATOMIC: + /* The modesetting DDX has a totally broken idea of atomic. */ + if (strstr(current->comm, "X")) + return -EOPNOTSUPP; if (!drm_core_check_feature(dev, DRIVER_ATOMIC)) return -EOPNOTSUPP; if (req->value > 1) -- 2.23.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/atomic: Rename crtc_state->pageflip_flags to async_flip
It's the only flag anyone actually cares about. Plus if we're unlucky,
the atomic ioctl might need a different flag for async flips. So
better to abstract this away from the uapi a bit.
Cc: Maarten Lankhorst
Cc: Michel Dänzer
Cc: Alex Deucher
Cc: Adam Jackson
Cc: Sean Paul
Cc: David Airlie
Signed-off-by: Daniel Vetter
Cc: Maxime Ripard
Cc: Daniel Vetter
Cc: Nicholas Kazlauskas
Cc: Leo Li
Cc: Harry Wentland
Cc: David Francis
Cc: Mario Kleiner
Cc: Bhawanpreet Lakha
Cc: Ben Skeggs
Cc: "Christian König"
Cc: Ilia Mirkin
Cc: Sam Ravnborg
Cc: Chris Wilson
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 ++---
drivers/gpu/drm/drm_atomic_helper.c | 2 +-
drivers/gpu/drm/drm_atomic_state_helper.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 4 ++--
include/drm/drm_crtc.h| 8
5 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 028a710c1b46..b3c5ab3d09d5 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5740,8 +5740,7 @@ static void amdgpu_dm_commit_planes(struct
drm_atomic_state *state,
* change FB pitch, DCC state, rotation or mirroing.
*/
bundle->flip_addrs[planes_count].flip_immediate =
- (crtc->state->pageflip_flags &
-DRM_MODE_PAGE_FLIP_ASYNC) != 0 &&
+ crtc->state->async_flip &&
acrtc_state->update_type == UPDATE_TYPE_FAST;
timestamp_ns = ktime_get_ns();
@@ -6335,7 +6334,7 @@ static void amdgpu_dm_atomic_commit_tail(struct
drm_atomic_state *state)
amdgpu_dm_enable_crtc_interrupts(dev, state, true);
for_each_new_crtc_in_state(state, crtc, new_crtc_state, j)
- if (new_crtc_state->pageflip_flags & DRM_MODE_PAGE_FLIP_ASYNC)
+ if (new_crtc_state->async_flip)
wait_for_vblank = false;
/* update planes when needed per crtc*/
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 9f17746f4251..8dbf416e2807 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3262,7 +3262,7 @@ static int page_flip_common(struct drm_atomic_state
*state,
return PTR_ERR(crtc_state);
crtc_state->event = event;
- crtc_state->pageflip_flags = flags;
+ crtc_state->async_flip = flags & DRM_MODE_PAGE_FLIP_ASYNC;
plane_state = drm_atomic_get_plane_state(state, plane);
if (IS_ERR(plane_state))
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
b/drivers/gpu/drm/drm_atomic_state_helper.c
index 46dc264a248b..d0a937fb0c56 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -128,7 +128,7 @@ void __drm_atomic_helper_crtc_duplicate_state(struct
drm_crtc *crtc,
state->zpos_changed = false;
state->commit = NULL;
state->event = NULL;
- state->pageflip_flags = 0;
+ state->async_flip = false;
/* Self refresh should be canceled when a new update is available */
state->active = drm_atomic_crtc_effectively_active(state);
diff --git a/drivers/gpu/drm/nouveau/dispnv50/wndw.c
b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
index 2db029371c91..5193b6257061 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/wndw.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
@@ -267,7 +267,7 @@ nv50_wndw_atomic_check_acquire(struct nv50_wndw *wndw, bool
modeset,
asyw->image.pitch[0] = fb->base.pitches[0];
}
- if (!(asyh->state.pageflip_flags & DRM_MODE_PAGE_FLIP_ASYNC))
+ if (!asyh->state.async_flip)
asyw->image.interval = 1;
else
asyw->image.interval = 0;
@@ -383,7 +383,7 @@ nv50_wndw_atomic_check_lut(struct nv50_wndw *wndw,
}
/* Can't do an immediate flip while changing the LUT. */
- asyh->state.pageflip_flags &= ~DRM_MODE_PAGE_FLIP_ASYNC;
+ asyh->state.async_flip = false;
}
static int
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 7d14c11bdc0a..c4528eb5d168 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -285,12 +285,12 @@ struct drm_crtc_state {
u32 target_vblank;
/**
-* @pageflip_flags:
+* @async_flip:
*
-* DRM_MODE_PAGE_FLIP_* flags, as passed to the page flip ioctl.
-* Zero in any other case.
+* This is set when DRM_MODE_PAGE_FLIP_ASYNC is set in the legacy
+* PAGE_FLIP IOCTL. It's not wired up for the atomic IOCTL itself yet.
*/
- u32 pageflip_flags;
+ bool async_flip;
/**
*
[Intel-gfx] [PATCH 3/3] fixup
---
drivers/gpu/drm/drm_ioctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 3c015dd3c94b..1cb7b4c3c87c 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -335,7 +335,7 @@ drm_setclientcap(struct drm_device *dev, void *data, struct
drm_file *file_priv)
break;
case DRM_CLIENT_CAP_ATOMIC:
/* The modesetting DDX has a totally broken idea of atomic. */
- if (strstr("X", current->comm))
+ if (strstr(current->comm, "X"))
return -EOPNOTSUPP;
if (!drm_core_check_feature(dev, DRIVER_ATOMIC))
return -EOPNOTSUPP;
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/atomic: Reject FLIP_ASYNC unconditionally
It's never been wired up. Only userspace that tried to use it (and didn't actually check whether anything works, but hey it builds) is the -modesetting atomic implementation. And we just shut that up. If there's anyone else then we need to silently accept this flag no matter what, and find a new one. Because once a flag is tainted, it's lost. Cc: Maarten Lankhorst Cc: Michel Dänzer Cc: Alex Deucher Cc: Adam Jackson Cc: Sean Paul Cc: David Airlie Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_atomic_uapi.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c index 5a5b42db6f2a..7a26bfb5329c 100644 --- a/drivers/gpu/drm/drm_atomic_uapi.c +++ b/drivers/gpu/drm/drm_atomic_uapi.c @@ -1305,8 +1305,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev, if (arg->reserved) return -EINVAL; - if ((arg->flags & DRM_MODE_PAGE_FLIP_ASYNC) && - !dev->mode_config.async_page_flip) + if (arg->flags & DRM_MODE_PAGE_FLIP_ASYNC) return -EINVAL; /* can't test and expect an event at the same time. */ -- 2.23.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for DC3CO Support for TGL (rev6)
== Series Details == Series: DC3CO Support for TGL (rev6) URL : https://patchwork.freedesktop.org/series/64923/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6828 -> Patchwork_14268 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_14268 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_14268, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14268/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_14268: ### IGT changes ### Possible regressions * igt@runner@aborted: - fi-whl-u: NOTRUN -> [FAIL][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14268/fi-whl-u/igt@run...@aborted.html Known issues Here are the changes found in Patchwork_14268 that come from known issues: ### IGT changes ### Issues hit * igt@kms_busy@basic-flip-c: - fi-kbl-7500u: [PASS][2] -> [SKIP][3] ([fdo#109271] / [fdo#109278]) +2 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6828/fi-kbl-7500u/igt@kms_b...@basic-flip-c.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14268/fi-kbl-7500u/igt@kms_b...@basic-flip-c.html Possible fixes * igt@gem_exec_suspend@basic-s3: - fi-blb-e6850: [INCOMPLETE][4] ([fdo#107718]) -> [PASS][5] [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6828/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14268/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html * igt@gem_exec_suspend@basic-s4-devices: - fi-kbl-7500u: [DMESG-WARN][6] ([fdo#105128] / [fdo#107139]) -> [PASS][7] [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6828/fi-kbl-7500u/igt@gem_exec_susp...@basic-s4-devices.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14268/fi-kbl-7500u/igt@gem_exec_susp...@basic-s4-devices.html [fdo#105128]: https://bugs.freedesktop.org/show_bug.cgi?id=105128 [fdo#107139]: https://bugs.freedesktop.org/show_bug.cgi?id=107139 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278 Participating hosts (53 -> 46) -- Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_6828 -> Patchwork_14268 CI-20190529: 20190529 CI_DRM_6828: 6e043dde15a1b2b97d908d0467e9197ffa8934c2 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5164: 90babd3f12707dfabaa58bb18f6b8e22636b6895 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_14268: 64428dde03af0bbd6fb7716c43ef0b03a7c5ddb6 @ git://anongit.freedesktop.org/gfx-ci/linux == Kernel 32bit build == Warning: Kernel 32bit buildtest failed: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14268/build_32bit.log CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh CHK include/generated/compile.h Kernel: arch/x86/boot/bzImage is ready (#1) Building modules, stage 2. MODPOST 117 modules ERROR: "__udivdi3" [drivers/gpu/drm/i915/i915.ko] undefined! ERROR: "__divdi3" [drivers/gpu/drm/i915/i915.ko] undefined! scripts/Makefile.modpost:103: recipe for target 'modules-modpost' failed make[1]: *** [modules-modpost] Error 1 Makefile:1301: recipe for target 'modules' failed make: *** [modules] Error 2 == Linux commits == 64428dde03af drm/i915/tgl: Add DC3CO counter in i915_dmc_info 6cde5d766d74 drm/i915/tgl: switch between dc3co and dc5 based on display idleness bbe23a634ddd drm/i915/tgl: DC3CO PSR2 helper d1df3094eb5f drm/i915/tgl: Add helper function for DC3CO exitline. 2f51045a1df1 drm/i915/tgl: Enable DC3CO state in "DC Off" power well 48ad8fa95f1a drm/i915/tgl: Add DC3CO mask to allowed_dc_mask and gen9_dc_mask f99eddda47f0 drm/i915/tgl: Add DC3CO required register and bits == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14268/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for i915/gem_ctx_shared: Prebind both context images
== Series Details == Series: i915/gem_ctx_shared: Prebind both context images URL : https://patchwork.freedesktop.org/series/66171/ State : success == Summary == CI Bug Log - changes from CI_DRM_6827_full -> IGTPW_3413_full Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/66171/revisions/1/mbox/ Known issues Here are the changes found in IGTPW_3413_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_shared@exec-single-timeline-bsd: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#110841]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6827/shard-iclb5/igt@gem_ctx_sha...@exec-single-timeline-bsd.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3413/shard-iclb1/igt@gem_ctx_sha...@exec-single-timeline-bsd.html * igt@gem_ctx_switch@legacy-bsd2-heavy: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276]) +13 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6827/shard-iclb4/igt@gem_ctx_swi...@legacy-bsd2-heavy.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3413/shard-iclb6/igt@gem_ctx_swi...@legacy-bsd2-heavy.html * igt@gem_exec_schedule@fifo-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#111325]) +4 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6827/shard-iclb8/igt@gem_exec_sched...@fifo-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3413/shard-iclb4/igt@gem_exec_sched...@fifo-bsd.html * igt@gem_tiled_swapping@non-threaded: - shard-glk: [PASS][7] -> [DMESG-WARN][8] ([fdo#108686]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6827/shard-glk8/igt@gem_tiled_swapp...@non-threaded.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3413/shard-glk9/igt@gem_tiled_swapp...@non-threaded.html - shard-apl: [PASS][9] -> [DMESG-WARN][10] ([fdo#108686]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6827/shard-apl5/igt@gem_tiled_swapp...@non-threaded.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3413/shard-apl2/igt@gem_tiled_swapp...@non-threaded.html * igt@i915_pm_rpm@modeset-non-lpsp-stress: - shard-hsw: [PASS][11] -> [FAIL][12] ([fdo#111548]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6827/shard-hsw1/igt@i915_pm_...@modeset-non-lpsp-stress.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3413/shard-hsw2/igt@i915_pm_...@modeset-non-lpsp-stress.html * igt@kms_color@pipe-b-degamma: - shard-kbl: [PASS][13] -> [FAIL][14] ([fdo#104782]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6827/shard-kbl3/igt@kms_co...@pipe-b-degamma.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3413/shard-kbl7/igt@kms_co...@pipe-b-degamma.html * igt@kms_cursor_crc@pipe-a-cursor-64x64-sliding: - shard-apl: [PASS][15] -> [FAIL][16] ([fdo#103232]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6827/shard-apl8/igt@kms_cursor_...@pipe-a-cursor-64x64-sliding.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3413/shard-apl1/igt@kms_cursor_...@pipe-a-cursor-64x64-sliding.html * igt@kms_cursor_legacy@cursor-vs-flip-toggle: - shard-hsw: [PASS][17] -> [FAIL][18] ([fdo#103355]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6827/shard-hsw4/igt@kms_cursor_leg...@cursor-vs-flip-toggle.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3413/shard-hsw1/igt@kms_cursor_leg...@cursor-vs-flip-toggle.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-render: - shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#103167]) +5 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6827/shard-iclb7/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-render.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3413/shard-iclb6/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-render.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes: - shard-apl: [PASS][21] -> [DMESG-WARN][22] ([fdo#108566]) +3 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6827/shard-apl5/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3413/shard-apl5/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html * igt@kms_psr2_su@frontbuffer: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109642] / [fdo#111068]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6827/shard-iclb2/igt@kms_psr2...@frontbuffer.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3413/shard-iclb1/igt@kms_psr2...@frontbuffer.html * igt@kms_psr@psr2_primary_blt: - shard-iclb: [PASS][25] -> [SKIP][26] ([fdo#109441]) +1
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for DC3CO Support for TGL (rev6)
== Series Details == Series: DC3CO Support for TGL (rev6) URL : https://patchwork.freedesktop.org/series/64923/ State : warning == Summary == $ dim checkpatch origin/drm-tip f99eddda47f0 drm/i915/tgl: Add DC3CO required register and bits 48ad8fa95f1a drm/i915/tgl: Add DC3CO mask to allowed_dc_mask and gen9_dc_mask 2f51045a1df1 drm/i915/tgl: Enable DC3CO state in "DC Off" power well -:56: CHECK:USLEEP_RANGE: usleep_range is preferred over udelay; see Documentation/timers/timers-howto.rst #56: FILE: drivers/gpu/drm/i915/display/intel_display_power.c:795: + udelay(200); total: 0 errors, 0 warnings, 1 checks, 167 lines checked d1df3094eb5f drm/i915/tgl: Add helper function for DC3CO exitline. bbe23a634ddd drm/i915/tgl: DC3CO PSR2 helper 6cde5d766d74 drm/i915/tgl: switch between dc3co and dc5 based on display idleness 64428dde03af drm/i915/tgl: Add DC3CO counter in i915_dmc_info ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 7/7] drm/i915/tgl: Add DC3CO counter in i915_dmc_info
Adding DC3CO counter in i915_dmc_info debugfs will be
useful for DC3CO validation.
DMC firmware uses DMC_DEBUG3 register as DC3CO counter
register on TGL, as per B.Specs DMC_DEBUG3 is general
purpose register.
Cc: Jani Nikula
Cc: Imre Deak
Cc: Animesh Manna
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/i915_debugfs.c | 6 ++
drivers/gpu/drm/i915/i915_reg.h | 2 ++
2 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 9798f27a697a..957b6ef37434 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2391,6 +2391,12 @@ static int i915_dmc_info(struct seq_file *m, void
*unused)
seq_printf(m, "version: %d.%d\n", CSR_VERSION_MAJOR(csr->version),
CSR_VERSION_MINOR(csr->version));
+ /*
+* TGL DMC f/w uses DMC_DEBUG3 register for DC3CO counter.
+*/
+ if (IS_TIGERLAKE(dev_priv))
+ seq_printf(m, "DC3CO count: %d\n", I915_READ(DMC_DEBUG3));
+
if (INTEL_GEN(dev_priv) >= 12) {
dc5_reg = TGL_DMC_DEBUG_DC5_COUNT;
dc6_reg = TGL_DMC_DEBUG_DC6_COUNT;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e1bdd54b1816..f751c67c3a5e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7238,6 +7238,8 @@ enum {
#define TGL_DMC_DEBUG_DC5_COUNT_MMIO(0x101084)
#define TGL_DMC_DEBUG_DC6_COUNT_MMIO(0x101088)
+#define DMC_DEBUG3 _MMIO(0x101090)
+
/* interrupts */
#define DE_MASTER_IRQ_CONTROL (1 << 31)
#define DE_SPRITEB_FLIP_DONE(1 << 29)
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 4/7] drm/i915/tgl: Add helper function for DC3CO exitline.
DC3CO enabling B.Specs sequence requires to enable end configure
exit scanlines to TRANS_EXITLINE register, programming this register
has to be part of modeset sequence as this can't be change when
transcoder or port is enabled.
When system boots with only eDP panel there may not be real
modeset as BIOS has already programmed the necessary registers,
therefore it needs to force a modeset at bootup to enable and configure
DC3CO exitline.
Cc: Jani Nikula
Cc: Imre Deak
Cc: Animesh Manna
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_display.c | 5 +
.../drm/i915/display/intel_display_power.c| 95 +++
.../drm/i915/display/intel_display_power.h| 6 ++
drivers/gpu/drm/i915/i915_drv.h | 3 +
drivers/gpu/drm/i915/intel_pm.c | 2 +-
drivers/gpu/drm/i915/intel_pm.h | 2 +
6 files changed, 112 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 12a94c6e3d51..01b23443c96b 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7409,6 +7409,8 @@ static int intel_crtc_compute_config(struct intel_crtc
*crtc,
const struct drm_display_mode *adjusted_mode =
_config->base.adjusted_mode;
int clock_limit = dev_priv->max_dotclk_freq;
+ tgl_compute_dc3co_crtc(pipe_config);
+
if (INTEL_GEN(dev_priv) < 4) {
clock_limit = dev_priv->max_cdclk_freq * 9 / 10;
@@ -13567,6 +13569,9 @@ static void intel_crtc_check_fastset(const struct
intel_crtc_state *old_crtc_sta
if (!intel_pipe_config_compare(old_crtc_state, new_crtc_state, true))
return;
+ if (!tgl_dc3co_can_enable_fastset(new_crtc_state))
+ return;
+
new_crtc_state->base.mode_changed = false;
new_crtc_state->update_pipe = true;
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 868197bb4860..95f352bf0173 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -19,6 +19,7 @@
#include "intel_hotplug.h"
#include "intel_sideband.h"
#include "intel_tc.h"
+#include "intel_pm.h"
bool intel_display_power_well_is_enabled(struct drm_i915_private *dev_priv,
enum i915_power_well_id power_well_id);
@@ -772,6 +773,100 @@ static void gen9_set_dc_state(struct drm_i915_private
*dev_priv, u32 state)
dev_priv->csr.dc_state = val & mask;
}
+void tgl_enable_psr2_transcoder_exitline(const struct intel_crtc_state *cstate)
+{
+ u32 linetime_us, val, exit_scanlines;
+ u32 crtc_vdisplay = cstate->base.adjusted_mode.crtc_vdisplay;
+ struct drm_i915_private *dev_priv = to_i915(cstate->base.crtc->dev);
+
+ linetime_us = fixed16_to_u32_round_up(intel_get_linetime_us(cstate));
+ if (WARN_ON(!linetime_us))
+ return;
+ /*
+* DC3CO Exit time 200us B.Spec 49196
+* PSR2 transcoder Early Exit scanlines = ROUNDUP(200 / line time) + 1
+* Exit line event need to program above calculated scan lines before
+* next VBLANK.
+*/
+ exit_scanlines = DIV_ROUND_UP(200, linetime_us) + 1;
+ if (WARN_ON(exit_scanlines > crtc_vdisplay))
+ return;
+
+ exit_scanlines = crtc_vdisplay - exit_scanlines;
+ exit_scanlines <<= EXITLINE_SHIFT;
+ val = I915_READ(EXITLINE(cstate->cpu_transcoder));
+ val &= ~(EXITLINE_MASK | EXITLINE_ENABLE);
+ val |= exit_scanlines;
+ val |= EXITLINE_ENABLE;
+ I915_WRITE(EXITLINE(cstate->cpu_transcoder), val);
+}
+
+static bool tgl_dc3co_is_edp_connected(struct intel_crtc_state *crtc_state)
+{
+ struct drm_atomic_state *state = crtc_state->base.state;
+ struct drm_connector *connector;
+ struct drm_connector_state *connector_state;
+ int i;
+
+ for_each_new_connector_in_state(state, connector, connector_state, i) {
+ if (connector->status == connector_status_connected &&
+ connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
+ return true;
+ }
+ }
+
+ return false;
+}
+
+/*
+ * DC3CO requires to enable exitline and program DC3CO requires
+ * exit scanlines to TRANS_EXITLINE register, which should only
+ * change before transcoder or port is enabled.
+ * This requires to disable the fastset at boot for eDP output.
+ */
+bool tgl_dc3co_can_enable_fastset(struct intel_crtc_state *crtc_state)
+{
+ struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
+ bool fastset = true;
+
+ if (!IS_TIGERLAKE(dev_priv))
+ return fastset;
+
+ if (!(dev_priv->csr.allowed_dc_mask & DC_STATE_EN_DC3CO))
+ return fastset;
+
+ if
[Intel-gfx] [PATCH v6 5/7] drm/i915/tgl: DC3CO PSR2 helper
Add dc3co helper functions to enable/disable psr2 deep sleep.
Adhere B.Specs by disallow DC3CO state before PSR2 exit.
Enable PSR2 exitline event and program the desired scanlines
to exit DC3CO in intel_psr_enable function at modeset path.
v1: moved calling of tgl_enable_psr2_transcoder_exitline() to
intel_psr_enable(). [Imre]
Cc: Jani Nikula
Cc: Imre Deak
Cc: Animesh Manna
Cc: José Roberto de Souza
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_psr.c | 43
drivers/gpu/drm/i915/display/intel_psr.h | 2 ++
2 files changed, 45 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index 629b8b98a97f..0098465ef573 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -549,6 +549,44 @@ transcoder_has_psr2(struct drm_i915_private *dev_priv,
enum transcoder trans)
return trans == TRANSCODER_EDP;
}
+static void psr2_program_idle_frames(struct drm_i915_private *dev_priv,
+u32 idle_frames)
+{
+ u32 val;
+
+ idle_frames <<= EDP_PSR2_IDLE_FRAME_SHIFT;
+ val = I915_READ(EDP_PSR2_CTL(dev_priv->psr.transcoder));
+ val &= ~EDP_PSR2_IDLE_FRAME_MASK;
+ val |= idle_frames;
+ I915_WRITE(EDP_PSR2_CTL(dev_priv->psr.transcoder), val);
+}
+
+void tgl_psr2_deep_sleep_disable(struct drm_i915_private *dev_priv)
+{
+ int idle_frames = 0;
+
+ psr2_program_idle_frames(dev_priv, idle_frames);
+}
+
+void tgl_psr2_deep_sleep_enable(struct drm_i915_private *dev_priv)
+{
+ int idle_frames;
+
+ /*
+* Let's use 6 as the minimum to cover all known cases including the
+* off-by-one issue that HW has in some cases.
+*/
+ idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
+ idle_frames = max(idle_frames, dev_priv->psr.sink_sync_latency + 1);
+ psr2_program_idle_frames(dev_priv, idle_frames);
+}
+
+static void tgl_disallow_dc3co_on_psr2_exit(struct drm_i915_private *dev_priv)
+{
+ /* Before PSR2 exit disallow dc3co*/
+ tgl_set_target_dc_state(dev_priv, DC_STATE_EN_UPTO_DC6);
+}
+
static bool intel_psr2_config_valid(struct intel_dp *intel_dp,
struct intel_crtc_state *crtc_state)
{
@@ -809,6 +847,10 @@ void intel_psr_enable(struct intel_dp *intel_dp,
WARN_ON(dev_priv->drrs.dp);
+ /* Enable PSR2 transcoder exit line */
+ if (crtc_state->has_psr2)
+ tgl_enable_psr2_transcoder_exitline(crtc_state);
+
mutex_lock(_priv->psr.lock);
if (!psr_global_enabled(dev_priv->psr.debug)) {
@@ -839,6 +881,7 @@ static void intel_psr_exit(struct drm_i915_private
*dev_priv)
}
if (dev_priv->psr.psr2_enabled) {
+ tgl_disallow_dc3co_on_psr2_exit(dev_priv);
val = I915_READ(EDP_PSR2_CTL(dev_priv->psr.transcoder));
WARN_ON(!(val & EDP_PSR2_ENABLE));
val &= ~EDP_PSR2_ENABLE;
diff --git a/drivers/gpu/drm/i915/display/intel_psr.h
b/drivers/gpu/drm/i915/display/intel_psr.h
index 46e4de8b8cd5..75a9862f36fd 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.h
+++ b/drivers/gpu/drm/i915/display/intel_psr.h
@@ -35,5 +35,7 @@ void intel_psr_short_pulse(struct intel_dp *intel_dp);
int intel_psr_wait_for_idle(const struct intel_crtc_state *new_crtc_state,
u32 *out_value);
bool intel_psr_enabled(struct intel_dp *intel_dp);
+void tgl_psr2_deep_sleep_disable(struct drm_i915_private *dev_priv);
+void tgl_psr2_deep_sleep_enable(struct drm_i915_private *dev_priv);
#endif /* __INTEL_PSR_H__ */
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 3/7] drm/i915/tgl: Enable DC3CO state in "DC Off" power well
Add max_dc_state and tgl_set_target_dc_state() API
in order to enable DC3CO state with existing DC states.
max_dc_state will enable/disable the desired DC state in
DC_STATE_EN reg when "DC Off" power well gets disable/enable.
v2: commit log improvement.
v3: Used intel_wait_for_register to wait for DC3CO exit. [Imre]
Used gen9_set_dc_state() to allow/disallow DC3CO. [Imre]
Moved transcoder psr2 exit line enablement from tgl_allow_dc3co()
to a appropriate place haswell_crtc_enable(). [Imre]
Changed the DC3CO power well enabled call back logic as
recommended in review comments. [Imre]
v4: Used wait_for_us() instead of intel_wait_for_reg(). [Imre (IRC)]
v5: using udelay() instead of waiting for DC3CO exit status.
v6: Fixed minor unwanted change.
v7: Removed DC3CO powerwell and POWER_DOMAIN_VIDEO.
Cc: Jani Nikula
Cc: Imre Deak
Cc: Animesh Manna
Signed-off-by: Anshuman Gupta
---
.../drm/i915/display/intel_display_power.c| 106 ++
.../drm/i915/display/intel_display_power.h| 2 +
drivers/gpu/drm/i915/i915_drv.h | 1 +
3 files changed, 89 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 496fa1b53ffb..868197bb4860 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -772,6 +772,29 @@ static void gen9_set_dc_state(struct drm_i915_private
*dev_priv, u32 state)
dev_priv->csr.dc_state = val & mask;
}
+static void tgl_allow_dc3co(struct drm_i915_private *dev_priv)
+{
+ if (!dev_priv->psr.sink_psr2_support)
+ return;
+
+ if (dev_priv->csr.allowed_dc_mask & DC_STATE_EN_DC3CO)
+ gen9_set_dc_state(dev_priv, DC_STATE_EN_DC3CO);
+}
+
+static void tgl_disallow_dc3co(struct drm_i915_private *dev_priv)
+{
+ u32 val;
+
+ val = I915_READ(DC_STATE_EN);
+ val &= ~DC_STATE_DC3CO_STATUS;
+ I915_WRITE(DC_STATE_EN, val);
+ gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
+ /*
+* Delay of 200us DC3CO Exit time B.Spec 49196
+*/
+ udelay(200);
+}
+
static void bxt_enable_dc9(struct drm_i915_private *dev_priv)
{
assert_can_enable_dc9(dev_priv);
@@ -939,7 +962,8 @@ static void bxt_verify_ddi_phy_power_wells(struct
drm_i915_private *dev_priv)
static bool gen9_dc_off_power_well_enabled(struct drm_i915_private *dev_priv,
struct i915_power_well *power_well)
{
- return (I915_READ(DC_STATE_EN) & DC_STATE_EN_UPTO_DC5_DC6_MASK) == 0;
+ return ((I915_READ(DC_STATE_EN) & DC_STATE_EN_DC3CO) == 0 &&
+ (I915_READ(DC_STATE_EN) & DC_STATE_EN_UPTO_DC5_DC6_MASK) == 0);
}
static void gen9_assert_dbuf_enabled(struct drm_i915_private *dev_priv)
@@ -955,24 +979,32 @@ static void gen9_disable_dc_states(struct
drm_i915_private *dev_priv)
{
struct intel_cdclk_state cdclk_state = {};
- gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
+ if (dev_priv->csr.max_dc_state & DC_STATE_EN_DC3CO) {
+ tgl_disallow_dc3co(dev_priv);
+ } else {
+ gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
- dev_priv->display.get_cdclk(dev_priv, _state);
- /* Can't read out voltage_level so can't use intel_cdclk_changed() */
- WARN_ON(intel_cdclk_needs_modeset(_priv->cdclk.hw, _state));
+ dev_priv->display.get_cdclk(dev_priv, _state);
+ /*
+* Can't read out voltage_level so can't use
+* intel_cdclk_changed()
+*/
+ WARN_ON(intel_cdclk_needs_modeset(_priv->cdclk.hw,
+ _state));
- gen9_assert_dbuf_enabled(dev_priv);
+ gen9_assert_dbuf_enabled(dev_priv);
- if (IS_GEN9_LP(dev_priv))
- bxt_verify_ddi_phy_power_wells(dev_priv);
+ if (IS_GEN9_LP(dev_priv))
+ bxt_verify_ddi_phy_power_wells(dev_priv);
- if (INTEL_GEN(dev_priv) >= 11)
- /*
-* DMC retains HW context only for port A, the other combo
-* PHY's HW context for port B is lost after DC transitions,
-* so we need to restore it manually.
-*/
- intel_combo_phy_init(dev_priv);
+ if (INTEL_GEN(dev_priv) >= 11)
+ /*
+* DMC retains HW context only for port A, the other
+* combo PHY's HW context for port B is lost after
+* DC transitions, so we need to restore it manually.
+*/
+ intel_combo_phy_init(dev_priv);
+ }
}
static void gen9_dc_off_power_well_enable(struct drm_i915_private *dev_priv,
@@ -987,10 +1019,43 @@ static void gen9_dc_off_power_well_disable(struct
[Intel-gfx] [PATCH v6 6/7] drm/i915/tgl: switch between dc3co and dc5 based on display idleness
DC3CO is useful power state, when DMC detects PSR2 idle frame
while an active video playback, playing 30fps video on 60hz panel
is the classic example of this use case.
DC5 and DC6 saves more power, but can't be entered during video
playback because there are not enough idle frames in a row to meet
most PSR2 panel deep sleep entry requirement typically 4 frames.
It will be worthy to enable DC3CO after completion of each flip
and switch back to DC5 when display is idle, as driver doesn't
differentiate between video playback and a normal flip.
It is safer to allow DC5 after 6 idle frame, as PSR2 requires
minimum 6 idle frame.
v2: calculated s/w state to switch over dc3co when there is an
update. [Imre]
used cancel_delayed_work_sync() in order to avoid any race
with already scheduled delayed work. [Imre]
v3: cancel_delayed_work_sync() may blocked the commit work.
Hence dropping it, dc5_idle_thread() checks the valid wakeref before
putting the reference count, which avoids any chances of dropping
a zero wakeref. [Imre (IRC)]
v4: use frontbuffer flush mechanism. [Imre]
Cc: Jani Nikula
Cc: Imre Deak
Cc: Animesh Manna
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_display.c | 2 +
.../drm/i915/display/intel_display_power.c| 75 +++
.../drm/i915/display/intel_display_power.h| 7 ++
.../gpu/drm/i915/display/intel_frontbuffer.c | 1 +
drivers/gpu/drm/i915/display/intel_psr.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 1 +
6 files changed, 87 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 01b23443c96b..94ee4fe6cc85 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -16166,6 +16166,7 @@ int intel_modeset_init(struct drm_device *dev)
init_llist_head(_priv->atomic_helper.free_list);
INIT_WORK(_priv->atomic_helper.free_work,
intel_atomic_helper_free_state_worker);
+ INIT_DELAYED_WORK(_priv->csr.idle_work, tgl_dc5_idle_thread);
intel_init_quirks(dev_priv);
@@ -17107,6 +17108,7 @@ void intel_modeset_driver_remove(struct drm_device *dev)
flush_workqueue(dev_priv->modeset_wq);
flush_work(_priv->atomic_helper.free_work);
+ flush_delayed_work(_priv->csr.idle_work);
WARN_ON(!llist_empty(_priv->atomic_helper.free_list));
/*
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 95f352bf0173..57248a2a6ad7 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -20,6 +20,7 @@
#include "intel_sideband.h"
#include "intel_tc.h"
#include "intel_pm.h"
+#include "intel_psr.h"
bool intel_display_power_well_is_enabled(struct drm_i915_private *dev_priv,
enum i915_power_well_id power_well_id);
@@ -773,6 +774,27 @@ static void gen9_set_dc_state(struct drm_i915_private
*dev_priv, u32 state)
dev_priv->csr.dc_state = val & mask;
}
+static u32 intel_get_frame_time_us(const struct intel_crtc_state *cstate)
+{
+ u32 pixel_rate, crtc_htotal, crtc_vtotal;
+ u32 frametime_us;
+
+ if (!cstate || !cstate->base.active)
+ return 0;
+
+ pixel_rate = cstate->pixel_rate;
+
+ if (WARN_ON(pixel_rate == 0))
+ return 0;
+
+ crtc_htotal = cstate->base.adjusted_mode.crtc_htotal;
+ crtc_vtotal = cstate->base.adjusted_mode.crtc_vtotal;
+ frametime_us = DIV_ROUND_UP(crtc_htotal * crtc_vtotal * 1000ULL,
+ pixel_rate);
+
+ return frametime_us;
+}
+
void tgl_enable_psr2_transcoder_exitline(const struct intel_crtc_state *cstate)
{
u32 linetime_us, val, exit_scanlines;
@@ -801,6 +823,50 @@ void tgl_enable_psr2_transcoder_exitline(const struct
intel_crtc_state *cstate)
I915_WRITE(EXITLINE(cstate->cpu_transcoder), val);
}
+void tgl_dc3co_flush(struct drm_i915_private *dev_priv,
+unsigned int frontbuffer_bits, enum fb_op_origin origin)
+{
+ struct intel_crtc_state *cstate;
+ u32 delay;
+ unsigned int busy_frontbuffer_bits;
+
+ if (!IS_TIGERLAKE(dev_priv))
+ return;
+
+ if (origin != ORIGIN_FLIP)
+ return;
+
+ if (!dev_priv->csr.dc3co_crtc)
+ return;
+
+ cstate = to_intel_crtc_state(dev_priv->csr.dc3co_crtc->base.state);
+ frontbuffer_bits &=
+ INTEL_FRONTBUFFER_ALL_MASK(dev_priv->csr.dc3co_crtc->pipe);
+ busy_frontbuffer_bits &= ~frontbuffer_bits;
+
+ mutex_lock(_priv->psr.lock);
+
+ if (!dev_priv->psr.psr2_enabled || !dev_priv->psr.active)
+ goto unlock;
+
+ /*
+* At every flip frontbuffer flush first cancel the delayed work,
+* when
[Intel-gfx] [PATCH v6 2/7] drm/i915/tgl: Add DC3CO mask to allowed_dc_mask and gen9_dc_mask
Enable dc3co state in enable_dc module param and add dc3co
enable mask to allowed_dc_mask and gen9_dc_mask.
v1: Adding enable_dc=3,4 options to enable DC3CO with DC5 and DC6
independently.
Cc: Jani Nikula
Cc: Imre Deak
Cc: Animesh Manna
Signed-off-by: Anshuman Gupta
---
.../drm/i915/display/intel_display_power.c| 29 ++-
drivers/gpu/drm/i915/i915_params.c| 3 +-
2 files changed, 23 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index ce88a27229ef..496fa1b53ffb 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -698,7 +698,11 @@ static u32 gen9_dc_mask(struct drm_i915_private *dev_priv)
u32 mask;
mask = DC_STATE_EN_UPTO_DC5;
- if (INTEL_GEN(dev_priv) >= 11)
+
+ if (INTEL_GEN(dev_priv) >= 12)
+ mask |= DC_STATE_EN_DC3CO | DC_STATE_EN_UPTO_DC6
+ | DC_STATE_EN_DC9;
+ else if (IS_GEN(dev_priv, 11))
mask |= DC_STATE_EN_UPTO_DC6 | DC_STATE_EN_DC9;
else if (IS_GEN9_LP(dev_priv))
mask |= DC_STATE_EN_DC9;
@@ -3927,14 +3931,17 @@ static u32 get_allowed_dc_mask(const struct
drm_i915_private *dev_priv,
int requested_dc;
int max_dc;
- if (INTEL_GEN(dev_priv) >= 11) {
- max_dc = 2;
+ if (INTEL_GEN(dev_priv) >= 12) {
+ max_dc = 4;
/*
* DC9 has a separate HW flow from the rest of the DC states,
* not depending on the DMC firmware. It's needed by system
* suspend/resume, so allow it unconditionally.
*/
mask = DC_STATE_EN_DC9;
+ } else if (IS_GEN(dev_priv, 11)) {
+ max_dc = 2;
+ mask = DC_STATE_EN_DC9;
} else if (IS_GEN(dev_priv, 10) || IS_GEN9_BC(dev_priv)) {
max_dc = 2;
mask = 0;
@@ -3953,7 +3960,7 @@ static u32 get_allowed_dc_mask(const struct
drm_i915_private *dev_priv,
requested_dc = enable_dc;
} else if (enable_dc == -1) {
requested_dc = max_dc;
- } else if (enable_dc > max_dc && enable_dc <= 2) {
+ } else if (enable_dc > max_dc && enable_dc <= 4) {
DRM_DEBUG_KMS("Adjusting requested max DC state (%d->%d)\n",
enable_dc, max_dc);
requested_dc = max_dc;
@@ -3962,10 +3969,16 @@ static u32 get_allowed_dc_mask(const struct
drm_i915_private *dev_priv,
requested_dc = max_dc;
}
- if (requested_dc > 1)
- mask |= DC_STATE_EN_UPTO_DC6;
- if (requested_dc > 0)
- mask |= DC_STATE_EN_UPTO_DC5;
+ if (requested_dc == 4) {
+ mask |= DC_STATE_EN_DC3CO | DC_STATE_EN_UPTO_DC6;
+ } else if (requested_dc == 3) {
+ mask |= DC_STATE_EN_DC3CO | DC_STATE_EN_UPTO_DC5;
+ } else {
+ if (requested_dc > 1)
+ mask |= DC_STATE_EN_UPTO_DC6;
+ if (requested_dc > 0)
+ mask |= DC_STATE_EN_UPTO_DC5;
+ }
DRM_DEBUG_KMS("Allowed DC state mask %02x\n", mask);
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 296452f9efe4..4f1806f65040 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -46,7 +46,8 @@ i915_param_named(modeset, int, 0400,
i915_param_named_unsafe(enable_dc, int, 0400,
"Enable power-saving display C-states. "
- "(-1=auto [default]; 0=disable; 1=up to DC5; 2=up to DC6)");
+ "(-1=auto [default]; 0=disable; 1=up to DC5; 2=up to DC6; "
+ "3=up to DC5 with DC3CO; 4=up to DC6 with DC3CO)");
i915_param_named_unsafe(enable_fbc, int, 0600,
"Enable frame buffer compression for power savings "
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 1/7] drm/i915/tgl: Add DC3CO required register and bits
Adding following definition to i915_reg.h
1. DC_STATE_EN register DC3CO bit fields and masks.
2. Transcoder EXITLINE register and its bit fields and mask.
Cc: Jani Nikula
Cc: Imre Deak
Cc: Animesh Manna
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/i915_reg.h | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 6c43b8c583bb..e1bdd54b1816 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4135,6 +4135,7 @@ enum {
#define _VTOTAL_A 0x6000c
#define _VBLANK_A 0x60010
#define _VSYNC_A 0x60014
+#define _EXITLINE_A0x60018
#define _PIPEASRC 0x6001c
#define _BCLRPAT_A 0x60020
#define _VSYNCSHIFT_A 0x60028
@@ -4181,11 +4182,16 @@ enum {
#define VTOTAL(trans) _MMIO_TRANS2(trans, _VTOTAL_A)
#define VBLANK(trans) _MMIO_TRANS2(trans, _VBLANK_A)
#define VSYNC(trans) _MMIO_TRANS2(trans, _VSYNC_A)
+#define EXITLINE(trans)_MMIO_TRANS2(trans, _EXITLINE_A)
#define BCLRPAT(trans) _MMIO_TRANS2(trans, _BCLRPAT_A)
#define VSYNCSHIFT(trans) _MMIO_TRANS2(trans, _VSYNCSHIFT_A)
#define PIPESRC(trans) _MMIO_TRANS2(trans, _PIPEASRC)
#define PIPE_MULT(trans) _MMIO_TRANS2(trans, _PIPE_MULT_A)
+#define EXITLINE_ENABLE (1 << 31)
+#define EXITLINE_MASK (0x1fff)
+#define EXITLINE_SHIFT0
+
/*
* HSW+ eDP PSR registers
*
@@ -10097,6 +10103,8 @@ enum skl_power_gate {
/* GEN9 DC */
#define DC_STATE_EN_MMIO(0x45504)
#define DC_STATE_DISABLE 0
+#define DC_STATE_EN_DC3CO (1 << 30)
+#define DC_STATE_DC3CO_STATUS (1 << 29)
#define DC_STATE_EN_UPTO_DC5 (1 << 0)
#define DC_STATE_EN_DC9 (1 << 3)
#define DC_STATE_EN_UPTO_DC6 (2 << 0)
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 0/7] DC3CO Support for TGL
This is a new design proposal for DC3CO feature after disscussing it with Ville and Imre. This design uses a API tgl_set_target_dc_state() API to switch between DC3CO and DC5 by using "DC off" power well. Another major change in this design using page flip frontbuffer flush call to allow DC3CO. As part of DC3CO feature, it needs to configure and enable TRANS_EXITLINE register which only needs to change when transcoder/port is not enabled. It requires to configure and enable it in full modeset sequence. Which requires to force the modeset only at system bootup, with only eDP panel. Tested this series on real H/W, DC3CO counter is validated without any other issue observed. Anshuman Gupta (7): drm/i915/tgl: Add DC3CO required register and bits drm/i915/tgl: Add DC3CO mask to allowed_dc_mask and gen9_dc_mask drm/i915/tgl: Enable DC3CO state in "DC Off" power well drm/i915/tgl: Add helper function for DC3CO exitline. drm/i915/tgl: DC3CO PSR2 helper drm/i915/tgl: switch between dc3co and dc5 based on display idleness drm/i915/tgl: Add DC3CO counter in i915_dmc_info drivers/gpu/drm/i915/display/intel_display.c | 7 + .../drm/i915/display/intel_display_power.c| 305 -- .../drm/i915/display/intel_display_power.h| 15 + .../gpu/drm/i915/display/intel_frontbuffer.c | 1 + drivers/gpu/drm/i915/display/intel_psr.c | 44 +++ drivers/gpu/drm/i915/display/intel_psr.h | 2 + drivers/gpu/drm/i915/i915_debugfs.c | 6 + drivers/gpu/drm/i915/i915_drv.h | 5 + drivers/gpu/drm/i915/i915_params.c| 3 +- drivers/gpu/drm/i915/i915_reg.h | 10 + drivers/gpu/drm/i915/intel_pm.c | 2 +- drivers/gpu/drm/i915/intel_pm.h | 2 + 12 files changed, 372 insertions(+), 30 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 v3 4/7] drm/i915/tgl: move DP_TP_* to transcoder
On Thu, Aug 29, 2019 at 02:25:51AM -0700, Lucas De Marchi wrote:
> Gen 12 onwards moves the DP_TP_* registers to be transcoder-based rather
> than port-based. This adds the new register addresses and changes all
> the callers to use the register saved in intel_dp->regs.*. This is
> filled out when preparing to enable the port so we take into account if
> we should use the transcoder or the port.
>
> v2: reimplement by stashing the registers we want to access under
> intel_dp->reg. Now they are initialized when enabling the port.
> Ville suggested to store the transcoder to be used exclusively
> by TGL+. After implementing I thought just storing the register directly
> made it cleaner.
>
> Cc: Ville Syrjälä
> Signed-off-by: Lucas De Marchi
Should we replace the direct usages of DP_TP_CTL DP_TP_STATUS in
hsw_fdi_link_train with as well for consistency? That code is specific
to HSW/BDW so it doesn't cause a problem, but there's always the risk
that it might get copy/pasted somewhere else where the direct register
usage is wrong.
Otherwise,
Reviewed-by: Matt Roper
Matt
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 43 ---
> .../drm/i915/display/intel_display_types.h| 9
> drivers/gpu/drm/i915/display/intel_dp.c | 13 +++---
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 8 ++--
> drivers/gpu/drm/i915/i915_reg.h | 4 ++
> 5 files changed, 51 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index df3e4fe7e3e9..73f7a4b0f6c2 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -3164,17 +3164,18 @@ static void intel_ddi_enable_fec(struct intel_encoder
> *encoder,
>const struct intel_crtc_state *crtc_state)
> {
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> - enum port port = encoder->port;
> + struct intel_dp *intel_dp;
> u32 val;
>
> if (!crtc_state->fec_enable)
> return;
>
> - val = I915_READ(DP_TP_CTL(port));
> + intel_dp = enc_to_intel_dp(>base);
> + val = I915_READ(intel_dp->regs.dp_tp_ctl);
> val |= DP_TP_CTL_FEC_ENABLE;
> - I915_WRITE(DP_TP_CTL(port), val);
> + I915_WRITE(intel_dp->regs.dp_tp_ctl, val);
>
> - if (intel_de_wait_for_set(dev_priv, DP_TP_STATUS(port),
> + if (intel_de_wait_for_set(dev_priv, intel_dp->regs.dp_tp_status,
> DP_TP_STATUS_FEC_ENABLE_LIVE, 1))
> DRM_ERROR("Timed out waiting for FEC Enable Status\n");
> }
> @@ -3183,16 +3184,17 @@ static void intel_ddi_disable_fec_state(struct
> intel_encoder *encoder,
> const struct intel_crtc_state
> *crtc_state)
> {
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> - enum port port = encoder->port;
> + struct intel_dp *intel_dp;
> u32 val;
>
> if (!crtc_state->fec_enable)
> return;
>
> - val = I915_READ(DP_TP_CTL(port));
> + intel_dp = enc_to_intel_dp(>base);
> + val = I915_READ(intel_dp->regs.dp_tp_ctl);
> val &= ~DP_TP_CTL_FEC_ENABLE;
> - I915_WRITE(DP_TP_CTL(port), val);
> - POSTING_READ(DP_TP_CTL(port));
> + I915_WRITE(intel_dp->regs.dp_tp_ctl, val);
> + POSTING_READ(intel_dp->regs.dp_tp_ctl);
> }
>
> static void tgl_ddi_pre_enable_dp(struct intel_encoder *encoder,
> @@ -3205,10 +3207,14 @@ static void tgl_ddi_pre_enable_dp(struct
> intel_encoder *encoder,
> struct intel_digital_port *dig_port = enc_to_dig_port(>base);
> bool is_mst = intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST);
> int level = intel_ddi_dp_level(intel_dp);
> + enum transcoder transcoder = crtc_state->cpu_transcoder;
>
> intel_dp_set_link_params(intel_dp, crtc_state->port_clock,
>crtc_state->lane_count, is_mst);
>
> + intel_dp->regs.dp_tp_ctl = TGL_DP_TP_CTL(transcoder);
> + intel_dp->regs.dp_tp_status = TGL_DP_TP_STATUS(transcoder);
> +
> /* 1.a got on intel_atomic_commit_tail() */
>
> /* 2. */
> @@ -3297,6 +3303,9 @@ static void hsw_ddi_pre_enable_dp(struct intel_encoder
> *encoder,
> intel_dp_set_link_params(intel_dp, crtc_state->port_clock,
>crtc_state->lane_count, is_mst);
>
> + intel_dp->regs.dp_tp_ctl = DP_TP_CTL(port);
> + intel_dp->regs.dp_tp_status = DP_TP_STATUS(port);
> +
> intel_edp_panel_on(intel_dp);
>
> intel_ddi_clk_select(encoder, crtc_state);
> @@ -3463,10 +3472,12 @@ static void intel_disable_ddi_buf(struct
> intel_encoder *encoder,
> }
>
> if (intel_encoder_is_dp(encoder)) {
> - val = I915_READ(DP_TP_CTL(port));
> + struct intel_dp *intel_dp = enc_to_intel_dp(>base);
> +
> + val = I915_READ(intel_dp->regs.dp_tp_ctl);
>
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 4/6] Add i915/gem_ctx_persistence
Hi Chris,
just a few quick question from a first look,
> +/**
> + * __gem_context_set_persistence:
> + * @i915: open i915 drm file descriptor
> + * @ctx: i915 context id
> + * @state: desired persistence
> + *
> + * Like __gem_context_set_persistence(), except we assert on failure.
> + */
> +void gem_context_set_persistence(int i915, uint32_t ctx, bool state)
> +{
> + igt_assert_eq(__gem_context_set_persistence(i915, ctx, state), 0);
> +}
Is this really required? We know what comes out of this, it's the
same as calling igt_assert_eq(1, 2); right?
> @@ -58,6 +63,10 @@ int __gem_context_get_param(int fd, struct
> drm_i915_gem_context_param *p);
> int __gem_context_set_priority(int fd, uint32_t ctx, int prio);
> void gem_context_set_priority(int fd, uint32_t ctx, int prio);
>
> +#define I915_CONTEXT_PARAM_PERSISTENCE 0xb
what if we want to add more parameters in the driver? We would
need to remember to update this as well.
> + gem_context_get_param(i915, );
> + expected = !!p.value;
> +
> + expected = !expected;
"expected = !p.value" ?
> + p.value = expected;
> + gem_context_set_param(i915, );
> + gem_context_get_param(i915, );
> + igt_assert_eq(p.value, expected);
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for Enable Nearest-neighbor for Integer mode scaling
== Series Details == Series: Enable Nearest-neighbor for Integer mode scaling URL : https://patchwork.freedesktop.org/series/66175/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6828 -> Patchwork_14267 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_14267 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_14267, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14267/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_14267: ### IGT changes ### Possible regressions * igt@gem_exec_suspend@basic-s3: - fi-kbl-r: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6828/fi-kbl-r/igt@gem_exec_susp...@basic-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14267/fi-kbl-r/igt@gem_exec_susp...@basic-s3.html - fi-whl-u: [PASS][3] -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6828/fi-whl-u/igt@gem_exec_susp...@basic-s3.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14267/fi-whl-u/igt@gem_exec_susp...@basic-s3.html - fi-kbl-x1275: [PASS][5] -> [INCOMPLETE][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6828/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14267/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html - fi-kbl-7500u: [PASS][7] -> [INCOMPLETE][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6828/fi-kbl-7500u/igt@gem_exec_susp...@basic-s3.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14267/fi-kbl-7500u/igt@gem_exec_susp...@basic-s3.html * igt@kms_busy@basic-flip-a: - fi-skl-6700k2: [PASS][9] -> [INCOMPLETE][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6828/fi-skl-6700k2/igt@kms_b...@basic-flip-a.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14267/fi-skl-6700k2/igt@kms_b...@basic-flip-a.html Known issues Here are the changes found in Patchwork_14267 that come from known issues: ### IGT changes ### Issues hit * igt@core_auth@basic-auth: - fi-icl-u3: [PASS][11] -> [DMESG-WARN][12] ([fdo#107724]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6828/fi-icl-u3/igt@core_a...@basic-auth.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14267/fi-icl-u3/igt@core_a...@basic-auth.html * igt@gem_exec_suspend@basic-s3: - fi-skl-6770hq: [PASS][13] -> [INCOMPLETE][14] ([fdo#104108]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6828/fi-skl-6770hq/igt@gem_exec_susp...@basic-s3.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14267/fi-skl-6770hq/igt@gem_exec_susp...@basic-s3.html - fi-cfl-8109u: [PASS][15] -> [INCOMPLETE][16] ([fdo#108126]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6828/fi-cfl-8109u/igt@gem_exec_susp...@basic-s3.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14267/fi-cfl-8109u/igt@gem_exec_susp...@basic-s3.html - fi-skl-lmem:[PASS][17] -> [INCOMPLETE][18] ([fdo#104108]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6828/fi-skl-lmem/igt@gem_exec_susp...@basic-s3.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14267/fi-skl-lmem/igt@gem_exec_susp...@basic-s3.html - fi-skl-6260u: [PASS][19] -> [INCOMPLETE][20] ([fdo#104108]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6828/fi-skl-6260u/igt@gem_exec_susp...@basic-s3.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14267/fi-skl-6260u/igt@gem_exec_susp...@basic-s3.html - fi-cfl-guc: [PASS][21] -> [INCOMPLETE][22] ([fdo#108126] / [fdo#108743]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6828/fi-cfl-guc/igt@gem_exec_susp...@basic-s3.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14267/fi-cfl-guc/igt@gem_exec_susp...@basic-s3.html - fi-skl-iommu: [PASS][23] -> [INCOMPLETE][24] ([fdo#104108]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6828/fi-skl-iommu/igt@gem_exec_susp...@basic-s3.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14267/fi-skl-iommu/igt@gem_exec_susp...@basic-s3.html - fi-skl-guc: [PASS][25] -> [INCOMPLETE][26] ([fdo#104108] / [fdo#108743]) [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6828/fi-skl-guc/igt@gem_exec_susp...@basic-s3.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14267/fi-skl-guc/igt@gem_exec_susp...@basic-s3.html - fi-glk-dsi: [PASS][27] -> [INCOMPLETE][28]
Re: [Intel-gfx] [RFC 0/2] Enable Nearest-neighbor for Integer mode scaling
On Tue, Sep 03, 2019 at 10:22:25PM +0530, Shashank Sharma wrote: > Blurry outputs during upscaling the buffer, is a generic problem of gfx > industry. One of the major reason behind this blurriness is the > interpolation of pixel values used by most of the upscaling hardwares. > > Nearest-neighbor is a scaling mode, which works by filling in the missing > color values in the upscaled image with that of the coordinate-mapped > nearest source pixel value. > > Nearest-neighbor can produce (almost) non-blurry scaling outputs when > the scaling ratio is complete integer. For example: > - input buffer resolution: 1280x720(HD) > - output buffer resolution: 3840x2160(UHD/4K) > - scaling ratio (h) = 3840/1280 = 3 > scaling ratio (v) = 2160/720 = 3 > In such scenarios, we should try to pick Nearest-neighbor as scaling > method when possible. > > Many gaming communities have been asking for integer-mode scaling > support, some links and background: > https://software.intel.com/en-us/articles/integer-scaling-support-on-intel-graphics > http://tanalin.com/en/articles/lossless-scaling/ > https://community.amd.com/thread/209107 > https://www.nvidia.com/en-us/geforce/forums/game-ready-drivers/13/1002/feature-request-nonblurry-upscaling-at-integer-rat/ > > This patch series enables NN scaling on Intel display (ICL), when the > upscaling > ratio is integer. I think we'd probably want a property for this sort of stuff. igt could perhaps also use it to enable crc based scaling tests. Another problem is that we currently don't expose the panel fitter for external displays so this would be limited to eDP/DSI only. I have a branch that implements borders (for underscan) for DP/HDMI which is at least moving the code a little bit into a direction where we could consider exposing the panel fitter for external displays. -- 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 v3 3/7] drm/i915: protect access to DP_TP_* on non-dp
On Thu, Aug 29, 2019 at 01:37:55PM +0300, Ville Syrjälä wrote:
> On Thu, Aug 29, 2019 at 02:25:50AM -0700, Lucas De Marchi wrote:
> > DP_TP_{CTL,STATUS} should only be programmed when the encoder is intel_dp.
> > Checking its current usages intel_disable_ddi_buf() is the only
> > offender, with other places being protected by checks like
> > pipe_config->fec_enable that is only set by intel_dp.
> >
> > Cc: Ville Syrjälä
> > Signed-off-by: Lucas De Marchi
> > ---
> > drivers/gpu/drm/i915/display/intel_ddi.c | 10 ++
> > 1 file changed, 6 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index 3180dacb5be4..df3e4fe7e3e9 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -3462,10 +3462,12 @@ static void intel_disable_ddi_buf(struct
> > intel_encoder *encoder,
> > wait = true;
> > }
> >
> > - val = I915_READ(DP_TP_CTL(port));
> > - val &= ~(DP_TP_CTL_ENABLE | DP_TP_CTL_LINK_TRAIN_MASK);
> > - val |= DP_TP_CTL_LINK_TRAIN_PAT1;
> > - I915_WRITE(DP_TP_CTL(port), val);
> > + if (intel_encoder_is_dp(encoder)) {
>
> Doesn't really make sense to me. Either we just do it (because a DDI is
> just a DDI so DP_TP_CTL does exist always), or we only do it when driving
> DP and not when driving HDMI.
I agree; I don't think there's a need to avoid program programming the
register just because we weren't previously in DP mode.
But I do question whether a RMW is necessary; it seems like just writing
a constant 0 to this register would be sufficient for the disable
sequence.
Matt
>
> For the latter I would perhaps suggest moving all this extra junk out
> from intel_disable_ddi_buf() into the DP specific code paths, leaving
> just the actual DDI_BUF_CTL disable here.
>
> > + val = I915_READ(DP_TP_CTL(port));
> > + val &= ~(DP_TP_CTL_ENABLE | DP_TP_CTL_LINK_TRAIN_MASK);
> > + val |= DP_TP_CTL_LINK_TRAIN_PAT1;
> > + I915_WRITE(DP_TP_CTL(port), val);
> > + }
> >
> > /* Disable FEC in DP Sink */
> > intel_ddi_disable_fec_state(encoder, crtc_state);
> > --
> > 2.23.0
>
> --
> Ville Syrjälä
> Intel
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Enable Nearest-neighbor for Integer mode scaling
== Series Details == Series: Enable Nearest-neighbor for Integer mode scaling URL : https://patchwork.freedesktop.org/series/66175/ State : warning == Summary == $ dim checkpatch origin/drm-tip 705e07a4f105 drm/i915: Indicate integer up-scaling ratios d3324b2f0df9 drm/i915: Pick nearest-neighbor mode for integer scaling ratios -:180: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'id' - possible side-effects? #180: FILE: drivers/gpu/drm/i915/i915_reg.h:7210: +#define SKL_PS_COEF_DATA_SET0(pipe, id) _MMIO_PIPE(pipe, \ + _ID(id, _PS_COEF_SET0_DATA_1A, _PS_COEF_SET0_DATA_2A), \ + _ID(id, _PS_COEF_SET0_DATA_1B, _PS_COEF_SET0_DATA_1B)) -:183: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'id' - possible side-effects? #183: FILE: drivers/gpu/drm/i915/i915_reg.h:7213: +#define SKL_PS_COEF_DATA_SET1(pipe, id) _MMIO_PIPE(pipe, \ + _ID(id, _PS_COEF_SET1_DATA_1A, _PS_COEF_SET1_DATA_2A), \ + _ID(id, _PS_COEF_SET1_DATA_1B, _PS_COEF_SET1_DATA_1B)) -:186: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'id' - possible side-effects? #186: FILE: drivers/gpu/drm/i915/i915_reg.h:7216: +#define SKL_PS_COEF_INDEX_SET0(pipe, id) _MMIO_PIPE(pipe, \ + _ID(id, _PS_COEF_SET0_INDEX_1A, _PS_COEF_SET0_INDEX_2A), \ + _ID(id, _PS_COEF_SET0_INDEX_1B, _PS_COEF_SET0_INDEX_1B)) -:189: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'id' - possible side-effects? #189: FILE: drivers/gpu/drm/i915/i915_reg.h:7219: +#define SKL_PS_COEF_INDEX_SET1(pipe, id) _MMIO_PIPE(pipe, \ + _ID(id, _PS_COEF_SET1_INDEX_1A, _PS_COEF_SET1_INDEX_2A), \ + _ID(id, _PS_COEF_SET1_INDEX_1B, _PS_COEF_SET1_INDEX_1B)) total: 0 errors, 0 warnings, 4 checks, 150 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Revert "drm/i915: Fix DP-MST crtc_mask"
== Series Details ==
Series: Revert "drm/i915: Fix DP-MST crtc_mask"
URL : https://patchwork.freedesktop.org/series/66173/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6828 -> Patchwork_14266
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14266/
Known issues
Here are the changes found in Patchwork_14266 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_frontbuffer_tracking@basic:
- fi-icl-u2: [PASS][1] -> [FAIL][2] ([fdo#103167])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6828/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14266/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
Possible fixes
* igt@gem_exec_reloc@basic-cpu-gtt-noreloc:
- fi-icl-u3: [DMESG-WARN][3] ([fdo#107724]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6828/fi-icl-u3/igt@gem_exec_re...@basic-cpu-gtt-noreloc.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14266/fi-icl-u3/igt@gem_exec_re...@basic-cpu-gtt-noreloc.html
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: [INCOMPLETE][5] ([fdo#107718]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6828/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14266/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
* igt@gem_exec_suspend@basic-s4-devices:
- fi-kbl-7500u: [DMESG-WARN][7] ([fdo#105128] / [fdo#107139]) ->
[PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6828/fi-kbl-7500u/igt@gem_exec_susp...@basic-s4-devices.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14266/fi-kbl-7500u/igt@gem_exec_susp...@basic-s4-devices.html
* igt@kms_chamelium@hdmi-crc-fast:
- fi-icl-u2: [FAIL][9] ([fdo#109635 ]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6828/fi-icl-u2/igt@kms_chamel...@hdmi-crc-fast.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14266/fi-icl-u2/igt@kms_chamel...@hdmi-crc-fast.html
* igt@kms_frontbuffer_tracking@basic:
- fi-icl-u3: [FAIL][11] ([fdo#103167]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6828/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14266/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html
Warnings
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: [FAIL][13] ([fdo#111407]) -> [FAIL][14] ([fdo#109483])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6828/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14266/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#105128]: https://bugs.freedesktop.org/show_bug.cgi?id=105128
[fdo#107139]: https://bugs.freedesktop.org/show_bug.cgi?id=107139
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#109483]: https://bugs.freedesktop.org/show_bug.cgi?id=109483
[fdo#109635 ]: https://bugs.freedesktop.org/show_bug.cgi?id=109635
[fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
Participating hosts (53 -> 46)
--
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y
fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6828 -> Patchwork_14266
CI-20190529: 20190529
CI_DRM_6828: 6e043dde15a1b2b97d908d0467e9197ffa8934c2 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5164: 90babd3f12707dfabaa58bb18f6b8e22636b6895 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14266: b4d2d7cced42ea0aa865682aecf415ec539f1aab @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
b4d2d7cced42 Revert "drm/i915: Fix DP-MST crtc_mask"
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14266/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 1/2] drm/i915: Indicate integer up-scaling ratios
If the upscaling ratio is a complete integer, Intel display HW can
pickup special scaling mode, which can produce better non-blurry
outputs. This patch adds a check to indicate if this is such an upscaling
opportunity, while calculating the scaler config, and stores it into scaler
state.
Cc: Jani Nikula
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Vivi, Rodrigo
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/display/intel_display.c | 21 +++
.../drm/i915/display/intel_display_types.h| 7 +++
2 files changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index ee54d9659c99..613130db3c05 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -5388,6 +5388,19 @@ u16 skl_scaler_calc_phase(int sub, int scale, bool
chroma_cosited)
#define SKL_MIN_YUV_420_SRC_W 16
#define SKL_MIN_YUV_420_SRC_H 16
+static inline bool
+scaling_ratio_integer(int src_w, int dst_w, int src_h, int dst_h)
+{
+ /* Integer mode scaling is applicable only for upscaling scenarios */
+ if (dst_w < src_w || dst_h < src_h)
+ return false;
+
+ if (dst_w % src_w == 0 && dst_h % src_h == 0)
+ return true;
+
+ return false;
+}
+
static int
skl_update_scaler(struct intel_crtc_state *crtc_state, bool force_detach,
unsigned int scaler_user, int *scaler_id,
@@ -5422,6 +5435,14 @@ skl_update_scaler(struct intel_crtc_state *crtc_state,
bool force_detach,
return -EINVAL;
}
+ /*
+* If we are upscaling, and the scaling ratios are integer, we can
+* pick nearest-neighbour method in HW for scaling, which produces
+* blurless outputs in such scenarios.
+*/
+ if (scaling_ratio_integer(src_w, dst_w, src_h, dst_h))
+ scaler_state->integer_scaling = true;
+
/*
* if plane is being disabled or scaler is no more required or force
detach
* - free scaler binded to this plane/crtc
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 3c1a5f3e1d22..6bb32fbf3153 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -613,6 +613,13 @@ struct intel_crtc_scaler_state {
/* scaler used by crtc for panel fitting purpose */
int scaler_id;
+
+ /*
+* Nearest-neighbor method of upscaling gieves blurless output if
+* the upscaling ratio is a complete integer. This bool is to indicate
+* such an opportunity.
+*/
+ bool integer_scaling;
};
/* drm_mode->private_flags */
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 2/2] drm/i915: Pick nearest-neighbor mode for integer scaling ratios
Nearest-neighbor, is a new scaling mode, introduced in GEN11 display HW.
Nearest-neighbor results in blurless outputs, when upscaling ratio is a
complete integer ratio like:
- upscaling from 1280x720(HD) to 3840x2160(UHD/4K)
horizontal upscaling factor = 3840/1280 = 3
vertical upscaling factor = 2160/720 = 3
This is an example of a scenario with integer scaling ratios, and if we
can pick nearest-neighbor mode scaling in display, it can produce sharp
and non-blurry output, compared to the default scaling mode selected by
I915 ("medium").
PS: NN has been introduced from GEN11 display HW only.
Cc: Jani Nikula
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Vivi, Rodrigo
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/display/intel_display.c | 81 +++-
drivers/gpu/drm/i915/i915_reg.h | 31
2 files changed, 111 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 613130db3c05..9808797a92d9 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -5613,6 +5613,74 @@ static void skylake_scaler_disable(struct intel_crtc
*crtc)
skl_detach_scaler(crtc, i);
}
+static void
+icl_setup_nearest_neighbor_mode(const struct intel_crtc_state *crtc_state)
+{
+ int count;
+ int phase;
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ int scaler_id = crtc_state->scaler_state.scaler_id;
+ enum pipe pipe = crtc->pipe;
+
+ /*
+* To setup nearest-neighbor integer scaling mode:
+* Write 60 dwords: represnting 119 coefficients.
+*
+* Seven basic Coefficients are named from An..Gn.
+* Value of every D'th coefficent must be 1, all others to be 0.
+*
+* 17 such phases of 7 such coefficients = 119 coefficients.
+* Arrange these 119 coefficients in 60 dwords, 2 coefficient
+* per dword, in the sequence shown below:
+*
+*++--+
+*| B0 | A0 |
+*+---+
+*|D0 = 1 | C0 |
+*+---+
+*| F0 | E0 |
+*+---+
+*| A1 | G0 |
+*+---+
+*| C1 | B1 |
+*+---+
+*| E1 | D1 = 1 |
+*+---+
+*|. | .|
+*+---+
+*|.. | .. |
+*+---+
+*|Res | G16 |
+*++--+
+*
+*/
+
+ for (phase = 0; phase < 17; phase++) {
+ for (count = 0; count < 7; count++) {
+ u32 val = 0;
+
+ /* Every D'th entry needs to be 1 */
+ if (count == 3) {
+ if (phase % 2)
+ val = 1;
+ else
+ val = (1 << 16);
+ }
+
+ I915_WRITE_FW(SKL_PS_COEF_INDEX_SET0(pipe, scaler_id),
+ phase * 17 + count);
+ I915_WRITE_FW(SKL_PS_COEF_DATA_SET0(pipe, scaler_id),
+ val);
+
+ I915_WRITE_FW(SKL_PS_COEF_INDEX_SET1(pipe, scaler_id),
+ phase * 17 + count);
+ I915_WRITE_FW(SKL_PS_COEF_DATA_SET1(pipe, scaler_id),
+ val);
+ }
+ }
+}
+
static void skylake_pfit_enable(const struct intel_crtc_state *crtc_state)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
@@ -5623,6 +5691,7 @@ static void skylake_pfit_enable(const struct
intel_crtc_state *crtc_state)
if (crtc_state->pch_pfit.enabled) {
u16 uv_rgb_hphase, uv_rgb_vphase;
+ u32 scaler_mode = PS_FILTER_MEDIUM;
int pfit_w, pfit_h, hscale, vscale;
int id;
@@ -5638,9 +5707,19 @@ static void skylake_pfit_enable(const struct
intel_crtc_state *crtc_state)
uv_rgb_hphase = skl_scaler_calc_phase(1, hscale, false);
uv_rgb_vphase = skl_scaler_calc_phase(1, vscale, false);
+ /*
+* Pick nearest-neighbor scaler mode over medium, if scaling
+* is happening at integer ratios.
+*/
+ if (INTEL_GEN(dev_priv) >= 11 &&
+ scaler_state->integer_scaling) {
+ scaler_mode = PS_FILTER_PROGRAMMED;
+
[Intel-gfx] [RFC 0/2] Enable Nearest-neighbor for Integer mode scaling
Blurry outputs during upscaling the buffer, is a generic problem of gfx industry. One of the major reason behind this blurriness is the interpolation of pixel values used by most of the upscaling hardwares. Nearest-neighbor is a scaling mode, which works by filling in the missing color values in the upscaled image with that of the coordinate-mapped nearest source pixel value. Nearest-neighbor can produce (almost) non-blurry scaling outputs when the scaling ratio is complete integer. For example: - input buffer resolution: 1280x720(HD) - output buffer resolution: 3840x2160(UHD/4K) - scaling ratio (h) = 3840/1280 = 3 scaling ratio (v) = 2160/720 = 3 In such scenarios, we should try to pick Nearest-neighbor as scaling method when possible. Many gaming communities have been asking for integer-mode scaling support, some links and background: https://software.intel.com/en-us/articles/integer-scaling-support-on-intel-graphics http://tanalin.com/en/articles/lossless-scaling/ https://community.amd.com/thread/209107 https://www.nvidia.com/en-us/geforce/forums/game-ready-drivers/13/1002/feature-request-nonblurry-upscaling-at-integer-rat/ This patch series enables NN scaling on Intel display (ICL), when the upscaling ratio is integer. Shashank Sharma (2): drm/i915: Indicate integer up-scaling ratios drm/i915: Pick nearest-neighbor mode for integer scaling ratios drivers/gpu/drm/i915/display/intel_display.c | 97 ++- .../drm/i915/display/intel_display_types.h| 7 ++ drivers/gpu/drm/i915/i915_reg.h | 31 ++ 3 files changed, 134 insertions(+), 1 deletion(-) -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 2/7] drm/i915/tgl: Access the right register when handling PSR interruptions
On Thu, Aug 29, 2019 at 02:25:49AM -0700, Lucas De Marchi wrote:
> From: José Roberto de Souza
>
> For older gens PSR IIR and IMR have fixed addresses. From TGL onwards those
> registers moved to each transcoder offset. The bits for the registers
> are defined without an offset per transcoder as right now we have one
> register per transcoder. So add a fake "trans_shift" when calculating
> the bits offsets: it will be 0 for gen12+ and psr.transcoder otherwise.
>
> v2 (Lucas): change the implementation to use trans_shift instead of
> getting each bit value with a different macro
>
> Cc: Imre Deak
> Cc: Dhinakaran Pandiyan
> Cc: Rodrigo Vivi
> Signed-off-by: José Roberto de Souza
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/display/intel_psr.c | 60 ++--
> drivers/gpu/drm/i915/i915_irq.c | 51 +---
> drivers/gpu/drm/i915/i915_reg.h | 10 +++-
> 3 files changed, 99 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 6f2bf50b6d80..e01c897ec9f9 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -90,17 +90,32 @@ static bool intel_psr2_enabled(struct drm_i915_private
> *dev_priv,
>
> static void psr_irq_control(struct drm_i915_private *dev_priv)
> {
> - enum transcoder trans = dev_priv->psr.transcoder;
> - u32 val, mask;
> + enum transcoder trans_shift;
> + u32 mask, val;
> + i915_reg_t imr_reg;
>
> - mask = EDP_PSR_ERROR(trans);
> + /*
> + * gen12+ has registers relative to transcoder and one per transcoder
> + * using the same bit definition: handle it as TRANSCODER_EDP to force
> + * 0 shift in bit definition
> + */
> + if (INTEL_GEN(dev_priv) >= 12) {
> + trans_shift = 0;
> + imr_reg = TRANS_PSR_IMR(dev_priv->psr.transcoder);
> + } else {
> + trans_shift = dev_priv->psr.transcoder;
> + imr_reg = EDP_PSR_IMR;
> + }
> +
> + mask = EDP_PSR_ERROR(trans_shift);
> if (dev_priv->psr.debug & I915_PSR_DEBUG_IRQ)
> - mask |= EDP_PSR_POST_EXIT(trans) | EDP_PSR_PRE_ENTRY(trans);
> + mask |= EDP_PSR_POST_EXIT(trans_shift) |
> + EDP_PSR_PRE_ENTRY(trans_shift);
>
> - val = I915_READ(EDP_PSR_IMR);
> - val &= ~EDP_PSR_TRANS_MASK(trans);
> + val = I915_READ(imr_reg);
> + val &= ~EDP_PSR_TRANS_MASK(trans_shift);
> val |= ~mask;
> - I915_WRITE(EDP_PSR_IMR, val);
> + I915_WRITE(imr_reg, val);
> }
>
> static void psr_event_print(u32 val, bool psr2_enabled)
> @@ -143,15 +158,25 @@ static void psr_event_print(u32 val, bool psr2_enabled)
> void intel_psr_irq_handler(struct drm_i915_private *dev_priv, u32 psr_iir)
> {
> enum transcoder cpu_transcoder = dev_priv->psr.transcoder;
> + enum transcoder trans_shift;
> + i915_reg_t imr_reg;
> ktime_t time_ns = ktime_get();
>
> - if (psr_iir & EDP_PSR_PRE_ENTRY(cpu_transcoder)) {
> + if (INTEL_GEN(dev_priv) >= 12) {
> + trans_shift = 0;
> + imr_reg = TRANS_PSR_IMR(dev_priv->psr.transcoder);
> + } else {
> + trans_shift = dev_priv->psr.transcoder;
> + imr_reg = EDP_PSR_IMR;
> + }
> +
> + if (psr_iir & EDP_PSR_PRE_ENTRY(trans_shift)) {
> dev_priv->psr.last_entry_attempt = time_ns;
> DRM_DEBUG_KMS("[transcoder %s] PSR entry attempt in 2
> vblanks\n",
> transcoder_name(cpu_transcoder));
> }
>
> - if (psr_iir & EDP_PSR_POST_EXIT(cpu_transcoder)) {
> + if (psr_iir & EDP_PSR_POST_EXIT(trans_shift)) {
> dev_priv->psr.last_exit = time_ns;
> DRM_DEBUG_KMS("[transcoder %s] PSR exit completed\n",
> transcoder_name(cpu_transcoder));
> @@ -165,7 +190,7 @@ void intel_psr_irq_handler(struct drm_i915_private
> *dev_priv, u32 psr_iir)
> }
> }
>
> - if (psr_iir & EDP_PSR_ERROR(cpu_transcoder)) {
> + if (psr_iir & EDP_PSR_ERROR(trans_shift)) {
> u32 val;
>
> DRM_WARN("[transcoder %s] PSR aux error\n",
> @@ -181,9 +206,9 @@ void intel_psr_irq_handler(struct drm_i915_private
> *dev_priv, u32 psr_iir)
>* again so we don't care about unmask the interruption
>* or unset irq_aux_error.
>*/
> - val = I915_READ(EDP_PSR_IMR);
> - val |= EDP_PSR_ERROR(cpu_transcoder);
> - I915_WRITE(EDP_PSR_IMR, val);
> + val = I915_READ(imr_reg);
> + val |= EDP_PSR_ERROR(trans_shift);
> + I915_WRITE(imr_reg, val);
>
> schedule_work(_priv->psr.work);
> }
> @@ -730,8 +755,13 @@ static void intel_psr_enable_locked(struct
> drm_i915_private *dev_priv,
>* first time that PSR HW tries to
[Intel-gfx] [PATCH AUTOSEL 4.19 160/167] drm/i915/userptr: Acquire the page lock around set_page_dirty()
From: Chris Wilson
[ Upstream commit aa56a292ce623734ddd30f52d73f527d1f3529b5 ]
set_page_dirty says:
For pages with a mapping this should be done under the page lock
for the benefit of asynchronous memory errors who prefer a
consistent dirty state. This rule can be broken in some special
cases, but should be better not to.
Under those rules, it is only safe for us to use the plain set_page_dirty
calls for shmemfs/anonymous memory. Userptr may be used with real
mappings and so needs to use the locked version (set_page_dirty_lock).
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203317
Fixes: 5cc9ed4b9a7a ("drm/i915: Introduce mapping of user pages into video
memory (userptr) ioctl")
References: 6dcc693bc57f ("ext4: warn when page is dirtied without buffers")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: sta...@vger.kernel.org
Reviewed-by: Tvrtko Ursulin
Link:
https://patchwork.freedesktop.org/patch/msgid/20190708140327.26825-1-ch...@chris-wilson.co.uk
(cherry picked from commit cb6d7c7dc7ff8cace666ddec66334117a6068ce2)
Signed-off-by: Jani Nikula
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/i915/i915_gem_userptr.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 2c9b284036d10..e13ea2ecd669c 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -692,7 +692,15 @@ i915_gem_userptr_put_pages(struct drm_i915_gem_object *obj,
for_each_sgt_page(page, sgt_iter, pages) {
if (obj->mm.dirty)
- set_page_dirty(page);
+ /*
+* As this may not be anonymous memory (e.g. shmem)
+* but exist on a real mapping, we have to lock
+* the page in order to dirty it -- holding
+* the page reference is not sufficient to
+* prevent the inode from being truncated.
+* Play safe and take the lock.
+*/
+ set_page_dirty_lock(page);
mark_page_accessed(page);
put_page(page);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH AUTOSEL 4.19 161/167] drm/i915: Make sure cdclk is high enough for DP audio on VLV/CHV
From: Ville Syrjälä [ Upstream commit a8f196a0fa6391a436f63f360a1fb57031fdf26c ] On VLV/CHV there is some kind of linkage between the cdclk frequency and the DP link frequency. The spec says: "For DP audio configuration, cdclk frequency shall be set to meet the following requirements: DP Link Frequency(MHz) | Cdclk frequency(MHz) 270| 320 or higher 162| 200 or higher" I suspect that would more accurately be expressed as "cdclk >= DP link clock", and in any case we can express it like that in the code because of the limited set of cdclk (200, 266, 320, 400 MHz) and link frequencies (162 and 270 MHz) we support. Without this we can end up in a situation where the cdclk is too low and enabling DP audio will kill the pipe. Happens eg. with 2560x1440 modes where the 266MHz cdclk is sufficient to pump the pixels (241.5 MHz dotclock) but is too low for the DP audio due to the link frequency being 270 MHz. v2: Spell out the cdclk and link frequencies we actually support Cc: sta...@vger.kernel.org Tested-by: Stefan Gottwald Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49 Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20190717114536.22937-1-ville.syrj...@linux.intel.com Acked-by: Chris Wilson (cherry picked from commit bffb31f73b29a60ef693842d8744950c2819851d) Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin --- drivers/gpu/drm/i915/intel_cdclk.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_cdclk.c b/drivers/gpu/drm/i915/intel_cdclk.c index 29075c7634280..7b4906ede148b 100644 --- a/drivers/gpu/drm/i915/intel_cdclk.c +++ b/drivers/gpu/drm/i915/intel_cdclk.c @@ -2208,6 +2208,17 @@ int intel_crtc_compute_min_cdclk(const struct intel_crtc_state *crtc_state) if (INTEL_GEN(dev_priv) >= 9) min_cdclk = max(2 * 96000, min_cdclk); + /* +* "For DP audio configuration, cdclk frequency shall be set to +* meet the following requirements: +* DP Link Frequency(MHz) | Cdclk frequency(MHz) +* 270| 320 or higher +* 162| 200 or higher" +*/ + if ((IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) && + intel_crtc_has_dp_encoder(crtc_state) && crtc_state->has_audio) + min_cdclk = max(crtc_state->port_clock, min_cdclk); + /* * On Valleyview some DSI panels lose (v|h)sync when the clock is lower * than 32KHz. -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH AUTOSEL 4.19 087/167] drm/i915: Handle vm_mmap error during I915_GEM_MMAP ioctl with WC set
From: Joonas Lahtinen
[ Upstream commit ebfb6977801da521d8d5d752d373a187e2a2b9b3 ]
Add err goto label and use it when VMA can't be established or changes
underneath.
v2:
- Dropping Fixes: as it's indeed impossible to race an object to the
error address. (Chris)
v3:
- Use IS_ERR_VALUE (Chris)
Reported-by: Adam Zabrocki
Signed-off-by: Joonas Lahtinen
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Adam Zabrocki
Reviewed-by: Tvrtko Ursulin #v2
Reviewed-by: Chris Wilson
Link:
https://patchwork.freedesktop.org/patch/msgid/20190207085454.10598-2-joonas.lahti...@linux.intel.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/i915/i915_gem.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index e81abd468a15d..9634d3adb8d01 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1881,6 +1881,9 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
addr = vm_mmap(obj->base.filp, 0, args->size,
PROT_READ | PROT_WRITE, MAP_SHARED,
args->offset);
+ if (IS_ERR_VALUE(addr))
+ goto err;
+
if (args->flags & I915_MMAP_WC) {
struct mm_struct *mm = current->mm;
struct vm_area_struct *vma;
@@ -1896,17 +1899,22 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
else
addr = -ENOMEM;
up_write(>mmap_sem);
+ if (IS_ERR_VALUE(addr))
+ goto err;
/* This may race, but that's ok, it only gets set */
WRITE_ONCE(obj->frontbuffer_ggtt_origin, ORIGIN_CPU);
}
i915_gem_object_put(obj);
- if (IS_ERR((void *)addr))
- return addr;
args->addr_ptr = (uint64_t) addr;
return 0;
+
+err:
+ i915_gem_object_put(obj);
+
+ return addr;
}
static unsigned int tile_row_pages(struct drm_i915_gem_object *obj)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH AUTOSEL 4.19 088/167] drm/i915: Sanity check mmap length against object size
From: Chris Wilson
[ Upstream commit 000c4f90e3f0194eef218ff2c6a8fd8ca1de4313 ]
We assumed that vm_mmap() would reject an attempt to mmap past the end of
the filp (our object), but we were wrong.
Applications that tried to use the mmap beyond the end of the object
would be greeted by a SIGBUS. After this patch, those applications will
be told about the error on creating the mmap, rather than at a random
moment on later access.
Reported-by: Antonio Argenziano
Testcase: igt/gem_mmap/bad-size
Signed-off-by: Chris Wilson
Cc: Antonio Argenziano
Cc: Joonas Lahtinen
Cc: Tvrtko Ursulin
Cc: sta...@vger.kernel.org
Reviewed-by: Tvrtko Ursulin
Reviewed-by: Joonas Lahtinen
Link:
https://patchwork.freedesktop.org/patch/msgid/20190314075829.16838-1-ch...@chris-wilson.co.uk
(cherry picked from commit 794a11cb67201ad1bb61af510bb8460280feb3f3)
Signed-off-by: Rodrigo Vivi
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/i915/i915_gem.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 9634d3adb8d01..9372877100420 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1874,8 +1874,13 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
* pages from.
*/
if (!obj->base.filp) {
- i915_gem_object_put(obj);
- return -ENXIO;
+ addr = -ENXIO;
+ goto err;
+ }
+
+ if (range_overflows(args->offset, args->size, (u64)obj->base.size)) {
+ addr = -EINVAL;
+ goto err;
}
addr = vm_mmap(obj->base.filp, 0, args->size,
@@ -1889,8 +1894,8 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
struct vm_area_struct *vma;
if (down_write_killable(>mmap_sem)) {
- i915_gem_object_put(obj);
- return -EINTR;
+ addr = -EINTR;
+ goto err;
}
vma = find_vma(mm, addr);
if (vma && __vma_matches(vma, obj->base.filp, addr, args->size))
@@ -1908,12 +1913,10 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
i915_gem_object_put(obj);
args->addr_ptr = (uint64_t) addr;
-
return 0;
err:
i915_gem_object_put(obj);
-
return addr;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH AUTOSEL 4.19 060/167] drm/i915/ilk: Fix warning when reading emon_status with no output
From: José Roberto de Souza [ Upstream commit cab870b7fdf3c4be747d88de5248b28db7d4055e ] When there is no output no one will hold a runtime_pm reference causing a warning when trying to read emom_status in debugfs. [22.756480] [ cut here ] [22.756489] RPM wakelock ref not held during HW access [22.756578] WARNING: CPU: 0 PID: 1058 at drivers/gpu/drm/i915/intel_drv.h:2104 gen5_read32+0x16b/0x1a0 [i915] [22.756580] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic i915 coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core e1000e snd_pcm mei_me prime_numbers mei lpc_ich [22.756595] CPU: 0 PID: 1058 Comm: debugfs_test Not tainted 4.20.0-rc1-CI-Trybot_3219+ #1 [22.756597] Hardware name: Hewlett-Packard HP Compaq 8100 Elite SFF PC/304Ah, BIOS 786H1 v01.13 07/14/2011 [22.756634] RIP: 0010:gen5_read32+0x16b/0x1a0 [i915] [22.756637] Code: a4 ea e0 0f 0b e9 d2 fe ff ff 80 3d a5 71 19 00 00 0f 85 d3 fe ff ff 48 c7 c7 48 d0 2d a0 c6 05 91 71 19 00 01 e8 35 a4 ea e0 <0f> 0b e9 b9 fe ff ff e8 69 c6 f2 e0 85 c0 75 92 48 c7 c2 78 d0 2d [22.756639] RSP: 0018:c9f1fd38 EFLAGS: 00010282 [22.756642] RAX: RBX: 8801f7ab RCX: 0006 [22.756643] RDX: 0006 RSI: 8212886a RDI: 820d6d57 [22.756645] RBP: 00011020 R08: 43e3d1a8 R09: [22.756647] R10: c9f1fd80 R11: R12: 0001 [22.756649] R13: 8801f7ab0068 R14: 0001 R15: 88020d53d188 [22.756651] FS: 7f2878849980() GS:880213a0() knlGS: [22.756653] CS: 0010 DS: ES: CR0: 80050033 [22.756655] CR2: 5638deedf028 CR3: 000203292001 CR4: 000206f0 [22.756657] Call Trace: [22.756689] i915_mch_val+0x1b/0x60 [i915] [22.756721] i915_emon_status+0x45/0xd0 [i915] [22.756730] seq_read+0xdb/0x3c0 [22.756736] ? lockdep_hardirqs_off+0x94/0xd0 [22.756740] ? __slab_free+0x24e/0x510 [22.756746] full_proxy_read+0x52/0x90 [22.756752] __vfs_read+0x31/0x170 [22.756759] ? do_sys_open+0x13b/0x240 [22.756763] ? rcu_read_lock_sched_held+0x6f/0x80 [22.756766] vfs_read+0x9e/0x140 [22.756770] ksys_read+0x50/0xc0 [22.756775] do_syscall_64+0x55/0x190 [22.756781] entry_SYSCALL_64_after_hwframe+0x49/0xbe [22.756783] RIP: 0033:0x7f28781dc34e [22.756786] Code: 00 00 00 00 48 8b 15 71 8c 20 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff c3 0f 1f 40 00 8b 05 ba d0 20 00 85 c0 75 16 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 5a f3 c3 0f 1f 84 00 00 00 00 00 41 54 55 49 [22.756787] RSP: 002b:7ffd33fa0d08 EFLAGS: 0246 ORIG_RAX: [22.756790] RAX: ffda RBX: RCX: 7f28781dc34e [22.756792] RDX: 0200 RSI: 7ffd33fa0d50 RDI: 0008 [22.756794] RBP: 7ffd33fa0f60 R08: R09: 0020 [22.756796] R10: R11: 0246 R12: 5638de45c2c0 [22.756797] R13: 7ffd33fa14b0 R14: R15: [22.756806] irq event stamp: 47950 [22.756811] hardirqs last enabled at (47949): [] vprintk_emit+0x124/0x320 [22.756813] hardirqs last disabled at (47950): [] trace_hardirqs_off_thunk+0x1a/0x1c [22.756816] softirqs last enabled at (47518): [] __do_softirq+0x33a/0x4b9 [22.756820] softirqs last disabled at (47479): [] irq_exit+0xa9/0xc0 [22.756858] WARNING: CPU: 0 PID: 1058 at drivers/gpu/drm/i915/intel_drv.h:2104 gen5_read32+0x16b/0x1a0 [i915] [22.756860] ---[ end trace bf56fa7d6a3cbf7a ] Signed-off-by: José Roberto de Souza Reviewed-by: Rodrigo Vivi Link: https://patchwork.freedesktop.org/patch/msgid/20181119230101.32460-1-jose.so...@intel.com Signed-off-by: Sasha Levin --- drivers/gpu/drm/i915/i915_debugfs.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index f9ce35da4123e..e063e98d1e82e 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -1788,6 +1788,8 @@ static int i915_emon_status(struct seq_file *m, void *unused) if (!IS_GEN5(dev_priv)) return -ENODEV; + intel_runtime_pm_get(dev_priv); + ret = mutex_lock_interruptible(>struct_mutex); if (ret) return ret; @@ -1802,6 +1804,8 @@ static int i915_emon_status(struct seq_file *m, void *unused) seq_printf(m, "GFX power: %ld\n", gfx); seq_printf(m, "Total power: %ld\n", chipset + gfx); + intel_runtime_pm_put(dev_priv); + return 0; } -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH AUTOSEL 4.19 017/167] drm/i915: Rename PLANE_CTL_DECOMPRESSION_ENABLE
From: Dhinakaran Pandiyan
[ Upstream commit 53867b46fa8443713b3aee520d6ca558b222d829 ]
Rename PLANE_CTL_DECOMPRESSION_ENABLE to resemble the bpsec name -
PLANE_CTL_RENDER_DECOMPRESSION_ENABLE
Suggested-by: Rodrigo Vivi
Cc: Daniel Vetter
Signed-off-by: Dhinakaran Pandiyan
Reviewed-by: Ville Syrjälä
Link:
https://patchwork.freedesktop.org/patch/msgid/20180822015053.1420-2-dhinakaran.pandi...@intel.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/i915/i915_reg.h | 2 +-
drivers/gpu/drm/i915/intel_display.c | 8
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 16f5d2d938014..4e070afb2738b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6531,7 +6531,7 @@ enum {
#define PLANE_CTL_YUV422_UYVY(1 << 16)
#define PLANE_CTL_YUV422_YVYU(2 << 16)
#define PLANE_CTL_YUV422_VYUY(3 << 16)
-#define PLANE_CTL_DECOMPRESSION_ENABLE (1 << 15)
+#define PLANE_CTL_RENDER_DECOMPRESSION_ENABLE(1 << 15)
#define PLANE_CTL_TRICKLE_FEED_DISABLE (1 << 14)
#define PLANE_CTL_PLANE_GAMMA_DISABLE(1 << 13) /* Pre-GLK */
#define PLANE_CTL_TILED_MASK (0x7 << 10)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 3bd44d042a1d9..f5367bdc04049 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3561,11 +3561,11 @@ static u32 skl_plane_ctl_tiling(uint64_t fb_modifier)
case I915_FORMAT_MOD_Y_TILED:
return PLANE_CTL_TILED_Y;
case I915_FORMAT_MOD_Y_TILED_CCS:
- return PLANE_CTL_TILED_Y | PLANE_CTL_DECOMPRESSION_ENABLE;
+ return PLANE_CTL_TILED_Y |
PLANE_CTL_RENDER_DECOMPRESSION_ENABLE;
case I915_FORMAT_MOD_Yf_TILED:
return PLANE_CTL_TILED_YF;
case I915_FORMAT_MOD_Yf_TILED_CCS:
- return PLANE_CTL_TILED_YF | PLANE_CTL_DECOMPRESSION_ENABLE;
+ return PLANE_CTL_TILED_YF |
PLANE_CTL_RENDER_DECOMPRESSION_ENABLE;
default:
MISSING_CASE(fb_modifier);
}
@@ -8812,13 +8812,13 @@ skylake_get_initial_plane_config(struct intel_crtc
*crtc,
fb->modifier = I915_FORMAT_MOD_X_TILED;
break;
case PLANE_CTL_TILED_Y:
- if (val & PLANE_CTL_DECOMPRESSION_ENABLE)
+ if (val & PLANE_CTL_RENDER_DECOMPRESSION_ENABLE)
fb->modifier = I915_FORMAT_MOD_Y_TILED_CCS;
else
fb->modifier = I915_FORMAT_MOD_Y_TILED;
break;
case PLANE_CTL_TILED_YF:
- if (val & PLANE_CTL_DECOMPRESSION_ENABLE)
+ if (val & PLANE_CTL_RENDER_DECOMPRESSION_ENABLE)
fb->modifier = I915_FORMAT_MOD_Yf_TILED_CCS;
else
fb->modifier = I915_FORMAT_MOD_Yf_TILED;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH AUTOSEL 4.19 016/167] drm/i915: Fix intel_dp_mst_best_encoder()
From: Lyude Paul [ Upstream commit a9f9ca33d1fe9325f414914be526c0fc4ba5281c ] Currently, i915 appears to rely on blocking modesets on no-longer-present MSTB ports by simply returning NULL for ->best_encoder(), which in turn causes any new atomic commits that don't disable the CRTC to fail. This is wrong however, since we still want to allow userspace to disable CRTCs on no-longer-present MSTB ports by changing the DPMS state to off and this still requires that we retrieve an encoder. So, fix this by always returning a valid encoder regardless of the state of the MST port. Changes since v1: - Remove mst atomic helper, since this got replaced with a much simpler solution Signed-off-by: Lyude Paul Reviewed-by: Daniel Vetter Cc: sta...@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20181008232437.5571-6-ly...@redhat.com Signed-off-by: Sasha Levin --- drivers/gpu/drm/i915/intel_dp_mst.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c index 1fec0c71b4d95..58ba14966d4f1 100644 --- a/drivers/gpu/drm/i915/intel_dp_mst.c +++ b/drivers/gpu/drm/i915/intel_dp_mst.c @@ -408,8 +408,6 @@ static struct drm_encoder *intel_mst_atomic_best_encoder(struct drm_connector *c struct intel_dp *intel_dp = intel_connector->mst_port; struct intel_crtc *crtc = to_intel_crtc(state->crtc); - if (!READ_ONCE(connector->registered)) - return NULL; return _dp->mst_encoders[crtc->pipe]->base.base; } -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH AUTOSEL 4.19 033/167] drm/i915: Restore sane defaults for KMS on GEM error load
From: Chris Wilson
[ Upstream commit 7ed43df720c007d60bee6d81da07bcdc7e4a55ae ]
If we fail during GEM initialisation, we scrub the HW state by
performing a device level GPU resuet. However, we want to leave the
system in a usable state (with functioning KMS but no GEM) so after
scrubbing the HW state, we need to restore some sane defaults and
re-enable the low-level common parts of the GPU (such as the GMCH).
v2: Restore GTT entries.
Signed-off-by: Chris Wilson
Link:
https://patchwork.freedesktop.org/patch/msgid/20180726085033.4044-2-ch...@chris-wilson.co.uk
Reviewed-by: Michał Winiarski
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/i915/i915_gem.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 03cda197fb6b8..5019dfd8bcf16 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5595,6 +5595,8 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
i915_gem_cleanup_userptr(dev_priv);
if (ret == -EIO) {
+ mutex_lock(_priv->drm.struct_mutex);
+
/*
* Allow engine initialisation to fail by marking the GPU as
* wedged. But we only want to do this where the GPU is angry,
@@ -5605,7 +5607,14 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
"Failed to initialize GPU, declaring it
wedged!\n");
i915_gem_set_wedged(dev_priv);
}
- ret = 0;
+
+ /* Minimal basic recovery for KMS */
+ ret = i915_ggtt_enable_hw(dev_priv);
+ i915_gem_restore_gtt_mappings(dev_priv);
+ i915_gem_restore_fences(dev_priv);
+ intel_init_clock_gating(dev_priv);
+
+ mutex_unlock(_priv->drm.struct_mutex);
}
i915_gem_drain_freed_objects(dev_priv);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH AUTOSEL 4.19 034/167] drm/i915: Cleanup gt powerstate from gem
From: Chris Wilson
[ Upstream commit 30b710840e4b9c9699d3d4b33fb19ad8880d4614 ]
Since the gt powerstate is allocated by i915_gem_init, clean it from
i915_gem_fini for symmetry and to correct the imbalance on error.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
Link:
https://patchwork.freedesktop.org/patch/msgid/20180812223642.24865-1-ch...@chris-wilson.co.uk
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/i915/i915_gem.c | 3 +++
drivers/gpu/drm/i915/intel_display.c | 4
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 5019dfd8bcf16..e81abd468a15d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5624,6 +5624,7 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
void i915_gem_fini(struct drm_i915_private *dev_priv)
{
i915_gem_suspend_late(dev_priv);
+ intel_disable_gt_powersave(dev_priv);
/* Flush any outstanding unpin_work. */
i915_gem_drain_workqueue(dev_priv);
@@ -5635,6 +5636,8 @@ void i915_gem_fini(struct drm_i915_private *dev_priv)
i915_gem_contexts_fini(dev_priv);
mutex_unlock(_priv->drm.struct_mutex);
+ intel_cleanup_gt_powersave(dev_priv);
+
intel_uc_fini_misc(dev_priv);
i915_gem_cleanup_userptr(dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 2622dfc7d2d9a..6902fd2da19ca 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15972,8 +15972,6 @@ void intel_modeset_cleanup(struct drm_device *dev)
flush_work(_priv->atomic_helper.free_work);
WARN_ON(!llist_empty(_priv->atomic_helper.free_list));
- intel_disable_gt_powersave(dev_priv);
-
/*
* Interrupts and polling as the first thing to avoid creating havoc.
* Too much stuff here (turning of connectors, ...) would
@@ -16001,8 +15999,6 @@ void intel_modeset_cleanup(struct drm_device *dev)
intel_cleanup_overlay(dev_priv);
- intel_cleanup_gt_powersave(dev_priv);
-
intel_teardown_gmbus(dev_priv);
destroy_workqueue(dev_priv->modeset_wq);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH AUTOSEL 4.19 018/167] drm/i915/gen9+: Fix initial readout for Y tiled framebuffers
From: Imre Deak
[ Upstream commit 914a4fd8cd28016038ce749a818a836124a8d270 ]
If BIOS configured a Y tiled FB we failed to set up the backing object
tiling accordingly, leading to a lack of GT fence installed and a
garbled console.
The problem was bisected to
commit 011f22eb545a ("drm/i915: Do NOT skip the first 4k of stolen memory for
pre-allocated buffers v2")
but it just revealed a pre-existing issue.
Kudos to Ville who suspected a missing fence looking at the corruption
on the screen.
Cc: Ville Syrjälä
Cc: Mika Westerberg
Cc: Hans de Goede
Cc:
Cc:
Reported-by: Mika Westerberg
Reported-by:
Tested-by:
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108264
Fixes: bc8d7dffacb1 ("drm/i915/skl: Provide a Skylake version of
get_plane_config()")
Signed-off-by: Imre Deak
Reviewed-by: Ville Syrjälä
Link:
https://patchwork.freedesktop.org/patch/msgid/20181016160011.28347-1-imre.d...@intel.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/i915/intel_display.c | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f5367bdc04049..2622dfc7d2d9a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2712,6 +2712,17 @@ intel_alloc_initial_plane_obj(struct intel_crtc *crtc,
if (size_aligned * 2 > dev_priv->stolen_usable_size)
return false;
+ switch (fb->modifier) {
+ case DRM_FORMAT_MOD_LINEAR:
+ case I915_FORMAT_MOD_X_TILED:
+ case I915_FORMAT_MOD_Y_TILED:
+ break;
+ default:
+ DRM_DEBUG_DRIVER("Unsupported modifier for initial FB:
0x%llx\n",
+fb->modifier);
+ return false;
+ }
+
mutex_lock(>struct_mutex);
obj = i915_gem_object_create_stolen_for_preallocated(dev_priv,
base_aligned,
@@ -2721,8 +2732,17 @@ intel_alloc_initial_plane_obj(struct intel_crtc *crtc,
if (!obj)
return false;
- if (plane_config->tiling == I915_TILING_X)
- obj->tiling_and_stride = fb->pitches[0] | I915_TILING_X;
+ switch (plane_config->tiling) {
+ case I915_TILING_NONE:
+ break;
+ case I915_TILING_X:
+ case I915_TILING_Y:
+ obj->tiling_and_stride = fb->pitches[0] | plane_config->tiling;
+ break;
+ default:
+ MISSING_CASE(plane_config->tiling);
+ return false;
+ }
mode_cmd.pixel_format = fb->format->format;
mode_cmd.width = fb->width;
@@ -8812,6 +8832,7 @@ skylake_get_initial_plane_config(struct intel_crtc *crtc,
fb->modifier = I915_FORMAT_MOD_X_TILED;
break;
case PLANE_CTL_TILED_Y:
+ plane_config->tiling = I915_TILING_Y;
if (val & PLANE_CTL_RENDER_DECOMPRESSION_ENABLE)
fb->modifier = I915_FORMAT_MOD_Y_TILED_CCS;
else
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH AUTOSEL 5.2 23/23] drm/i915/icl: whitelist PS_(DEPTH|INVOCATION)_COUNT
From: Lionel Landwerlin [ Upstream commit cf8f9aa1eda7d916bd23f6b8c226404deb11690c ] The same tests failing on CFL+ platforms are also failing on ICL. Documentation doesn't list the WaAllowPMDepthAndInvocationCountAccessFromUMD workaround for ICL but applying it fixes the same tests as CFL. v2: Use only one whitelist entry (Lionel) Signed-off-by: Lionel Landwerlin Tested-by: Anuj Phogat Cc: sta...@vger.kernel.org # 6883eab27481: drm/i915: Support flags in whitlist WAs Cc: sta...@vger.kernel.org Acked-by: Chris Wilson Signed-off-by: Chris Wilson Link: https://patchwork.freedesktop.org/patch/msgid/20190628120720.21682-4-lionel.g.landwer...@intel.com (cherry picked from commit 3fe0107e45ab396342497e06b8924cdd485cde3b) Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin --- drivers/gpu/drm/i915/intel_workarounds.c | 13 + 1 file changed, 13 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_workarounds.c b/drivers/gpu/drm/i915/intel_workarounds.c index efea5a18fa6db..edd57a5e0495f 100644 --- a/drivers/gpu/drm/i915/intel_workarounds.c +++ b/drivers/gpu/drm/i915/intel_workarounds.c @@ -1107,6 +1107,19 @@ static void icl_whitelist_build(struct intel_engine_cs *engine) /* WaEnableStateCacheRedirectToCS:icl */ whitelist_reg(w, GEN9_SLICE_COMMON_ECO_CHICKEN1); + + /* +* WaAllowPMDepthAndInvocationCountAccessFromUMD:icl +* +* This covers 4 register which are next to one another : +* - PS_INVOCATION_COUNT +* - PS_INVOCATION_COUNT_UDW +* - PS_DEPTH_COUNT +* - PS_DEPTH_COUNT_UDW +*/ + whitelist_reg_ext(w, PS_INVOCATION_COUNT, + RING_FORCE_TO_NONPRIV_RD | + RING_FORCE_TO_NONPRIV_RANGE_4); break; case VIDEO_DECODE_CLASS: -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH AUTOSEL 5.2 22/23] drm/i915: Add whitelist workarounds for ICL
From: John Harrison
[ Upstream commit 7b3d406310983a89ed7a1ecdd115efbe12b0ded5 ]
Updated whitelist table for ICL.
v2: Reduce changes to just those required for media driver until
the selftest can be updated to support the new features of the
other entries.
Signed-off-by: John Harrison
Signed-off-by: Robert M. Fosha
Cc: Tvrtko Ursulin
Cc: Chris Wilson
Reviewed-by: Tvrtko Ursulin
Signed-off-by: Tvrtko Ursulin
Link:
https://patchwork.freedesktop.org/patch/msgid/20190618010108.27499-4-john.c.harri...@intel.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/i915/intel_workarounds.c | 38 +---
1 file changed, 27 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
b/drivers/gpu/drm/i915/intel_workarounds.c
index be3688908f0ce..efea5a18fa6db 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -1097,17 +1097,33 @@ static void icl_whitelist_build(struct intel_engine_cs
*engine)
{
struct i915_wa_list *w = >whitelist;
- if (engine->class != RENDER_CLASS)
- return;
-
- /* WaAllowUMDToModifyHalfSliceChicken7:icl */
- whitelist_reg(w, GEN9_HALF_SLICE_CHICKEN7);
-
- /* WaAllowUMDToModifySamplerMode:icl */
- whitelist_reg(w, GEN10_SAMPLER_MODE);
-
- /* WaEnableStateCacheRedirectToCS:icl */
- whitelist_reg(w, GEN9_SLICE_COMMON_ECO_CHICKEN1);
+ switch (engine->class) {
+ case RENDER_CLASS:
+ /* WaAllowUMDToModifyHalfSliceChicken7:icl */
+ whitelist_reg(w, GEN9_HALF_SLICE_CHICKEN7);
+
+ /* WaAllowUMDToModifySamplerMode:icl */
+ whitelist_reg(w, GEN10_SAMPLER_MODE);
+
+ /* WaEnableStateCacheRedirectToCS:icl */
+ whitelist_reg(w, GEN9_SLICE_COMMON_ECO_CHICKEN1);
+ break;
+
+ case VIDEO_DECODE_CLASS:
+ /* hucStatusRegOffset */
+ whitelist_reg_ext(w, _MMIO(0x2000 + engine->mmio_base),
+ RING_FORCE_TO_NONPRIV_RD);
+ /* hucUKernelHdrInfoRegOffset */
+ whitelist_reg_ext(w, _MMIO(0x2014 + engine->mmio_base),
+ RING_FORCE_TO_NONPRIV_RD);
+ /* hucStatus2RegOffset */
+ whitelist_reg_ext(w, _MMIO(0x23B0 + engine->mmio_base),
+ RING_FORCE_TO_NONPRIV_RD);
+ break;
+
+ default:
+ break;
+ }
}
void intel_engine_init_whitelist(struct intel_engine_cs *engine)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH AUTOSEL 5.2 21/23] drm/i915: whitelist PS_(DEPTH|INVOCATION)_COUNT
From: Lionel Landwerlin
[ Upstream commit 6ce5bfe936ac31d5c52c4b1328d0bfda5f97e7ca ]
CFL:C0+ changed the status of those registers which are now
blacklisted by default.
This is breaking a number of CTS tests on GL & Vulkan :
KHR-GL45.pipeline_statistics_query_tests_ARB.functional_fragment_shader_invocations
(GL)
dEQP-VK.query_pool.statistics_query.fragment_shader_invocations.* (Vulkan)
v2: Only use one whitelist entry (Lionel)
Bspec: 14091
Signed-off-by: Lionel Landwerlin
Cc: sta...@vger.kernel.org # 6883eab27481: drm/i915: Support flags in whitlist
WAs
Cc: sta...@vger.kernel.org
Acked-by: Chris Wilson
Signed-off-by: Chris Wilson
Link:
https://patchwork.freedesktop.org/patch/msgid/20190628120720.21682-3-lionel.g.landwer...@intel.com
(cherry picked from commit 2c903da50f5a9522b134e488bd0f92646c46f3c0)
Signed-off-by: Jani Nikula
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/i915/intel_workarounds.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
b/drivers/gpu/drm/i915/intel_workarounds.c
index 0b80fde927899..be3688908f0ce 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -1061,10 +1061,25 @@ static void glk_whitelist_build(struct intel_engine_cs
*engine)
static void cfl_whitelist_build(struct intel_engine_cs *engine)
{
+ struct i915_wa_list *w = >whitelist;
+
if (engine->class != RENDER_CLASS)
return;
- gen9_whitelist_build(>whitelist);
+ gen9_whitelist_build(w);
+
+ /*
+* WaAllowPMDepthAndInvocationCountAccessFromUMD:cfl,whl,cml,aml
+*
+* This covers 4 register which are next to one another :
+* - PS_INVOCATION_COUNT
+* - PS_INVOCATION_COUNT_UDW
+* - PS_DEPTH_COUNT
+* - PS_DEPTH_COUNT_UDW
+*/
+ whitelist_reg_ext(w, PS_INVOCATION_COUNT,
+ RING_FORCE_TO_NONPRIV_RD |
+ RING_FORCE_TO_NONPRIV_RANGE_4);
}
static void cnl_whitelist_build(struct intel_engine_cs *engine)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH AUTOSEL 5.2 12/23] drm/i915: Disable SAMPLER_STATE prefetching on all Gen11 steppings.
From: Kenneth Graunke
[ Upstream commit 248f883db61283b4f5a1c92a5e27277377b09f16 ]
The Demand Prefetch workaround (binding table prefetching) only applies
to Icelake A0/B0. But the Sampler Prefetch workaround needs to be
applied to all Gen11 steppings, according to a programming note in the
SARCHKMD documentation.
Using the Intel Gallium driver, I have seen intermittent failures in
the dEQP-GLES31.functional.copy_image.non_compressed.* tests. After
applying this workaround, the tests reliably pass.
v2: Remove the overlap with a pre-production w/a
BSpec: 9663
Signed-off-by: Kenneth Graunke
Signed-off-by: Chris Wilson
Cc: sta...@vger.kernel.org
Reviewed-by: Mika Kuoppala
Link:
https://patchwork.freedesktop.org/patch/msgid/20190625090655.19220-1-ch...@chris-wilson.co.uk
(cherry picked from commit f9a393875d3af13cc3267477746608dadb7f17c1)
Signed-off-by: Jani Nikula
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/i915/intel_workarounds.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
b/drivers/gpu/drm/i915/intel_workarounds.c
index 841b8e515f4d6..2fb70fab2d1c6 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -1167,8 +1167,12 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
struct i915_wa_list *wal)
if (IS_ICL_REVID(i915, ICL_REVID_A0, ICL_REVID_B0))
wa_write_or(wal,
GEN7_SARCHKMD,
- GEN7_DISABLE_DEMAND_PREFETCH |
- GEN7_DISABLE_SAMPLER_PREFETCH);
+ GEN7_DISABLE_DEMAND_PREFETCH);
+
+ /* Wa_1606682166:icl */
+ wa_write_or(wal,
+ GEN7_SARCHKMD,
+ GEN7_DISABLE_SAMPLER_PREFETCH);
}
if (IS_GEN_RANGE(i915, 9, 11)) {
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH AUTOSEL 4.19 001/167] drm/i915: Re-apply "Perform link quality check, unconditionally during long pulse"
From: Jan-Marek Glogowski
[ Upstream commit 3cf71bc9904d7ee4a25a822c5dcb54c7804ea388 ]
This re-applies the workaround for "some DP sinks, [which] are a
little nuts" from commit 1a36147bb939 ("drm/i915: Perform link
quality check unconditionally during long pulse").
It makes the secondary AOC E2460P monitor connected via DP to an
acer Veriton N4640G usable again.
This hunk was dropped in commit c85d200e8321 ("drm/i915: Move SST
DP link retraining into the ->post_hotplug() hook")
Fixes: c85d200e8321 ("drm/i915: Move SST DP link retraining into the
->post_hotplug() hook")
[Cleaned up commit message, added stable cc]
Signed-off-by: Lyude Paul
Signed-off-by: Jan-Marek Glogowski
Cc: sta...@vger.kernel.org
Link:
https://patchwork.freedesktop.org/patch/msgid/20180825191035.3945-1-ly...@redhat.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/i915/intel_dp.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f92079e19de8d..20cd4c8acecc3 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4739,6 +4739,22 @@ intel_dp_long_pulse(struct intel_connector *connector,
*/
status = connector_status_disconnected;
goto out;
+ } else {
+ /*
+* If display is now connected check links status,
+* there has been known issues of link loss triggering
+* long pulse.
+*
+* Some sinks (eg. ASUS PB287Q) seem to perform some
+* weird HPD ping pong during modesets. So we can apparently
+* end up with HPD going low during a modeset, and then
+* going back up soon after. And once that happens we must
+* retrain the link to get a picture. That's in case no
+* userspace component reacted to intermittent HPD dip.
+*/
+ struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
+
+ intel_dp_retrain_link(encoder, ctx);
}
/*
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH AUTOSEL 5.2 14/23] drm/i915: Make sure cdclk is high enough for DP audio on VLV/CHV
From: Ville Syrjälä [ Upstream commit a8f196a0fa6391a436f63f360a1fb57031fdf26c ] On VLV/CHV there is some kind of linkage between the cdclk frequency and the DP link frequency. The spec says: "For DP audio configuration, cdclk frequency shall be set to meet the following requirements: DP Link Frequency(MHz) | Cdclk frequency(MHz) 270| 320 or higher 162| 200 or higher" I suspect that would more accurately be expressed as "cdclk >= DP link clock", and in any case we can express it like that in the code because of the limited set of cdclk (200, 266, 320, 400 MHz) and link frequencies (162 and 270 MHz) we support. Without this we can end up in a situation where the cdclk is too low and enabling DP audio will kill the pipe. Happens eg. with 2560x1440 modes where the 266MHz cdclk is sufficient to pump the pixels (241.5 MHz dotclock) but is too low for the DP audio due to the link frequency being 270 MHz. v2: Spell out the cdclk and link frequencies we actually support Cc: sta...@vger.kernel.org Tested-by: Stefan Gottwald Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49 Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20190717114536.22937-1-ville.syrj...@linux.intel.com Acked-by: Chris Wilson (cherry picked from commit bffb31f73b29a60ef693842d8744950c2819851d) Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin --- drivers/gpu/drm/i915/intel_cdclk.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_cdclk.c b/drivers/gpu/drm/i915/intel_cdclk.c index ae40a8679314e..fd5236da039fb 100644 --- a/drivers/gpu/drm/i915/intel_cdclk.c +++ b/drivers/gpu/drm/i915/intel_cdclk.c @@ -2269,6 +2269,17 @@ int intel_crtc_compute_min_cdclk(const struct intel_crtc_state *crtc_state) if (crtc_state->has_audio && INTEL_GEN(dev_priv) >= 9) min_cdclk = max(2 * 96000, min_cdclk); + /* +* "For DP audio configuration, cdclk frequency shall be set to +* meet the following requirements: +* DP Link Frequency(MHz) | Cdclk frequency(MHz) +* 270| 320 or higher +* 162| 200 or higher" +*/ + if ((IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) && + intel_crtc_has_dp_encoder(crtc_state) && crtc_state->has_audio) + min_cdclk = max(crtc_state->port_clock, min_cdclk); + /* * On Valleyview some DSI panels lose (v|h)sync when the clock is lower * than 32KHz. -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH AUTOSEL 5.2 13/23] drm/i915/userptr: Acquire the page lock around set_page_dirty()
From: Chris Wilson
[ Upstream commit aa56a292ce623734ddd30f52d73f527d1f3529b5 ]
set_page_dirty says:
For pages with a mapping this should be done under the page lock
for the benefit of asynchronous memory errors who prefer a
consistent dirty state. This rule can be broken in some special
cases, but should be better not to.
Under those rules, it is only safe for us to use the plain set_page_dirty
calls for shmemfs/anonymous memory. Userptr may be used with real
mappings and so needs to use the locked version (set_page_dirty_lock).
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203317
Fixes: 5cc9ed4b9a7a ("drm/i915: Introduce mapping of user pages into video
memory (userptr) ioctl")
References: 6dcc693bc57f ("ext4: warn when page is dirtied without buffers")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: sta...@vger.kernel.org
Reviewed-by: Tvrtko Ursulin
Link:
https://patchwork.freedesktop.org/patch/msgid/20190708140327.26825-1-ch...@chris-wilson.co.uk
(cherry picked from commit cb6d7c7dc7ff8cace666ddec66334117a6068ce2)
Signed-off-by: Jani Nikula
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/i915/i915_gem_userptr.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 8079ea3af1039..b1fc15c7f5997 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -678,7 +678,15 @@ i915_gem_userptr_put_pages(struct drm_i915_gem_object *obj,
for_each_sgt_page(page, sgt_iter, pages) {
if (obj->mm.dirty)
- set_page_dirty(page);
+ /*
+* As this may not be anonymous memory (e.g. shmem)
+* but exist on a real mapping, we have to lock
+* the page in order to dirty it -- holding
+* the page reference is not sufficient to
+* prevent the inode from being truncated.
+* Play safe and take the lock.
+*/
+ set_page_dirty_lock(page);
mark_page_accessed(page);
put_page(page);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH AUTOSEL 5.2 20/23] drm/i915: Support whitelist workarounds on all engines
From: John Harrison
[ Upstream commit ebd2de47a19f1c17ae47f8331aae3cd43673 ]
Newer hardware requires setting up whitelists on engines other than
render. So, extend the whitelist code to support all engines.
Signed-off-by: John Harrison
Signed-off-by: Robert M. Fosha
Cc: Tvrtko Ursulin
Cc: Chris Wilson
Reviewed-by: Tvrtko Ursulin
Signed-off-by: Tvrtko Ursulin
Link:
https://patchwork.freedesktop.org/patch/msgid/20190618010108.27499-3-john.c.harri...@intel.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/i915/intel_workarounds.c | 65 +---
1 file changed, 47 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
b/drivers/gpu/drm/i915/intel_workarounds.c
index 1db826b12774e..0b80fde927899 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -1012,48 +1012,79 @@ static void gen9_whitelist_build(struct i915_wa_list *w)
whitelist_reg(w, GEN8_HDC_CHICKEN1);
}
-static void skl_whitelist_build(struct i915_wa_list *w)
+static void skl_whitelist_build(struct intel_engine_cs *engine)
{
+ struct i915_wa_list *w = >whitelist;
+
+ if (engine->class != RENDER_CLASS)
+ return;
+
gen9_whitelist_build(w);
/* WaDisableLSQCROPERFforOCL:skl */
whitelist_reg(w, GEN8_L3SQCREG4);
}
-static void bxt_whitelist_build(struct i915_wa_list *w)
+static void bxt_whitelist_build(struct intel_engine_cs *engine)
{
- gen9_whitelist_build(w);
+ if (engine->class != RENDER_CLASS)
+ return;
+
+ gen9_whitelist_build(>whitelist);
}
-static void kbl_whitelist_build(struct i915_wa_list *w)
+static void kbl_whitelist_build(struct intel_engine_cs *engine)
{
+ struct i915_wa_list *w = >whitelist;
+
+ if (engine->class != RENDER_CLASS)
+ return;
+
gen9_whitelist_build(w);
/* WaDisableLSQCROPERFforOCL:kbl */
whitelist_reg(w, GEN8_L3SQCREG4);
}
-static void glk_whitelist_build(struct i915_wa_list *w)
+static void glk_whitelist_build(struct intel_engine_cs *engine)
{
+ struct i915_wa_list *w = >whitelist;
+
+ if (engine->class != RENDER_CLASS)
+ return;
+
gen9_whitelist_build(w);
/* WA #0862: Userspace has to set "Barrier Mode" to avoid hangs. */
whitelist_reg(w, GEN9_SLICE_COMMON_ECO_CHICKEN1);
}
-static void cfl_whitelist_build(struct i915_wa_list *w)
+static void cfl_whitelist_build(struct intel_engine_cs *engine)
{
- gen9_whitelist_build(w);
+ if (engine->class != RENDER_CLASS)
+ return;
+
+ gen9_whitelist_build(>whitelist);
}
-static void cnl_whitelist_build(struct i915_wa_list *w)
+static void cnl_whitelist_build(struct intel_engine_cs *engine)
{
+ struct i915_wa_list *w = >whitelist;
+
+ if (engine->class != RENDER_CLASS)
+ return;
+
/* WaEnablePreemptionGranularityControlByUMD:cnl */
whitelist_reg(w, GEN8_CS_CHICKEN1);
}
-static void icl_whitelist_build(struct i915_wa_list *w)
+static void icl_whitelist_build(struct intel_engine_cs *engine)
{
+ struct i915_wa_list *w = >whitelist;
+
+ if (engine->class != RENDER_CLASS)
+ return;
+
/* WaAllowUMDToModifyHalfSliceChicken7:icl */
whitelist_reg(w, GEN9_HALF_SLICE_CHICKEN7);
@@ -1069,24 +1100,22 @@ void intel_engine_init_whitelist(struct intel_engine_cs
*engine)
struct drm_i915_private *i915 = engine->i915;
struct i915_wa_list *w = >whitelist;
- GEM_BUG_ON(engine->id != RCS0);
-
wa_init_start(w, "whitelist");
if (IS_GEN(i915, 11))
- icl_whitelist_build(w);
+ icl_whitelist_build(engine);
else if (IS_CANNONLAKE(i915))
- cnl_whitelist_build(w);
+ cnl_whitelist_build(engine);
else if (IS_COFFEELAKE(i915))
- cfl_whitelist_build(w);
+ cfl_whitelist_build(engine);
else if (IS_GEMINILAKE(i915))
- glk_whitelist_build(w);
+ glk_whitelist_build(engine);
else if (IS_KABYLAKE(i915))
- kbl_whitelist_build(w);
+ kbl_whitelist_build(engine);
else if (IS_BROXTON(i915))
- bxt_whitelist_build(w);
+ bxt_whitelist_build(engine);
else if (IS_SKYLAKE(i915))
- skl_whitelist_build(w);
+ skl_whitelist_build(engine);
else if (INTEL_GEN(i915) <= 8)
return;
else
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH AUTOSEL 5.2 19/23] drm/i915: Support flags in whitlist WAs
From: John Harrison
[ Upstream commit 6883eab274813d158bfcfb499aa225ece61c0f29 ]
Newer hardware adds flags to the whitelist work-around register. These
allow per access direction privileges and ranges.
Signed-off-by: John Harrison
Signed-off-by: Robert M. Fosha
Cc: Tvrtko Ursulin
Cc: Chris Wilson
Reviewed-by: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
Signed-off-by: Tvrtko Ursulin
Link:
https://patchwork.freedesktop.org/patch/msgid/20190618010108.27499-2-john.c.harri...@intel.com
(cherry picked from commit 5380d0b781c491d94b4f4690ecf9762c1946c4ec)
Signed-off-by: Joonas Lahtinen
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/i915/i915_reg.h | 7 +++
drivers/gpu/drm/i915/intel_workarounds.c | 9 -
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 13d6bd4e17b20..cf748b80e6401 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2510,6 +2510,13 @@ enum i915_power_well_id {
#define RING_WAIT_SEMAPHORE (1 << 10) /* gen6+ */
#define RING_FORCE_TO_NONPRIV(base, i) _MMIO(((base) + 0x4D0) + (i) * 4)
+#define RING_FORCE_TO_NONPRIV_RW (0 << 28)/* CFL+ & Gen11+ */
+#define RING_FORCE_TO_NONPRIV_RD (1 << 28)
+#define RING_FORCE_TO_NONPRIV_WR (2 << 28)
+#define RING_FORCE_TO_NONPRIV_RANGE_1(0 << 0) /* CFL+ &
Gen11+ */
+#define RING_FORCE_TO_NONPRIV_RANGE_4(1 << 0)
+#define RING_FORCE_TO_NONPRIV_RANGE_16 (2 << 0)
+#define RING_FORCE_TO_NONPRIV_RANGE_64 (3 << 0)
#define RING_MAX_NONPRIV_SLOTS 12
#define GEN7_TLB_RD_ADDR _MMIO(0x4700)
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
b/drivers/gpu/drm/i915/intel_workarounds.c
index 2fb70fab2d1c6..1db826b12774e 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -981,7 +981,7 @@ bool intel_gt_verify_workarounds(struct drm_i915_private
*i915,
}
static void
-whitelist_reg(struct i915_wa_list *wal, i915_reg_t reg)
+whitelist_reg_ext(struct i915_wa_list *wal, i915_reg_t reg, u32 flags)
{
struct i915_wa wa = {
.reg = reg
@@ -990,9 +990,16 @@ whitelist_reg(struct i915_wa_list *wal, i915_reg_t reg)
if (GEM_DEBUG_WARN_ON(wal->count >= RING_MAX_NONPRIV_SLOTS))
return;
+ wa.reg.reg |= flags;
_wa_add(wal, );
}
+static void
+whitelist_reg(struct i915_wa_list *wal, i915_reg_t reg)
+{
+ whitelist_reg_ext(wal, reg, RING_FORCE_TO_NONPRIV_RW);
+}
+
static void gen9_whitelist_build(struct i915_wa_list *w)
{
/* WaVFEStateAfterPipeControlwithMediaStateClear:skl,bxt,glk,cfl */
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 0/3] Send a hotplug when edid changes
On Tue, Sep 03, 2019 at 11:49:23AM +, Lisovskiy, Stanislav wrote: > On Tue, 2019-09-03 at 11:40 +0200, Daniel Vetter wrote: > > > > > > In fact I was wrong - when it worked, it was using exactly those > > > > patches :). With clean drm-tip - it seems to work ocassionally > > > > and it > > > > doesn't update the actual display edid and other stuff, so even > > > > when > > > > displays are changed we still see the old info/edid from > > > > userspace. > > > > > > > > We always get a hpd irq when suspend/resume however it doesn't > > > > always > > > > result in uevent being sent. So there is a real need in those > > > > patches. > > > > > > > > > > Just decided to "ping" this discussion again. The issue is already > > > some > > > years old and still nothing is fixed. I do agree that may be > > > something > > > needs to be fixed/changed here in those patches, but something must > > > be > > > agreed at least I guess, as discussions themself do not fix bugs. > > > Currently those patches address a particular issue which occurs, if > > > display is changed during suspend. > > > On ocassional basis, userspace might not get a hotplug event at > > > all, > > > causing different kind of problems(like wrong mode set on display > > > or > > > diaply not working at all). Also some kms_chamelium hotplug tests > > > fail > > > because of that. > > > > I still think we'll long-term regret this if we just duct-tape more > > stuff > > on top, instead of giving userspace a more informative uevent. This > > will > > send more uevents to userspace, so maybe then userspace tries to > > filter > > more and be clever, which never works, and we're back to tears. > > But here we actually do need a uevent as currently we don't get any at > all, if edid changes during suspend. If userspace will try to filter > this out - it's just stupid, however we still need to do things > correctly. > > > > > Anyway, on the approach itself: It's extremely i915 specific, and it > > requires that all drivers roll out drm_edid_equal checks and not > > forget to > > increment the epoch counter. > > > > > What I had in mind is that when we set the edid for a connector with > > drm_connector_update_edid_property() or whatever, then the epoch > > counter > > would auto-increment if anything has changed. Similarly (long-term > > idea at > > least) if anything important with DP registers has changed. > > > > Can't we do that, instead of this sub-optimal solution of requiring > > all > > drivers to roll out lots of code? > > 1) We update edid in intel_dp_set_edid, which is called from > intel_dp_detect(drm_connector_helper_funcs->detect_ctx hook) which is > called from drm_helper_probe_detect. That one is called either from > specific intel_encoder->hotplug hook in i915_hotplug_work_func or by > userspace request during reprobe. > > 2) Previously we were simply updating edid in intel_dp_set_edid without > caring if it is the same or not and hotplug event was sent only once > connection_status had changed. > > 3) drm_connector_update_edid_property is called from connector- > >get_modes hook(lets say intel_dp_get_modes fo dp) however it simply > uses results of > drm_helper_probe_detect so without actual comparison it would not be > able to detect if we really need to update epoch_counter or not. > > Because as I said currently intel_dp_set_edid simply assigns it without > checking, so that way you will get epoch_counter updated every time, > i.e exactly what you wanted to avoid here. > > So we really need someway to determine if edid had changed, instead of > simply assigning it all the time - that is why I had to make this > function. update_edid is the thing which changes the userspace visible edid. We can check there with the previous userspace visible edid, and if it's different, increase the epoch counter. If we never call update_edid then userspace won't see the changed edid (it might see the changed mode list or whatever), so doing that is pretty much a requirement for correctness. The higher levels should notice the epoch counter change (you might not have captured all of them, there's a bunch between ioctl, poll worker and sysfs iirc), and send out the uevent. Why does that not work? -Daniel > > Cheers, > > Stanislav > > > > -Daniel > > > > > > > > > > > > > > > > > > > > > > - Stanislav > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Stanislav > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, Daniel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Stanislav > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Daniel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Stanislav Lisovskiy (3): > > > > > > > > > > > > drm: Add helper to compare edids. > > > > > > > > > > > > drm: Introduce change counter to drm_connector > > > > > > > > > > > > drm/i915: Send hotplug event if edid had > > > > > > > >
Re: [Intel-gfx] [PATCH] drm/vblank: Document and fix vblank count barrier semantics
On Tue, Sep 03, 2019 at 11:17:12AM -0400, Rodrigo Siqueira wrote:
> Hi, thanks for the explanation.
>
> I noticed that I forgot to add my r-b.
>
> Reviewed-by: Rodrigo Siqueira
Uh I just pushed, so can't add your r-b now :-/
Sry.
-Daniel
>
> On 09/03, Daniel Vetter wrote:
> > On Tue, Sep 03, 2019 at 08:47:03AM -0400, Rodrigo Siqueira wrote:
> > > Hi Daniel,
> > >
> > > All the series look really good for me. I just have some few questions
> > > here.
> > >
> > > On 07/23, Daniel Vetter wrote:
> > > > Noticed while reviewing code. I'm not sure whether this might or might
> > > > not explain some of the missed vblank hilarity we've been seeing. I
> > >
> > > I have to admit that I'm a little bit confused about the "missed vblank
> > > hilarity we've been seeing". Could you elaborate a little bit more about
> > > this problem in the commit message?
> >
> > We've had various reports on various drivers that hw vblanks seem to get
> > lost and the driver stuck on vblank waits. I think most of those where
> > just driver bugs, but could be also that there's some issues in the vblank
> > core.
> >
> > > Additionally, how about break this commit in two? One dedicated to the
> > > barriers
> > > and the atomic64, and the other related to the documentation?
> > >
> > > > think those all go through the vblank completion event, which has
> > > > unconditional barriers - it always takes the spinlock. Therefore no
> > > > cc stable.
> > > >
> > > > v2:
> > > > - Barrriers are hard, put them in in the right order (Chris).
> > > > - Improve the comments a bit.
> > > >
> > > > v3:
> > > >
> > > > Ville noticed that on 32bit we might be breaking up the load/stores,
> > > > now that the vblank counter has been switched over to be 64 bit. Fix
> > > > that up by switching to atomic64_t. This this happens so rarely in
> > > > practice I figured no need to cc: stable ...
> > > >
> > > > Cc: Ville Syrjälä
> > > > Cc: Keith Packard
> > > > References: 570e86963a51 ("drm: Widen vblank count to 64-bits [v3]")
> > > > Cc: Rodrigo Siqueira
> > > > Cc: Chris Wilson
> > > > Signed-off-by: Daniel Vetter
> > > > ---
> > > > drivers/gpu/drm/drm_vblank.c | 45
> > > > include/drm/drm_vblank.h | 15 ++--
> > > > 2 files changed, 54 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> > > > index 603ab105125d..03e37bceac9c 100644
> > > > --- a/drivers/gpu/drm/drm_vblank.c
> > > > +++ b/drivers/gpu/drm/drm_vblank.c
> > > > @@ -107,7 +107,7 @@ static void store_vblank(struct drm_device *dev,
> > > > unsigned int pipe,
> > > >
> > > > write_seqlock(>seqlock);
> > > > vblank->time = t_vblank;
> > > > - vblank->count += vblank_count_inc;
> > > > + atomic64_add(vblank_count_inc, >count);
> > > > write_sequnlock(>seqlock);
> > > > }
> > > >
> > > > @@ -273,7 +273,8 @@ static void drm_update_vblank_count(struct
> > > > drm_device *dev, unsigned int pipe,
> > > >
> > > > DRM_DEBUG_VBL("updating vblank count on crtc %u:"
> > > > " current=%llu, diff=%u, hw=%u hw_last=%u\n",
> > > > - pipe, vblank->count, diff, cur_vblank,
> > > > vblank->last);
> > > > + pipe, atomic64_read(>count), diff,
> > > > + cur_vblank, vblank->last);
> > > >
> > > > if (diff == 0) {
> > > > WARN_ON_ONCE(cur_vblank != vblank->last);
> > > > @@ -295,11 +296,23 @@ static void drm_update_vblank_count(struct
> > > > drm_device *dev, unsigned int pipe,
> > > > static u64 drm_vblank_count(struct drm_device *dev, unsigned int pipe)
> > > > {
> > > > struct drm_vblank_crtc *vblank = >vblank[pipe];
> > > > + u64 count;
> > > >
> > > > if (WARN_ON(pipe >= dev->num_crtcs))
> > > > return 0;
> > > >
> > > > - return vblank->count;
> > > > + count = atomic64_read(>count);
> > > > +
> > > > + /*
> > > > +* This read barrier corresponds to the implicit write barrier
> > > > of the
> > > > +* write seqlock in store_vblank(). Note that this is the only
> > > > place
> > > > +* where we need an explicit barrier, since all other access
> > > > goes
> > > > +* through drm_vblank_count_and_time(), which already has the
> > > > required
> > > > +* read barrier curtesy of the read seqlock.
> > > > +*/
> > > > + smp_rmb();
> > >
> > > I think I did not get all the idea behind the smp_rmb() in this function.
> > > FWIU,
> > > smp_xxx are used for preventing race conditions in a multiprocessor
> > > system,
> > > right? In this sense, I can presume that this change can bring benefits
> > > for
> > > VKMS or any other virtual driver; on the other hand, this will not bring
> > > any
> > > advantage on real drivers like i915 and amdgpu since these devices are not
> > > related with smp
[Intel-gfx] [PATCH] Revert "drm/i915: Fix DP-MST crtc_mask"
From: Ville Syrjälä This reverts commit 4eaceea3a00f8e936a7f48dcd0c975a57f88930f. Several userspace clients (modesetting ddx and mutter+wayland at least) handle encoder.possible_crtcs incorrectly. What they essentially do is the following: possible_crtcs = ~0; for_each_possible_encoder(connector) possible_crtcs &= encoder->possible_crtcs; Ie. they calculate the intersection of the possible_crtcs for the connector when they really should be calculating the union instead. In our case each MST encoder now has just one unique bit set, and so the intersection is always zero. The end result is that MST connectors can't be lit up because no crtc can be found to drive them. I've submitted a fix for the modesetting ddx [1], and complained on #wayland about mutter, so hopefully the situation will improve in the future. In the meantime we have regression, and so must go back to the old way of misconfiguring possible_crtcs in the kernel. [1] https://gitlab.freedesktop.org/xorg/xserver/merge_requests/277 Cc: Jonas Ådahl Cc: Stanislav Lisovskiy Cc: Lionel Landwerlin Cc: Dhinakaran Pandiyan Cc: Lucas De Marchi Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111507 Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c b/drivers/gpu/drm/i915/display/intel_dp_mst.c index 6df240a01b8c..37366f81255b 100644 --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c @@ -615,7 +615,7 @@ intel_dp_create_fake_mst_encoder(struct intel_digital_port *intel_dig_port, enum intel_encoder->type = INTEL_OUTPUT_DP_MST; intel_encoder->power_domain = intel_dig_port->base.power_domain; intel_encoder->port = intel_dig_port->base.port; - intel_encoder->crtc_mask = BIT(pipe); + intel_encoder->crtc_mask = 0x7; intel_encoder->cloneable = 0; intel_encoder->compute_config = intel_dp_mst_compute_config; -- 2.21.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/21] drm/i915: Refresh the errno to vmf_fault translations
On 02/09/2019 7.02, Chris Wilson wrote:
> It's been a long time since we accidentally reported -EIO upon wedging,
> it can now only be generated by failure to swap in a page.
>
Reviewed-by: Abdiel Janulgue
> Signed-off-by: Chris Wilson
> Cc: Abdiel Janulgue
> ---
> drivers/gpu/drm/i915/gem/i915_gem_mman.c | 39 +---
> 1 file changed, 15 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> index 261c9bd83f51..82db2b783123 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> @@ -287,6 +287,9 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
> view.type = I915_GGTT_VIEW_PARTIAL;
> vma = i915_gem_object_ggtt_pin(obj, , 0, 0, flags);
> }
> +
> + /* The entire mappable GGTT is pinned? Unexpected! */
> + GEM_BUG_ON(vma == ERR_PTR(-ENOSPC));
> }
> if (IS_ERR(vma)) {
> ret = PTR_ERR(vma);
> @@ -333,23 +336,19 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
> i915_gem_object_unpin_pages(obj);
> err:
> switch (ret) {
> - case -EIO:
> - /*
> - * We eat errors when the gpu is terminally wedged to avoid
> - * userspace unduly crashing (gl has no provisions for mmaps to
> - * fail). But any other -EIO isn't ours (e.g. swap in failure)
> - * and so needs to be reported.
> - */
> - if (!intel_gt_is_wedged(ggtt->vm.gt))
> - return VM_FAULT_SIGBUS;
> - /* else, fall through */
> - case -EAGAIN:
> - /*
> - * EAGAIN means the gpu is hung and we'll wait for the error
> - * handler to reset everything when re-faulting in
> - * i915_mutex_lock_interruptible.
> - */
> + default:
> + WARN_ONCE(ret, "unhandled error in %s: %i\n", __func__, ret);
> + /* fallthrough */
> + case -EIO: /* shmemfs failure from swap device */
> + case -EFAULT: /* purged object */
> + return VM_FAULT_SIGBUS;
> +
> + case -ENOSPC: /* shmemfs allocation failure */
> + case -ENOMEM: /* our allocation failure */
> + return VM_FAULT_OOM;
> +
> case 0:
> + case -EAGAIN:
> case -ERESTARTSYS:
> case -EINTR:
> case -EBUSY:
> @@ -358,14 +357,6 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
>* already did the job.
>*/
> return VM_FAULT_NOPAGE;
> - case -ENOMEM:
> - return VM_FAULT_OOM;
> - case -ENOSPC:
> - case -EFAULT:
> - return VM_FAULT_SIGBUS;
> - default:
> - WARN_ONCE(ret, "unhandled error in %s: %i\n", __func__, ret);
> - return VM_FAULT_SIGBUS;
> }
> }
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 3/6] i915/gem_tiled_swapped: Tweak mlocked size
Hi Chris, > - num_threads = gem_available_fences(fd); > + num_threads = gem_available_fences(fd) + 1; any reason for this? Andi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 2/6] i915/gem_ctx_shared: Prebind both context images
Hi Chris, On Mon, Sep 02, 2019 at 05:15:44AM +0100, Chris Wilson wrote: > If we are using an aliasing-ppgtt, the context images are in the same > virtual address space as our target objects. We have to be careful that > cloning and using a new context does not evict our unreferenced target > object. To avoid that, we first bind both context images while creating > the hole in the address space to ensure that the hole is still available > later on. > > Signed-off-by: Chris Wilson > --- > tests/i915/gem_ctx_shared.c | 15 +++ > 1 file changed, 11 insertions(+), 4 deletions(-) > > diff --git a/tests/i915/gem_ctx_shared.c b/tests/i915/gem_ctx_shared.c > index b073bdfc9..c9e7b8a1a 100644 > --- a/tests/i915/gem_ctx_shared.c > +++ b/tests/i915/gem_ctx_shared.c > @@ -191,6 +191,7 @@ static void exec_shared_gtt(int i915, unsigned int ring) > .buffer_count = 1, > .flags = ring, > }; > + uint32_t clone; > uint32_t scratch, *s; > uint32_t batch, cs[16]; > uint64_t offset; > @@ -199,13 +200,18 @@ static void exec_shared_gtt(int i915, unsigned int ring) > gem_require_ring(i915, ring); > igt_require(gem_can_store_dword(i915, ring)); > > + clone = gem_context_clone(i915, 0, I915_CONTEXT_CLONE_VM, 0); > + > /* Find a hole big enough for both objects later */ > - scratch = gem_create(i915, 16384); > + scratch = gem_create(i915, 64<<10); I guess this is a leftover, right? Reviewed-by: Andi Shyti Andi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/vblank: Document and fix vblank count barrier semantics
Hi, thanks for the explanation.
I noticed that I forgot to add my r-b.
Reviewed-by: Rodrigo Siqueira
On 09/03, Daniel Vetter wrote:
> On Tue, Sep 03, 2019 at 08:47:03AM -0400, Rodrigo Siqueira wrote:
> > Hi Daniel,
> >
> > All the series look really good for me. I just have some few questions
> > here.
> >
> > On 07/23, Daniel Vetter wrote:
> > > Noticed while reviewing code. I'm not sure whether this might or might
> > > not explain some of the missed vblank hilarity we've been seeing. I
> >
> > I have to admit that I'm a little bit confused about the "missed vblank
> > hilarity we've been seeing". Could you elaborate a little bit more about
> > this problem in the commit message?
>
> We've had various reports on various drivers that hw vblanks seem to get
> lost and the driver stuck on vblank waits. I think most of those where
> just driver bugs, but could be also that there's some issues in the vblank
> core.
>
> > Additionally, how about break this commit in two? One dedicated to the
> > barriers
> > and the atomic64, and the other related to the documentation?
> >
> > > think those all go through the vblank completion event, which has
> > > unconditional barriers - it always takes the spinlock. Therefore no
> > > cc stable.
> > >
> > > v2:
> > > - Barrriers are hard, put them in in the right order (Chris).
> > > - Improve the comments a bit.
> > >
> > > v3:
> > >
> > > Ville noticed that on 32bit we might be breaking up the load/stores,
> > > now that the vblank counter has been switched over to be 64 bit. Fix
> > > that up by switching to atomic64_t. This this happens so rarely in
> > > practice I figured no need to cc: stable ...
> > >
> > > Cc: Ville Syrjälä
> > > Cc: Keith Packard
> > > References: 570e86963a51 ("drm: Widen vblank count to 64-bits [v3]")
> > > Cc: Rodrigo Siqueira
> > > Cc: Chris Wilson
> > > Signed-off-by: Daniel Vetter
> > > ---
> > > drivers/gpu/drm/drm_vblank.c | 45
> > > include/drm/drm_vblank.h | 15 ++--
> > > 2 files changed, 54 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> > > index 603ab105125d..03e37bceac9c 100644
> > > --- a/drivers/gpu/drm/drm_vblank.c
> > > +++ b/drivers/gpu/drm/drm_vblank.c
> > > @@ -107,7 +107,7 @@ static void store_vblank(struct drm_device *dev,
> > > unsigned int pipe,
> > >
> > > write_seqlock(>seqlock);
> > > vblank->time = t_vblank;
> > > - vblank->count += vblank_count_inc;
> > > + atomic64_add(vblank_count_inc, >count);
> > > write_sequnlock(>seqlock);
> > > }
> > >
> > > @@ -273,7 +273,8 @@ static void drm_update_vblank_count(struct drm_device
> > > *dev, unsigned int pipe,
> > >
> > > DRM_DEBUG_VBL("updating vblank count on crtc %u:"
> > > " current=%llu, diff=%u, hw=%u hw_last=%u\n",
> > > - pipe, vblank->count, diff, cur_vblank, vblank->last);
> > > + pipe, atomic64_read(>count), diff,
> > > + cur_vblank, vblank->last);
> > >
> > > if (diff == 0) {
> > > WARN_ON_ONCE(cur_vblank != vblank->last);
> > > @@ -295,11 +296,23 @@ static void drm_update_vblank_count(struct
> > > drm_device *dev, unsigned int pipe,
> > > static u64 drm_vblank_count(struct drm_device *dev, unsigned int pipe)
> > > {
> > > struct drm_vblank_crtc *vblank = >vblank[pipe];
> > > + u64 count;
> > >
> > > if (WARN_ON(pipe >= dev->num_crtcs))
> > > return 0;
> > >
> > > - return vblank->count;
> > > + count = atomic64_read(>count);
> > > +
> > > + /*
> > > + * This read barrier corresponds to the implicit write barrier of the
> > > + * write seqlock in store_vblank(). Note that this is the only place
> > > + * where we need an explicit barrier, since all other access goes
> > > + * through drm_vblank_count_and_time(), which already has the required
> > > + * read barrier curtesy of the read seqlock.
> > > + */
> > > + smp_rmb();
> >
> > I think I did not get all the idea behind the smp_rmb() in this function.
> > FWIU,
> > smp_xxx are used for preventing race conditions in a multiprocessor system,
> > right? In this sense, I can presume that this change can bring benefits for
> > VKMS or any other virtual driver; on the other hand, this will not bring any
> > advantage on real drivers like i915 and amdgpu since these devices are not
> > related with smp stuff, right?
>
> smp or not smp is about the cpu your driver is running on, not anything to
> do with the device hardware itself. And nowadays there's simply no
> single-threaded processors anymore, everything has at least 2 cores (even
> the tiniest soc). So yeah, this matters for everyone.
>
> smp_* functions only get compiled out to nothing if you have CONFIG_UP
> (which means only 1 cpu core with only 1 SMT thread is supported).
>
> And yeah correctly placing smp barriers is Real Hard Stuff (tm).
> -Daniel
>
>
> > Thanks
> >
> > > +
> > > + return
Re: [Intel-gfx] [PATCH 3/3] drm/vkms: Reduce critical section in vblank_simulate
On Tue, Sep 03, 2019 at 08:50:29AM -0400, Rodrigo Siqueira wrote:
> Thanks for this patch! It looks good for me.
>
> Reviewed-by: Rodrigo Siqueira
Thanks for taking a look at all this, entire series merged. With the r-b
from Ville on patch 1, but I'm happy to further discuss your questions.
Plus I augmented the commit message a bit for patch 1 to explain the
missed vblank story better.
-Daniel
>
> On 07/19, Daniel Vetter wrote:
> > We can reduce the critical section in vkms_vblank_simulate under
> > output->lock quite a lot:
> >
> > - hrtimer_forward_now just needs to be ordered correctly wrt
> > drm_crtc_handle_vblank. We already access the hrtimer timestamp
> > without locks. While auditing that I noticed that we don't correctly
> > annotate the read there, so sprinkle a READ_ONCE to make sure the
> > compiler doesn't do anything foolish.
> >
> > - drm_crtc_handle_vblank must stay under the lock to avoid races with
> > drm_crtc_arm_vblank_event.
> >
> > - The access to vkms_ouptut->crc_state also must stay under the lock.
> >
> > - next problem is making sure the output->state structure doesn't get
> > freed too early. First we rely on a given hrtimer being serialized:
> > If we call drm_crtc_handle_vblank, then we are guaranteed that the
> > previous call to vkms_vblank_simulate has completed. The other side
> > of the coin is that the atomic updates waits for the vblank to
> > happen before it releases the old state. Both taken together means
> > that by the time the atomic update releases the old state, the
> > hrtimer won't access it anymore (it might be accessing the new state
> > at the same time, but that's ok).
> >
> > - state is invariant, except the few fields separate protected by
> > state->crc_lock. So no need to hold the lock for that.
> >
> > - finally the queue_work. We need to make sure there's no races with
> > the flush_work, i.e. when we call flush_work we need to guarantee
> > that the hrtimer can't requeue the work again. This is guaranteed by
> > the same vblank/hrtimer ordering guarantees like the reasoning above
> > why state won't be freed too early: flush_work on the old state is
> > called after wait_for_flip_done in the atomic commit code.
> >
> > Therefore we can also move everything after the output->crc_state out
> > of the critical section.
> >
> > Motivated by suggestions from Rodrigo.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Rodrigo Siqueira
> > Cc: Haneen Mohammed
> > Cc: Daniel Vetter
> > ---
> > drivers/gpu/drm/vkms/vkms_crtc.c | 9 -
> > 1 file changed, 4 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c
> > b/drivers/gpu/drm/vkms/vkms_crtc.c
> > index 927dafaebc76..74f703b8d22a 100644
> > --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> > +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> > @@ -16,17 +16,18 @@ static enum hrtimer_restart vkms_vblank_simulate(struct
> > hrtimer *timer)
> > u64 ret_overrun;
> > bool ret;
> >
> > - spin_lock(>lock);
> > -
> > ret_overrun = hrtimer_forward_now(>vblank_hrtimer,
> > output->period_ns);
> > WARN_ON(ret_overrun != 1);
> >
> > + spin_lock(>lock);
> > ret = drm_crtc_handle_vblank(crtc);
> > if (!ret)
> > DRM_ERROR("vkms failure on handling vblank");
> >
> > state = output->composer_state;
> > + spin_unlock(>lock);
> > +
> > if (state && output->composer_enabled) {
> > u64 frame = drm_crtc_accurate_vblank_count(crtc);
> >
> > @@ -48,8 +49,6 @@ static enum hrtimer_restart vkms_vblank_simulate(struct
> > hrtimer *timer)
> > DRM_DEBUG_DRIVER("Composer worker already queued\n");
> > }
> >
> > - spin_unlock(>lock);
> > -
> > return HRTIMER_RESTART;
> > }
> >
> > @@ -85,7 +84,7 @@ bool vkms_get_vblank_timestamp(struct drm_device *dev,
> > unsigned int pipe,
> > struct vkms_output *output = >output;
> > struct drm_vblank_crtc *vblank = >vblank[pipe];
> >
> > - *vblank_time = output->vblank_hrtimer.node.expires;
> > + *vblank_time = READ_ONCE(output->vblank_hrtimer.node.expires);
> >
> > if (WARN_ON(*vblank_time == vblank->time))
> > return true;
> > --
> > 2.22.0
> >
>
> --
> Rodrigo Siqueira
> Software Engineer, Advanced Micro Devices (AMD)
> https://siqueira.tech
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/vkms: Use wait_for_flip_done
On Tue, Sep 03, 2019 at 08:49:06AM -0400, Rodrigo Siqueira wrote:
> On 07/19, Daniel Vetter wrote:
> > It's the recommended version, wait_for_vblanks is a bit a hacky
> > interim thing that predates all the flip_done tracking. It's
> > unfortunately still the default ...
>
> Just one question, is it safe to replace drm_atomic_helper_wait_for_vblanks by
> drm_atomic_helper_wait_for_flip_done? I noticed that only six drivers use
> these
> functions; they are:
>
> * atmel-hlcdc
> * mediatek
> * msm
> * tegra
> * tilcdc
> * virtio
>
> If we change these drivers, can we drop the helper
> drm_atomic_helper_wait_for_vblanks?
Yes, but there might be a tiny behaviour change, that's why I haven't just
made it the default.
Also note that wait_for_vblanks is still the default in the
atomic_commit_tail (seee drm_atomic_helper_commit_tail), so there's a pile
more drivers using this implicitly.
But yeah would be really great to fix that all up, since I think
wait_for_flip_done is the better function. Maybe a todo.rst? Or perhaps we
should at least do it for atomic helpers, and just see what breaks? As a
start for this conversion.
> Reviewed-by: Rodrigo Siqueira
Thanks, Daniel
>
> Thanks
>
> > Signed-off-by: Daniel Vetter
> > Cc: Rodrigo Siqueira
> > Cc: Haneen Mohammed
> > Cc: Daniel Vetter
> > ---
> > drivers/gpu/drm/vkms/vkms_drv.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/vkms/vkms_drv.c
> > b/drivers/gpu/drm/vkms/vkms_drv.c
> > index 44ab9f8ef8be..80524a22412a 100644
> > --- a/drivers/gpu/drm/vkms/vkms_drv.c
> > +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> > @@ -83,7 +83,7 @@ static void vkms_atomic_commit_tail(struct
> > drm_atomic_state *old_state)
> >
> > drm_atomic_helper_commit_hw_done(old_state);
> >
> > - drm_atomic_helper_wait_for_vblanks(dev, old_state);
> > + drm_atomic_helper_wait_for_flip_done(dev, old_state);
> >
> > for_each_old_crtc_in_state(old_state, crtc, old_crtc_state, i) {
> > struct vkms_crtc_state *vkms_state =
> > --
> > 2.22.0
> >
>
> --
> Rodrigo Siqueira
> Software Engineer, Advanced Micro Devices (AMD)
> https://siqueira.tech
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/vblank: Document and fix vblank count barrier semantics
On Tue, Sep 03, 2019 at 08:47:03AM -0400, Rodrigo Siqueira wrote:
> Hi Daniel,
>
> All the series look really good for me. I just have some few questions
> here.
>
> On 07/23, Daniel Vetter wrote:
> > Noticed while reviewing code. I'm not sure whether this might or might
> > not explain some of the missed vblank hilarity we've been seeing. I
>
> I have to admit that I'm a little bit confused about the "missed vblank
> hilarity we've been seeing". Could you elaborate a little bit more about
> this problem in the commit message?
We've had various reports on various drivers that hw vblanks seem to get
lost and the driver stuck on vblank waits. I think most of those where
just driver bugs, but could be also that there's some issues in the vblank
core.
> Additionally, how about break this commit in two? One dedicated to the
> barriers
> and the atomic64, and the other related to the documentation?
>
> > think those all go through the vblank completion event, which has
> > unconditional barriers - it always takes the spinlock. Therefore no
> > cc stable.
> >
> > v2:
> > - Barrriers are hard, put them in in the right order (Chris).
> > - Improve the comments a bit.
> >
> > v3:
> >
> > Ville noticed that on 32bit we might be breaking up the load/stores,
> > now that the vblank counter has been switched over to be 64 bit. Fix
> > that up by switching to atomic64_t. This this happens so rarely in
> > practice I figured no need to cc: stable ...
> >
> > Cc: Ville Syrjälä
> > Cc: Keith Packard
> > References: 570e86963a51 ("drm: Widen vblank count to 64-bits [v3]")
> > Cc: Rodrigo Siqueira
> > Cc: Chris Wilson
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_vblank.c | 45
> > include/drm/drm_vblank.h | 15 ++--
> > 2 files changed, 54 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> > index 603ab105125d..03e37bceac9c 100644
> > --- a/drivers/gpu/drm/drm_vblank.c
> > +++ b/drivers/gpu/drm/drm_vblank.c
> > @@ -107,7 +107,7 @@ static void store_vblank(struct drm_device *dev,
> > unsigned int pipe,
> >
> > write_seqlock(>seqlock);
> > vblank->time = t_vblank;
> > - vblank->count += vblank_count_inc;
> > + atomic64_add(vblank_count_inc, >count);
> > write_sequnlock(>seqlock);
> > }
> >
> > @@ -273,7 +273,8 @@ static void drm_update_vblank_count(struct drm_device
> > *dev, unsigned int pipe,
> >
> > DRM_DEBUG_VBL("updating vblank count on crtc %u:"
> > " current=%llu, diff=%u, hw=%u hw_last=%u\n",
> > - pipe, vblank->count, diff, cur_vblank, vblank->last);
> > + pipe, atomic64_read(>count), diff,
> > + cur_vblank, vblank->last);
> >
> > if (diff == 0) {
> > WARN_ON_ONCE(cur_vblank != vblank->last);
> > @@ -295,11 +296,23 @@ static void drm_update_vblank_count(struct drm_device
> > *dev, unsigned int pipe,
> > static u64 drm_vblank_count(struct drm_device *dev, unsigned int pipe)
> > {
> > struct drm_vblank_crtc *vblank = >vblank[pipe];
> > + u64 count;
> >
> > if (WARN_ON(pipe >= dev->num_crtcs))
> > return 0;
> >
> > - return vblank->count;
> > + count = atomic64_read(>count);
> > +
> > + /*
> > +* This read barrier corresponds to the implicit write barrier of the
> > +* write seqlock in store_vblank(). Note that this is the only place
> > +* where we need an explicit barrier, since all other access goes
> > +* through drm_vblank_count_and_time(), which already has the required
> > +* read barrier curtesy of the read seqlock.
> > +*/
> > + smp_rmb();
>
> I think I did not get all the idea behind the smp_rmb() in this function.
> FWIU,
> smp_xxx are used for preventing race conditions in a multiprocessor system,
> right? In this sense, I can presume that this change can bring benefits for
> VKMS or any other virtual driver; on the other hand, this will not bring any
> advantage on real drivers like i915 and amdgpu since these devices are not
> related with smp stuff, right?
smp or not smp is about the cpu your driver is running on, not anything to
do with the device hardware itself. And nowadays there's simply no
single-threaded processors anymore, everything has at least 2 cores (even
the tiniest soc). So yeah, this matters for everyone.
smp_* functions only get compiled out to nothing if you have CONFIG_UP
(which means only 1 cpu core with only 1 SMT thread is supported).
And yeah correctly placing smp barriers is Real Hard Stuff (tm).
-Daniel
> Thanks
>
> > +
> > + return count;
> > }
> >
> > /**
> > @@ -764,6 +777,14 @@ drm_get_last_vbltimestamp(struct drm_device *dev,
> > unsigned int pipe,
> > * vblank interrupt (since it only reports the software vblank counter),
> > see
> > * drm_crtc_accurate_vblank_count() for such use-cases.
> > *
> > + * Note that for a given vblank
[Intel-gfx] ✓ Fi.CI.BAT: success for i915/gem_ctx_shared: Prebind both context images
== Series Details ==
Series: i915/gem_ctx_shared: Prebind both context images
URL : https://patchwork.freedesktop.org/series/66171/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6827 -> IGTPW_3413
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/66171/revisions/1/mbox/
Known issues
Here are the changes found in IGTPW_3413 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_close_race@basic-process:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6827/fi-icl-u3/igt@gem_close_r...@basic-process.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3413/fi-icl-u3/igt@gem_close_r...@basic-process.html
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: [PASS][3] -> [INCOMPLETE][4] ([fdo#107718])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6827/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3413/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
Possible fixes
* igt@gem_ctx_create@basic-files:
- {fi-icl-guc}: [INCOMPLETE][5] ([fdo#107713] / [fdo#109100]) ->
[PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6827/fi-icl-guc/igt@gem_ctx_cre...@basic-files.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3413/fi-icl-guc/igt@gem_ctx_cre...@basic-files.html
* igt@gem_ctx_switch@legacy-render:
- fi-bxt-dsi: [INCOMPLETE][7] ([fdo#103927] / [fdo#111381]) ->
[PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6827/fi-bxt-dsi/igt@gem_ctx_swi...@legacy-render.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3413/fi-bxt-dsi/igt@gem_ctx_swi...@legacy-render.html
* igt@i915_selftest@live_execlists:
- fi-skl-gvtdvm: [DMESG-FAIL][9] ([fdo#08]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6827/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3413/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: [DMESG-WARN][11] ([fdo#102614]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6827/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3413/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#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#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100
[fdo#08]: https://bugs.freedesktop.org/show_bug.cgi?id=08
[fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381
Participating hosts (53 -> 46)
--
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y
fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* IGT: IGT_5164 -> IGTPW_3413
CI-20190529: 20190529
CI_DRM_6827: 0e106feacb0b1a642b86609a4cdfa7e37bf3065d @
git://anongit.freedesktop.org/gfx-ci/linux
IGTPW_3413: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3413/
IGT_5164: 90babd3f12707dfabaa58bb18f6b8e22636b6895 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3413/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/2] linux/kernel.h: add yesno(), onoff(), enableddisabled(), plural() helpers
== Series Details == Series: series starting with [1/2] linux/kernel.h: add yesno(), onoff(), enableddisabled(), plural() helpers URL : https://patchwork.freedesktop.org/series/66170/ State : failure == Summary == Applying: linux/kernel.h: add yesno(), onoff(), enableddisabled(), plural() helpers Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_utils.h Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/i915_utils.h CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/i915_utils.h error: Failed to merge in the changes. hint: Use 'git am --show-current-patch' to see the failed patch Patch failed at 0001 linux/kernel.h: add yesno(), onoff(), enableddisabled(), plural() helpers 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 v4 6/7] drm/i915/dp: Program an Infoframe SDP Header and DB for HDR Static Metadata
>-Original Message-
>From: Mun, Gwan-gyeong
>Sent: Tuesday, September 3, 2019 2:43 PM
>To: intel-gfx@lists.freedesktop.org
>Cc: dri-de...@lists.freedesktop.org; Shankar, Uma ;
>Sharma, Shashank ; ville.syrj...@linux.intel.com
>Subject: [PATCH v4 6/7] drm/i915/dp: Program an Infoframe SDP Header and DB for
>HDR Static Metadata
>
>Function intel_dp_setup_hdr_metadata_infoframe_sdp handles Infoframe SDP
>header and data block setup for HDR Static Metadata. It enables writing of HDR
>metadata infoframe SDP to panel. Support for HDR video was introduced in
>DisplayPort 1.4. It implements the CTA-861-G standard for transport of static
>HDR
>metadata. The HDR Metadata will be provided by userspace compositors, based on
>blending policies and passed to the driver through a blob property.
>
>Because each of GEN11 and prior GEN11 have different register size for HDR
>Metadata Infoframe SDP packet, it adds and uses different register size.
>
>Setup Infoframe SDP header and data block in function
>intel_dp_setup_hdr_metadata_infoframe_sdp for HDR Static Metadata as per dp 1.4
>spec and CTA-861-F spec.
>As per DP 1.4 spec, 2.2.2.5 SDP Formats. It enables Dynamic Range and Mastering
>Infoframe for HDR content, which is defined in CTA-861-F spec.
>According to DP 1.4 spec and CEA-861-F spec Table 5, in order to transmit
>static HDR
>metadata, we have to use Non-audio INFOFRAME SDP v1.3.
>
>++---+
>| [ Packet Type Value ] | [ Packet Type ] |
>++---+
>| 80h + Non-audio INFOFRAME Type | CEA-861-F Non-audio INFOFRAME |
>++---+
>| [Transmission Timing] |
>++
>| As per CEA-861-F for INFOFRAME, including CEA-861.3 within |
>| which Dynamic Range and Mastering INFOFRAME are defined|
>++
>
>v2: Add a missed blank line after function declaration.
>v3: Remove not handled return values from
>intel_dp_setup_hdr_metadata_infoframe_sdp(). [Uma]
Looks good to me.
Reviewed-by: Uma Shankar
>Signed-off-by: Gwan-gyeong Mun
>---
> drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
>drivers/gpu/drm/i915/display/intel_dp.c | 89
>drivers/gpu/drm/i915/display/intel_dp.h | 3 +
> 3 files changed, 93 insertions(+)
>
>diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
>b/drivers/gpu/drm/i915/display/intel_ddi.c
>index 87dc5a19cb7b..111a5c95be85 100644
>--- a/drivers/gpu/drm/i915/display/intel_ddi.c
>+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
>@@ -3612,6 +3612,7 @@ static void intel_enable_ddi_dp(struct intel_encoder
>*encoder,
> intel_edp_backlight_on(crtc_state, conn_state);
> intel_psr_enable(intel_dp, crtc_state);
> intel_dp_vsc_enable(intel_dp, crtc_state, conn_state);
>+ intel_dp_hdr_metadata_enable(intel_dp, crtc_state, conn_state);
> intel_edp_drrs_enable(intel_dp, crtc_state);
>
> if (crtc_state->has_audio)
>diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
>b/drivers/gpu/drm/i915/display/intel_dp.c
>index 9fa107d720ee..7fcc9f28d2e7 100644
>--- a/drivers/gpu/drm/i915/display/intel_dp.c
>+++ b/drivers/gpu/drm/i915/display/intel_dp.c
>@@ -4596,6 +4596,83 @@ intel_dp_setup_vsc_sdp(struct intel_dp *intel_dp,
> crtc_state, DP_SDP_VSC, _sdp, sizeof(vsc_sdp)); }
>
>+static void
>+intel_dp_setup_hdr_metadata_infoframe_sdp(struct intel_dp *intel_dp,
>+const struct intel_crtc_state
>*crtc_state,
>+const struct drm_connector_state
>*conn_state) {
>+ struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
>+ struct drm_i915_private *dev_priv =
>to_i915(intel_dig_port->base.base.dev);
>+ struct dp_sdp infoframe_sdp = {};
>+ struct hdmi_drm_infoframe drm_infoframe = {};
>+ const int infoframe_size = HDMI_INFOFRAME_HEADER_SIZE +
>HDMI_DRM_INFOFRAME_SIZE;
>+ unsigned char buf[HDMI_INFOFRAME_HEADER_SIZE +
>HDMI_DRM_INFOFRAME_SIZE];
>+ ssize_t len;
>+ int ret;
>+
>+ ret = drm_hdmi_infoframe_set_hdr_metadata(_infoframe, conn_state);
>+ if (ret) {
>+ DRM_DEBUG_KMS("couldn't set HDR metadata in infoframe\n");
>+ return;
>+ }
>+
>+ len = hdmi_drm_infoframe_pack_only(_infoframe, buf, sizeof(buf));
>+ if (len < 0) {
>+ DRM_DEBUG_KMS("buffer size is smaller than hdr metadata
>infoframe\n");
>+ return;
>+ }
>+
>+ if (len != infoframe_size) {
>+ DRM_DEBUG_KMS("wrong static hdr metadata size\n");
>+ return;
>+ }
>+
>+ /*
>+ * Set up the infoframe sdp packet for HDR static metadata.
>+ * Prepare VSC Header for SU as
Re: [Intel-gfx] [PATCH v2 5/6] drm/i915/dp: Program an Infoframe SDP Header and DB for HDR Static Metadata
>-Original Message-
>From: Mun, Gwan-gyeong
>Sent: Tuesday, September 3, 2019 10:54 AM
>To: Shankar, Uma ; intel-gfx@lists.freedesktop.org
>Cc: dri-de...@lists.freedesktop.org; Sharma, Shashank
>
>Subject: Re: [PATCH v2 5/6] drm/i915/dp: Program an Infoframe SDP Header and DB
>for HDR Static Metadata
>
>On Tue, 2019-08-27 at 01:14 +0530, Shankar, Uma wrote:
>> > -Original Message-
>> > From: Mun, Gwan-gyeong
>> > Sent: Friday, August 23, 2019 3:23 PM
>> > To: intel-gfx@lists.freedesktop.org
>> > Cc: dri-de...@lists.freedesktop.org; Shankar, Uma <
>> > uma.shan...@intel.com>; Sharma, Shashank
>> > Subject: [PATCH v2 5/6] drm/i915/dp: Program an Infoframe SDP Header
>> > and DB for HDR Static Metadata
>> >
>> > Function intel_dp_setup_hdr_metadata_infoframe_sdp handles Infoframe
>> > SDP header and data block setup for HDR Static Metadata. It enables
>> > writing of HDR metadata infoframe SDP to panel. Support for HDR
>> > video was introduced in DisplayPort 1.4. It implements the CTA-861-G
>> > standard for transport of static HDR metadata. The HDR Metadata will
>> > be provided by userspace compositors, based on blending policies and
>> > passed to the driver through a blob property.
>> >
>> > Because each of GEN11 and prior GEN11 have different register size
>> > for HDR Metadata Infoframe SDP packet, it adds and uses different
>> > register size.
>> >
>> > Setup Infoframe SDP header and data block in function
>> > intel_dp_setup_hdr_metadata_infoframe_sdp for HDR Static Metadata as
>> > per dp 1.4 spec and CTA-861-F spec.
>> > As per DP 1.4 spec, 2.2.2.5 SDP Formats. It enables Dynamic Range
>> > and Mastering Infoframe for HDR content, which is defined in
>> > CTA-861-F spec.
>> > According to DP 1.4 spec and CEA-861-F spec Table 5, in order to
>> > transmit static HDR metadata, we have to use Non-audio INFOFRAME SDP
>> > v1.3.
>> >
>> > ++---+
>> > > [ Packet Type Value ] | [ Packet Type ] |
>> > ++---+
>> > > 80h + Non-audio INFOFRAME Type | CEA-861-F Non-audio INFOFRAME |
>> > ++---+
>> > > [Transmission Timing] |
>> > ++
>> > > As per CEA-861-F for INFOFRAME, including CEA-861.3 within |
>> > > which Dynamic Range and Mastering INFOFRAME are defined|
>> > ++
>> >
>> > v2: Add a missed blank line after function declaration.
>> >
>> > Signed-off-by: Gwan-gyeong Mun
>> > ---
>> > drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
>> > drivers/gpu/drm/i915/display/intel_dp.c | 91
>> >
>> > drivers/gpu/drm/i915/display/intel_dp.h | 3 +
>> > drivers/gpu/drm/i915/i915_reg.h | 1 +
>> > 4 files changed, 96 insertions(+)
>> >
>> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
>> > b/drivers/gpu/drm/i915/display/intel_ddi.c
>> > index 5c42b58c1c2f..9f5bea941bcd 100644
>> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
>> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
>> > @@ -3478,6 +3478,7 @@ static void intel_enable_ddi_dp(struct
>> > intel_encoder *encoder,
>> >intel_edp_backlight_on(crtc_state, conn_state);
>> >intel_psr_enable(intel_dp, crtc_state);
>> >intel_dp_vsc_enable(intel_dp, crtc_state, conn_state);
>> > + intel_dp_hdr_metadata_enable(intel_dp, crtc_state, conn_state);
>> >intel_edp_drrs_enable(intel_dp, crtc_state);
>> >
>> >if (crtc_state->has_audio)
>> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
>> > b/drivers/gpu/drm/i915/display/intel_dp.c
>> > index 7218e159f55d..00da8221eaba 100644
>> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
>> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
>> > @@ -4554,6 +4554,85 @@ intel_dp_setup_vsc_sdp(struct intel_dp
>> > *intel_dp,
>> >crtc_state, DP_SDP_VSC, _sdp, sizeof(vsc_sdp)); }
>> >
>> > +static int
>> > +intel_dp_setup_hdr_metadata_infoframe_sdp(struct intel_dp
>> > *intel_dp,
>> > +const struct intel_crtc_state
>> > *crtc_state,
>> > +const struct
>> > drm_connector_state
>>
>> The return value is not handled, you may convert it as void.
>>
>Okay, I'll remove the return values which is not handled from
>intel_dp_setup_hdr_metadata_infoframe_sdp().
>
>> > *conn_state) {
>> > + struct intel_digital_port *intel_dig_port =
>> > dp_to_dig_port(intel_dp);
>> > + struct drm_i915_private *dev_priv = to_i915(intel_dig_port-
>> > >base.base.dev);
>> > + struct dp_sdp infoframe_sdp = {};
>> > + struct hdmi_drm_infoframe drm_infoframe = {};
>> > + const int infoframe_size = HDMI_INFOFRAME_HEADER_SIZE +
>> > HDMI_DRM_INFOFRAME_SIZE;
>> > + unsigned char buf[HDMI_INFOFRAME_HEADER_SIZE +
>> >
Re: [Intel-gfx] [PATCH v3 0/3] Send a hotplug when edid changes
On Tue, 2019-09-03 at 11:49 +, Lisovskiy, Stanislav wrote: > On Tue, 2019-09-03 at 11:40 +0200, Daniel Vetter wrote: > > > > > > In fact I was wrong - when it worked, it was using exactly > > > > those > > > > patches :). With clean drm-tip - it seems to work ocassionally > > > > and it > > > > doesn't update the actual display edid and other stuff, so even > > > > when > > > > displays are changed we still see the old info/edid from > > > > userspace. > > > > > > > > We always get a hpd irq when suspend/resume however it doesn't > > > > always > > > > result in uevent being sent. So there is a real need in those > > > > patches. > > > > > > > > > > Just decided to "ping" this discussion again. The issue is > > > already > > > some > > > years old and still nothing is fixed. I do agree that may be > > > something > > > needs to be fixed/changed here in those patches, but something > > > must > > > be > > > agreed at least I guess, as discussions themself do not fix bugs. > > > Currently those patches address a particular issue which occurs, > > > if > > > display is changed during suspend. > > > On ocassional basis, userspace might not get a hotplug event at > > > all, > > > causing different kind of problems(like wrong mode set on display > > > or > > > diaply not working at all). Also some kms_chamelium hotplug tests > > > fail > > > because of that. > > > > I still think we'll long-term regret this if we just duct-tape more > > stuff > > on top, instead of giving userspace a more informative uevent. This > > will > > send more uevents to userspace, so maybe then userspace tries to > > filter > > more and be clever, which never works, and we're back to tears. > > But here we actually do need a uevent as currently we don't get any > at > all, if edid changes during suspend. If userspace will try to filter > this out - it's just stupid, however we still need to do things > correctly. > > > > > Anyway, on the approach itself: It's extremely i915 specific, and > > it > > requires that all drivers roll out drm_edid_equal checks and not > > forget to > > increment the epoch counter. > > > > What I had in mind is that when we set the edid for a connector > > with > > drm_connector_update_edid_property() or whatever, then the epoch > > counter > > would auto-increment if anything has changed. Similarly (long-term > > idea at > > least) if anything important with DP registers has changed. > > > > Can't we do that, instead of this sub-optimal solution of requiring > > all > > drivers to roll out lots of code? So once again, just to summarize things: 1) We update edid in intel_dp_set_edid, which is called from intel_dp_detect(drm_connector_helper_funcs->detect_ctx hook) which is called from drm_helper_probe_detect. That one is called either from specific intel_encoder->hotplug hook in i915_hotplug_work_func or by userspace request during reprobe. 2) Currently we are simply updating edid in intel_dp_set_edid without caring if it is the same or not and hotplug event is sent only once connection_status had changed. 3) drm_connector_update_edid_property is called from connector- >get_modes hook(lets say intel_dp_get_modes fo dp) however it simply uses results of drm_helper_probe_detect so without actual comparison it would not be able to detect if we really need to update epoch_counter or not. Because as I said currently intel_dp_set_edid simply assigns it without checking, so that way you will get epoch_counter updated every time, i.e exactly what you wanted to avoid here. So we really need someway to determine if edid had changed, instead of simply assigning it all the time - that is why I had to implement drm_edid_equal function. - Stanislav > > > > -Daniel > > > > > > > > > > > > > > > > > > > > > > - Stanislav > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Stanislav > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, Daniel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Stanislav > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Daniel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Stanislav Lisovskiy (3): > > > > > > > > > > > > drm: Add helper to compare edids. > > > > > > > > > > > > drm: Introduce change counter to > > > > > > > > > > > > drm_connector > > > > > > > > > > > > drm/i915: Send hotplug event if edid had > > > > > > > > > > > > changed. > > > > > > > > > > > > > > > > > > > > > > > > drivers/gpu/drm/drm_connector.c | > > > > > > > > > > > > > > > > > > > > > > > > 1 + > > > > > > > > > > > > drivers/gpu/drm/drm_edid.c | > > > > > > > > > > > > 33 > > > > > > > > > > > > > > > > > > > > > > > > drivers/gpu/drm/drm_probe_helper.c | > > > > > > > > > > > > 29 > > > > > > > > > > > > +++- > > > > > > > > > > > > - > > > > > > > > > > > >
Re: [Intel-gfx] [PATCH v4 5/7] drm/i915: Add new GMP register size for GEN11
>-Original Message-
>From: dri-devel On Behalf Of Gwan-
>gyeong Mun
>Sent: Tuesday, September 3, 2019 2:43 PM
>To: intel-gfx@lists.freedesktop.org
>Cc: Shankar, Uma ; dri-de...@lists.freedesktop.org
>Subject: [PATCH v4 5/7] drm/i915: Add new GMP register size for GEN11
>
>According to Bspec, GEN11 and prior GEN11 have different register size for HDR
>Metadata Infoframe SDP packet. It adds new VIDEO_DIP_GMP_DATA_SIZE for
>GEN11. And it makes handle different register size for
>HDMI_PACKET_TYPE_GAMUT_METADATA on hsw_dip_data_size() for each GEN
>platforms. It addresses Uma's review comments.
Looks good to me.
Reviewed-by: Uma Shankar
>Signed-off-by: Gwan-gyeong Mun
>---
> drivers/gpu/drm/i915/display/intel_hdmi.c | 10 --
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> 2 files changed, 9 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
>b/drivers/gpu/drm/i915/display/intel_hdmi.c
>index c500fc9154c8..287999b31217 100644
>--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
>+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
>@@ -189,13 +189,19 @@ hsw_dip_data_reg(struct drm_i915_private *dev_priv,
> }
> }
>
>-static int hsw_dip_data_size(unsigned int type)
>+static int hsw_dip_data_size(struct drm_i915_private *dev_priv,
>+ unsigned int type)
> {
> switch (type) {
> case DP_SDP_VSC:
> return VIDEO_DIP_VSC_DATA_SIZE;
> case DP_SDP_PPS:
> return VIDEO_DIP_PPS_DATA_SIZE;
>+ case HDMI_PACKET_TYPE_GAMUT_METADATA:
>+ if (INTEL_GEN(dev_priv) >= 11)
>+ return VIDEO_DIP_GMP_DATA_SIZE;
>+ else
>+ return VIDEO_DIP_DATA_SIZE;
> default:
> return VIDEO_DIP_DATA_SIZE;
> }
>@@ -514,7 +520,7 @@ static void hsw_write_infoframe(struct intel_encoder
>*encoder,
> int i;
> u32 val = I915_READ(ctl_reg);
>
>- data_size = hsw_dip_data_size(type);
>+ data_size = hsw_dip_data_size(dev_priv, type);
>
> val &= ~hsw_infoframe_enable(type);
> I915_WRITE(ctl_reg, val);
>diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
>index
>6c43b8c583bb..8b31ad7426d6 100644
>--- a/drivers/gpu/drm/i915/i915_reg.h
>+++ b/drivers/gpu/drm/i915/i915_reg.h
>@@ -4667,6 +4667,7 @@ enum {
> * (Haswell and newer) to see which VIDEO_DIP_DATA byte corresponds to each
> byte
> * of the infoframe structure specified by CEA-861. */
> #define VIDEO_DIP_DATA_SIZE 32
>+#define VIDEO_DIP_GMP_DATA_SIZE 36
> #define VIDEO_DIP_VSC_DATA_SIZE 36
> #define VIDEO_DIP_PPS_DATA_SIZE 132
> #define VIDEO_DIP_CTL _MMIO(0x61170)
>--
>2.23.0
>
>___
>dri-devel mailing list
>dri-de...@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 3/7] drm: Add DisplayPort colorspace property
>-Original Message-
>From: dri-devel On Behalf Of Gwan-
>gyeong Mun
>Sent: Tuesday, September 3, 2019 2:43 PM
>To: intel-gfx@lists.freedesktop.org
>Cc: Shankar, Uma ; dri-de...@lists.freedesktop.org
>Subject: [PATCH v4 3/7] drm: Add DisplayPort colorspace property
>
>In order to use colorspace property to Display Port connectors, it extends
>DRM_MODE_CONNECTOR_DisplayPort connector_type on
>drm_mode_create_colorspace_property function.
>
>v3: Addressed review comments from Ville
>- Add new colorimetry options for DP 1.4a spec.
>- Separate set of colorimetry enum values for DP.
Thanks Ville for spotting this and Gwan-gyeong Mun for fixing it.
Somehow missed this in my first scan.
>v4: Add additional comments to struct drm_prop_enum_list.
>Polishing an enum string of struct drm_prop_enum_list
>Signed-off-by: Gwan-gyeong Mun
>Reviewed-by: Uma Shankar
>---
> drivers/gpu/drm/drm_connector.c | 46 +
> include/drm/drm_connector.h | 8 ++
> 2 files changed, 54 insertions(+)
>
>diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
>index 4c766624b20d..5834e6d330a0 100644
>--- a/drivers/gpu/drm/drm_connector.c
>+++ b/drivers/gpu/drm/drm_connector.c
>@@ -882,6 +882,44 @@ static const struct drm_prop_enum_list hdmi_colorspaces[]
>= {
> { DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI-
>P3_RGB_Theater" }, };
>
>+/*
>+ * As per DP 1.4a spec, 2.2.5.7.5 VSC SDP Payload for Pixel
>+Encoding/Colorimetry
>+ * Format Table 2-120
>+ */
>+static const struct drm_prop_enum_list dp_colorspaces[] = {
>+ /* For Default case, driver will set the colorspace */
>+ { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
>+ /* Colorimetry based on IEC 61966-2-1 */
>+ { DRM_MODE_COLORIMETRY_SRGB, "sRGB" },
>+ { DRM_MODE_COLORIMETRY_WIDE_GAMUT_FIXED_POINT_RGB,
>"wide_gamut_fixed_point_RGB" },
>+ /* Colorimetry based on IEC 61966-2-2, wide gamut floating point RGB */
>+ { DRM_MODE_COLORIMETRY_SCRGB, "scRGB" },
>+ { DRM_MODE_COLORIMETRY_ADOBE_RGB, "Adobe_RGB" },
>+ /* Colorimetry based on SMPTE RP 431-2 */
>+ { DRM_MODE_COLORIMETRY_DCP_P3_RGB, "DCI-P3_RGB" },
>+ /* Colorimetry based on ITU-R BT.2020 */
>+ { DRM_MODE_COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
>+ { DRM_MODE_COLORIMETRY_BT601_YCC, "BT601_YCC" },
>+ { DRM_MODE_COLORIMETRY_BT709_YCC, "BT709_YCC" },
>+ /* Standard Definition Colorimetry based on IEC 61966-2-4 */
>+ { DRM_MODE_COLORIMETRY_XVYCC_601, "XVYCC_601" },
>+ /* High Definition Colorimetry based on IEC 61966-2-4 */
>+ { DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" },
>+ /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
>+ { DRM_MODE_COLORIMETRY_SYCC_601, "SYCC_601" },
>+ /* Colorimetry based on IEC 61966-2-5 [33] */
>+ { DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" },
>+ /* Colorimetry based on ITU-R BT.2020 */
>+ { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
>+ /* Colorimetry based on ITU-R BT.2020 */
>+ { DRM_MODE_COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
>+ /*
>+ * Colorumetry based on Digital Imaging and Communications in Medicine
Typo here.
>+ * (DICOM) Part 14: Grayscale Standard Display Function
>+ */
>+ { DRM_MODE_COLORIMETRY_DICOM_PART_14_GRAYSCALE,
>+"DICOM_Part_14_Grayscale" }, };
>+
> /**
> * DOC: standard connector properties
> *
>@@ -1710,6 +1748,14 @@ int drm_mode_create_colorspace_property(struct
>drm_connector *connector)
> ARRAY_SIZE(hdmi_colorspaces));
> if (!prop)
> return -ENOMEM;
>+ } else if (connector->connector_type ==
>DRM_MODE_CONNECTOR_DisplayPort ||
>+ connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
>+ prop = drm_property_create_enum(dev, DRM_MODE_PROP_ENUM,
>+ "Colorspace",
>+ dp_colorspaces,
>+ ARRAY_SIZE(dp_colorspaces));
>+ if (!prop)
>+ return -ENOMEM;
> } else {
> DRM_DEBUG_KMS("Colorspace property not supported\n");
> return 0;
>diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h index
>681cb590f952..8848e5d6b0c4 100644
>--- a/include/drm/drm_connector.h
>+++ b/include/drm/drm_connector.h
>@@ -281,6 +281,14 @@ enum drm_panel_orientation {
> /* Additional Colorimetry extension added as part of CTA 861.G */
> #define DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65 11
> #define DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER 12
>+/* Additional Colorimetry Options added for DP 1.4a VSC Colorimetry Format */
>+#define DRM_MODE_COLORIMETRY_SRGB 13
>+#define DRM_MODE_COLORIMETRY_WIDE_GAMUT_FIXED_POINT_RGB 14
>+#define DRM_MODE_COLORIMETRY_SCRGB15
>+#define
[Intel-gfx] [PATCH i-g-t] i915/gem_ctx_shared: Prebind both context images
If we are using an aliasing-ppgtt, the context images are in the same virtual address space as our target objects. We have to be careful that cloning and using a new context does not evict our unreferenced target object. To avoid that, we first bind both context images while creating the hole in the address space to ensure that the hole is still available later on. Signed-off-by: Chris Wilson --- tests/i915/gem_ctx_shared.c | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/tests/i915/gem_ctx_shared.c b/tests/i915/gem_ctx_shared.c index b073bdfc9..f78524822 100644 --- a/tests/i915/gem_ctx_shared.c +++ b/tests/i915/gem_ctx_shared.c @@ -191,6 +191,7 @@ static void exec_shared_gtt(int i915, unsigned int ring) .buffer_count = 1, .flags = ring, }; + uint32_t clone; uint32_t scratch, *s; uint32_t batch, cs[16]; uint64_t offset; @@ -199,13 +200,18 @@ static void exec_shared_gtt(int i915, unsigned int ring) gem_require_ring(i915, ring); igt_require(gem_can_store_dword(i915, ring)); + clone = gem_context_clone(i915, 0, I915_CONTEXT_CLONE_VM, 0); + /* Find a hole big enough for both objects later */ scratch = gem_create(i915, 16384); gem_write(i915, scratch, 0, , sizeof(bbe)); obj.handle = scratch; gem_execbuf(i915, ); - gem_close(i915, scratch); obj.flags |= EXEC_OBJECT_PINNED; /* reuse this address */ + execbuf.rsvd1 = clone; /* and bind the second context image */ + gem_execbuf(i915, ); + execbuf.rsvd1 = 0; + gem_close(i915, scratch); scratch = gem_create(i915, 4096); s = gem_mmap__wc(i915, scratch, 0, 4096, PROT_WRITE); @@ -241,7 +247,7 @@ static void exec_shared_gtt(int i915, unsigned int ring) obj.handle = batch; obj.offset += 8192; /* make sure we don't cause an eviction! */ - execbuf.rsvd1 = gem_context_clone(i915, 0, I915_CONTEXT_CLONE_VM, 0); + execbuf.rsvd1 = clone; if (gen > 3 && gen < 6) execbuf.flags |= I915_EXEC_SECURE; gem_execbuf(i915, ); @@ -253,7 +259,6 @@ static void exec_shared_gtt(int i915, unsigned int ring) execbuf.batch_start_offset = 64 * sizeof(s[0]); gem_execbuf(i915, ); igt_assert_eq_u64(obj.offset, offset); - gem_context_destroy(i915, execbuf.rsvd1); gem_sync(i915, batch); /* write hazard lies */ gem_close(i915, batch); @@ -268,6 +273,8 @@ static void exec_shared_gtt(int i915, unsigned int ring) munmap(s, 4096); gem_close(i915, scratch); + + gem_context_destroy(i915, clone); } static int nop_sync(int i915, uint32_t ctx, unsigned int ring, int64_t timeout) -- 2.23.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
