Re: [Intel-gfx] [PATCH v2] drm/i915/gt: Initialize reserved and unspecified MOCS indices
Joonas Lahtinen writes:
> + Jason and Ken
>
> Quoting Francisco Jerez (2020-06-05 00:34:57)
>> Ayaz A Siddiqui writes:
>>
>> > In order to avoid functional breakage of mis-programmed applications that
>> > have grown to depend on unused MOCS entries, we are programming
>> > those entries to be equal to fully cached ("L3 + LLC") entry as per the
>> > recommendation from architecture team.
>> >
>> > These reserved and unspecified entries should not be used as they may be
>> > changed to less performant variants with better coherency in the future
>> > if more entries are needed.
>
> This patch message needs reworking. It should just standalone describe
> the technical reasoning behind the patch completely, without referring
> to elsewhere or to some other decision.
>
> The patch should also Cc: relevant developers who have previously been
> working on the MOCS code and the userspace driver folks (Mesa, compute
> and media).
>
>> This change seems highly questionable to me... If a future kernel
>> release introduces a new MOCS entry with more strict coherency
>> semantics, and an application starts relying on it, that application
>> won't work when run on an older kernel version with this patch is
>> applied. IOW setting uninitialized entries to the most strict caching
>> setting available (UC) ensures forwards compatibility with future
>> userspace, which seems like a more important design principle than
>> giving full caching to broken userspace that accidentally makes use of
>> an undefined MOCS entry not part of the kernel ABI.
>
> Both choices were considered, and ultimately Ken and Jason were more in
> favor of 'worst coherency' if using reserved MOCS entry.
n>
> Your concern about newer software on older kernel is valid. But the
> starting point of the decision is the no-regression policy of Linux.
>
> If we have some application developed on an older kernel where the MOCS
> entry is unused and would be UC (best coherency), we would have no
> choice but to keep that entry unused indefinitely not to break the
> mis-programmed application.
>
That's a valid concern too, however it didn't seem like much an issue
with the original Gen9 workflow that gave i915 the freedom to assign
MOCS indices as it would see fit. If some broken userspace starts
relying on the caching semantics of a random MOCS index not part of the
currently exposed kernel ABI, and that userspace isn't some proprietary
blob broken beyond repair, the kernel has the possibility (or the
obligation?) to give that application the semantics it expected for that
MOCS entry alone -- Which would likely improve the performance of the
application beyond the original behavior unless UC was what it was
actually expecting.
IOW it seems to me that this conflict between forwards and backwards ABI
compatibility is created by the rather artificial imperative to follow
the reference MOCS tables without modification, which could conceivably
tie our hands in the future and give us no choice but to break the
no-regression policy if the reference MOCS tables change in a
non-backwards-compatible way as has happened in the past (though luckily
before any software started relying on it AFAIA), and largely defeats
the point of having programmable MOCS tables IMO. Not really thrilled
about that decision :P.
> Now we have the worst coherency by default if an application is using
> reserved entry, making it more likely to be noticed at develop time. And
> even if it would not be noticed, modifying the entry for better
> coherency should not functionally break the application.
>
> Regards, Joonas
>
>> > Signed-off-by: Ayaz A Siddiqui
>> > Cc: Joonas Lahtinen
>> > ---
>> > drivers/gpu/drm/i915/gt/intel_mocs.c | 93 ++--
>> > 1 file changed, 89 insertions(+), 4 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c
>> > b/drivers/gpu/drm/i915/gt/intel_mocs.c
>> > index 632e08a4592b..1089bd5fdba2 100644
>> > --- a/drivers/gpu/drm/i915/gt/intel_mocs.c
>> > +++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
>> > @@ -234,10 +234,6 @@ static const struct drm_i915_mocs_entry
>> > broxton_mocs_table[] = {
>> > L3_1_UC)
>> >
>> > static const struct drm_i915_mocs_entry tgl_mocs_table[] = {
>> > - /* Base - Error (Reserved for Non-Use) */
>> > - MOCS_ENTRY(0, 0x0, 0x0),
>> > - /* Base - Reserved */
>> > - MOCS_ENTRY(1, 0x0, 0x0),
>> >
>> > GEN11_MOCS_ENTRIES,
>> >
>> > @@ -265,6 +261,95 @@ static const struct drm_i915_mocs_entry
>> > tgl_mocs_table[] = {
>> > MOCS_ENTRY(61,
>> > LE_1_UC | LE_TC_1_LLC,
>> > L3_3_WB),
>> > +
>> > + /* NOTE:
>> > + * Reserved and unspecified MOCS indices have been set to (L3 + LCC).
>> > + * These reserved entry should never be used, they may be chanaged
>> > + * to low performant variants with better coherency in the future if
>> > + * more entries are needed.
>> > + */
>> > +
>> > +
[Intel-gfx] ✗ Fi.CI.BUILD: failure for Disabling FBC when PSR2 SU update enabled
== Series Details == Series: Disabling FBC when PSR2 SU update enabled URL : https://patchwork.freedesktop.org/series/78138/ State : failure == Summary == Applying: Disabling FBC when PSR2 SU update enabled Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/display/intel_fbc.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/display/intel_fbc.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/display/intel_fbc.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 Disabling FBC when PSR2 SU update enabled 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] [PATCH v2] Disabling FBC when PSR2 SU update enabled
---
drivers/gpu/drm/i915/display/intel_fbc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 52bc7483adb5..1505d93c6685 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -1419,9 +1419,9 @@ void intel_fbc_init(struct drm_i915_private *dev_priv)
drm_dbg_kms(_priv->drm, "Sanitized enable_fbc value: %d\n",
i915_modparams.enable_fbc);
- if (i915_modparams.enable_psr) {
- i915_modparams.enable_fbc = 0;
-DRM_DEBUG_KMS("PSR enabled. FBC no longer needed. Disable
FBC. \n");
+ if (i915_modparams.enable_psr && dev_priv->psr.sink_psr2_support) {
+ i915_modparams.enable_fbc = 0;
+ DRM_DEBUG_KMS("PSR enabled. FBC no longer needed. Disable FBC.
\n");
}
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH AUTOSEL 5.6 163/606] drm/i915: Propagate error from completed fences
From: Chris Wilson
commit bc850943486887e3859597a266767f95db90aa72 upstream.
We need to preserve fatal errors from fences that are being terminated
as we hook them up.
Fixes: ef4688497512 ("drm/i915: Propagate fence errors")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Matthew Auld
Reviewed-by: Matthew Auld
Link:
https://patchwork.freedesktop.org/patch/msgid/20200506162136.3325-1-ch...@chris-wilson.co.uk
(cherry picked from commit 24fe5f2ab2478053d50a3bc629ada895903a5cbc)
Signed-off-by: Rodrigo Vivi
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/i915/i915_request.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 32ab154db788..1f50fc8bcebf 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -947,8 +947,10 @@ i915_request_await_request(struct i915_request *to, struct
i915_request *from)
GEM_BUG_ON(to == from);
GEM_BUG_ON(to->timeline == from->timeline);
- if (i915_request_completed(from))
+ if (i915_request_completed(from)) {
+ i915_sw_fence_set_error_once(>submit, from->fence.error);
return 0;
+ }
if (to->engine->schedule) {
ret = i915_sched_node_add_dependency(>sched,
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH AUTOSEL 5.6 162/606] drm/i915/gvt: Init DPLL/DDI vreg for virtual display instead of inheritance.
From: Colin Xu
commit f965b68188ab59a40a421ced1b05a2fea638465c upstream.
Init value of some display vregs rea inherited from host pregs. When
host display in different status, i.e. all monitors unpluged, different
display configurations, etc., GVT virtual display setup don't consistent
thus may lead to guest driver consider display goes malfunctional.
The added init vreg values are based on PRMs and fixed by calcuation
from current configuration (only PIPE_A) and the virtual EDID.
Fixes: 04d348ae3f0a ("drm/i915/gvt: vGPU display virtualization")
Acked-by: Zhenyu Wang
Signed-off-by: Colin Xu
Signed-off-by: Zhenyu Wang
Link:
http://patchwork.freedesktop.org/patch/msgid/20200508060506.216250-1-colin...@intel.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/i915/gvt/display.c | 49 +++---
1 file changed, 44 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/display.c
b/drivers/gpu/drm/i915/gvt/display.c
index a62bdf9be682..59aa5e64acb0 100644
--- a/drivers/gpu/drm/i915/gvt/display.c
+++ b/drivers/gpu/drm/i915/gvt/display.c
@@ -207,14 +207,41 @@ static void emulate_monitor_status_change(struct
intel_vgpu *vgpu)
SKL_FUSE_PG_DIST_STATUS(SKL_PG0) |
SKL_FUSE_PG_DIST_STATUS(SKL_PG1) |
SKL_FUSE_PG_DIST_STATUS(SKL_PG2);
- vgpu_vreg_t(vgpu, LCPLL1_CTL) |=
- LCPLL_PLL_ENABLE |
- LCPLL_PLL_LOCK;
- vgpu_vreg_t(vgpu, LCPLL2_CTL) |= LCPLL_PLL_ENABLE;
-
+ /*
+* Only 1 PIPE enabled in current vGPU display and PIPE_A is
+* tied to TRANSCODER_A in HW, so it's safe to assume PIPE_A,
+* TRANSCODER_A can be enabled. PORT_x depends on the input of
+* setup_virtual_dp_monitor, we can bind DPLL0 to any PORT_x
+* so we fixed to DPLL0 here.
+* Setup DPLL0: DP link clk 1620 MHz, non SSC, DP Mode
+*/
+ vgpu_vreg_t(vgpu, DPLL_CTRL1) =
+ DPLL_CTRL1_OVERRIDE(DPLL_ID_SKL_DPLL0);
+ vgpu_vreg_t(vgpu, DPLL_CTRL1) |=
+ DPLL_CTRL1_LINK_RATE(DPLL_CTRL1_LINK_RATE_1620,
DPLL_ID_SKL_DPLL0);
+ vgpu_vreg_t(vgpu, LCPLL1_CTL) =
+ LCPLL_PLL_ENABLE | LCPLL_PLL_LOCK;
+ vgpu_vreg_t(vgpu, DPLL_STATUS) = DPLL_LOCK(DPLL_ID_SKL_DPLL0);
+ /*
+* Golden M/N are calculated based on:
+* 24 bpp, 4 lanes, 154000 pixel clk (from virtual EDID),
+* DP link clk 1620 MHz and non-constant_n.
+* TODO: calculate DP link symbol clk and stream clk m/n.
+*/
+ vgpu_vreg_t(vgpu, PIPE_DATA_M1(TRANSCODER_A)) = 63 <<
TU_SIZE_SHIFT;
+ vgpu_vreg_t(vgpu, PIPE_DATA_M1(TRANSCODER_A)) |= 0x5b425e;
+ vgpu_vreg_t(vgpu, PIPE_DATA_N1(TRANSCODER_A)) = 0x80;
+ vgpu_vreg_t(vgpu, PIPE_LINK_M1(TRANSCODER_A)) = 0x3cd6e;
+ vgpu_vreg_t(vgpu, PIPE_LINK_N1(TRANSCODER_A)) = 0x8;
}
if (intel_vgpu_has_monitor_on_port(vgpu, PORT_B)) {
+ vgpu_vreg_t(vgpu, DPLL_CTRL2) &=
+ ~DPLL_CTRL2_DDI_CLK_OFF(PORT_B);
+ vgpu_vreg_t(vgpu, DPLL_CTRL2) |=
+ DPLL_CTRL2_DDI_CLK_SEL(DPLL_ID_SKL_DPLL0, PORT_B);
+ vgpu_vreg_t(vgpu, DPLL_CTRL2) |=
+ DPLL_CTRL2_DDI_SEL_OVERRIDE(PORT_B);
vgpu_vreg_t(vgpu, SFUSE_STRAP) |= SFUSE_STRAP_DDIB_DETECTED;
vgpu_vreg_t(vgpu, TRANS_DDI_FUNC_CTL(TRANSCODER_A)) &=
~(TRANS_DDI_BPC_MASK | TRANS_DDI_MODE_SELECT_MASK |
@@ -235,6 +262,12 @@ static void emulate_monitor_status_change(struct
intel_vgpu *vgpu)
}
if (intel_vgpu_has_monitor_on_port(vgpu, PORT_C)) {
+ vgpu_vreg_t(vgpu, DPLL_CTRL2) &=
+ ~DPLL_CTRL2_DDI_CLK_OFF(PORT_C);
+ vgpu_vreg_t(vgpu, DPLL_CTRL2) |=
+ DPLL_CTRL2_DDI_CLK_SEL(DPLL_ID_SKL_DPLL0, PORT_C);
+ vgpu_vreg_t(vgpu, DPLL_CTRL2) |=
+ DPLL_CTRL2_DDI_SEL_OVERRIDE(PORT_C);
vgpu_vreg_t(vgpu, SDEISR) |= SDE_PORTC_HOTPLUG_CPT;
vgpu_vreg_t(vgpu, TRANS_DDI_FUNC_CTL(TRANSCODER_A)) &=
~(TRANS_DDI_BPC_MASK | TRANS_DDI_MODE_SELECT_MASK |
@@ -255,6 +288,12 @@ static void emulate_monitor_status_change(struct
intel_vgpu *vgpu)
}
if (intel_vgpu_has_monitor_on_port(vgpu, PORT_D)) {
+ vgpu_vreg_t(vgpu, DPLL_CTRL2) &=
+ ~DPLL_CTRL2_DDI_CLK_OFF(PORT_D);
+ vgpu_vreg_t(vgpu, DPLL_CTRL2) |=
+ DPLL_CTRL2_DDI_CLK_SEL(DPLL_ID_SKL_DPLL0, PORT_D);
+ vgpu_vreg_t(vgpu, DPLL_CTRL2) |=
[Intel-gfx] [PATCH AUTOSEL 5.6 037/606] drm/i915/tgl+: Fix interrupt handling for DP AUX transactions
From: Imre Deak
commit 4457a9db2bdec2360ddb15242341696108167886 upstream.
Unmask/enable AUX interrupts on all ports on TGL+. So far the interrupts
worked only on port A, which meant each transaction on other ports took
10ms.
Cc: # v5.4+
Signed-off-by: Imre Deak
Reviewed-by: Ville Syrjälä
Link:
https://patchwork.freedesktop.org/patch/msgid/20200504075828.20348-1-imre.d...@intel.com
(cherry picked from commit 054318c7e35f1d7d06b216143fff5f32405047ee)
Signed-off-by: Rodrigo Vivi
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/i915/i915_irq.c | 16 +++-
1 file changed, 3 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index c6f02b0b6c7a..52825ae8301b 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3324,7 +3324,7 @@ static void gen8_de_irq_postinstall(struct
drm_i915_private *dev_priv)
u32 de_pipe_masked = gen8_de_pipe_fault_mask(dev_priv) |
GEN8_PIPE_CDCLK_CRC_DONE;
u32 de_pipe_enables;
- u32 de_port_masked = GEN8_AUX_CHANNEL_A;
+ u32 de_port_masked = gen8_de_port_aux_mask(dev_priv);
u32 de_port_enables;
u32 de_misc_masked = GEN8_DE_EDP_PSR;
enum pipe pipe;
@@ -3332,18 +3332,8 @@ static void gen8_de_irq_postinstall(struct
drm_i915_private *dev_priv)
if (INTEL_GEN(dev_priv) <= 10)
de_misc_masked |= GEN8_DE_MISC_GSE;
- if (INTEL_GEN(dev_priv) >= 9) {
- de_port_masked |= GEN9_AUX_CHANNEL_B | GEN9_AUX_CHANNEL_C |
- GEN9_AUX_CHANNEL_D;
- if (IS_GEN9_LP(dev_priv))
- de_port_masked |= BXT_DE_PORT_GMBUS;
- }
-
- if (INTEL_GEN(dev_priv) >= 11)
- de_port_masked |= ICL_AUX_CHANNEL_E;
-
- if (IS_CNL_WITH_PORT_F(dev_priv) || INTEL_GEN(dev_priv) >= 11)
- de_port_masked |= CNL_AUX_CHANNEL_F;
+ if (IS_GEN9_LP(dev_priv))
+ de_port_masked |= BXT_DE_PORT_GMBUS;
de_pipe_enables = de_pipe_masked | GEN8_PIPE_VBLANK |
GEN8_PIPE_FIFO_UNDERRUN;
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH AUTOSEL 5.6 031/606] Make the "Reducing compressed framebufer size" message be DRM_INFO_ONCE()
From: Peter Jones
commit 82152d424b6cb6fc1ede7d03d69c04e786688740 upstream.
This was sort of annoying me:
random:~$ dmesg | tail -1
[523884.039227] [drm] Reducing the compressed framebuffer size. This may lead
to less power savings than a non-reduced-size. Try to increase stolen memory
size if available in BIOS.
random:~$ dmesg | grep -c "Reducing the compressed"
47
This patch makes it DRM_INFO_ONCE() just like the similar message
farther down in that function is pr_info_once().
Cc: sta...@vger.kernel.org
Signed-off-by: Peter Jones
Acked-by: Rodrigo Vivi
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1745
Link:
https://patchwork.freedesktop.org/patch/msgid/20180706190424.29194-1-pjo...@redhat.com
[vsyrjala: Rebase due to per-device logging]
Signed-off-by: Ville Syrjälä
(cherry picked from commit 6b7fc6a3e6af4ff5773949d0fed70d8e7f68d5ce)
[Rodrigo: port back to DRM_INFO_ONCE]
Signed-off-by: Rodrigo Vivi
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/i915/display/intel_fbc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b/drivers/gpu/drm/i915/display/intel_fbc.c
index a1048ece541e..b6d5e7defa5b 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -478,8 +478,7 @@ static int intel_fbc_alloc_cfb(struct drm_i915_private
*dev_priv,
if (!ret)
goto err_llb;
else if (ret > 1) {
- DRM_INFO("Reducing the compressed framebuffer size. This may
lead to less power savings than a non-reduced-size. Try to increase stolen
memory size if available in BIOS.\n");
-
+ DRM_INFO_ONCE("Reducing the compressed framebuffer size. This
may lead to less power savings than a non-reduced-size. Try to increase stolen
memory size if available in BIOS.\n");
}
fbc->threshold = ret;
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH AUTOSEL 5.6 003/606] drm/i915: Handle idling during i915_gem_evict_something busy loops
From: Chris Wilson
[ Upstream commit 955da9d77435acac066139e9d7f7723ce7204a1d ]
i915_gem_evict_something() is charged with finding a slot within the GTT
that we may reuse. Since our goal is not to stall, we first look for a
slot that only overlaps idle vma. To this end, on the first pass we move
any active vma to the end of the search list. However, we only stopped
moving active vma after we see the first active vma twice. If during the
search, that first active vma completed, we would not notice and keep on
extending the search list.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1746
Fixes: 2850748ef876 ("drm/i915: Pull i915_vma_pin under the vm->mutex")
Fixes: b1e3177bd1d8 ("drm/i915: Coordinate i915_active with its own mutex")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: # v5.5+
Reviewed-by: Mika Kuoppala
Link:
https://patchwork.freedesktop.org/patch/msgid/20200509115217.26853-1-ch...@chris-wilson.co.uk
(cherry picked from commit 73e28cc40bf00b5d168cb8f5cff1ae63e9097446)
Signed-off-by: Rodrigo Vivi
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/i915/i915_gem_evict.c | 26 --
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c
b/drivers/gpu/drm/i915/i915_gem_evict.c
index 0697bedebeef..d99df9c33708 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/i915_gem_evict.c
@@ -130,6 +130,13 @@ i915_gem_evict_something(struct i915_address_space *vm,
active = NULL;
INIT_LIST_HEAD(_list);
list_for_each_entry_safe(vma, next, >bound_list, vm_link) {
+ if (vma == active) { /* now seen this vma twice */
+ if (flags & PIN_NONBLOCK)
+ break;
+
+ active = ERR_PTR(-EAGAIN);
+ }
+
/*
* We keep this list in a rough least-recently scanned order
* of active elements (inactive elements are cheap to reap).
@@ -145,21 +152,12 @@ i915_gem_evict_something(struct i915_address_space *vm,
* To notice when we complete one full cycle, we record the
* first active element seen, before moving it to the tail.
*/
- if (i915_vma_is_active(vma)) {
- if (vma == active) {
- if (flags & PIN_NONBLOCK)
- break;
-
- active = ERR_PTR(-EAGAIN);
- }
-
- if (active != ERR_PTR(-EAGAIN)) {
- if (!active)
- active = vma;
+ if (active != ERR_PTR(-EAGAIN) && i915_vma_is_active(vma)) {
+ if (!active)
+ active = vma;
- list_move_tail(>vm_link, >bound_list);
- continue;
- }
+ list_move_tail(>vm_link, >bound_list);
+ continue;
}
if (mark_free(, vma, flags, _list))
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/display: Avoid PSR and FBC features concurently.
I had a meeting with an Intel Display Architect. The expected behavior for the
driver is PSR2-SU enabling should disable FBC. I will update the patch to
limit fbc disabling for PSR2-SU only, not PSR1. Please look at the HSD below
for expected driver implementation.
https://hsdes.intel.com/appstore/article/#/14010265390
Thanks,
Jason
-Original Message-
From: Souza, Jose
Sent: Monday, June 08, 2020 9:52 AM
To: Le, Jason V ; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Avoid PSR and FBC features
concurently.
On Sun, 2020-06-07 at 23:56 -0700, Jason Le wrote:
> Issue: Enble both PSR and FBC caused some fickers on some eDP panels
> (eg. Panel GIS 13.5" QHD Glare NE135FBM-N41/NC135GFL02). Disbling
> either PSR or FBC will solve this flicker issue.
>
> Both PSR and FBC features save power when render is not busy. When PSR
> is active, saving power achieved by source turning off source
> transmitter and main link, putting memory on self-refresh mode.
> Therefore with PSR enabled, FBC role is minimized since PSR power
> saving already covers most what FBC does. Disabling FBC in case to
> avoid conflict between PSR and FBC which causes display anomaly in some
> scenarios.
The combination of both saves even more power so no to this, we should fix the
issue not disable features because of a single panel having issues.
A PSR2 fix was merged yesterday "drm/i915/psr: Program default IO buffer Wake
and Fast Wake" try with that, if just that don't fix try set
psr_safest_params=1.
If this do not helps, please file a bug, add debug information and then we
proceed from that.
>
> Tests:
> Booted system with PSR enabled, verified FBC disabled.
> Disabled PSR with disabled (i915.enable_psr=0), verified FBC enabled.
> ---
> drivers/gpu/drm/i915/display/intel_fbc.c | 6 ++
> drivers/gpu/drm/i915/display/intel_psr.c | 4 +++-
> 2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
> b/drivers/gpu/drm/i915/display/intel_fbc.c
> index 1c26673acb2d..52bc7483adb5 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> @@ -1419,6 +1419,12 @@ void intel_fbc_init(struct drm_i915_private *dev_priv)
> drm_dbg_kms(_priv->drm, "Sanitized enable_fbc value: %d\n",
> i915_modparams.enable_fbc);
>
> + if (i915_modparams.enable_psr) {
> + i915_modparams.enable_fbc = 0;
> +DRM_DEBUG_KMS("PSR enabled. FBC no longer needed. Disable
> FBC. \n");
> + }
> +
> +
> if (!HAS_FBC(dev_priv)) {
> fbc->no_fbc_reason = "unsupported by this chipset";
> return;
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index b7a2c102648a..25accfdd5ad3 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1439,8 +1439,10 @@ void intel_psr_init(struct drm_i915_private *dev_priv)
> if (!HAS_PSR(dev_priv))
> return;
>
> - if (!dev_priv->psr.sink_support)
> + if (!dev_priv->psr.sink_support) {
> + i915_modparams.enable_psr = 0;
> return;
> + }
>
> if (IS_HASWELL(dev_priv))
> /*
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/tc: fix the reset of ln0
== Series Details == Series: drm/i915/tc: fix the reset of ln0 URL : https://patchwork.freedesktop.org/series/78132/ State : success == Summary == CI Bug Log - changes from CI_DRM_8601_full -> Patchwork_17912_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17912_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_create@forked: - shard-glk: [PASS][1] -> [DMESG-WARN][2] ([i915#118] / [i915#95]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-glk5/igt@gem_exec_cre...@forked.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17912/shard-glk6/igt@gem_exec_cre...@forked.html * igt@gem_sync@basic-store-each: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([i915#95]) +11 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-apl3/igt@gem_s...@basic-store-each.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17912/shard-apl7/igt@gem_s...@basic-store-each.html * igt@i915_module_load@reload: - shard-tglb: [PASS][5] -> [DMESG-WARN][6] ([i915#402]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-tglb5/igt@i915_module_l...@reload.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17912/shard-tglb1/igt@i915_module_l...@reload.html * igt@i915_suspend@debugfs-reader: - shard-kbl: [PASS][7] -> [DMESG-WARN][8] ([i915#180]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-kbl3/igt@i915_susp...@debugfs-reader.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17912/shard-kbl7/igt@i915_susp...@debugfs-reader.html * igt@kms_big_fb@linear-16bpp-rotate-0: - shard-apl: [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-apl2/igt@kms_big...@linear-16bpp-rotate-0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17912/shard-apl8/igt@kms_big...@linear-16bpp-rotate-0.html * igt@kms_big_fb@y-tiled-64bpp-rotate-0: - shard-iclb: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-iclb5/igt@kms_big...@y-tiled-64bpp-rotate-0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17912/shard-iclb3/igt@kms_big...@y-tiled-64bpp-rotate-0.html * igt@kms_color@pipe-c-ctm-blue-to-red: - shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([i915#93] / [i915#95]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-kbl6/igt@kms_co...@pipe-c-ctm-blue-to-red.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17912/shard-kbl7/igt@kms_co...@pipe-c-ctm-blue-to-red.html * igt@kms_draw_crc@draw-method-rgb565-blt-ytiled: - shard-skl: [PASS][15] -> [DMESG-WARN][16] ([i915#1982]) +4 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-skl9/igt@kms_draw_...@draw-method-rgb565-blt-ytiled.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17912/shard-skl8/igt@kms_draw_...@draw-method-rgb565-blt-ytiled.html * igt@kms_frontbuffer_tracking@fbc-stridechange: - shard-glk: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-glk4/igt@kms_frontbuffer_track...@fbc-stridechange.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17912/shard-glk6/igt@kms_frontbuffer_track...@fbc-stridechange.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-indfb-draw-pwrite: - shard-tglb: [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-tglb5/igt@kms_frontbuffer_track...@fbcpsr-1p-offscren-pri-indfb-draw-pwrite.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17912/shard-tglb1/igt@kms_frontbuffer_track...@fbcpsr-1p-offscren-pri-indfb-draw-pwrite.html * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min: - shard-skl: [PASS][21] -> [FAIL][22] ([fdo#108145] / [i915#265]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-skl2/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17912/shard-skl1/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html * igt@kms_psr@psr2_cursor_plane_move: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109441]) +2 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-iclb2/igt@kms_psr@psr2_cursor_plane_move.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17912/shard-iclb4/igt@kms_psr@psr2_cursor_plane_move.html * igt@kms_vblank@pipe-b-ts-continuation-dpms-suspend: - shard-skl:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/tc: fix the reset of ln0
== Series Details ==
Series: drm/i915/tc: fix the reset of ln0
URL : https://patchwork.freedesktop.org/series/78132/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8601 -> Patchwork_17912
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17912/index.html
Known issues
Here are the changes found in Patchwork_17912 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [PASS][1] -> [DMESG-WARN][2] ([i915#62] / [i915#92] /
[i915#95])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17912/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
Possible fixes
* igt@debugfs_test@read_all_entries:
- fi-skl-6700k2: [{ABORT}][3] ([i915#1814]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/fi-skl-6700k2/igt@debugfs_test@read_all_entries.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17912/fi-skl-6700k2/igt@debugfs_test@read_all_entries.html
* igt@i915_module_load@reload:
- fi-byt-n2820: [DMESG-WARN][5] ([i915#1982]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/fi-byt-n2820/igt@i915_module_l...@reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17912/fi-byt-n2820/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [DMESG-WARN][7] ([i915#1982]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17912/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@basic-rte:
- fi-byt-j1900: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/fi-byt-j1900/igt@i915_pm_...@basic-rte.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17912/fi-byt-j1900/igt@i915_pm_...@basic-rte.html
* igt@i915_pm_rpm@module-reload:
- fi-glk-dsi: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/fi-glk-dsi/igt@i915_pm_...@module-reload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17912/fi-glk-dsi/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- {fi-kbl-7560u}: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17912/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
- fi-icl-u2: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16] +1
similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17912/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
Warnings
* igt@kms_cursor_legacy@basic-flip-before-cursor-varying-size:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][18] ([i915#62] / [i915#92]) +2 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-size.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17912/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-size.html
* igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92]) ->
[DMESG-WARN][20] ([i915#62] / [i915#92] / [i915#95]) +5 similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17912/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1814]: https://gitlab.freedesktop.org/drm/intel/issues/1814
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (49 -> 43)
--
Missing(6): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600
fi-byt-clapper
[Intel-gfx] [PATCH v5 12/13] drm/i915: Use debug category printer for welcome message
From: Sean Paul
The welcome printer is meant to be gated on DRM_UT_DRIVER, so use the
debug category printer to avoid dumping the message in the wrong
place.
Signed-off-by: Sean Paul
Changes in v5:
-Added to the set
---
drivers/gpu/drm/i915/i915_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 34ee12f3f02d..966212805ef7 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -876,7 +876,8 @@ static void i915_driver_unregister(struct drm_i915_private
*dev_priv)
static void i915_welcome_messages(struct drm_i915_private *dev_priv)
{
if (drm_debug_enabled(DRM_UT_DRIVER)) {
- struct drm_printer p = drm_debug_printer("i915 device info:");
+ struct drm_printer p = drm_debug_category_printer(DRM_UT_DRIVER,
+ "i915 device info:");
drm_printf(, "pciid=0x%04x rev=0x%02x platform=%s
(subplatform=0x%x) gen=%i\n",
INTEL_DEVID(dev_priv),
--
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 09/13] drm/i915: Change infoframe debug checks to specify syslog
From: Sean Paul
Since the logs protected by these checks specifically target syslog,
use the new drm_debug_syslog_enabled() call to avoid triggering
these prints when only trace is enabled.
Signed-off-by: Sean Paul
Changes in v5:
-Added to the set
---
drivers/gpu/drm/i915/display/intel_display.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index b16aca0fe5f0..de449755d1e5 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -12876,7 +12876,7 @@ static void
intel_dump_infoframe(struct drm_i915_private *dev_priv,
const union hdmi_infoframe *frame)
{
- if (!drm_debug_enabled(DRM_UT_KMS))
+ if (!drm_debug_syslog_enabled(DRM_UT_KMS))
return;
hdmi_infoframe_log(KERN_DEBUG, dev_priv->drm.dev, frame);
@@ -13519,7 +13519,7 @@ pipe_config_infoframe_mismatch(struct drm_i915_private
*dev_priv,
const union hdmi_infoframe *b)
{
if (fastset) {
- if (!drm_debug_enabled(DRM_UT_KMS))
+ if (!drm_debug_syslog_enabled(DRM_UT_KMS))
return;
drm_dbg_kms(_priv->drm,
--
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/tc: fix the reset of ln0
On Mon, 2020-06-08 at 13:54 -0700, José Roberto de Souza wrote: > On Mon, 2020-06-08 at 13:45 -0700, Khaled Almahallawy wrote: > > Setting ln0 similar to ln1 > Hum guess would good to have a Fixes tag to the patch adding the line fixed. > Reviewed-by: José Roberto de Souza > > > Signed-off-by: Khaled Almahallawy > > --- > > drivers/gpu/drm/i915/display/intel_ddi.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c > > b/drivers/gpu/drm/i915/display/intel_ddi.c > > index 96eaa4b39c68..1c0c369573e7 100644 > > --- a/drivers/gpu/drm/i915/display/intel_ddi.c > > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c > > @@ -3025,7 +3025,7 @@ icl_program_mg_dp_mode(struct intel_digital_port > > *intel_dig_port, > > ln1 = intel_de_read(dev_priv, MG_DP_MODE(1, tc_port)); > > } > > > > - ln0 &= ~(MG_DP_MODE_CFG_DP_X1_MODE | MG_DP_MODE_CFG_DP_X1_MODE); > > + ln0 &= ~(MG_DP_MODE_CFG_DP_X1_MODE | MG_DP_MODE_CFG_DP_X2_MODE); > > ln1 &= ~(MG_DP_MODE_CFG_DP_X1_MODE | MG_DP_MODE_CFG_DP_X2_MODE); > > > > /* DPPATC */ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 03/13] drm/i915/utils: Replace dev_printk with drm helpers
From: Sean Paul Use drm logging helpers to add support for the upcoming tracefs implementation. Signed-off-by: Sean Paul Changes in v5: -Added to the set --- drivers/gpu/drm/i915/i915_utils.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_utils.c b/drivers/gpu/drm/i915/i915_utils.c index f42a9e9a0b4f..99499c0885cf 100644 --- a/drivers/gpu/drm/i915/i915_utils.c +++ b/drivers/gpu/drm/i915/i915_utils.c @@ -30,10 +30,9 @@ __i915_printk(struct drm_i915_private *dev_priv, const char *level, vaf.va = if (is_error) - dev_printk(level, kdev, "%pV", ); + drm_dev_printk(kdev, level, "%pV", ); else - dev_printk(level, kdev, "[" DRM_NAME ":%ps] %pV", - __builtin_return_address(0), ); + drm_err(_priv->drm, "%pV", ); va_end(args); -- Sean Paul, Software Engineer, Google / Chromium OS ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/28] drm/i915/selftests: Make the hanging request non-preemptible
Chris Wilson writes:
> In some of our hangtests, we try to reset an active engine while it is
> spinning inside the recursive spinner. However, we also try to flood the
> engine with requests that preempt the hang, and so should disable the
> preemption to be sure that we reset the right request.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 36 ++--
> 1 file changed, 26 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
> b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
> index 4aa4cc917d8b..035f363fb0f8 100644
> --- a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
> +++ b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
> @@ -203,12 +203,12 @@ hang_create_request(struct hang *h, struct
> intel_engine_cs *engine)
> *batch++ = lower_32_bits(hws_address(hws, rq));
> *batch++ = upper_32_bits(hws_address(hws, rq));
> *batch++ = rq->fence.seqno;
> - *batch++ = MI_ARB_CHECK;
> + *batch++ = MI_NOOP;
>
> memset(batch, 0, 1024);
> batch += 1024 / sizeof(*batch);
>
> - *batch++ = MI_ARB_CHECK;
> + *batch++ = MI_NOOP;
> *batch++ = MI_BATCH_BUFFER_START | 1 << 8 | 1;
> *batch++ = lower_32_bits(vma->node.start);
> *batch++ = upper_32_bits(vma->node.start);
> @@ -217,12 +217,12 @@ hang_create_request(struct hang *h, struct
> intel_engine_cs *engine)
> *batch++ = 0;
> *batch++ = lower_32_bits(hws_address(hws, rq));
> *batch++ = rq->fence.seqno;
> - *batch++ = MI_ARB_CHECK;
> + *batch++ = MI_NOOP;
>
> memset(batch, 0, 1024);
> batch += 1024 / sizeof(*batch);
>
> - *batch++ = MI_ARB_CHECK;
> + *batch++ = MI_NOOP;
> *batch++ = MI_BATCH_BUFFER_START | 1 << 8;
> *batch++ = lower_32_bits(vma->node.start);
> } else if (INTEL_GEN(gt->i915) >= 4) {
> @@ -230,24 +230,24 @@ hang_create_request(struct hang *h, struct
> intel_engine_cs *engine)
> *batch++ = 0;
> *batch++ = lower_32_bits(hws_address(hws, rq));
> *batch++ = rq->fence.seqno;
> - *batch++ = MI_ARB_CHECK;
> + *batch++ = MI_NOOP;
>
> memset(batch, 0, 1024);
> batch += 1024 / sizeof(*batch);
>
> - *batch++ = MI_ARB_CHECK;
> + *batch++ = MI_NOOP;
> *batch++ = MI_BATCH_BUFFER_START | 2 << 6;
> *batch++ = lower_32_bits(vma->node.start);
> } else {
> *batch++ = MI_STORE_DWORD_IMM | MI_MEM_VIRTUAL;
> *batch++ = lower_32_bits(hws_address(hws, rq));
> *batch++ = rq->fence.seqno;
> - *batch++ = MI_ARB_CHECK;
> + *batch++ = MI_NOOP;
>
> memset(batch, 0, 1024);
> batch += 1024 / sizeof(*batch);
>
> - *batch++ = MI_ARB_CHECK;
> + *batch++ = MI_NOOP;
> *batch++ = MI_BATCH_BUFFER_START | 2 << 6;
> *batch++ = lower_32_bits(vma->node.start);
> }
> @@ -866,13 +866,29 @@ static int __igt_reset_engines(struct intel_gt *gt,
> count++;
>
> if (rq) {
> + if (rq->fence.error != -EIO) {
> + pr_err("i915_reset_engine(%s:%s):"
> +" failed to reset request
> %llx:%lld\n",
> +engine->name, test_name,
> +rq->fence.context,
> +rq->fence.seqno);
> + i915_request_put(rq);
> +
> + GEM_TRACE_DUMP();
> + intel_gt_set_wedged(gt);
> + err = -EIO;
> + break;
> + }
> +
> if (i915_request_wait(rq, 0, HZ / 5) < 0) {
> struct drm_printer p =
>
> drm_info_printer(gt->i915->drm.dev);
>
> pr_err("i915_reset_engine(%s:%s):"
> -" failed to complete request
> after reset\n",
> -engine->name, test_name);
> +" failed to complete request
> %llx:%lld after reset\n",
> +engine->name, test_name,
> +rq->fence.context,
> +rq->fence.seqno);
>
Re: [Intel-gfx] [PATCH] drm/i915/tc: fix the reset of ln0
On Mon, 2020-06-08 at 13:45 -0700, Khaled Almahallawy wrote: > Setting ln0 similar to ln1 Reviewed-by: José Roberto de Souza > > Signed-off-by: Khaled Almahallawy > --- > drivers/gpu/drm/i915/display/intel_ddi.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c > b/drivers/gpu/drm/i915/display/intel_ddi.c > index 96eaa4b39c68..1c0c369573e7 100644 > --- a/drivers/gpu/drm/i915/display/intel_ddi.c > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c > @@ -3025,7 +3025,7 @@ icl_program_mg_dp_mode(struct intel_digital_port > *intel_dig_port, > ln1 = intel_de_read(dev_priv, MG_DP_MODE(1, tc_port)); > } > > - ln0 &= ~(MG_DP_MODE_CFG_DP_X1_MODE | MG_DP_MODE_CFG_DP_X1_MODE); > + ln0 &= ~(MG_DP_MODE_CFG_DP_X1_MODE | MG_DP_MODE_CFG_DP_X2_MODE); > ln1 &= ~(MG_DP_MODE_CFG_DP_X1_MODE | MG_DP_MODE_CFG_DP_X2_MODE); > > /* DPPATC */ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/28] drm/i915: Adjust the sentinel assert to match implementation
Chris Wilson writes:
> From: Tvrtko Ursulin
>
> Sentinels are supposed to be last reqeusts in the elsp queue, not the
> only one, so adjust the assert accordingly.
s/reqeusts/requests
>
> Signed-off-by: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 14 +++---
> 1 file changed, 3 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index d55a5e0466e5..db8a170b0e5c 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -1635,9 +1635,9 @@ assert_pending_valid(const struct
> intel_engine_execlists *execlists,
> ccid = ce->lrc.ccid;
>
> /*
> - * Sentinels are supposed to be lonely so they flush the
> - * current exection off the HW. Check that they are the
> - * only request in the pending submission.
> + * Sentinels are supposed to be the last request so they flush
> + * the current exection off the HW. Check that they are the only
s/exection/exeqution
Reviewed-by: Mika Kuoppala
> + * request in the pending submission.
>*/
> if (sentinel) {
> GEM_TRACE_ERR("%s: context:%llx after sentinel in
> pending[%zd]\n",
> @@ -1646,15 +1646,7 @@ assert_pending_valid(const struct
> intel_engine_execlists *execlists,
> port - execlists->pending);
> return false;
> }
> -
> sentinel = i915_request_has_sentinel(rq);
> - if (sentinel && port != execlists->pending) {
> - GEM_TRACE_ERR("%s: sentinel context:%llx not in prime
> position[%zd]\n",
> - engine->name,
> - ce->timeline->fence_context,
> - port - execlists->pending);
> - return false;
> - }
>
> /* Hold tightly onto the lock to prevent concurrent retires! */
> if (!spin_trylock_irqsave(>lock, flags))
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/tc: fix the reset of ln0
Setting ln0 similar to ln1 Signed-off-by: Khaled Almahallawy --- drivers/gpu/drm/i915/display/intel_ddi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c b/drivers/gpu/drm/i915/display/intel_ddi.c index 96eaa4b39c68..1c0c369573e7 100644 --- a/drivers/gpu/drm/i915/display/intel_ddi.c +++ b/drivers/gpu/drm/i915/display/intel_ddi.c @@ -3025,7 +3025,7 @@ icl_program_mg_dp_mode(struct intel_digital_port *intel_dig_port, ln1 = intel_de_read(dev_priv, MG_DP_MODE(1, tc_port)); } - ln0 &= ~(MG_DP_MODE_CFG_DP_X1_MODE | MG_DP_MODE_CFG_DP_X1_MODE); + ln0 &= ~(MG_DP_MODE_CFG_DP_X1_MODE | MG_DP_MODE_CFG_DP_X2_MODE); ln1 &= ~(MG_DP_MODE_CFG_DP_X1_MODE | MG_DP_MODE_CFG_DP_X2_MODE); /* DPPATC */ -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix the i915_dsc_fec_support debugfs file for DP MST connectors (rev2)
== Series Details == Series: drm/i915: Fix the i915_dsc_fec_support debugfs file for DP MST connectors (rev2) URL : https://patchwork.freedesktop.org/series/78128/ State : success == Summary == CI Bug Log - changes from CI_DRM_8601_full -> Patchwork_17911_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17911_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_engines@idempotent: - shard-tglb: [PASS][1] -> [DMESG-WARN][2] ([i915#402]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-tglb6/igt@gem_ctx_engi...@idempotent.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17911/shard-tglb2/igt@gem_ctx_engi...@idempotent.html * igt@gem_exec_whisper@basic-queues-priority-all: - shard-glk: [PASS][3] -> [DMESG-WARN][4] ([i915#118] / [i915#95]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-glk4/igt@gem_exec_whis...@basic-queues-priority-all.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17911/shard-glk7/igt@gem_exec_whis...@basic-queues-priority-all.html * igt@gem_sync@basic-store-each: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([i915#95]) +11 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-apl3/igt@gem_s...@basic-store-each.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17911/shard-apl4/igt@gem_s...@basic-store-each.html * igt@i915_suspend@forcewake: - shard-kbl: [PASS][7] -> [DMESG-WARN][8] ([i915#180]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-kbl6/igt@i915_susp...@forcewake.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17911/shard-kbl2/igt@i915_susp...@forcewake.html * igt@kms_big_fb@y-tiled-64bpp-rotate-180: - shard-glk: [PASS][9] -> [DMESG-FAIL][10] ([i915#118] / [i915#95]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-glk6/igt@kms_big...@y-tiled-64bpp-rotate-180.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17911/shard-glk8/igt@kms_big...@y-tiled-64bpp-rotate-180.html * igt@kms_color@pipe-c-ctm-0-5: - shard-skl: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) +6 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-skl5/igt@kms_co...@pipe-c-ctm-0-5.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17911/shard-skl8/igt@kms_co...@pipe-c-ctm-0-5.html * igt@kms_color@pipe-c-ctm-blue-to-red: - shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([i915#93] / [i915#95]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-kbl6/igt@kms_co...@pipe-c-ctm-blue-to-red.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17911/shard-kbl2/igt@kms_co...@pipe-c-ctm-blue-to-red.html * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions: - shard-skl: [PASS][15] -> [FAIL][16] ([IGT#5]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-skl3/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17911/shard-skl4/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-onoff: - shard-tglb: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-tglb8/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-onoff.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17911/shard-tglb1/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-onoff.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-blt: - shard-snb: [PASS][19] -> [SKIP][20] ([fdo#109271]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-snb5/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-blt.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17911/shard-snb6/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-blt.html * igt@kms_frontbuffer_tracking@fbc-stridechange: - shard-glk: [PASS][21] -> [DMESG-WARN][22] ([i915#1982]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-glk4/igt@kms_frontbuffer_track...@fbc-stridechange.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17911/shard-glk6/igt@kms_frontbuffer_track...@fbc-stridechange.html * igt@kms_hdr@bpc-switch: - shard-skl: [PASS][23] -> [FAIL][24] ([i915#1188]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-skl7/igt@kms_...@bpc-switch.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17911/shard-skl6/igt@kms_...@bpc-switch.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes:
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Include asm sources for {ivb, hsw}_clear_kernel.c
== Series Details ==
Series: drm/i915: Include asm sources for {ivb, hsw}_clear_kernel.c
URL : https://patchwork.freedesktop.org/series/78126/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8601_full -> Patchwork_17910_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_17910_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_persistence@engines-mixed-process@rcs0:
- shard-apl: [PASS][1] -> [FAIL][2] ([i915#1528])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-apl8/igt@gem_ctx_persistence@engines-mixed-proc...@rcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17910/shard-apl6/igt@gem_ctx_persistence@engines-mixed-proc...@rcs0.html
* igt@gem_exec_create@forked:
- shard-glk: [PASS][3] -> [DMESG-WARN][4] ([i915#118] / [i915#95])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-glk5/igt@gem_exec_cre...@forked.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17910/shard-glk8/igt@gem_exec_cre...@forked.html
* igt@i915_pm_dc@dc6-psr:
- shard-iclb: [PASS][5] -> [FAIL][6] ([i915#454])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-iclb5/igt@i915_pm...@dc6-psr.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17910/shard-iclb2/igt@i915_pm...@dc6-psr.html
* igt@i915_suspend@sysfs-reader:
- shard-apl: [PASS][7] -> [DMESG-WARN][8] ([i915#180]) +7 similar
issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-apl3/igt@i915_susp...@sysfs-reader.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17910/shard-apl4/igt@i915_susp...@sysfs-reader.html
* igt@kms_color@pipe-c-ctm-0-25:
- shard-skl: [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) +8
similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-skl3/igt@kms_co...@pipe-c-ctm-0-25.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17910/shard-skl5/igt@kms_co...@pipe-c-ctm-0-25.html
* igt@kms_color@pipe-c-ctm-blue-to-red:
- shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([i915#93] / [i915#95])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-kbl6/igt@kms_co...@pipe-c-ctm-blue-to-red.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17910/shard-kbl7/igt@kms_co...@pipe-c-ctm-blue-to-red.html
* igt@kms_cursor_crc@pipe-a-cursor-256x85-onscreen:
- shard-hsw: [PASS][13] -> [INCOMPLETE][14] ([i915#61])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-hsw8/igt@kms_cursor_...@pipe-a-cursor-256x85-onscreen.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17910/shard-hsw8/igt@kms_cursor_...@pipe-a-cursor-256x85-onscreen.html
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-onoff:
- shard-apl: [PASS][15] -> [DMESG-WARN][16] ([i915#95]) +11
similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-apl6/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-onoff.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17910/shard-apl2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-onoff.html
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
- shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([i915#180]) +1
similar issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-kbl4/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17910/shard-kbl2/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html
* igt@kms_psr@psr2_cursor_plane_move:
- shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441]) +2 similar
issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-iclb2/igt@kms_psr@psr2_cursor_plane_move.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17910/shard-iclb7/igt@kms_psr@psr2_cursor_plane_move.html
* igt@kms_rmfb@rmfb-ioctl:
- shard-snb: [PASS][21] -> [SKIP][22] ([fdo#109271])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-snb1/igt@kms_r...@rmfb-ioctl.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17910/shard-snb2/igt@kms_r...@rmfb-ioctl.html
Possible fixes
* {igt@gem_exec_reloc@basic-concurrent0}:
- shard-glk: [FAIL][23] ([i915#1930]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-glk6/igt@gem_exec_re...@basic-concurrent0.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17910/shard-glk6/igt@gem_exec_re...@basic-concurrent0.html
* igt@gem_exec_whisper@basic-queues-forked:
- shard-glk: [DMESG-WARN][25] ([i915#118] / [i915#95]) ->
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix the i915_dsc_fec_support debugfs file for DP MST connectors (rev2)
== Series Details ==
Series: drm/i915: Fix the i915_dsc_fec_support debugfs file for DP MST
connectors (rev2)
URL : https://patchwork.freedesktop.org/series/78128/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8601 -> Patchwork_17911
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17911/index.html
Known issues
Here are the changes found in Patchwork_17911 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@module-reload:
- fi-byt-j1900: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/fi-byt-j1900/igt@i915_pm_...@module-reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17911/fi-byt-j1900/igt@i915_pm_...@module-reload.html
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [PASS][3] -> [DMESG-WARN][4] ([i915#62] / [i915#92] /
[i915#95])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17911/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-kefka: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17911/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- fi-icl-u2: [PASS][7] -> [DMESG-WARN][8] ([i915#1982])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17911/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
Possible fixes
* igt@i915_module_load@reload:
- fi-byt-n2820: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/fi-byt-n2820/igt@i915_module_l...@reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17911/fi-byt-n2820/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17911/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@basic-rte:
- fi-byt-j1900: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/fi-byt-j1900/igt@i915_pm_...@basic-rte.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17911/fi-byt-j1900/igt@i915_pm_...@basic-rte.html
* igt@i915_pm_rpm@module-reload:
- fi-glk-dsi: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/fi-glk-dsi/igt@i915_pm_...@module-reload.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17911/fi-glk-dsi/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
- fi-icl-u2: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18] +1
similar issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17911/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
Warnings
* igt@kms_cursor_legacy@basic-flip-before-cursor-varying-size:
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][20] ([i915#62] / [i915#92])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-size.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17911/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-size.html
* igt@kms_force_connector_basic@force-connector-state:
- fi-kbl-x1275: [DMESG-WARN][21] ([i915#62] / [i915#92]) ->
[DMESG-WARN][22] ([i915#62] / [i915#92] / [i915#95]) +2 similar issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/fi-kbl-x1275/igt@kms_force_connector_ba...@force-connector-state.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17911/fi-kbl-x1275/igt@kms_force_connector_ba...@force-connector-state.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1982]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Include asm sources for {ivb, hsw}_clear_kernel.c
== Series Details ==
Series: drm/i915: Include asm sources for {ivb, hsw}_clear_kernel.c
URL : https://patchwork.freedesktop.org/series/78126/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8601 -> Patchwork_17910
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17910/index.html
Known issues
Here are the changes found in Patchwork_17910 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [PASS][1] -> [DMESG-WARN][2] ([i915#62] / [i915#92] /
[i915#95])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17910/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-glk-dsi: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/fi-glk-dsi/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17910/fi-glk-dsi/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
Possible fixes
* igt@i915_module_load@reload:
- fi-byt-n2820: [DMESG-WARN][5] ([i915#1982]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/fi-byt-n2820/igt@i915_module_l...@reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17910/fi-byt-n2820/igt@i915_module_l...@reload.html
* igt@i915_pm_backlight@basic-brightness:
- fi-whl-u: [DMESG-WARN][7] ([i915#95]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17910/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17910/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@basic-rte:
- fi-byt-j1900: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/fi-byt-j1900/igt@i915_pm_...@basic-rte.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17910/fi-byt-j1900/igt@i915_pm_...@basic-rte.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
- fi-icl-u2: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14] +1
similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17910/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
Warnings
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-kbl-guc: [SKIP][15] ([fdo#109271]) -> [FAIL][16] ([i915#665] /
[i915#704])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/fi-kbl-guc/igt@i915_pm_...@basic-pci-d3-state.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17910/fi-kbl-guc/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [SKIP][17] ([fdo#109271]) -> [DMESG-FAIL][18]
([i915#62])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17910/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-varying-size:
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][20] ([i915#62] / [i915#92]) +1 similar issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-size.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17910/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-size.html
* igt@kms_force_connector_basic@force-connector-state:
- fi-kbl-x1275: [DMESG-WARN][21] ([i915#62] / [i915#92]) ->
[DMESG-WARN][22] ([i915#62] / [i915#92] / [i915#95]) +2 similar issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/fi-kbl-x1275/igt@kms_force_connector_ba...@force-connector-state.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17910/fi-kbl-x1275/igt@kms_force_connector_ba...@force-connector-state.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]:
[Intel-gfx] [PATCH v2] drm/i915: Fix the i915_dsc_fec_support debugfs file for DP MST connectors
DSC is not supported on DP MST streams so just return -EINVAL when
reading/writing the i915_dsc_fec_support debugfs file for such
connectors.
This also fixes an OOPS, caused by the encoder->digport cast, which is
not valid for MST encoders.
v2:
- Check encoder, which is unset for an MST connector, before it gets
enabled.
Signed-off-by: Imre Deak
---
.../drm/i915/display/intel_display_debugfs.c | 36 +++
1 file changed, 29 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 2b640d8ab9d2..9db6f7e0ccaa 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -2094,6 +2094,8 @@ static int i915_dsc_fec_support_show(struct seq_file *m,
void *data)
drm_modeset_acquire_init(, DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
do {
+ struct intel_encoder *encoder;
+
try_again = false;
ret = drm_modeset_lock(>mode_config.connection_mutex,
);
@@ -2120,8 +2122,17 @@ static int i915_dsc_fec_support_show(struct seq_file *m,
void *data)
} else if (ret) {
break;
}
- intel_dp = intel_attached_dp(to_intel_connector(connector));
+
+ encoder = intel_attached_encoder(to_intel_connector(connector));
+ /* TODO: Add DSC support for MST streams */
+ if (encoder->type == INTEL_OUTPUT_DP_MST) {
+ ret = -EINVAL;
+ break;
+ }
+
+ intel_dp = _to_dig_port(encoder)->dp;
crtc_state = to_intel_crtc_state(crtc->state);
+
seq_printf(m, "DSC_Enabled: %s\n",
yesno(crtc_state->dsc.compression_enable));
seq_printf(m, "DSC_Sink_Support: %s\n",
@@ -2147,9 +2158,8 @@ static ssize_t i915_dsc_fec_support_write(struct file
*file,
int ret;
struct drm_connector *connector =
((struct seq_file *)file->private_data)->private;
- struct intel_encoder *encoder =
intel_attached_encoder(to_intel_connector(connector));
- struct drm_i915_private *i915 = to_i915(encoder->base.dev);
- struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+ struct drm_i915_private *i915 = to_i915(connector->dev);
+ struct intel_encoder *encoder;
if (len == 0)
return 0;
@@ -2163,10 +2173,22 @@ static ssize_t i915_dsc_fec_support_write(struct file
*file,
drm_dbg(>drm, "Got %s for DSC Enable\n",
(dsc_enable) ? "true" : "false");
- intel_dp->force_dsc_en = dsc_enable;
- *offp += len;
- return len;
+ drm_modeset_lock(>drm.mode_config.connection_mutex, NULL);
+
+ encoder = intel_attached_encoder(to_intel_connector(connector));
+ /* TODO: Add DSC support for MST streams */
+ if (!encoder || encoder->type == INTEL_OUTPUT_DP_MST) {
+ ret = -EINVAL;
+ } else {
+ enc_to_intel_dp(encoder)->force_dsc_en = dsc_enable;
+ *offp += len;
+ ret = len;
+ }
+
+ drm_modeset_unlock(>drm.mode_config.connection_mutex);
+
+ return ret;
}
static int i915_dsc_fec_support_open(struct inode *inode,
--
2.23.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/mm: remove invalid entry based optimization
== Series Details == Series: drm/mm: remove invalid entry based optimization URL : https://patchwork.freedesktop.org/series/78125/ State : success == Summary == CI Bug Log - changes from CI_DRM_8601_full -> Patchwork_17909_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17909_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@processes: - shard-skl: [PASS][1] -> [FAIL][2] ([i915#1528]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-skl5/igt@gem_ctx_persiste...@processes.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17909/shard-skl6/igt@gem_ctx_persiste...@processes.html * igt@gem_exec_whisper@basic-queues-priority-all: - shard-glk: [PASS][3] -> [DMESG-WARN][4] ([i915#118] / [i915#95]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-glk4/igt@gem_exec_whis...@basic-queues-priority-all.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17909/shard-glk1/igt@gem_exec_whis...@basic-queues-priority-all.html * igt@gem_sync@basic-store-each: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([i915#95]) +14 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-apl3/igt@gem_s...@basic-store-each.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17909/shard-apl1/igt@gem_s...@basic-store-each.html * igt@i915_module_load@reload: - shard-tglb: [PASS][7] -> [DMESG-WARN][8] ([i915#402]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-tglb5/igt@i915_module_l...@reload.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17909/shard-tglb6/igt@i915_module_l...@reload.html * igt@i915_pm_dc@dc6-psr: - shard-skl: [PASS][9] -> [FAIL][10] ([i915#454]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-skl9/igt@i915_pm...@dc6-psr.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17909/shard-skl5/igt@i915_pm...@dc6-psr.html * igt@i915_suspend@forcewake: - shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([i915#180]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-kbl6/igt@i915_susp...@forcewake.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17909/shard-kbl2/igt@i915_susp...@forcewake.html * igt@kms_big_fb@linear-16bpp-rotate-0: - shard-apl: [PASS][13] -> [DMESG-WARN][14] ([i915#1982]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-apl2/igt@kms_big...@linear-16bpp-rotate-0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17909/shard-apl2/igt@kms_big...@linear-16bpp-rotate-0.html * igt@kms_big_fb@y-tiled-64bpp-rotate-0: - shard-glk: [PASS][15] -> [DMESG-FAIL][16] ([i915#118] / [i915#95]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-glk5/igt@kms_big...@y-tiled-64bpp-rotate-0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17909/shard-glk8/igt@kms_big...@y-tiled-64bpp-rotate-0.html * igt@kms_color@pipe-a-ctm-blue-to-red: - shard-skl: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) +4 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-skl2/igt@kms_co...@pipe-a-ctm-blue-to-red.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17909/shard-skl10/igt@kms_co...@pipe-a-ctm-blue-to-red.html * igt@kms_color@pipe-c-ctm-blue-to-red: - shard-kbl: [PASS][19] -> [DMESG-WARN][20] ([i915#93] / [i915#95]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-kbl6/igt@kms_co...@pipe-c-ctm-blue-to-red.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17909/shard-kbl1/igt@kms_co...@pipe-c-ctm-blue-to-red.html * igt@kms_cursor_crc@pipe-b-cursor-suspend: - shard-apl: [PASS][21] -> [DMESG-WARN][22] ([i915#180]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-apl3/igt@kms_cursor_...@pipe-b-cursor-suspend.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17909/shard-apl1/igt@kms_cursor_...@pipe-b-cursor-suspend.html * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min: - shard-skl: [PASS][23] -> [FAIL][24] ([fdo#108145] / [i915#265]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-skl2/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17909/shard-skl10/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html * igt@kms_psr@no_drrs: - shard-iclb: [PASS][25] -> [FAIL][26] ([i915#173]) [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/shard-iclb2/igt@kms_psr@no_drrs.html [26]:
Re: [Intel-gfx] [PATCH] drm/i915: Include asm sources for {ivb, hsw}_clear_kernel.c
Quoting Rodrigo Vivi (2020-06-08 18:46:53)
> Alexandre Oliva has recently removed these files from Linux Libre
> with concerns that the sources weren't available.
>
> The sources are available on IGT repository, and only open source
> tools are used to generate the {ivb,hsw}_clear_kernel.c files.
>
> However, the remaining concern from Alexandre Oliva was around
> GPL license and the source not been present when distributing
> the code.
>
> So, it looks like 2 alternatives are possible, the use of
> linux-firmware.git repository to store the blob or making sure
> that the source is also present in our tree. Since the goal
> is to limit the i915 firmware to only the micro-controller blobs
> let's make sure that we do include the asm sources here in our tree.
>
> Btw, I tried to have some diligence here and make sure that the
> asms that these commits are adding are truly the source for
> the mentioned files:
>
> ./scripts/generate_clear_kernel.sh -g ivb -m
> /home/vivijim/intel/freedesktop.org/mesa/mesa/build/src/intel/tools/i965_asm
>
> igt$ ./scripts/generate_clear_kernel.sh -g ivb -m
> /home/vivijim/intel/freedesktop.org/mesa/mesa/build/src/intel/tools/i965_asm
> Output file not specified - using default file "ivb-cb_assembled"
>
> Generating gen7 CB Kernel assembled file "ivb_clear_kernel.c" for i915
> driver...
>
> igt$ diff
> /home/vivijim/i915/drm-tip/drivers/gpu/drm/i915/gt/ivb_clear_kernel.c
> ivb_clear_kernel.c
> 5c5
> < * Generated by: IGT Gpu Tools on Fri 21 Feb 2020 05:29:32 AM UTC
> ---
> > * Generated by: IGT Gpu Tools on Mon 08 Jun 2020 10:00:54 AM PDT
> 61c61
> < };
> ---
> > };
> \ No newline at end of file
>
> igt$ ./scripts/generate_clear_kernel.sh -g hsw -m /hom
> e/vivijim/intel/freedesktop.org/mesa/mesa/build/src/intel/tools/i965_asm
> Output file not specified - using default file "hsw-cb_assembled"
>
> Generating gen7.5 CB Kernel assembled file "hsw_clear_kernel.c" for i915
> driver...
>
> igt$ diff
> /home/vivijim/i915/drm-tip/drivers/gpu/drm/i915/gt/hsw_clear_kernel.c
> hsw_clear_kernel.c
> 5c5
> < * Generated by: IGT Gpu Tools on Fri 21 Feb 2020 05:30:13 AM UTC
> ---
> > * Generated by: IGT Gpu Tools on Mon 08 Jun 2020 10:01:42 AM PDT
> 61c61
> < };
> ---
> > };
> \ No newline at end of file
>
> Used IGT and Mesa master repositories from Fri Jun 5 2020)
> IGT: 53e8c878a6fb ("tests/kms_chamelium: Force reprobe after replugging the
> connector")
> Mesa: 5d13c7477eb1 ("radv: set keep_statistic_info with
> RADV_DEBUG=shaderstats")
> Mesa built with: meson build -D platforms=drm,x11 -D dri-drivers=i965 -D
> gallium-drivers=iris -D prefix=/usr -D libdir=/usr/lib64/ -Dtools=intel
> -Dkulkan-drivers=intel && ninja -C build
>
> Reference: http://www.fsfla.org/pipermail/linux-libre/2020-June/003374.html
> Reference: http://www.fsfla.org/pipermail/linux-libre/2020-June/003375.html
> Fixes: 47f8253d2b89 ("drm/i915/gen7: Clear all EU/L3 residual contexts")
> Cc: # v5.7+
> Cc: Alexandre Oliva
> Cc: Prathap Kumar Valsan
> Cc: Akeem G Abodunrin
> Cc: Mika Kuoppala
> Cc: Chris Wilson
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Signed-off-by: Rodrigo Vivi
> ---
> .../drm/i915/gt/shaders/clear_kernel/hsw.asm | 141 ++
> .../drm/i915/gt/shaders/clear_kernel/ivb.asm | 139 +
> 2 files changed, 280 insertions(+)
> create mode 100644 drivers/gpu/drm/i915/gt/shaders/clear_kernel/hsw.asm
> create mode 100644 drivers/gpu/drm/i915/gt/shaders/clear_kernel/ivb.asm
>
> diff --git a/drivers/gpu/drm/i915/gt/shaders/clear_kernel/hsw.asm
> b/drivers/gpu/drm/i915/gt/shaders/clear_kernel/hsw.asm
> new file mode 100644
> index ..bc29baf22c61
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/gt/shaders/clear_kernel/hsw.asm
> @@ -0,0 +1,141 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright © 2020 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Include asm sources for {ivb, hsw}_clear_kernel.c
== Series Details ==
Series: drm/i915: Include asm sources for {ivb, hsw}_clear_kernel.c
URL : https://patchwork.freedesktop.org/series/78126/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
62de4aea38dc drm/i915: Include asm sources for {ivb, hsw}_clear_kernel.c
-:26: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#26:
./scripts/generate_clear_kernel.sh -g ivb -m
/home/vivijim/intel/freedesktop.org/mesa/mesa/build/src/intel/tools/i965_asm
-:33: WARNING:USE_RELATIVE_PATH: use relative pathname instead of absolute in
changelog text
#33:
igt$ diff /home/vivijim/i915/drm-tip/drivers/gpu/drm/i915/gt/ivb_clear_kernel.c
ivb_clear_kernel.c
-:38: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#38:
new file mode 100644
-:328: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s)
total: 1 errors, 3 warnings, 0 checks, 280 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Fix the i915_dsc_fec_support debugfs file for DP MST connectors
DSC is not supported on DP MST streams so just return -EINVAL when
reading/writing the i915_dsc_fec_support debugfs file for such
connectors.
This also fixes an OOPS, caused by the encoder->digport cast, which is
not valid for MST encoders.
Signed-off-by: Imre Deak
---
.../drm/i915/display/intel_display_debugfs.c | 36 +++
1 file changed, 29 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 2b640d8ab9d2..ebca8e488d03 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -2094,6 +2094,8 @@ static int i915_dsc_fec_support_show(struct seq_file *m,
void *data)
drm_modeset_acquire_init(, DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
do {
+ struct intel_encoder *encoder;
+
try_again = false;
ret = drm_modeset_lock(>mode_config.connection_mutex,
);
@@ -2120,8 +2122,17 @@ static int i915_dsc_fec_support_show(struct seq_file *m,
void *data)
} else if (ret) {
break;
}
- intel_dp = intel_attached_dp(to_intel_connector(connector));
+
+ encoder = intel_attached_encoder(to_intel_connector(connector));
+ /* TODO: Add DSC support for MST streams */
+ if (encoder->type == INTEL_OUTPUT_DP_MST) {
+ ret = -EINVAL;
+ break;
+ }
+
+ intel_dp = _to_dig_port(encoder)->dp;
crtc_state = to_intel_crtc_state(crtc->state);
+
seq_printf(m, "DSC_Enabled: %s\n",
yesno(crtc_state->dsc.compression_enable));
seq_printf(m, "DSC_Sink_Support: %s\n",
@@ -2147,9 +2158,8 @@ static ssize_t i915_dsc_fec_support_write(struct file
*file,
int ret;
struct drm_connector *connector =
((struct seq_file *)file->private_data)->private;
- struct intel_encoder *encoder =
intel_attached_encoder(to_intel_connector(connector));
- struct drm_i915_private *i915 = to_i915(encoder->base.dev);
- struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+ struct drm_i915_private *i915 = to_i915(connector->dev);
+ struct intel_encoder *encoder;
if (len == 0)
return 0;
@@ -2163,10 +2173,22 @@ static ssize_t i915_dsc_fec_support_write(struct file
*file,
drm_dbg(>drm, "Got %s for DSC Enable\n",
(dsc_enable) ? "true" : "false");
- intel_dp->force_dsc_en = dsc_enable;
- *offp += len;
- return len;
+ drm_modeset_lock(>drm.mode_config.connection_mutex, NULL);
+
+ encoder = intel_attached_encoder(to_intel_connector(connector));
+ /* TODO: Add DSC support for MST streams */
+ if (encoder->type == INTEL_OUTPUT_DP_MST) {
+ ret = -EINVAL;
+ } else {
+ enc_to_intel_dp(encoder)->force_dsc_en = dsc_enable;
+ *offp += len;
+ ret = len;
+ }
+
+ drm_modeset_unlock(>drm.mode_config.connection_mutex);
+
+ return ret;
}
static int i915_dsc_fec_support_open(struct inode *inode,
--
2.23.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Include asm sources for {ivb, hsw}_clear_kernel.c
Alexandre Oliva has recently removed these files from Linux Libre
with concerns that the sources weren't available.
The sources are available on IGT repository, and only open source
tools are used to generate the {ivb,hsw}_clear_kernel.c files.
However, the remaining concern from Alexandre Oliva was around
GPL license and the source not been present when distributing
the code.
So, it looks like 2 alternatives are possible, the use of
linux-firmware.git repository to store the blob or making sure
that the source is also present in our tree. Since the goal
is to limit the i915 firmware to only the micro-controller blobs
let's make sure that we do include the asm sources here in our tree.
Btw, I tried to have some diligence here and make sure that the
asms that these commits are adding are truly the source for
the mentioned files:
./scripts/generate_clear_kernel.sh -g ivb -m
/home/vivijim/intel/freedesktop.org/mesa/mesa/build/src/intel/tools/i965_asm
igt$ ./scripts/generate_clear_kernel.sh -g ivb -m
/home/vivijim/intel/freedesktop.org/mesa/mesa/build/src/intel/tools/i965_asm
Output file not specified - using default file "ivb-cb_assembled"
Generating gen7 CB Kernel assembled file "ivb_clear_kernel.c" for i915 driver...
igt$ diff /home/vivijim/i915/drm-tip/drivers/gpu/drm/i915/gt/ivb_clear_kernel.c
ivb_clear_kernel.c
5c5
< * Generated by: IGT Gpu Tools on Fri 21 Feb 2020 05:29:32 AM UTC
---
> * Generated by: IGT Gpu Tools on Mon 08 Jun 2020 10:00:54 AM PDT
61c61
< };
---
> };
\ No newline at end of file
igt$ ./scripts/generate_clear_kernel.sh -g hsw -m /hom
e/vivijim/intel/freedesktop.org/mesa/mesa/build/src/intel/tools/i965_asm
Output file not specified - using default file "hsw-cb_assembled"
Generating gen7.5 CB Kernel assembled file "hsw_clear_kernel.c" for i915
driver...
igt$ diff /home/vivijim/i915/drm-tip/drivers/gpu/drm/i915/gt/hsw_clear_kernel.c
hsw_clear_kernel.c
5c5
< * Generated by: IGT Gpu Tools on Fri 21 Feb 2020 05:30:13 AM UTC
---
> * Generated by: IGT Gpu Tools on Mon 08 Jun 2020 10:01:42 AM PDT
61c61
< };
---
> };
\ No newline at end of file
Used IGT and Mesa master repositories from Fri Jun 5 2020)
IGT: 53e8c878a6fb ("tests/kms_chamelium: Force reprobe after replugging the
connector")
Mesa: 5d13c7477eb1 ("radv: set keep_statistic_info with RADV_DEBUG=shaderstats")
Mesa built with: meson build -D platforms=drm,x11 -D dri-drivers=i965 -D
gallium-drivers=iris -D prefix=/usr -D libdir=/usr/lib64/ -Dtools=intel
-Dkulkan-drivers=intel && ninja -C build
Reference: http://www.fsfla.org/pipermail/linux-libre/2020-June/003374.html
Reference: http://www.fsfla.org/pipermail/linux-libre/2020-June/003375.html
Fixes: 47f8253d2b89 ("drm/i915/gen7: Clear all EU/L3 residual contexts")
Cc: # v5.7+
Cc: Alexandre Oliva
Cc: Prathap Kumar Valsan
Cc: Akeem G Abodunrin
Cc: Mika Kuoppala
Cc: Chris Wilson
Cc: Jani Nikula
Cc: Joonas Lahtinen
Signed-off-by: Rodrigo Vivi
---
.../drm/i915/gt/shaders/clear_kernel/hsw.asm | 141 ++
.../drm/i915/gt/shaders/clear_kernel/ivb.asm | 139 +
2 files changed, 280 insertions(+)
create mode 100644 drivers/gpu/drm/i915/gt/shaders/clear_kernel/hsw.asm
create mode 100644 drivers/gpu/drm/i915/gt/shaders/clear_kernel/ivb.asm
diff --git a/drivers/gpu/drm/i915/gt/shaders/clear_kernel/hsw.asm
b/drivers/gpu/drm/i915/gt/shaders/clear_kernel/hsw.asm
new file mode 100644
index ..bc29baf22c61
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/shaders/clear_kernel/hsw.asm
@@ -0,0 +1,141 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2020 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ */
+
+/**
+ * Kernel name: hsw_clear_buf.asm
+ *
+ * Kernel for PAVP buffer clear.
+ *
+ * 1. Clear all 64 GRF registers assigned to the kernel with designated
value;
+ * 2. Write 32x16 block of all "0" to render target buffer which
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/mm: remove invalid entry based optimization
== Series Details ==
Series: drm/mm: remove invalid entry based optimization
URL : https://patchwork.freedesktop.org/series/78125/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8601 -> Patchwork_17909
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17909/index.html
Known issues
Here are the changes found in Patchwork_17909 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-icl-u2: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17909/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
- fi-bsw-kefka: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17909/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
Possible fixes
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [DMESG-WARN][5] ([i915#1982]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17909/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@basic-rte:
- fi-byt-j1900: [DMESG-WARN][7] ([i915#1982]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/fi-byt-j1900/igt@i915_pm_...@basic-rte.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17909/fi-byt-j1900/igt@i915_pm_...@basic-rte.html
* igt@i915_pm_rpm@module-reload:
- fi-glk-dsi: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/fi-glk-dsi/igt@i915_pm_...@module-reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17909/fi-glk-dsi/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
- fi-icl-u2: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12] +1
similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17909/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
Warnings
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275: [DMESG-WARN][13] ([i915#62] / [i915#92]) ->
[DMESG-WARN][14] ([i915#1982] / [i915#62] / [i915#92] / [i915#95])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17909/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
* igt@gem_exec_suspend@basic-s3:
- fi-kbl-x1275: [DMESG-WARN][15] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][16] ([i915#62] / [i915#92]) +1 similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17909/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [SKIP][17] ([fdo#109271]) -> [DMESG-FAIL][18]
([i915#62])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17909/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
* igt@kms_force_connector_basic@force-connector-state:
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92]) ->
[DMESG-WARN][20] ([i915#62] / [i915#92] / [i915#95]) +3 similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8601/fi-kbl-x1275/igt@kms_force_connector_ba...@force-connector-state.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17909/fi-kbl-x1275/igt@kms_force_connector_ba...@force-connector-state.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (49 -> 42)
--
Missing(7): fi-ilk-m540 fi-byt-squawks
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/mm: remove invalid entry based optimization
== Series Details == Series: drm/mm: remove invalid entry based optimization URL : https://patchwork.freedesktop.org/series/78125/ State : warning == Summary == $ dim checkpatch origin/drm-tip 700bb6db2857 drm/mm: remove invalid entry based optimization -:40: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author '"Christian König" ' total: 0 errors, 1 warnings, 0 checks, 18 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] A panic and a hang in the i915 drm driver
Jani Nikula wrote: > David, please try [1]. Assuming you mean this: https://patchwork.freedesktop.org/patch/366958/?series=77635=1 yes, that works. Tested-by: David Howells ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/display: Avoid PSR and FBC features concurently.
On Sun, 2020-06-07 at 23:56 -0700, Jason Le wrote:
> Issue: Enble both PSR and FBC caused some fickers on some eDP panels (eg.
> Panel GIS
> 13.5" QHD Glare NE135FBM-N41/NC135GFL02). Disbling either PSR or FBC
> will solve this flicker issue.
>
> Both PSR and FBC features save power when render is not busy. When PSR is
> active, saving power achieved by source turning off source transmitter and
> main link,
> putting memory on self-refresh mode. Therefore with PSR enabled,
> FBC role is minimized since PSR power saving already covers most what
> FBC does. Disabling FBC in case to avoid conflict between PSR and FBC
> which causes display anomaly in some scenarios.
The combination of both saves even more power so no to this, we should fix the
issue not disable features because of a single panel having issues.
A PSR2 fix was merged yesterday "drm/i915/psr: Program default IO buffer Wake
and Fast Wake" try with that, if just that don't fix try set
psr_safest_params=1.
If this do not helps, please file a bug, add debug information and then we
proceed from that.
>
> Tests:
> Booted system with PSR enabled, verified FBC disabled.
> Disabled PSR with disabled (i915.enable_psr=0), verified FBC enabled.
> ---
> drivers/gpu/drm/i915/display/intel_fbc.c | 6 ++
> drivers/gpu/drm/i915/display/intel_psr.c | 4 +++-
> 2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
> b/drivers/gpu/drm/i915/display/intel_fbc.c
> index 1c26673acb2d..52bc7483adb5 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> @@ -1419,6 +1419,12 @@ void intel_fbc_init(struct drm_i915_private *dev_priv)
> drm_dbg_kms(_priv->drm, "Sanitized enable_fbc value: %d\n",
> i915_modparams.enable_fbc);
>
> + if (i915_modparams.enable_psr) {
> + i915_modparams.enable_fbc = 0;
> +DRM_DEBUG_KMS("PSR enabled. FBC no longer needed. Disable
> FBC. \n");
> + }
> +
> +
> if (!HAS_FBC(dev_priv)) {
> fbc->no_fbc_reason = "unsupported by this chipset";
> return;
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index b7a2c102648a..25accfdd5ad3 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1439,8 +1439,10 @@ void intel_psr_init(struct drm_i915_private *dev_priv)
> if (!HAS_PSR(dev_priv))
> return;
>
> - if (!dev_priv->psr.sink_support)
> + if (!dev_priv->psr.sink_support) {
> + i915_modparams.enable_psr = 0;
> return;
> + }
>
> if (IS_HASWELL(dev_priv))
> /*
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/mm: remove invalid entry based optimization
When the current entry is rejected as candidate for the search it does not mean that we can abort the subtree search. It is perfectly possible that only the alignment, but not the size is the reason for the rejection. Signed-off-by: Christian König --- drivers/gpu/drm/drm_mm.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c index 60e9a9c91e9d..82d2888eb7fe 100644 --- a/drivers/gpu/drm/drm_mm.c +++ b/drivers/gpu/drm/drm_mm.c @@ -406,8 +406,7 @@ next_hole_high_addr(struct drm_mm_node *entry, u64 size) parent_rb_node = rb_parent(rb_node); left_node = rb_entry(left_rb_node, struct drm_mm_node, rb_hole_addr); - if ((left_node->subtree_max_hole < size || -HOLE_SIZE(entry) == entry->subtree_max_hole) && + if (left_node->subtree_max_hole < size && parent_rb_node && parent_rb_node->rb_left != rb_node) return rb_hole_addr_to_node(parent_rb_node); } @@ -446,8 +445,7 @@ next_hole_low_addr(struct drm_mm_node *entry, u64 size) parent_rb_node = rb_parent(rb_node); right_node = rb_entry(right_rb_node, struct drm_mm_node, rb_hole_addr); - if ((right_node->subtree_max_hole < size || -HOLE_SIZE(entry) == entry->subtree_max_hole) && + if (right_node->subtree_max_hole < size && parent_rb_node && parent_rb_node->rb_right != rb_node) return rb_hole_addr_to_node(parent_rb_node); } -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gt: Prevent enabling breadcrumbs on the virtual engine (rev2)
== Series Details == Series: drm/i915/gt: Prevent enabling breadcrumbs on the virtual engine (rev2) URL : https://patchwork.freedesktop.org/series/78117/ State : success == Summary == CI Bug Log - changes from CI_DRM_8600_full -> Patchwork_17908_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17908_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_create@forked: - shard-glk: [PASS][1] -> [DMESG-WARN][2] ([i915#118] / [i915#95]) +2 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/shard-glk4/igt@gem_exec_cre...@forked.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17908/shard-glk5/igt@gem_exec_cre...@forked.html * igt@i915_module_load@reload-with-fault-injection: - shard-tglb: [PASS][3] -> [DMESG-WARN][4] ([i915#402]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/shard-tglb5/igt@i915_module_l...@reload-with-fault-injection.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17908/shard-tglb3/igt@i915_module_l...@reload-with-fault-injection.html * igt@i915_pm_dc@dc6-psr: - shard-iclb: [PASS][5] -> [FAIL][6] ([i915#454]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/shard-iclb4/igt@i915_pm...@dc6-psr.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17908/shard-iclb2/igt@i915_pm...@dc6-psr.html - shard-skl: [PASS][7] -> [DMESG-FAIL][8] ([i915#1982]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/shard-skl6/igt@i915_pm...@dc6-psr.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17908/shard-skl4/igt@i915_pm...@dc6-psr.html * igt@i915_suspend@fence-restore-untiled: - shard-skl: [PASS][9] -> [INCOMPLETE][10] ([i915#69]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/shard-skl1/igt@i915_susp...@fence-restore-untiled.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17908/shard-skl3/igt@i915_susp...@fence-restore-untiled.html * igt@kms_big_fb@y-tiled-32bpp-rotate-180: - shard-skl: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) +9 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/shard-skl9/igt@kms_big...@y-tiled-32bpp-rotate-180.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17908/shard-skl2/igt@kms_big...@y-tiled-32bpp-rotate-180.html * igt@kms_color@pipe-c-ctm-blue-to-red: - shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([i915#93] / [i915#95]) +2 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/shard-kbl3/igt@kms_co...@pipe-c-ctm-blue-to-red.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17908/shard-kbl1/igt@kms_co...@pipe-c-ctm-blue-to-red.html * igt@kms_cursor_crc@pipe-c-cursor-256x256-sliding: - shard-skl: [PASS][15] -> [FAIL][16] ([i915#54]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/shard-skl6/igt@kms_cursor_...@pipe-c-cursor-256x256-sliding.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17908/shard-skl1/igt@kms_cursor_...@pipe-c-cursor-256x256-sliding.html * igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-atomic: - shard-iclb: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/shard-iclb1/igt@kms_cursor_leg...@flip-vs-cursor-busy-crc-atomic.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17908/shard-iclb3/igt@kms_cursor_leg...@flip-vs-cursor-busy-crc-atomic.html * igt@kms_draw_crc@draw-method-xrgb-render-xtiled: - shard-skl: [PASS][19] -> [FAIL][20] ([i915#52] / [i915#54]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/shard-skl3/igt@kms_draw_...@draw-method-xrgb-render-xtiled.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17908/shard-skl9/igt@kms_draw_...@draw-method-xrgb-render-xtiled.html * igt@kms_fbcon_fbt@fbc-suspend: - shard-glk: [PASS][21] -> [FAIL][22] ([i915#64]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/shard-glk2/igt@kms_fbcon_...@fbc-suspend.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17908/shard-glk9/igt@kms_fbcon_...@fbc-suspend.html * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-mmap-gtt: - shard-apl: [PASS][23] -> [DMESG-WARN][24] ([i915#95]) +22 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/shard-apl6/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-mmap-gtt.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17908/shard-apl3/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-mmap-gtt.html * igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw: - shard-tglb: [PASS][25]
Re: [Intel-gfx] [PATCH 8/9] drm/shmem-helpers: Ensure get_pages is not called on imported dma-buf
On Mon, Jun 08, 2020 at 04:40:26PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 03.06.20 um 15:12 schrieb Daniel Vetter:
> > On Thu, May 14, 2020 at 09:30:04AM +0200, Thomas Zimmermann wrote:
> >> Hi
> >>
> >> Am 11.05.20 um 11:35 schrieb Daniel Vetter:
> >>> Just a bit of light paranoia. Also sprinkle this check over
> >>> drm_gem_shmem_get_sg_table, which should only be called when
> >>> exporting, same for the pin/unpin functions, on which it relies to
> >>> work correctly.
> >>>
> >>> Cc: Gerd Hoffmann
> >>> Cc: Rob Herring
> >>> Cc: Noralf Trønnes
> >>> Signed-off-by: Daniel Vetter
> >>> ---
> >>> drivers/gpu/drm/drm_gem_shmem_helper.c | 10 ++
> >>> 1 file changed, 10 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
> >>> b/drivers/gpu/drm/drm_gem_shmem_helper.c
> >>> index 117a7841e284..f7011338813e 100644
> >>> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> >>> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> >>> @@ -170,6 +170,8 @@ int drm_gem_shmem_get_pages(struct
> >>> drm_gem_shmem_object *shmem)
> >>> {
> >>> int ret;
> >>>
> >>> + WARN_ON(shmem->base.import_attach);
> >>> +
> >>> ret = mutex_lock_interruptible(>pages_lock);
> >>> if (ret)
> >>> return ret;
> >>> @@ -225,6 +227,8 @@ int drm_gem_shmem_pin(struct drm_gem_object *obj)
> >>> {
> >>> struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj);
> >>>
> >>> + WARN_ON(shmem->base.import_attach);
> >>> +
> >>
> >> I don't understand this change. If a driver pins pages it now has to
> >> check that the pages are not imported?
> >
> > Nope. There's two classes of functions in the helpers, and I'm trying to
> > unconfuse them:
> >
> > - stuff used to implement gem_funcs. These are obviously only ever used on
> > native objects, never on imported ones (on imported ones we try to
> > forward through the dma-buf layer to the exporter). drm_gem_shmem_pin is
> > only used in that role to implement gem_funcs->pin. Calling it on an
> > imported buffer is indeed a bug.
> >
> > - the other set of functions are for drivers to do their stuff. The
> > interface which (implicitly) pins stuff into places is various set of
> > get_pages, which do have different paths for native and imported
> > objects.
>
> Thanks for explaining. Patch is
Thanks for taking a look at all this, last 2 patches now also merged to
drm-misc-next.
-Daniel
>
> Acked-by: Thomas Zimmermann
>
> >
> > Apologies that I missed your question here, I merged all the patches
> > leading up to this one for now.
> >
> > Thanks, Daniel
> >
> >>
> >>
> >>> return drm_gem_shmem_get_pages(shmem);
> >>> }
> >>> EXPORT_SYMBOL(drm_gem_shmem_pin);
> >>> @@ -240,6 +244,8 @@ void drm_gem_shmem_unpin(struct drm_gem_object *obj)
> >>> {
> >>> struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj);
> >>>
> >>> + WARN_ON(shmem->base.import_attach);
> >>> +
> >>> drm_gem_shmem_put_pages(shmem);
> >>> }
> >>> EXPORT_SYMBOL(drm_gem_shmem_unpin);
> >>> @@ -510,6 +516,8 @@ static void drm_gem_shmem_vm_open(struct
> >>> vm_area_struct *vma)
> >>> struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj);
> >>> int ret;
> >>>
> >>> + WARN_ON(shmem->base.import_attach);
> >>> +
> >>> ret = drm_gem_shmem_get_pages(shmem);
> >>> WARN_ON_ONCE(ret != 0);
> >>>
> >>> @@ -611,6 +619,8 @@ struct sg_table *drm_gem_shmem_get_sg_table(struct
> >>> drm_gem_object *obj)
> >>> {
> >>> struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj);
> >>>
> >>> + WARN_ON(shmem->base.import_attach);
> >>> +
> >>> return drm_prime_pages_to_sg(shmem->pages, obj->size >> PAGE_SHIFT);
> >>> }
> >>> EXPORT_SYMBOL_GPL(drm_gem_shmem_get_sg_table);
> >>>
> >>
> >> --
> >> Thomas Zimmermann
> >> Graphics Driver Developer
> >> SUSE Software Solutions Germany GmbH
> >> Maxfeldstr. 5, 90409 Nürnberg, Germany
> >> (HRB 36809, AG Nürnberg)
> >> Geschäftsführer: Felix Imendörffer
> >>
> >
> >
> >
> >
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
>
--
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
[Intel-gfx] ✓ Fi.CI.IGT: success for Add debugfs for requesting HDCP version
== Series Details ==
Series: Add debugfs for requesting HDCP version
URL : https://patchwork.freedesktop.org/series/78115/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8600_full -> Patchwork_17906_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_17906_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_softpin@noreloc-s3:
- shard-apl: [PASS][1] -> [DMESG-WARN][2] ([i915#180]) +2 similar
issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/shard-apl6/igt@gem_soft...@noreloc-s3.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17906/shard-apl4/igt@gem_soft...@noreloc-s3.html
* igt@i915_module_load@reload-with-fault-injection:
- shard-iclb: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/shard-iclb8/igt@i915_module_l...@reload-with-fault-injection.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17906/shard-iclb5/igt@i915_module_l...@reload-with-fault-injection.html
* igt@i915_pm_dc@dc6-psr:
- shard-iclb: [PASS][5] -> [FAIL][6] ([i915#454])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/shard-iclb4/igt@i915_pm...@dc6-psr.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17906/shard-iclb4/igt@i915_pm...@dc6-psr.html
- shard-skl: [PASS][7] -> [DMESG-FAIL][8] ([i915#1982])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/shard-skl6/igt@i915_pm...@dc6-psr.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17906/shard-skl7/igt@i915_pm...@dc6-psr.html
* igt@kms_color@pipe-c-ctm-blue-to-red:
- shard-kbl: [PASS][9] -> [DMESG-WARN][10] ([i915#93] / [i915#95])
+3 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/shard-kbl3/igt@kms_co...@pipe-c-ctm-blue-to-red.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17906/shard-kbl3/igt@kms_co...@pipe-c-ctm-blue-to-red.html
- shard-apl: [PASS][11] -> [DMESG-WARN][12] ([i915#95]) +15
similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/shard-apl4/igt@kms_co...@pipe-c-ctm-blue-to-red.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17906/shard-apl6/igt@kms_co...@pipe-c-ctm-blue-to-red.html
* igt@kms_cursor_legacy@cursora-vs-flipa-atomic-transitions:
- shard-skl: [PASS][13] -> [DMESG-WARN][14] ([i915#1982]) +1
similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/shard-skl6/igt@kms_cursor_leg...@cursora-vs-flipa-atomic-transitions.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17906/shard-skl7/igt@kms_cursor_leg...@cursora-vs-flipa-atomic-transitions.html
* igt@kms_hdr@bpc-switch:
- shard-skl: [PASS][15] -> [FAIL][16] ([i915#1188])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/shard-skl2/igt@kms_...@bpc-switch.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17906/shard-skl10/igt@kms_...@bpc-switch.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([i915#180])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/shard-kbl2/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-b.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17906/shard-kbl2/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-b.html
* igt@kms_psr@psr2_primary_page_flip:
- shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441]) +2 similar
issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/shard-iclb2/igt@kms_psr@psr2_primary_page_flip.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17906/shard-iclb4/igt@kms_psr@psr2_primary_page_flip.html
* igt@kms_vblank@pipe-b-ts-continuation-suspend:
- shard-kbl: [PASS][21] -> [INCOMPLETE][22] ([i915#155])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/shard-kbl7/igt@kms_vbl...@pipe-b-ts-continuation-suspend.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17906/shard-kbl4/igt@kms_vbl...@pipe-b-ts-continuation-suspend.html
Possible fixes
* {igt@gem_exec_reloc@basic-concurrent0}:
- shard-glk: [FAIL][23] ([i915#1930]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/shard-glk6/igt@gem_exec_re...@basic-concurrent0.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17906/shard-glk2/igt@gem_exec_re...@basic-concurrent0.html
* igt@gem_exec_whisper@basic-queues-priority-all:
- shard-glk: [DMESG-WARN][25] ([i915#118] / [i915#95]) ->
[PASS][26]
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/shard-glk2/igt@gem_exec_whis...@basic-queues-priority-all.html
[26]:
Re: [Intel-gfx] [PATCH 8/9] drm/shmem-helpers: Ensure get_pages is not called on imported dma-buf
Hi
Am 03.06.20 um 15:12 schrieb Daniel Vetter:
> On Thu, May 14, 2020 at 09:30:04AM +0200, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 11.05.20 um 11:35 schrieb Daniel Vetter:
>>> Just a bit of light paranoia. Also sprinkle this check over
>>> drm_gem_shmem_get_sg_table, which should only be called when
>>> exporting, same for the pin/unpin functions, on which it relies to
>>> work correctly.
>>>
>>> Cc: Gerd Hoffmann
>>> Cc: Rob Herring
>>> Cc: Noralf Trønnes
>>> Signed-off-by: Daniel Vetter
>>> ---
>>> drivers/gpu/drm/drm_gem_shmem_helper.c | 10 ++
>>> 1 file changed, 10 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
>>> b/drivers/gpu/drm/drm_gem_shmem_helper.c
>>> index 117a7841e284..f7011338813e 100644
>>> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
>>> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
>>> @@ -170,6 +170,8 @@ int drm_gem_shmem_get_pages(struct drm_gem_shmem_object
>>> *shmem)
>>> {
>>> int ret;
>>>
>>> + WARN_ON(shmem->base.import_attach);
>>> +
>>> ret = mutex_lock_interruptible(>pages_lock);
>>> if (ret)
>>> return ret;
>>> @@ -225,6 +227,8 @@ int drm_gem_shmem_pin(struct drm_gem_object *obj)
>>> {
>>> struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj);
>>>
>>> + WARN_ON(shmem->base.import_attach);
>>> +
>>
>> I don't understand this change. If a driver pins pages it now has to
>> check that the pages are not imported?
>
> Nope. There's two classes of functions in the helpers, and I'm trying to
> unconfuse them:
>
> - stuff used to implement gem_funcs. These are obviously only ever used on
> native objects, never on imported ones (on imported ones we try to
> forward through the dma-buf layer to the exporter). drm_gem_shmem_pin is
> only used in that role to implement gem_funcs->pin. Calling it on an
> imported buffer is indeed a bug.
>
> - the other set of functions are for drivers to do their stuff. The
> interface which (implicitly) pins stuff into places is various set of
> get_pages, which do have different paths for native and imported
> objects.
Thanks for explaining. Patch is
Acked-by: Thomas Zimmermann
>
> Apologies that I missed your question here, I merged all the patches
> leading up to this one for now.
>
> Thanks, Daniel
>
>>
>>
>>> return drm_gem_shmem_get_pages(shmem);
>>> }
>>> EXPORT_SYMBOL(drm_gem_shmem_pin);
>>> @@ -240,6 +244,8 @@ void drm_gem_shmem_unpin(struct drm_gem_object *obj)
>>> {
>>> struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj);
>>>
>>> + WARN_ON(shmem->base.import_attach);
>>> +
>>> drm_gem_shmem_put_pages(shmem);
>>> }
>>> EXPORT_SYMBOL(drm_gem_shmem_unpin);
>>> @@ -510,6 +516,8 @@ static void drm_gem_shmem_vm_open(struct vm_area_struct
>>> *vma)
>>> struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj);
>>> int ret;
>>>
>>> + WARN_ON(shmem->base.import_attach);
>>> +
>>> ret = drm_gem_shmem_get_pages(shmem);
>>> WARN_ON_ONCE(ret != 0);
>>>
>>> @@ -611,6 +619,8 @@ struct sg_table *drm_gem_shmem_get_sg_table(struct
>>> drm_gem_object *obj)
>>> {
>>> struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj);
>>>
>>> + WARN_ON(shmem->base.import_attach);
>>> +
>>> return drm_prime_pages_to_sg(shmem->pages, obj->size >> PAGE_SHIFT);
>>> }
>>> EXPORT_SYMBOL_GPL(drm_gem_shmem_get_sg_table);
>>>
>>
>> --
>> Thomas Zimmermann
>> Graphics Driver Developer
>> SUSE Software Solutions Germany GmbH
>> Maxfeldstr. 5, 90409 Nürnberg, Germany
>> (HRB 36809, AG Nürnberg)
>> Geschäftsführer: Felix Imendörffer
>>
>
>
>
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
signature.asc
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] pwm/i915: Convert pwm-crc and i915 driver's PWM code to use the atomic PWM API
On Sat, Jun 06, 2020 at 10:25:45PM +0200, Hans de Goede wrote: > Hi All, > > This patch series converts the i915 driver's cpde for controlling the > panel's backlight with an external PWM controller to use the atomic PWM API. > > Initially the plan was for this series to consist of 2 parts: > 1. convert the pwm-crc driver to support the atomic PWM API and > 2. convert the i915 driver's PWM code to use the atomic PWM API. > > But during testing I've found a number of bugs in the pwm-lpss and I > found that the acpi_lpss code needs some special handling because of > some ugliness found in most Cherry Trail DSDTs. > > So now this series has grown somewhat large and consists of 4 parts: > > 1. acpi_lpss fixes workarounds for Cherry Trail DSTD nastiness > 2. various fixes to the pwm-lpss driver > 3. convert the pwm-crc driver to support the atomic PWM API and > 4. convert the i915 driver's PWM code to use the atomic PWM API > > So we need to discuss how to merge this (once it passes review). > Although the inter-dependencies are only runtime I still think we should > make sure that 1-3 are in the drm-intel-next-queued (dinq) tree before > merging the i915 changes. Both to make sure that the intel-gfx CI system > does not become unhappy and for bisecting reasons. Simplest is if acpi acks the acpi patches for merging through drm-intel.git. Second simplest is topic branch (drm-intel maintainers can do that) with the entire pile, which then acpi and drm-intel can both pull in. Up to the two maintainer teams to figure this one out. /me out Cheers, Daniel > > The involved acpi_lpss and pwm drivers do not see a whole lot of churn, > so we could just merge everything through dinq, or we could use immutable > branch and merge those into dinq. > > So Rafael and Thierry, can I either get your Acked-by for directly merging > this into dinq, or can you provide an immutable branch with these patches? > > This series has been tested (and re-tested after adding various bug-fixes) > extensively. It has been tested on the following devices: > > -Asus T100TA BYT + CRC-PMIC PWM > -Toshiba WT8-ABYT + CRC-PMIC PWM > -Thundersoft TS178BYT + CRC-PMIC PWM, inverse PWM > -Asus T100HA CHT + CRC-PMIC PWM > -Terra Pad 1061 BYT + LPSS PWM > -Trekstor Twin 10.1 BYT + LPSS PWM > -Asus T101HA CHT + CRC-PMIC PWM > -GPD Pocket CHT + CRC-PMIC PWM > > Regards, > > Hans > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- 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 v2 03/15] pwm: lpss: Add range limit check for the base_unit register value
Hi, On 6/8/20 2:51 PM, Andy Shevchenko wrote: On Mon, Jun 08, 2020 at 01:07:12PM +0200, Hans de Goede wrote: On 6/8/20 5:50 AM, Andy Shevchenko wrote: On Sun, Jun 07, 2020 at 08:18:28PM +0200, Hans de Goede wrote: When the user requests a high enough period ns value, then the calculations in pwm_lpss_prepare() might result in a base_unit value of 0. But according to the data-sheet the way the PWM controller works is that each input clock-cycle the base_unit gets added to a N bit counter and that counter overflowing determines the PWM output frequency. Adding 0 to the counter is a no-op. The data-sheet even explicitly states that writing 0 to the base_unit bits will result in the PWM outputting a continuous 0 signal. So, and why it's a problem? Lets sya the user requests a PWM output frequency of 100Hz on Cherry Trail which has a 1920 Hz clock this will result in 100 * 65536 / 1920 = 0.3 -> 0 as base-unit value. So instead of getting 100 Hz the user will now get a pin which is always outputting low. OTOH if we clamp to 1 as lowest value, the user will get 19200 / 65536 = 292 Hz as output frequency which is as close to the requested value as we can get while actually still working as a PWM controller. So, we should basically divide and round up, no? Yes, that will work for the low limit of base_unit but it will make all the other requested period values less accurate. At least for 0 we will get 0. We're dealing with frequency here, but the API is dealing with period, so to get 0 HZ the API user would have to request a period of > 1s e.g. request 2s / 0.5 Hz but then the user is still not really requesting 0Hz (that would correspond with a period of infinity which integers cannot represent. base_unit values > (base_unit_range / 256), or iow base_unit values using the 8 most significant bits, cause loss of resolution of the duty-cycle. E.g. assuming a base_unit_range of 65536 steps, then a base_unit value of 768 (256 * 3), limits the duty-cycle resolution to 65536 / 768 = 85 steps. Clamp the max base_unit value to base_unit_range / 32 to ensure a duty-cycle resolution of at least 32 steps. This limits the maximum output frequency to 600 KHz / 780 KHz depending on the base clock. This part I don't understand. Why we limiting base unit? I seems like a deliberate regression. The way the PWM controller works is that the base-unit gets added to say a 16 bit (on CHT) counter each input clock and then the highest 8 bits of that counter get compared to the value programmed into the ON_TIME_DIV bits. Lets say we do not clamp and allow any value and lets say the user selects an output frequency of half the input clock, so base-unit value is 32768, then the counter will only have 2 values: 0 and 32768 after that it will wrap around again. So any on time-div value < 128 will result in the output being always high and any value > 128 will result in the output being high/low 50% of the time and a value of 255 will make the output always low. So in essence we now only have 3 duty cycle levels, which seems like a bad idea to me / not what a pwm controller is supposed to do. It's exactly what is written in the documentation. I can't buy base unit clamp. Though, I can buy, perhaps, on time divisor granularity, i.e. 1/ 0% - 25%-1 (0%) 2/ 25% - 50% - 75% (50%) 3/ 75%+1 - 100% (100%) And so on till we got a maximum resolution (8 bits). Note that the PWM API does not expose the granularity to the API user, which is why I went with just putting a minimum on it of 32 steps. Anyways I don't have a strong opinion on this, so I'm fine with not clamping the base-unit to preserve granularity. We should still clamp it to avoid overflow if the user us requesting a really high frequency though! The old code had: base_unit &= base_unit_range; Which means that if the user requests a too high value, then we first overflow base_unit and then truncate it to fit leading to a random frequency. So if we forget my minimal granularity argument, then at a minimum we need to replace the above line with: base_unit = clamp_t(unsigned long long, base_unit, 1, base_unit_range - 1); And since we need the clamp anyways we can then keep the current round-closest behavior. Regards, Hans ___ 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/gt: Prevent enabling breadcrumbs on the virtual engine (rev2)
== Series Details == Series: drm/i915/gt: Prevent enabling breadcrumbs on the virtual engine (rev2) URL : https://patchwork.freedesktop.org/series/78117/ State : success == Summary == CI Bug Log - changes from CI_DRM_8600 -> Patchwork_17908 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17908/index.html Known issues Here are the changes found in Patchwork_17908 that come from known issues: ### IGT changes ### Issues hit * igt@i915_module_load@reload: - fi-byt-j1900: [PASS][1] -> [DMESG-WARN][2] ([i915#1982]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/fi-byt-j1900/igt@i915_module_l...@reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17908/fi-byt-j1900/igt@i915_module_l...@reload.html * igt@i915_pm_rpm@module-reload: - fi-glk-dsi: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/fi-glk-dsi/igt@i915_pm_...@module-reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17908/fi-glk-dsi/igt@i915_pm_...@module-reload.html * igt@kms_cursor_legacy@basic-flip-after-cursor-atomic: - fi-icl-guc: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/fi-icl-guc/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17908/fi-icl-guc/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html Possible fixes * igt@gem_exec_suspend@basic-s0: - fi-glk-dsi: [DMESG-WARN][7] ([i915#1982]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/fi-glk-dsi/igt@gem_exec_susp...@basic-s0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17908/fi-glk-dsi/igt@gem_exec_susp...@basic-s0.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - fi-icl-u2: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10] +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17908/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html Warnings * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - fi-kbl-x1275: [DMESG-WARN][11] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][12] ([i915#62] / [i915#92]) +4 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/fi-kbl-x1275/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17908/fi-kbl-x1275/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@kms_force_connector_basic@force-edid: - fi-kbl-x1275: [DMESG-WARN][13] ([i915#62] / [i915#92]) -> [DMESG-WARN][14] ([i915#62] / [i915#92] / [i915#95]) +3 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17908/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982 [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62 [i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92 [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95 Participating hosts (49 -> 43) -- Missing(6): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_8600 -> Patchwork_17908 CI-20190529: 20190529 CI_DRM_8600: 9232911f67be3d072e5bd6ff0eb4d8e8281f5c5f @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5699: 201da47cb57b8fadd9bc45be16b82617b32a2c01 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17908: 0ed9d466630faf01b7a04c422587332f71fc9615 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 0ed9d466630f drm/i915/gt: Prevent enabling breadcrumbs on the virtual engine == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17908/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 04/15] pwm: lpss: Fix off by one error in base_unit math in pwm_lpss_prepare()
On Mon, Jun 08, 2020 at 01:13:01PM +0200, Hans de Goede wrote:
> On 6/8/20 5:55 AM, Andy Shevchenko wrote:
> > On Sun, Jun 07, 2020 at 08:18:29PM +0200, Hans de Goede wrote:
> > > According to the data-sheet the way the PWM controller works is that
> > > each input clock-cycle the base_unit gets added to a N bit counter and
> > > that counter overflowing determines the PWM output frequency.
> > >
> > > So assuming e.g. a 16 bit counter this means that if base_unit is set to
> > > 1,
> > > after 65535 input clock-cycles the counter has been increased from 0 to
> > > 65535 and it will overflow on the next cycle, so it will overflow after
> > > every 65536 clock cycles and thus the calculations done in
> > > pwm_lpss_prepare() should use 65536 and not 65535.
> > >
> > > This commit fixes this. Note this also aligns the calculations in
> > > pwm_lpss_prepare() with those in pwm_lpss_get_state().
> >
> > This one sounds like a bug which I have noticed on Broxton (but thought as a
> > hardware issue). In any case it has to be tested on various platforms to see
> > how it affects on them.
>
> If you like at the datasheet / read my commit description then it
> becomes obvious that because of the way the PWM controller works that
> it takes the full 2^(base-unit-bits) for the counter to overflow,
> not 2^(base-unit-bits) - 1. This will make a difference of a factor
> 65535/65536 in the output frequency which will be tricky to measure.
>
> IOW I'm not sure we can really test if this helps, but it is
> obviously the right thing to do and it aligns the pwm_apply code
> with the pwm_get_state code which already does not have the - 1.
Yes. It seems I did a mistake in the commit
684309e5043e ("pwm: lpss: Avoid potential overflow of base_unit")
when missed multiplication.
For this one
Reviewed-by: Andy Shevchenko
--
With Best Regards,
Andy Shevchenko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/gt: Prevent enabling breadcrumbs on the virtual engine
The virtual engines are not connected directly to hardware, so do not
generate interrupts themselves, nor do we expect to enable breadcrumb
tracking on them. However, if we clear out a stale virtual request, we
will process the breadcrumbs on the current virtual engine. Here, we
only need to add the delayed signal onto the stale signal queue, and
send the signal once clear of the engine locks. In the meantime, this
may be transferred onto the next sibling if we execute the next virtual
request before the work is completed.
The effect of losing tracking of the virtual breadcrumb interrupt is
that we leak the GT wakeref, keeping the device awake.
Reported-by: Tvrtko Ursulin
Fixes: b647c7df01b7 ("drm/i915: Fixup preempt-to-busy vs resubmission of a
virtual request")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: # v5.5+
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 6 ++
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 3 +++
drivers/gpu/drm/i915/gt/intel_lrc.c | 2 ++
3 files changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index d907d538176e..9eaf3dc17c99 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -225,6 +225,9 @@ static bool __intel_breadcrumbs_arm_irq(struct
intel_breadcrumbs *b)
struct intel_engine_cs *engine =
container_of(b, struct intel_engine_cs, breadcrumbs);
+ if (intel_engine_is_virtual(engine))
+ return true;
+
lockdep_assert_held(>irq_lock);
if (b->irq_armed)
return true;
@@ -308,6 +311,9 @@ void intel_engine_transfer_stale_breadcrumbs(struct
intel_engine_cs *engine,
void intel_engine_fini_breadcrumbs(struct intel_engine_cs *engine)
{
+ struct intel_breadcrumbs *b = >breadcrumbs;
+
+ GEM_BUG_ON(atomic_read(>irq_work.flags));
}
bool i915_request_enable_breadcrumb(struct i915_request *rq)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index e5141a897786..4f2c348aa32c 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1515,6 +1515,9 @@ void intel_engine_dump(struct intel_engine_cs *engine,
drm_printf(m, "*** WEDGED ***\n");
drm_printf(m, "\tAwake? %d\n", atomic_read(>wakeref.count));
+ drm_printf(m, "\tBreadcrumbs? armed:%s, signalers:%s\n",
+ yesno(engine->breadcrumbs.irq_armed),
+ yesno(!list_empty(>breadcrumbs.signalers)));
drm_printf(m, "\tBarriers?: %s\n",
yesno(!llist_empty(>barrier_tasks)));
drm_printf(m, "\tLatency: %luus\n",
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index d55a5e0466e5..9d932e985d96 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -5339,6 +5339,8 @@ static void virtual_context_destroy(struct kref *kref)
GEM_BUG_ON(ve->request);
GEM_BUG_ON(ve->context.inflight);
+ intel_engine_fini_breadcrumbs(>base);
+
for (n = 0; n < ve->num_siblings; n++) {
struct intel_engine_cs *sibling = ve->siblings[n];
struct rb_node *node = >nodes[sibling->id].rb;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 03/15] pwm: lpss: Add range limit check for the base_unit register value
On Mon, Jun 08, 2020 at 01:07:12PM +0200, Hans de Goede wrote: > On 6/8/20 5:50 AM, Andy Shevchenko wrote: > > On Sun, Jun 07, 2020 at 08:18:28PM +0200, Hans de Goede wrote: > > > When the user requests a high enough period ns value, then the > > > calculations in pwm_lpss_prepare() might result in a base_unit value of 0. > > > > > > But according to the data-sheet the way the PWM controller works is that > > > each input clock-cycle the base_unit gets added to a N bit counter and > > > that counter overflowing determines the PWM output frequency. Adding 0 > > > to the counter is a no-op. The data-sheet even explicitly states that > > > writing 0 to the base_unit bits will result in the PWM outputting a > > > continuous 0 signal. > > > > So, and why it's a problem? > > Lets sya the user requests a PWM output frequency of 100Hz on Cherry Trail > which has a 1920 Hz clock this will result in 100 * 65536 / 1920 = > 0.3 -> 0 as base-unit value. So instead of getting 100 Hz the user will > now get a pin which is always outputting low. > > OTOH if we clamp to 1 as lowest value, the user will get 19200 / 65536 > = 292 Hz as output frequency which is as close to the requested value as > we can get while actually still working as a PWM controller. So, we should basically divide and round up, no? At least for 0 we will get 0. > > > base_unit values > (base_unit_range / 256), or iow base_unit values using > > > the 8 most significant bits, cause loss of resolution of the duty-cycle. > > > E.g. assuming a base_unit_range of 65536 steps, then a base_unit value of > > > 768 (256 * 3), limits the duty-cycle resolution to 65536 / 768 = 85 steps. > > > Clamp the max base_unit value to base_unit_range / 32 to ensure a > > > duty-cycle resolution of at least 32 steps. This limits the maximum > > > output frequency to 600 KHz / 780 KHz depending on the base clock. > > > > This part I don't understand. Why we limiting base unit? I seems like a > > deliberate regression. > > The way the PWM controller works is that the base-unit gets added to > say a 16 bit (on CHT) counter each input clock and then the highest 8 > bits of that counter get compared to the value programmed into the > ON_TIME_DIV bits. > > Lets say we do not clamp and allow any value and lets say the user > selects an output frequency of half the input clock, so base-unit > value is 32768, then the counter will only have 2 values: > 0 and 32768 after that it will wrap around again. So any on time-div > value < 128 will result in the output being always high and any > value > 128 will result in the output being high/low 50% of the time > and a value of 255 will make the output always low. > > So in essence we now only have 3 duty cycle levels, which seems like > a bad idea to me / not what a pwm controller is supposed to do. It's exactly what is written in the documentation. I can't buy base unit clamp. Though, I can buy, perhaps, on time divisor granularity, i.e. 1/0% - 25%-1 (0%) 2/25% - 50% - 75% (50%) 3/75%+1 - 100% (100%) And so on till we got a maximum resolution (8 bits). -- With Best Regards, Andy Shevchenko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gt: Prevent enabling breadcrumbs on the virtual engine
== Series Details ==
Series: drm/i915/gt: Prevent enabling breadcrumbs on the virtual engine
URL : https://patchwork.freedesktop.org/series/78117/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8600 -> Patchwork_17907
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_17907 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_17907, 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_17907/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_17907:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@execlists:
- fi-cfl-8109u: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17907/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html
- fi-skl-lmem:[PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/fi-skl-lmem/igt@i915_selftest@l...@execlists.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17907/fi-skl-lmem/igt@i915_selftest@l...@execlists.html
- fi-icl-u2: [PASS][5] -> [INCOMPLETE][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/fi-icl-u2/igt@i915_selftest@l...@execlists.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17907/fi-icl-u2/igt@i915_selftest@l...@execlists.html
- fi-icl-y: [PASS][7] -> [INCOMPLETE][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/fi-icl-y/igt@i915_selftest@l...@execlists.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17907/fi-icl-y/igt@i915_selftest@l...@execlists.html
- fi-bdw-5557u: [PASS][9] -> [INCOMPLETE][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/fi-bdw-5557u/igt@i915_selftest@l...@execlists.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17907/fi-bdw-5557u/igt@i915_selftest@l...@execlists.html
- fi-icl-guc: [PASS][11] -> [INCOMPLETE][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/fi-icl-guc/igt@i915_selftest@l...@execlists.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17907/fi-icl-guc/igt@i915_selftest@l...@execlists.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@execlists:
- {fi-tgl-u}: [PASS][13] -> [INCOMPLETE][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/fi-tgl-u/igt@i915_selftest@l...@execlists.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17907/fi-tgl-u/igt@i915_selftest@l...@execlists.html
- {fi-kbl-7560u}: [PASS][15] -> [INCOMPLETE][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/fi-kbl-7560u/igt@i915_selftest@l...@execlists.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17907/fi-kbl-7560u/igt@i915_selftest@l...@execlists.html
- {fi-tgl-dsi}: [PASS][17] -> [INCOMPLETE][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/fi-tgl-dsi/igt@i915_selftest@l...@execlists.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17907/fi-tgl-dsi/igt@i915_selftest@l...@execlists.html
Known issues
Here are the changes found in Patchwork_17907 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@active:
- fi-cfl-8109u: [PASS][19] -> [DMESG-FAIL][20] ([i915#666])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/fi-cfl-8109u/igt@i915_selftest@l...@active.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17907/fi-cfl-8109u/igt@i915_selftest@l...@active.html
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [PASS][21] -> [DMESG-WARN][22] ([i915#62] / [i915#92]
/ [i915#95])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17907/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-byt-j1900: [PASS][23] -> [DMESG-WARN][24] ([i915#1982])
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17907/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
- fi-bsw-kefka: [PASS][25] -> [DMESG-WARN][26] ([i915#1982])
[Intel-gfx] ✓ Fi.CI.BAT: success for Add debugfs for requesting HDCP version
== Series Details ==
Series: Add debugfs for requesting HDCP version
URL : https://patchwork.freedesktop.org/series/78115/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8600 -> Patchwork_17906
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17906/index.html
Known issues
Here are the changes found in Patchwork_17906 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@module-reload:
- fi-byt-j1900: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/fi-byt-j1900/igt@i915_pm_...@module-reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17906/fi-byt-j1900/igt@i915_pm_...@module-reload.html
Possible fixes
* igt@gem_exec_suspend@basic-s0:
- fi-glk-dsi: [DMESG-WARN][3] ([i915#1982]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/fi-glk-dsi/igt@gem_exec_susp...@basic-s0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17906/fi-glk-dsi/igt@gem_exec_susp...@basic-s0.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-whl-u: [DMESG-WARN][5] ([i915#95]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/fi-whl-u/igt@i915_pm_...@basic-pci-d3-state.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17906/fi-whl-u/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2: [DMESG-WARN][7] ([i915#1982]) -> [PASS][8] +1 similar
issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17906/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
Warnings
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-kbl-x1275: [DMESG-WARN][9] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][10] ([i915#62] / [i915#92]) +2 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/fi-kbl-x1275/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17906/fi-kbl-x1275/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size:
- fi-kbl-x1275: [DMESG-WARN][11] ([i915#62] / [i915#92]) ->
[DMESG-WARN][12] ([i915#62] / [i915#92] / [i915#95]) +1 similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8600/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-varying-size.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17906/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-varying-size.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (49 -> 41)
--
Missing(8): fi-ilk-m540 fi-bdw-samus fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-kbl-7560u fi-byt-clapper fi-skl-6700k2
Build changes
-
* Linux: CI_DRM_8600 -> Patchwork_17906
CI-20190529: 20190529
CI_DRM_8600: 9232911f67be3d072e5bd6ff0eb4d8e8281f5c5f @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5699: 201da47cb57b8fadd9bc45be16b82617b32a2c01 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_17906: e9aea7c387bfa3af005fbd439f664d6e902b3cf6 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
e9aea7c387bf drm/i915: Add a new debugfs to request HDCP version
b610d6ebbfb3 drm/i915: Add support for considering HDCP ver requested via
debugfs
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17906/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Add debugfs for requesting HDCP version
== Series Details == Series: Add debugfs for requesting HDCP version URL : https://patchwork.freedesktop.org/series/78115/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/display/intel_display.c:1222:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1225:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1228:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1231:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/gem/i915_gem_context.c:2274:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2275:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2276:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2277:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2278:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2279:17: error: bad integer constant expression +drivers/gpu/drm/i915/gt/intel_reset.c:1310:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_write8' - different lock contexts for basic block
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: Init lspcon chip dynamically
== Series Details == Series: drm/i915: Init lspcon chip dynamically URL : https://patchwork.freedesktop.org/series/78114/ State : failure == Summary == Applying: drm/i915: Init lspcon chip dynamically Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/display/intel_ddi.c M drivers/gpu/drm/i915/display/intel_dp.c M drivers/gpu/drm/i915/display/intel_hdmi.c M drivers/gpu/drm/i915/display/intel_lspcon.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/display/intel_lspcon.c Auto-merging drivers/gpu/drm/i915/display/intel_hdmi.c Auto-merging drivers/gpu/drm/i915/display/intel_dp.c Auto-merging drivers/gpu/drm/i915/display/intel_ddi.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/display/intel_ddi.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 drm/i915: Init lspcon chip dynamically When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 04/15] pwm: lpss: Fix off by one error in base_unit math in pwm_lpss_prepare()
Hi, On 6/8/20 5:55 AM, Andy Shevchenko wrote: On Sun, Jun 07, 2020 at 08:18:29PM +0200, Hans de Goede wrote: According to the data-sheet the way the PWM controller works is that each input clock-cycle the base_unit gets added to a N bit counter and that counter overflowing determines the PWM output frequency. So assuming e.g. a 16 bit counter this means that if base_unit is set to 1, after 65535 input clock-cycles the counter has been increased from 0 to 65535 and it will overflow on the next cycle, so it will overflow after every 65536 clock cycles and thus the calculations done in pwm_lpss_prepare() should use 65536 and not 65535. This commit fixes this. Note this also aligns the calculations in pwm_lpss_prepare() with those in pwm_lpss_get_state(). This one sounds like a bug which I have noticed on Broxton (but thought as a hardware issue). In any case it has to be tested on various platforms to see how it affects on them. If you like at the datasheet / read my commit description then it becomes obvious that because of the way the PWM controller works that it takes the full 2^(base-unit-bits) for the counter to overflow, not 2^(base-unit-bits) - 1. This will make a difference of a factor 65535/65536 in the output frequency which will be tricky to measure. IOW I'm not sure we can really test if this helps, but it is obviously the right thing to do and it aligns the pwm_apply code with the pwm_get_state code which already does not have the - 1. Regards, Hans ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 03/15] pwm: lpss: Add range limit check for the base_unit register value
Hi, On 6/8/20 5:50 AM, Andy Shevchenko wrote: On Sun, Jun 07, 2020 at 08:18:28PM +0200, Hans de Goede wrote: When the user requests a high enough period ns value, then the calculations in pwm_lpss_prepare() might result in a base_unit value of 0. But according to the data-sheet the way the PWM controller works is that each input clock-cycle the base_unit gets added to a N bit counter and that counter overflowing determines the PWM output frequency. Adding 0 to the counter is a no-op. The data-sheet even explicitly states that writing 0 to the base_unit bits will result in the PWM outputting a continuous 0 signal. So, and why it's a problem? Lets sya the user requests a PWM output frequency of 100Hz on Cherry Trail which has a 1920 Hz clock this will result in 100 * 65536 / 1920 = 0.3 -> 0 as base-unit value. So instead of getting 100 Hz the user will now get a pin which is always outputting low. OTOH if we clamp to 1 as lowest value, the user will get 19200 / 65536 = 292 Hz as output frequency which is as close to the requested value as we can get while actually still working as a PWM controller. base_unit values > (base_unit_range / 256), or iow base_unit values using the 8 most significant bits, cause loss of resolution of the duty-cycle. E.g. assuming a base_unit_range of 65536 steps, then a base_unit value of 768 (256 * 3), limits the duty-cycle resolution to 65536 / 768 = 85 steps. Clamp the max base_unit value to base_unit_range / 32 to ensure a duty-cycle resolution of at least 32 steps. This limits the maximum output frequency to 600 KHz / 780 KHz depending on the base clock. This part I don't understand. Why we limiting base unit? I seems like a deliberate regression. The way the PWM controller works is that the base-unit gets added to say a 16 bit (on CHT) counter each input clock and then the highest 8 bits of that counter get compared to the value programmed into the ON_TIME_DIV bits. Lets say we do not clamp and allow any value and lets say the user selects an output frequency of half the input clock, so base-unit value is 32768, then the counter will only have 2 values: 0 and 32768 after that it will wrap around again. So any on time-div value < 128 will result in the output being always high and any value > 128 will result in the output being high/low 50% of the time and a value of 255 will make the output always low. So in essence we now only have 3 duty cycle levels, which seems like a bad idea to me / not what a pwm controller is supposed to do. So I decided to put a cut of at having at least 32 steps. The mean reason I wrote this patch though is to avoid a base-unit value of 0 which really results in a completely non working PWM output. I personally believe clamping on the high side is a good idea too. But if you are against that I can drop that part. Note that the clamping on the high side will not affect the primary user of the LPSS-pwm driver which is the i915 backlight code, that never asks for such high frequencies. But it could help to avoid an user shooting themselves in the foot when using the PWM on a dev board through the sysfs interface. Regards, Hans ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gt: Prevent enabling breadcrumbs on the virtual engine
The virtual engines are not connected directly to hardware, so do not
generate interrupts themselves, nor do we expect to enable breadcrumb
tracking on them. However, if we clear out a stale virtual request, we
will process the breadcrumbs on the current virtual engine. Here, we
only need to add the delayed signal onto the stale signal queue, and
send the signal once clear of the engine locks. In the meantime, this
may be transferred onto the next sibling if we execute the next virtual
request before the work is completed.
The effect of losing tracking of the virtual breadcrumb interrupt is
that we leak the GT wakeref, keeping the device awake.
Reported-by: Tvrtko Ursulin
Fixes: b647c7df01b7 ("drm/i915: Fixup preempt-to-busy vs resubmission of a
virtual request")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: # v5.5+
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 6 ++
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 3 +++
drivers/gpu/drm/i915/gt/intel_lrc.c | 2 ++
3 files changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index d907d538176e..a6ab1c1dc2cd 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -225,6 +225,9 @@ static bool __intel_breadcrumbs_arm_irq(struct
intel_breadcrumbs *b)
struct intel_engine_cs *engine =
container_of(b, struct intel_engine_cs, breadcrumbs);
+ if (intel_engine_is_virtual(engine))
+ return true;
+
lockdep_assert_held(>irq_lock);
if (b->irq_armed)
return true;
@@ -308,6 +311,9 @@ void intel_engine_transfer_stale_breadcrumbs(struct
intel_engine_cs *engine,
void intel_engine_fini_breadcrumbs(struct intel_engine_cs *engine)
{
+ struct intel_breadcrumbs *b = >breadcrumbs;
+
+ irq_work_sync(>irq_work);
}
bool i915_request_enable_breadcrumb(struct i915_request *rq)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index e5141a897786..4f2c348aa32c 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1515,6 +1515,9 @@ void intel_engine_dump(struct intel_engine_cs *engine,
drm_printf(m, "*** WEDGED ***\n");
drm_printf(m, "\tAwake? %d\n", atomic_read(>wakeref.count));
+ drm_printf(m, "\tBreadcrumbs? armed:%s, signalers:%s\n",
+ yesno(engine->breadcrumbs.irq_armed),
+ yesno(!list_empty(>breadcrumbs.signalers)));
drm_printf(m, "\tBarriers?: %s\n",
yesno(!llist_empty(>barrier_tasks)));
drm_printf(m, "\tLatency: %luus\n",
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index d55a5e0466e5..9d932e985d96 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -5339,6 +5339,8 @@ static void virtual_context_destroy(struct kref *kref)
GEM_BUG_ON(ve->request);
GEM_BUG_ON(ve->context.inflight);
+ intel_engine_fini_breadcrumbs(>base);
+
for (n = 0; n < ve->num_siblings; n++) {
struct intel_engine_cs *sibling = ve->siblings[n];
struct rb_node *node = >nodes[sibling->id].rb;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/2] drm/i915: Add a new debugfs to request HDCP version
As per the current HDCP design, the driver selects the highest
version of HDCP that can be used to satisfy the content-protection
requirements of the user. Due to this, the content-protection
tests cannot test a lower version of HDCP, if the platform and the
display panel, both support higher HDCP version.
To provide some support for testing and debugging, a per-connector
debugfs is required to set the HDCP version via debugfs that the
kernel can consider, while enabling HDCP.
This patch adds a new debugfs entry for each connector that supports
HDCP. For enforcing a particular HDCP version for a connector, the user
can write into the debugfs for that connector.
v2: As suggested by Jani Nikula:
-used kstrtouint_from_user() to directly read as uint from user buffer.
-used 32 bit flag instead of 64 bit for hdcp_ver flag.
-removed unnecessary prints and fixed other minor formatting issues.
Signed-off-by: Ankit Nautiyal
---
.../drm/i915/display/intel_display_debugfs.c | 68 +++
1 file changed, 68 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 70525623bcdf..c01653d412e7 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -2185,6 +2185,72 @@ static const struct file_operations
i915_dsc_fec_support_fops = {
.write = i915_dsc_fec_support_write
};
+static int i915_hdcp_ver_request_show(struct seq_file *m, void *data)
+{
+ struct drm_connector *connector = m->private;
+ struct intel_connector *intel_connector = to_intel_connector(connector);
+ u32 hdcp_ver_flag;
+
+ if (connector->status != connector_status_connected)
+ return -ENODEV;
+
+ /* HDCP is supported by connector */
+ if (!intel_connector->hdcp.shim)
+ return -EINVAL;
+
+ hdcp_ver_flag = intel_connector->hdcp.debugfs_ver_request;
+ seq_printf(m, "HDCP_VER_FLAGS: %u\n", hdcp_ver_flag);
+
+ return 0;
+}
+
+static int i915_hdcp_ver_request_open(struct inode *inode,
+ struct file *file)
+{
+ return single_open(file, i915_hdcp_ver_request_show,
+ inode->i_private);
+}
+
+static ssize_t i915_hdcp_ver_request_write(struct file *file,
+ const char __user *ubuf,
+ size_t len, loff_t *offp)
+{
+ unsigned int hdcp_ver = 0;
+ int ret;
+ struct drm_connector *connector =
+ ((struct seq_file *)file->private_data)->private;
+ struct intel_connector *intel_connector = to_intel_connector(connector);
+ struct intel_hdcp *hdcp = _connector->hdcp;
+
+ if (!hdcp->shim)
+ return -EINVAL;
+
+ if (len == 0)
+ return 0;
+
+ ret = kstrtouint_from_user(ubuf, len, 0, _ver);
+ if (ret < 0)
+ return ret;
+
+ if (hdcp_ver > HDCP_VERSION_MASK)
+ return -EINVAL;
+
+ hdcp->debugfs_ver_request = hdcp_ver;
+
+ *offp += len;
+
+ return len;
+}
+
+static const struct file_operations i915_hdcp_ver_request_fops = {
+ .owner = THIS_MODULE,
+ .open = i915_hdcp_ver_request_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+ .write = i915_hdcp_ver_request_write
+};
+
/**
* intel_connector_debugfs_add - add i915 specific connector debugfs files
* @connector: pointer to a registered drm_connector
@@ -2215,6 +2281,8 @@ int intel_connector_debugfs_add(struct drm_connector
*connector)
connector->connector_type == DRM_MODE_CONNECTOR_HDMIB) {
debugfs_create_file("i915_hdcp_sink_capability", S_IRUGO, root,
connector, _hdcp_sink_capability_fops);
+ debugfs_create_file("i915_hdcp_version_request", 0444, root,
+ connector, _hdcp_ver_request_fops);
}
if (INTEL_GEN(dev_priv) >= 10 &&
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 0/2] Add debugfs for requesting HDCP version
Currently, for a given content-protection request, the kernel selects the highest version of HDCP supported by the panel and the platform. This makes the testing/debugging difficult for lower versions of HDCP. E.g. In case both the lower and the higher HDCP versions are supported then the higher version of HDCP will always be selected and the lower HDCP version cannot be tested without changing the setup. A solution for this was proposed in an IGT patch [1] by removing "mei_hdcp" module, but a need for a generic future-proof solution was identified. As suggested by the community members, this patch attempts to add a new debugfs per connector for requesting a specific version of HDCP for debug/testing environment. The test can request for a specific HDCP version and set the appropriate content-protection connector properties to test the required version. The kernel will consider the request if the HDCP version is sufficient for the requested content-protection. [1] https://patchwork.freedesktop.org/patch/358240/ Ankit Nautiyal (2): drm/i915: Add support for considering HDCP ver requested via debugfs drm/i915: Add a new debugfs to request HDCP version .../drm/i915/display/intel_display_debugfs.c | 68 +++ .../drm/i915/display/intel_display_types.h| 10 +++ drivers/gpu/drm/i915/display/intel_hdcp.c | 16 - 3 files changed, 92 insertions(+), 2 deletions(-) -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/2] drm/i915: Add support for considering HDCP ver requested via debugfs
For testing and debugging each HDCP version separately, a debugfs
entry for requesting a specific version is required. The version
requested via debugfs needs to be stored in hdcp structure. This can
then be considered while enabling HDCP, provided the platform and the
display supports the requested version.
This patch adds the support for storing the version requested as a 32bit
flag. It also adds a helper function to check if a version is requested.
If a specific HDCP version is requested through the debugfs, the driver
chooses that version, instead of policy of choosing the highest HDCP
version supported.
v2: Initialize debugfs_ver_request flag with 0. (Jani Nikula)
Signed-off-by: Ankit Nautiyal
---
.../gpu/drm/i915/display/intel_display_types.h | 10 ++
drivers/gpu/drm/i915/display/intel_hdcp.c| 16 ++--
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 9488449e4b94..cfa641c70717 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -408,6 +408,16 @@ struct intel_hdcp {
* Hence caching the transcoder here.
*/
enum transcoder cpu_transcoder;
+
+ /*
+* HDCP version requested from debugfs i915_hdcp_ver_request.
+* Kernel will read these bits and entertain the request, as per
+* the HDCP capability of the panel and platform.
+*/
+#define HDCP_VERSION_1_4 0x01
+#define HDCP_VERSION_2_2 0x02
+#define HDCP_VERSION_MASK 0x03
+ u32 debugfs_ver_request;
};
struct intel_connector {
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 2cbc4619b4ce..a21ea9c2e9a7 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -1977,6 +1977,8 @@ int intel_hdcp_init(struct intel_connector *connector,
if (!shim)
return -EINVAL;
+ hdcp->debugfs_ver_request = 0;
+
if (is_hdcp2_supported(dev_priv))
intel_hdcp2_init(connector, shim);
@@ -1998,6 +2000,14 @@ int intel_hdcp_init(struct intel_connector *connector,
return 0;
}
+static bool hdcp_debugfs_requested(struct intel_hdcp *hdcp, u32 hdcp_version)
+{
+ if (!hdcp->debugfs_ver_request)
+ return true;
+
+ return hdcp->debugfs_ver_request & hdcp_version ? true : false;
+}
+
int intel_hdcp_enable(struct intel_connector *connector,
enum transcoder cpu_transcoder, u8 content_type)
{
@@ -2023,7 +2033,8 @@ int intel_hdcp_enable(struct intel_connector *connector,
* Considering that HDCP2.2 is more secure than HDCP1.4, If the setup
* is capable of HDCP2.2, it is preferred to use HDCP2.2.
*/
- if (intel_hdcp2_capable(connector)) {
+ if (hdcp_debugfs_requested(hdcp, HDCP_VERSION_2_2) &&
+ intel_hdcp2_capable(connector)) {
ret = _intel_hdcp2_enable(connector);
if (!ret)
check_link_interval = DRM_HDCP2_CHECK_PERIOD_MS;
@@ -2033,7 +2044,8 @@ int intel_hdcp_enable(struct intel_connector *connector,
* When HDCP2.2 fails and Content Type is not Type1, HDCP1.4 will
* be attempted.
*/
- if (ret && intel_hdcp_capable(connector) &&
+ if (ret && hdcp_debugfs_requested(hdcp, HDCP_VERSION_1_4) &&
+ intel_hdcp_capable(connector) &&
hdcp->content_type != DRM_MODE_HDCP_CONTENT_TYPE1) {
ret = _intel_hdcp_enable(connector);
}
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/gt: Initialize reserved and unspecified MOCS indices
+ Jason and Ken
Quoting Francisco Jerez (2020-06-05 00:34:57)
> Ayaz A Siddiqui writes:
>
> > In order to avoid functional breakage of mis-programmed applications that
> > have grown to depend on unused MOCS entries, we are programming
> > those entries to be equal to fully cached ("L3 + LLC") entry as per the
> > recommendation from architecture team.
> >
> > These reserved and unspecified entries should not be used as they may be
> > changed to less performant variants with better coherency in the future
> > if more entries are needed.
This patch message needs reworking. It should just standalone describe
the technical reasoning behind the patch completely, without referring
to elsewhere or to some other decision.
The patch should also Cc: relevant developers who have previously been
working on the MOCS code and the userspace driver folks (Mesa, compute
and media).
> This change seems highly questionable to me... If a future kernel
> release introduces a new MOCS entry with more strict coherency
> semantics, and an application starts relying on it, that application
> won't work when run on an older kernel version with this patch is
> applied. IOW setting uninitialized entries to the most strict caching
> setting available (UC) ensures forwards compatibility with future
> userspace, which seems like a more important design principle than
> giving full caching to broken userspace that accidentally makes use of
> an undefined MOCS entry not part of the kernel ABI.
Both choices were considered, and ultimately Ken and Jason were more in
favor of 'worst coherency' if using reserved MOCS entry.
Your concern about newer software on older kernel is valid. But the
starting point of the decision is the no-regression policy of Linux.
If we have some application developed on an older kernel where the MOCS
entry is unused and would be UC (best coherency), we would have no
choice but to keep that entry unused indefinitely not to break the
mis-programmed application.
Now we have the worst coherency by default if an application is using
reserved entry, making it more likely to be noticed at develop time. And
even if it would not be noticed, modifying the entry for better
coherency should not functionally break the application.
Regards, Joonas
> > Signed-off-by: Ayaz A Siddiqui
> > Cc: Joonas Lahtinen
> > ---
> > drivers/gpu/drm/i915/gt/intel_mocs.c | 93 ++--
> > 1 file changed, 89 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c
> > b/drivers/gpu/drm/i915/gt/intel_mocs.c
> > index 632e08a4592b..1089bd5fdba2 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_mocs.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
> > @@ -234,10 +234,6 @@ static const struct drm_i915_mocs_entry
> > broxton_mocs_table[] = {
> > L3_1_UC)
> >
> > static const struct drm_i915_mocs_entry tgl_mocs_table[] = {
> > - /* Base - Error (Reserved for Non-Use) */
> > - MOCS_ENTRY(0, 0x0, 0x0),
> > - /* Base - Reserved */
> > - MOCS_ENTRY(1, 0x0, 0x0),
> >
> > GEN11_MOCS_ENTRIES,
> >
> > @@ -265,6 +261,95 @@ static const struct drm_i915_mocs_entry
> > tgl_mocs_table[] = {
> > MOCS_ENTRY(61,
> > LE_1_UC | LE_TC_1_LLC,
> > L3_3_WB),
> > +
> > + /* NOTE:
> > + * Reserved and unspecified MOCS indices have been set to (L3 + LCC).
> > + * These reserved entry should never be used, they may be chanaged
> > + * to low performant variants with better coherency in the future if
> > + * more entries are needed.
> > + */
> > +
> > + /* Reserved index 0 and 1 */
> > + MOCS_ENTRY(0, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
> > +L3_3_WB),
> > + MOCS_ENTRY(1, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
> > +L3_3_WB),
> > +
> > + /* Reserved index 16 and 17 */
> > + MOCS_ENTRY(16, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
> > +L3_3_WB),
> > + MOCS_ENTRY(17, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
> > +L3_3_WB),
> > +
> > + /* Reserved index 24 and 25 */
> > + MOCS_ENTRY(24, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
> > +L3_3_WB),
> > + MOCS_ENTRY(25, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
> > +L3_3_WB),
> > +
> > + /* Unspecified indices 26 to 47 */
> > + MOCS_ENTRY(26, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
> > +L3_3_WB),
> > + MOCS_ENTRY(27, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
> > +L3_3_WB),
> > + MOCS_ENTRY(28, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
> > +L3_3_WB),
> > + MOCS_ENTRY(29, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
> > +L3_3_WB),
> > + MOCS_ENTRY(30, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
> > +L3_3_WB),
> > + MOCS_ENTRY(31, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
> > +L3_3_WB),
> > + MOCS_ENTRY(32, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
> > +
Re: [Intel-gfx] [PATCH] Revert "drm/i915: Remove unneeded hack now for CDCLK"
On Mon, 08 Jun 2020, "Lisovskiy, Stanislav"
wrote:
> On Mon, Jun 08, 2020 at 11:21:14AM +0300, Jani Nikula wrote:
>> On Mon, 08 Jun 2020, Stanislav Lisovskiy
>> wrote:
>> > This reverts commit 82ea174dc5425d4e85e25d0c4ba961a2e494392a.
>> >
>>
>> Please explain why. What's going on, why we need the revert.
>>
>> It's fine to reply here, the commit message can be amended by whoever
>> applies the patch.
>
> Yes,
>
> Unfortunately according to our recent findings there is still some
> unidentified factor, requiring CDCLK to be set higher - otherwise we
> still get underruns on some multipipe configurations, despite CDCLK being set
> according to BSpec formula. So getting again back into debug mode to
> indentify the cause, meanwhile setting CDCLK=Pixel rate back in order
> to remove regression in 10% of the cases due to FIFO underruns.
Thanks, pushed.
BR,
Jani.
>
> Stan
>
>>
>> BR,
>> Jani.
>>
>>
>> > Signed-off-by: Stanislav Lisovskiy
>> > Fixes: cd1915460861 ("drm/i915: Adjust CDCLK accordingly to our DBuf bw
>> > needs")
>> > ---
>> > drivers/gpu/drm/i915/display/intel_cdclk.c | 12
>> > 1 file changed, 12 insertions(+)
>> >
>> > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
>> > b/drivers/gpu/drm/i915/display/intel_cdclk.c
>> > index 08468b121d02..45f7f33d1144 100644
>> > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
>> > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
>> > @@ -2071,6 +2071,18 @@ int intel_crtc_compute_min_cdclk(const struct
>> > intel_crtc_state *crtc_state)
>> >/* Account for additional needs from the planes */
>> >min_cdclk = max(intel_planes_min_cdclk(crtc_state), min_cdclk);
>> >
>> > + /*
>> > + * HACK. Currently for TGL platforms we calculate
>> > + * min_cdclk initially based on pixel_rate divided
>> > + * by 2, accounting for also plane requirements,
>> > + * however in some cases the lowest possible CDCLK
>> > + * doesn't work and causing the underruns.
>> > + * Explicitly stating here that this seems to be currently
>> > + * rather a Hack, than final solution.
>> > + */
>> > + if (IS_TIGERLAKE(dev_priv))
>> > + min_cdclk = max(min_cdclk, (int)crtc_state->pixel_rate);
>> > +
>> >if (min_cdclk > dev_priv->max_cdclk_freq) {
>> >drm_dbg_kms(_priv->drm,
>> >"required cdclk (%d kHz) exceeds max (%d kHz)\n",
>>
>> --
>> Jani Nikula, Intel Open Source Graphics Center
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/28] drm/i915: Adjust the sentinel assert to match implementation
Quoting Tvrtko Ursulin (2020-06-08 08:44:01)
>
> On 07/06/2020 23:20, Chris Wilson wrote:
> > From: Tvrtko Ursulin
> >
> > Sentinels are supposed to be last reqeusts in the elsp queue, not the
> > only one, so adjust the assert accordingly.
> >
> > Signed-off-by: Tvrtko Ursulin
> > ---
> > drivers/gpu/drm/i915/gt/intel_lrc.c | 14 +++---
> > 1 file changed, 3 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > index d55a5e0466e5..db8a170b0e5c 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > @@ -1635,9 +1635,9 @@ assert_pending_valid(const struct
> > intel_engine_execlists *execlists,
> > ccid = ce->lrc.ccid;
> >
> > /*
> > - * Sentinels are supposed to be lonely so they flush the
> > - * current exection off the HW. Check that they are the
> > - * only request in the pending submission.
> > + * Sentinels are supposed to be the last request so they flush
> > + * the current exection off the HW. Check that they are the
> > only
> > + * request in the pending submission.
> >*/
> > if (sentinel) {
> > GEM_TRACE_ERR("%s: context:%llx after sentinel in
> > pending[%zd]\n",
> > @@ -1646,15 +1646,7 @@ assert_pending_valid(const struct
> > intel_engine_execlists *execlists,
> > port - execlists->pending);
> > return false;
> > }
> > -
> > sentinel = i915_request_has_sentinel(rq);
>
> FWIW I was changing it to "sentinel |= ..." so it keeps working if we
> decide to use more than 2 elsp ports on Icelake one day.
But it will always fail on the next port...
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display: Avoid PSR and FBC features concurently.
== Series Details == Series: drm/i915/display: Avoid PSR and FBC features concurently. URL : https://patchwork.freedesktop.org/series/78107/ State : success == Summary == CI Bug Log - changes from CI_DRM_8599_full -> Patchwork_17904_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17904_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_workarounds@suspend-resume-fd: - shard-kbl: [PASS][1] -> [DMESG-WARN][2] ([i915#180]) +2 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8599/shard-kbl4/igt@gem_workarou...@suspend-resume-fd.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17904/shard-kbl7/igt@gem_workarou...@suspend-resume-fd.html * igt@gen9_exec_parse@allowed-all: - shard-skl: [PASS][3] -> [DMESG-WARN][4] ([i915#1436] / [i915#716]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8599/shard-skl2/igt@gen9_exec_pa...@allowed-all.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17904/shard-skl7/igt@gen9_exec_pa...@allowed-all.html * igt@kms_big_fb@linear-64bpp-rotate-180: - shard-glk: [PASS][5] -> [DMESG-FAIL][6] ([i915#118] / [i915#95]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8599/shard-glk1/igt@kms_big...@linear-64bpp-rotate-180.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17904/shard-glk8/igt@kms_big...@linear-64bpp-rotate-180.html * igt@kms_color@pipe-a-ctm-0-5: - shard-skl: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) +6 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8599/shard-skl10/igt@kms_co...@pipe-a-ctm-0-5.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17904/shard-skl2/igt@kms_co...@pipe-a-ctm-0-5.html * igt@kms_cursor_legacy@all-pipes-torture-bo: - shard-hsw: [PASS][9] -> [DMESG-WARN][10] ([i915#128]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8599/shard-hsw1/igt@kms_cursor_leg...@all-pipes-torture-bo.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17904/shard-hsw2/igt@kms_cursor_leg...@all-pipes-torture-bo.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-mmap-gtt: - shard-tglb: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8599/shard-tglb7/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-shrfb-draw-mmap-gtt.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17904/shard-tglb5/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-shrfb-draw-mmap-gtt.html * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min: - shard-skl: [PASS][13] -> [FAIL][14] ([fdo#108145] / [i915#265]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8599/shard-skl3/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17904/shard-skl9/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html * igt@kms_psr2_su@page_flip: - shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109642] / [fdo#111068]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8599/shard-iclb2/igt@kms_psr2_su@page_flip.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17904/shard-iclb8/igt@kms_psr2_su@page_flip.html * igt@kms_psr@suspend: - shard-iclb: [PASS][17] -> [INCOMPLETE][18] ([i915#1185]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8599/shard-iclb3/igt@kms_...@suspend.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17904/shard-iclb3/igt@kms_...@suspend.html * igt@kms_vblank@pipe-c-ts-continuation-dpms-suspend: - shard-skl: [PASS][19] -> [INCOMPLETE][20] ([i915#69]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8599/shard-skl4/igt@kms_vbl...@pipe-c-ts-continuation-dpms-suspend.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17904/shard-skl10/igt@kms_vbl...@pipe-c-ts-continuation-dpms-suspend.html Possible fixes * igt@gem_exec_schedule@smoketest-all: - shard-glk: [DMESG-WARN][21] ([i915#118] / [i915#95]) -> [PASS][22] +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8599/shard-glk1/igt@gem_exec_sched...@smoketest-all.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17904/shard-glk8/igt@gem_exec_sched...@smoketest-all.html * igt@gem_pread@display: - shard-hsw: [INCOMPLETE][23] ([i915#61]) -> [PASS][24] +1 similar issue [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8599/shard-hsw4/igt@gem_pr...@display.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17904/shard-hsw7/igt@gem_pr...@display.html * igt@gen9_exec_parse@allowed-all: - shard-apl: [DMESG-WARN][25]
[Intel-gfx] [PATCH v5] drm/i915: Init lspcon chip dynamically
On HP 800 G4 DM, if HDMI cable isn't plugged before boot, the HDMI port
becomes useless and never responds to cable hotplugging:
[3.031904] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
[3.031945] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on port D
Seems like the lspcon chip on the system only gets powered after the
cable is plugged.
Consolidate lspcon_init() into lspcon_resume() to dynamically init
lspcon chip, and make HDMI port work.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/203
Signed-off-by: Kai-Heng Feng
---
v5:
- Consolidate lspcon_resume() with lspcon_init().
- Move more logic into lspcon code.
v4:
- Trust VBT in intel_infoframe_init().
- Init lspcon in intel_dp_detect().
v3:
- Make sure it's handled under long HPD case.
v2:
- Move lspcon_init() inside of intel_dp_hpd_pulse().
drivers/gpu/drm/i915/display/intel_ddi.c| 19 +--
drivers/gpu/drm/i915/display/intel_dp.c | 10 ++--
drivers/gpu/drm/i915/display/intel_hdmi.c | 3 +-
drivers/gpu/drm/i915/display/intel_lspcon.c | 63 -
drivers/gpu/drm/i915/display/intel_lspcon.h | 3 +-
5 files changed, 43 insertions(+), 55 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 5601673c3f30..798fd640da54 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4770,7 +4770,7 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
enum port port)
{
struct intel_digital_port *intel_dig_port;
struct intel_encoder *encoder;
- bool init_hdmi, init_dp, init_lspcon = false;
+ bool init_hdmi, init_dp;
enum phy phy = intel_port_to_phy(dev_priv, port);
init_hdmi = intel_bios_port_supports_dvi(dev_priv, port) ||
@@ -4784,7 +4784,6 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
enum port port)
* is initialized before lspcon.
*/
init_dp = true;
- init_lspcon = true;
init_hdmi = false;
drm_dbg_kms(_priv->drm, "VBT says port %c has lspcon\n",
port_name(port));
@@ -4869,22 +4868,6 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
enum port port)
goto err;
}
- if (init_lspcon) {
- if (lspcon_init(intel_dig_port))
- /* TODO: handle hdmi info frame part */
- drm_dbg_kms(_priv->drm,
- "LSPCON init success on port %c\n",
- port_name(port));
- else
- /*
-* LSPCON init faied, but DP init was success, so
-* lets try to drive as DP++ port.
-*/
- drm_err(_priv->drm,
- "LSPCON init failed on port %c\n",
- port_name(port));
- }
-
intel_infoframe_init(intel_dig_port);
return;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 6952b0295096..e26aa35d6e37 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5938,15 +5938,14 @@ static enum drm_connector_status
intel_dp_detect_dpcd(struct intel_dp *intel_dp)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
- struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
+ struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
u8 *dpcd = intel_dp->dpcd;
u8 type;
if (WARN_ON(intel_dp_is_edp(intel_dp)))
return connector_status_connected;
- if (lspcon->active)
- lspcon_resume(lspcon);
+ lspcon_resume(dig_port);
if (!intel_dp_get_dpcd(intel_dp))
return connector_status_disconnected;
@@ -7198,14 +7197,13 @@ void intel_dp_encoder_reset(struct drm_encoder *encoder)
{
struct drm_i915_private *dev_priv = to_i915(encoder->dev);
struct intel_dp *intel_dp = enc_to_intel_dp(to_intel_encoder(encoder));
- struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
+ struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
intel_wakeref_t wakeref;
if (!HAS_DDI(dev_priv))
intel_dp->DP = intel_de_read(dev_priv, intel_dp->output_reg);
- if (lspcon->active)
- lspcon_resume(lspcon);
+ lspcon_resume(dig_port);
intel_dp->reset_link_params = true;
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 010f37240710..643ad2127931 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -3155,7 +3155,8 @@ void intel_infoframe_init(struct intel_digital_port
*intel_dig_port)
Re: [Intel-gfx] A panic and a hang in the i915 drm driver
HI,
> -Original Message-
> From: Intel-gfx On Behalf Of Jani
> Nikula
> Sent: maanantai 8. kesäkuuta 2020 10.49
> To: David Howells ; Joonas Lahtinen
> ; Vivi, Rodrigo
> Cc: intel-gfx@lists.freedesktop.org; linux-ker...@vger.kernel.org; dri-
> de...@lists.freedesktop.org; dhowe...@redhat.com; airl...@redhat.com
> Subject: Re: [Intel-gfx] A panic and a hang in the i915 drm driver
>
> On Sun, 07 Jun 2020, David Howells wrote:
> > Hi,
> >
> > I'm seeing the attached oops and panic from the i915 drm driver. I've tried
> > bisecting it, but there's a problem in that one of the merged branches
> > causes
> > the machine to hang without output.
It was not this one?
https://gitlab.freedesktop.org/drm/intel/-/issues/1892
>
> Cc: Ville and GG, I thought this was fixed (reverted) already.
>
> BR,
> Jani.
>
>
> >
> > The oops for commit c41219fda6e04255c44d37fd2c0d898c1c46abf1 looks like:
> >
> > BUG: kernel NULL pointer dereference, address:
> > #PF: supervisor read access in kernel mode
> > #PF: error_code(0x) - not-present page
> > PGD 0 P4D 0
> > Oops: [#1] SMP PTI
> > CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.7.0-rc2-fscache+ #883
> > Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014
> > RIP: 0010:intel_psr_enabled+0xb/0x6e
> > Code: 8b 44 24 08 65 48 33 04 25 28 00 00 00 74 05 e8 7e ff 97 ff 48 83 c4
> > 10 5b 5d
> 41 5c 41 5d c3 0f 1f 44 00 00 41 55 41 54 55 53 <48> 8b 9f d8 fe ff ff f6 83
> 5e 08 00
> 00 20 75 05 45 31 e4 eb 44 80
> > RSP: :88840dedfa18 EFLAGS: 00010246
> > RAX: RBX: 8884086f9000 RCX:
> > RDX: 0001 RSI: 8884086f9000 RDI: 0128
> > RBP: 8884086fb000 R08: R09: 0001
> > R10: 0001 R11: 00ff R12: 88840868
> > R13: R14: R15: 8884086fb200
> > FS: () GS:88840fb0()
> knlGS:
> > CS: 0010 DS: ES: CR0: 80050033
> > CR2: CR3: 0440c001 CR4: 001606e0
> > Call Trace:
> > intel_read_dp_sdp+0x71/0x2c5
> > hsw_crt_get_config+0x18/0x41
> > intel_modeset_readout_hw_state+0x24d/0x662
> > ? do_raw_spin_lock+0x8b/0xcd
> > ? _raw_spin_lock_irqsave+0x10/0x16
> > intel_modeset_setup_hw_state+0xa8/0xb59
> > ? __next_node_in+0x39/0x42
> > ? ww_mutex_lock+0x3d/0x1da
> > ? modeset_lock+0xd4/0x114
> > ? drm_modeset_lock_all_ctx+0x86/0xcc
> > intel_modeset_init+0x285/0x5bf
> > ? intel_irq_postinstall+0x485/0x4d1
> > i915_driver_probe+0x1b4/0x49c
> > ? __kernfs_new_node+0x161/0x1b2
> > ? rpm_resume+0x45e/0x485
> > i915_pci_probe+0xfd/0x11d
> > ? __pm_runtime_resume+0x51/0x5e
> > local_pci_probe+0x39/0x7a
> > pci_device_probe+0xf5/0x14f
> > ? sysfs_do_create_link_sd.isra.0+0x77/0xa3
> > really_probe+0x140/0x2a9
> > driver_probe_device+0x9c/0xd1
> > device_driver_attach+0x3c/0x55
> > __driver_attach+0x97/0x9f
> > ? device_driver_attach+0x55/0x55
> > bus_for_each_dev+0x72/0xa8
> > bus_add_driver+0x108/0x1b9
> > driver_register+0x9e/0xd7
> > ? mipi_dsi_bus_init+0x11/0x11
> > i915_init+0x58/0x6b
> > do_one_initcall+0x83/0x18a
> > kernel_init_freeable+0x19b/0x1fd
> > ? rest_init+0x9f/0x9f
> > kernel_init+0xa/0xfa
> > ret_from_fork+0x1f/0x30
> > Modules linked in:
> > CR2:
> > ---[ end trace d0c4f561618aeb37 ]---
> > RIP: 0010:intel_psr_enabled+0xb/0x6e
> > Code: 8b 44 24 08 65 48 33 04 25 28 00 00 00 74 05 e8 7e ff 97 ff 48 83 c4
> > 10 5b 5d
> 41 5c 41 5d c3 0f 1f 44 00 00 41 55 41 54 55 53 <48> 8b 9f d8 fe ff ff f6 83
> 5e 08 00
> 00 20 75 05 45 31 e4 eb 44 80
> > RSP: :88840dedfa18 EFLAGS: 00010246
> > RAX: RBX: 8884086f9000 RCX:
> > RDX: 0001 RSI: 8884086f9000 RDI: 0128
> > RBP: 8884086fb000 R08: R09: 0001
> > R10: 0001 R11: 00ff R12: 88840868
> > R13: R14: R15: 8884086fb200
> > FS: () GS:88840fb0()
> knlGS:
> > CS: 0010 DS: ES: CR0: 80050033
> > CR2: CR3: 0440c001 CR4: 001606e0
> > Kernel panic - not syncing: Attempted to kill init! exitcode=0x0009
> > Kernel Offset: disabled
> > ---[ end Kernel panic - not syncing: Attempted to kill init!
> > exitcode=0x0009 ]---
> >
> >
> > Decoding the RIP gives:
> >
> > RIP: 0010:intel_psr_enabled (/data/fs/linux-
> fs/build3/../drivers/gpu/drm/i915/display/intel_display_types.h:1595
> /data/fs/linux-
> fs/build3/../drivers/gpu/drm/i915/display/intel_psr.c:1598)
> >
> >
> >
> > Commit c41219fda6e04255c44d37fd2c0d898c1c46abf1 ("Merge tag
> > 'drm-intel-next-fixes-2020-05-20' of
> > git://anongit.freedesktop.org/drm/drm-intel into drm-next") is definitely
> > bad
> > and logs an oops to the console and panics, but it's
Re: [Intel-gfx] [PATCH] Revert "drm/i915: Remove unneeded hack now for CDCLK"
On Mon, Jun 08, 2020 at 11:21:14AM +0300, Jani Nikula wrote:
> On Mon, 08 Jun 2020, Stanislav Lisovskiy
> wrote:
> > This reverts commit 82ea174dc5425d4e85e25d0c4ba961a2e494392a.
> >
>
> Please explain why. What's going on, why we need the revert.
>
> It's fine to reply here, the commit message can be amended by whoever
> applies the patch.
Yes,
Unfortunately according to our recent findings there is still some
unidentified factor, requiring CDCLK to be set higher - otherwise we
still get underruns on some multipipe configurations, despite CDCLK being set
according to BSpec formula. So getting again back into debug mode to
indentify the cause, meanwhile setting CDCLK=Pixel rate back in order
to remove regression in 10% of the cases due to FIFO underruns.
Stan
>
> BR,
> Jani.
>
>
> > Signed-off-by: Stanislav Lisovskiy
> > Fixes: cd1915460861 ("drm/i915: Adjust CDCLK accordingly to our DBuf bw
> > needs")
> > ---
> > drivers/gpu/drm/i915/display/intel_cdclk.c | 12
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > index 08468b121d02..45f7f33d1144 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > @@ -2071,6 +2071,18 @@ int intel_crtc_compute_min_cdclk(const struct
> > intel_crtc_state *crtc_state)
> > /* Account for additional needs from the planes */
> > min_cdclk = max(intel_planes_min_cdclk(crtc_state), min_cdclk);
> >
> > + /*
> > +* HACK. Currently for TGL platforms we calculate
> > +* min_cdclk initially based on pixel_rate divided
> > +* by 2, accounting for also plane requirements,
> > +* however in some cases the lowest possible CDCLK
> > +* doesn't work and causing the underruns.
> > +* Explicitly stating here that this seems to be currently
> > +* rather a Hack, than final solution.
> > +*/
> > + if (IS_TIGERLAKE(dev_priv))
> > + min_cdclk = max(min_cdclk, (int)crtc_state->pixel_rate);
> > +
> > if (min_cdclk > dev_priv->max_cdclk_freq) {
> > drm_dbg_kms(_priv->drm,
> > "required cdclk (%d kHz) exceeds max (%d kHz)\n",
>
> --
> Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for Revert "drm/i915: Remove unneeded hack now for CDCLK"
== Series Details == Series: Revert "drm/i915: Remove unneeded hack now for CDCLK" URL : https://patchwork.freedesktop.org/series/78106/ State : success == Summary == CI Bug Log - changes from CI_DRM_8599_full -> Patchwork_17903_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17903_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@engines-mixed-process@vcs0: - shard-skl: [PASS][1] -> [FAIL][2] ([i915#1528]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8599/shard-skl8/igt@gem_ctx_persistence@engines-mixed-proc...@vcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17903/shard-skl7/igt@gem_ctx_persistence@engines-mixed-proc...@vcs0.html * igt@gem_exec_suspend@basic-s3: - shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([i915#180]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8599/shard-kbl3/igt@gem_exec_susp...@basic-s3.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17903/shard-kbl1/igt@gem_exec_susp...@basic-s3.html * igt@gem_exec_whisper@basic-contexts-priority: - shard-glk: [PASS][5] -> [DMESG-WARN][6] ([i915#118] / [i915#95]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8599/shard-glk1/igt@gem_exec_whis...@basic-contexts-priority.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17903/shard-glk7/igt@gem_exec_whis...@basic-contexts-priority.html * igt@gem_mmap_offset@basic-uaf: - shard-apl: [PASS][7] -> [DMESG-WARN][8] ([i915#95]) +19 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8599/shard-apl2/igt@gem_mmap_off...@basic-uaf.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17903/shard-apl1/igt@gem_mmap_off...@basic-uaf.html * igt@i915_suspend@fence-restore-tiled2untiled: - shard-apl: [PASS][9] -> [DMESG-WARN][10] ([i915#180]) +3 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8599/shard-apl8/igt@i915_susp...@fence-restore-tiled2untiled.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17903/shard-apl4/igt@i915_susp...@fence-restore-tiled2untiled.html * igt@kms_big_fb@x-tiled-64bpp-rotate-0: - shard-apl: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8599/shard-apl3/igt@kms_big...@x-tiled-64bpp-rotate-0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17903/shard-apl8/igt@kms_big...@x-tiled-64bpp-rotate-0.html - shard-glk: [PASS][13] -> [DMESG-FAIL][14] ([i915#118] / [i915#95]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8599/shard-glk7/igt@kms_big...@x-tiled-64bpp-rotate-0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17903/shard-glk8/igt@kms_big...@x-tiled-64bpp-rotate-0.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - shard-skl: [PASS][15] -> [DMESG-WARN][16] ([i915#1982]) +9 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8599/shard-skl4/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17903/shard-skl2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_flip_tiling@flip-changes-tiling: - shard-skl: [PASS][17] -> [FAIL][18] ([i915#699]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8599/shard-skl8/igt@kms_flip_til...@flip-changes-tiling.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17903/shard-skl2/igt@kms_flip_til...@flip-changes-tiling.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-render: - shard-kbl: [PASS][19] -> [DMESG-WARN][20] ([i915#93] / [i915#95]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8599/shard-kbl4/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-draw-render.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17903/shard-kbl3/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-draw-render.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-pwrite: - shard-tglb: [PASS][21] -> [DMESG-WARN][22] ([i915#1982]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8599/shard-tglb3/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-shrfb-draw-pwrite.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17903/shard-tglb7/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-shrfb-draw-pwrite.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes: - shard-glk: [PASS][23] -> [DMESG-WARN][24] ([i915#1982]) [23]:
Re: [Intel-gfx] [PATCH] Revert "drm/i915: Remove unneeded hack now for CDCLK"
On Mon, 08 Jun 2020, Stanislav Lisovskiy wrote:
> This reverts commit 82ea174dc5425d4e85e25d0c4ba961a2e494392a.
>
Please explain why. What's going on, why we need the revert.
It's fine to reply here, the commit message can be amended by whoever
applies the patch.
BR,
Jani.
> Signed-off-by: Stanislav Lisovskiy
> Fixes: cd1915460861 ("drm/i915: Adjust CDCLK accordingly to our DBuf bw
> needs")
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 08468b121d02..45f7f33d1144 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -2071,6 +2071,18 @@ int intel_crtc_compute_min_cdclk(const struct
> intel_crtc_state *crtc_state)
> /* Account for additional needs from the planes */
> min_cdclk = max(intel_planes_min_cdclk(crtc_state), min_cdclk);
>
> + /*
> + * HACK. Currently for TGL platforms we calculate
> + * min_cdclk initially based on pixel_rate divided
> + * by 2, accounting for also plane requirements,
> + * however in some cases the lowest possible CDCLK
> + * doesn't work and causing the underruns.
> + * Explicitly stating here that this seems to be currently
> + * rather a Hack, than final solution.
> + */
> + if (IS_TIGERLAKE(dev_priv))
> + min_cdclk = max(min_cdclk, (int)crtc_state->pixel_rate);
> +
> if (min_cdclk > dev_priv->max_cdclk_freq) {
> drm_dbg_kms(_priv->drm,
> "required cdclk (%d kHz) exceeds max (%d kHz)\n",
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Avoid PSR and FBC features concurently.
== Series Details ==
Series: drm/i915/display: Avoid PSR and FBC features concurently.
URL : https://patchwork.freedesktop.org/series/78107/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8599 -> Patchwork_17904
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17904/index.html
Known issues
Here are the changes found in Patchwork_17904 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload:
- fi-byt-n2820: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8599/fi-byt-n2820/igt@i915_module_l...@reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17904/fi-byt-n2820/igt@i915_module_l...@reload.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-n3050: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8599/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17904/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- fi-icl-guc: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) +3 similar
issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8599/fi-icl-guc/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17904/fi-icl-guc/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
Possible fixes
* igt@i915_pm_backlight@basic-brightness:
- fi-whl-u: [DMESG-WARN][7] ([i915#95]) -> [PASS][8] +1 similar
issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8599/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17904/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- {fi-tgl-dsi}: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8599/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17904/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [DMESG-WARN][11] ([i915#62] / [i915#92] / [i915#95])
-> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8599/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17904/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-kefka: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14] +1
similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8599/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17904/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- fi-icl-u2: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8599/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17904/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
Warnings
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][18] ([i915#62] / [i915#92]) +5 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8599/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17904/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92]) ->
[DMESG-WARN][20] ([i915#62] / [i915#92] / [i915#95])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8599/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17904/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (46 -> 41)
--
Re: [Intel-gfx] A panic and a hang in the i915 drm driver
On Sun, 07 Jun 2020, David Howells wrote:
> Hi,
>
> I'm seeing the attached oops and panic from the i915 drm driver. I've tried
> bisecting it, but there's a problem in that one of the merged branches causes
> the machine to hang without output.
Cc: Ville and GG, I thought this was fixed (reverted) already.
BR,
Jani.
>
> The oops for commit c41219fda6e04255c44d37fd2c0d898c1c46abf1 looks like:
>
> BUG: kernel NULL pointer dereference, address:
> #PF: supervisor read access in kernel mode
> #PF: error_code(0x) - not-present page
> PGD 0 P4D 0
> Oops: [#1] SMP PTI
> CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.7.0-rc2-fscache+ #883
> Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014
> RIP: 0010:intel_psr_enabled+0xb/0x6e
> Code: 8b 44 24 08 65 48 33 04 25 28 00 00 00 74 05 e8 7e ff 97 ff 48 83 c4 10
> 5b 5d 41 5c 41 5d c3 0f 1f 44 00 00 41 55 41 54 55 53 <48> 8b 9f d8 fe ff ff
> f6 83 5e 08 00 00 20 75 05 45 31 e4 eb 44 80
> RSP: :88840dedfa18 EFLAGS: 00010246
> RAX: RBX: 8884086f9000 RCX:
> RDX: 0001 RSI: 8884086f9000 RDI: 0128
> RBP: 8884086fb000 R08: R09: 0001
> R10: 0001 R11: 00ff R12: 88840868
> R13: R14: R15: 8884086fb200
> FS: () GS:88840fb0() knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: CR3: 0440c001 CR4: 001606e0
> Call Trace:
> intel_read_dp_sdp+0x71/0x2c5
> hsw_crt_get_config+0x18/0x41
> intel_modeset_readout_hw_state+0x24d/0x662
> ? do_raw_spin_lock+0x8b/0xcd
> ? _raw_spin_lock_irqsave+0x10/0x16
> intel_modeset_setup_hw_state+0xa8/0xb59
> ? __next_node_in+0x39/0x42
> ? ww_mutex_lock+0x3d/0x1da
> ? modeset_lock+0xd4/0x114
> ? drm_modeset_lock_all_ctx+0x86/0xcc
> intel_modeset_init+0x285/0x5bf
> ? intel_irq_postinstall+0x485/0x4d1
> i915_driver_probe+0x1b4/0x49c
> ? __kernfs_new_node+0x161/0x1b2
> ? rpm_resume+0x45e/0x485
> i915_pci_probe+0xfd/0x11d
> ? __pm_runtime_resume+0x51/0x5e
> local_pci_probe+0x39/0x7a
> pci_device_probe+0xf5/0x14f
> ? sysfs_do_create_link_sd.isra.0+0x77/0xa3
> really_probe+0x140/0x2a9
> driver_probe_device+0x9c/0xd1
> device_driver_attach+0x3c/0x55
> __driver_attach+0x97/0x9f
> ? device_driver_attach+0x55/0x55
> bus_for_each_dev+0x72/0xa8
> bus_add_driver+0x108/0x1b9
> driver_register+0x9e/0xd7
> ? mipi_dsi_bus_init+0x11/0x11
> i915_init+0x58/0x6b
> do_one_initcall+0x83/0x18a
> kernel_init_freeable+0x19b/0x1fd
> ? rest_init+0x9f/0x9f
> kernel_init+0xa/0xfa
> ret_from_fork+0x1f/0x30
> Modules linked in:
> CR2:
> ---[ end trace d0c4f561618aeb37 ]---
> RIP: 0010:intel_psr_enabled+0xb/0x6e
> Code: 8b 44 24 08 65 48 33 04 25 28 00 00 00 74 05 e8 7e ff 97 ff 48 83 c4 10
> 5b 5d 41 5c 41 5d c3 0f 1f 44 00 00 41 55 41 54 55 53 <48> 8b 9f d8 fe ff ff
> f6 83 5e 08 00 00 20 75 05 45 31 e4 eb 44 80
> RSP: :88840dedfa18 EFLAGS: 00010246
> RAX: RBX: 8884086f9000 RCX:
> RDX: 0001 RSI: 8884086f9000 RDI: 0128
> RBP: 8884086fb000 R08: R09: 0001
> R10: 0001 R11: 00ff R12: 88840868
> R13: R14: R15: 8884086fb200
> FS: () GS:88840fb0() knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: CR3: 0440c001 CR4: 001606e0
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0009
> Kernel Offset: disabled
> ---[ end Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x0009 ]---
>
>
> Decoding the RIP gives:
>
> RIP: 0010:intel_psr_enabled
> (/data/fs/linux-fs/build3/../drivers/gpu/drm/i915/display/intel_display_types.h:1595
> /data/fs/linux-fs/build3/../drivers/gpu/drm/i915/display/intel_psr.c:1598)
>
>
>
> Commit c41219fda6e04255c44d37fd2c0d898c1c46abf1 ("Merge tag
> 'drm-intel-next-fixes-2020-05-20' of
> git://anongit.freedesktop.org/drm/drm-intel into drm-next") is definitely bad
> and logs an oops to the console and panics, but it's a merge.
>
> On one side is e20bb857dea2f620ff37ae541ed8aee70e3c89f1 ("Merge tag
> 'exynos-drm-next-for-v5.8' of
> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into
> drm-next"), which hangs. This is also a merge.
>
> One side of e20bb is f84e1ba336a4f47ae251e4d2d8a694902571b0df
> ("drm/exynos-vidi: convert platform driver to use dev_groups") which is good.
>
> The other side of c4121 and e20bb derive from the same line of commits, with
> three patches between. All of these, down to at least
> 230982d8d8df7f9d9aa216840ea2db1df6ad5d37 ("drm/i915: Update DRIVER_DATE to
> 20200430") cause the machine to hang without any sort of console output.
>
> Commit
Re: [Intel-gfx] [PATCH 01/28] drm/i915: Adjust the sentinel assert to match implementation
On 07/06/2020 23:20, Chris Wilson wrote:
From: Tvrtko Ursulin
Sentinels are supposed to be last reqeusts in the elsp queue, not the
only one, so adjust the assert accordingly.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index d55a5e0466e5..db8a170b0e5c 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1635,9 +1635,9 @@ assert_pending_valid(const struct intel_engine_execlists
*execlists,
ccid = ce->lrc.ccid;
/*
-* Sentinels are supposed to be lonely so they flush the
-* current exection off the HW. Check that they are the
-* only request in the pending submission.
+* Sentinels are supposed to be the last request so they flush
+* the current exection off the HW. Check that they are the only
+* request in the pending submission.
*/
if (sentinel) {
GEM_TRACE_ERR("%s: context:%llx after sentinel in
pending[%zd]\n",
@@ -1646,15 +1646,7 @@ assert_pending_valid(const struct intel_engine_execlists
*execlists,
port - execlists->pending);
return false;
}
-
sentinel = i915_request_has_sentinel(rq);
FWIW I was changing it to "sentinel |= ..." so it keeps working if we
decide to use more than 2 elsp ports on Icelake one day.
Regards,
Tvrtko
- if (sentinel && port != execlists->pending) {
- GEM_TRACE_ERR("%s: sentinel context:%llx not in prime
position[%zd]\n",
- engine->name,
- ce->timeline->fence_context,
- port - execlists->pending);
- return false;
- }
/* Hold tightly onto the lock to prevent concurrent retires! */
if (!spin_trylock_irqsave(>lock, flags))
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/display: Avoid PSR and FBC features concurently.
== Series Details ==
Series: drm/i915/display: Avoid PSR and FBC features concurently.
URL : https://patchwork.freedesktop.org/series/78107/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
dee7c897c6ed drm/i915/display: Avoid PSR and FBC features concurently.
-:6: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#6:
Issue: Enble both PSR and FBC caused some fickers on some eDP panels (eg. Panel
GIS
-:6: WARNING:TYPO_SPELLING: 'Enble' may be misspelled - perhaps 'Enable'?
#6:
Issue: Enble both PSR and FBC caused some fickers on some eDP panels (eg. Panel
GIS
-:29: WARNING:SUSPECT_CODE_INDENT: suspect code indent for conditional
statements (8, 15)
#29: FILE: drivers/gpu/drm/i915/display/intel_fbc.c:1422:
+ if (i915_modparams.enable_psr) {
+ i915_modparams.enable_fbc = 0;
-:30: ERROR:CODE_INDENT: code indent should use tabs where possible
#30: FILE: drivers/gpu/drm/i915/display/intel_fbc.c:1423:
+ i915_modparams.enable_fbc = 0;$
-:30: WARNING:LEADING_SPACE: please, no spaces at the start of a line
#30: FILE: drivers/gpu/drm/i915/display/intel_fbc.c:1423:
+ i915_modparams.enable_fbc = 0;$
-:31: ERROR:CODE_INDENT: code indent should use tabs where possible
#31: FILE: drivers/gpu/drm/i915/display/intel_fbc.c:1424:
+DRM_DEBUG_KMS("PSR enabled. FBC no longer needed. Disable
FBC. \n");$
-:31: WARNING:LEADING_SPACE: please, no spaces at the start of a line
#31: FILE: drivers/gpu/drm/i915/display/intel_fbc.c:1424:
+DRM_DEBUG_KMS("PSR enabled. FBC no longer needed. Disable
FBC. \n");$
-:31: WARNING:QUOTED_WHITESPACE_BEFORE_NEWLINE: unnecessary whitespace before a
quoted newline
#31: FILE: drivers/gpu/drm/i915/display/intel_fbc.c:1424:
+DRM_DEBUG_KMS("PSR enabled. FBC no longer needed. Disable
FBC. \n");
-:34: CHECK:LINE_SPACING: Please don't use multiple blank lines
#34: FILE: drivers/gpu/drm/i915/display/intel_fbc.c:1427:
+
+
-:53: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s)
total: 3 errors, 6 warnings, 1 checks, 23 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: Remove unneeded hack now for CDCLK"
== Series Details == Series: Revert "drm/i915: Remove unneeded hack now for CDCLK" URL : https://patchwork.freedesktop.org/series/78106/ State : success == Summary == CI Bug Log - changes from CI_DRM_8599 -> Patchwork_17903 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17903/index.html Known issues Here are the changes found in Patchwork_17903 that come from known issues: ### IGT changes ### Issues hit * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-bsw-n3050: [PASS][1] -> [DMESG-WARN][2] ([i915#1982]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8599/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17903/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html Possible fixes * igt@i915_pm_rpm@basic-pci-d3-state: - fi-bsw-kefka: [DMESG-WARN][3] ([i915#1982]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8599/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17903/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html * igt@kms_busy@basic@flip: - fi-kbl-x1275: [DMESG-WARN][5] ([i915#62] / [i915#92] / [i915#95]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8599/fi-kbl-x1275/igt@kms_busy@ba...@flip.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17903/fi-kbl-x1275/igt@kms_busy@ba...@flip.html * igt@kms_cursor_legacy@basic-flip-after-cursor-legacy: - fi-icl-u2: [DMESG-WARN][7] ([i915#1982]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8599/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17903/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html Warnings * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - fi-kbl-x1275: [DMESG-WARN][9] ([i915#62] / [i915#92]) -> [DMESG-WARN][10] ([i915#62] / [i915#92] / [i915#95]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8599/fi-kbl-x1275/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17903/fi-kbl-x1275/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@kms_cursor_legacy@basic-flip-before-cursor-varying-size: - fi-kbl-x1275: [DMESG-WARN][11] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][12] ([i915#62] / [i915#92]) +5 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8599/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-size.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17903/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-size.html [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982 [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62 [i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92 [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95 Participating hosts (46 -> 41) -- Additional (1): fi-kbl-7560u Missing(6): fi-ilk-m540 fi-skl-guc fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper Build changes - * Linux: CI_DRM_8599 -> Patchwork_17903 CI-20190529: 20190529 CI_DRM_8599: 41ca9ea98b74c926c923e84931b9b4a4c3955e08 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5697: 5b8be04285ded1201fac5a2c2b50a7d70fa332d8 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17903: c2441c67163365c1e27cf62805b377392b66feb6 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == c2441c671633 Revert "drm/i915: Remove unneeded hack now for CDCLK" == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17903/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] Revert "drm/i915: Remove unneeded hack now for CDCLK"
This reverts commit 82ea174dc5425d4e85e25d0c4ba961a2e494392a.
Signed-off-by: Stanislav Lisovskiy
Fixes: cd1915460861 ("drm/i915: Adjust CDCLK accordingly to our DBuf bw needs")
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 08468b121d02..45f7f33d1144 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -2071,6 +2071,18 @@ int intel_crtc_compute_min_cdclk(const struct
intel_crtc_state *crtc_state)
/* Account for additional needs from the planes */
min_cdclk = max(intel_planes_min_cdclk(crtc_state), min_cdclk);
+ /*
+* HACK. Currently for TGL platforms we calculate
+* min_cdclk initially based on pixel_rate divided
+* by 2, accounting for also plane requirements,
+* however in some cases the lowest possible CDCLK
+* doesn't work and causing the underruns.
+* Explicitly stating here that this seems to be currently
+* rather a Hack, than final solution.
+*/
+ if (IS_TIGERLAKE(dev_priv))
+ min_cdclk = max(min_cdclk, (int)crtc_state->pixel_rate);
+
if (min_cdclk > dev_priv->max_cdclk_freq) {
drm_dbg_kms(_priv->drm,
"required cdclk (%d kHz) exceeds max (%d kHz)\n",
--
2.24.1.485.gad05a3d8e5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/display: Avoid PSR and FBC features concurently.
Issue: Enble both PSR and FBC caused some fickers on some eDP panels (eg. Panel
GIS
13.5" QHD Glare NE135FBM-N41/NC135GFL02). Disbling either PSR or FBC
will solve this flicker issue.
Both PSR and FBC features save power when render is not busy. When PSR is
active, saving power achieved by source turning off source transmitter and
main link,
putting memory on self-refresh mode. Therefore with PSR enabled,
FBC role is minimized since PSR power saving already covers most what
FBC does. Disabling FBC in case to avoid conflict between PSR and FBC
which causes display anomaly in some scenarios.
Tests:
Booted system with PSR enabled, verified FBC disabled.
Disabled PSR with disabled (i915.enable_psr=0), verified FBC enabled.
---
drivers/gpu/drm/i915/display/intel_fbc.c | 6 ++
drivers/gpu/drm/i915/display/intel_psr.c | 4 +++-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 1c26673acb2d..52bc7483adb5 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -1419,6 +1419,12 @@ void intel_fbc_init(struct drm_i915_private *dev_priv)
drm_dbg_kms(_priv->drm, "Sanitized enable_fbc value: %d\n",
i915_modparams.enable_fbc);
+ if (i915_modparams.enable_psr) {
+ i915_modparams.enable_fbc = 0;
+DRM_DEBUG_KMS("PSR enabled. FBC no longer needed. Disable
FBC. \n");
+ }
+
+
if (!HAS_FBC(dev_priv)) {
fbc->no_fbc_reason = "unsupported by this chipset";
return;
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index b7a2c102648a..25accfdd5ad3 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -1439,8 +1439,10 @@ void intel_psr_init(struct drm_i915_private *dev_priv)
if (!HAS_PSR(dev_priv))
return;
- if (!dev_priv->psr.sink_support)
+ if (!dev_priv->psr.sink_support) {
+ i915_modparams.enable_psr = 0;
return;
+ }
if (IS_HASWELL(dev_priv))
/*
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
