[Intel-gfx] Regression on linux-next (next-20231016)
Hello Lorenzo, Hope you are doing well. I am Chaitanya from the linux graphics team in Intel. This mail is regarding a regression we are seeing in our CI runs[1] on linux-next repository. Since the version next-20231016 [2], we are seeing the following error ``` <6>[4.550196] e1000e :00:1f.6 enp0s31f6: renamed from eth0 <1>[4.581173] BUG: kernel NULL pointer dereference, address: 01b8 <1>[4.581178] #PF: supervisor read access in kernel mode <1>[4.581180] #PF: error_code(0x) - not-present page <6>[4.581182] PGD 0 P4D 0 <4>[4.581184] Oops: [#1] PREEMPT SMP NOPTI <4>[4.581186] CPU: 6 PID: 460 Comm: apache2 Not tainted 6.6.0-rc6-next-20231016-next-20231016-g4d0515b235de+ #1 <4>[4.581189] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.3157.A00.2204200131 04/20/2022 <4>[4.581193] RIP: 0010:mmap_region+0x803/0xa50 ` Details log can be found in [3]. After bisecting the tree, the following patch [4] seems to be causing the regression. ` 1db41d29b79ad271674081c752961edd064bbbac is the first bad commit commit 1db41d29b79ad271674081c752961edd064bbbac Author: Lorenzo Stoakes lstoa...@gmail.com Date: Thu Oct 12 18:04:30 2023 +0100 mm: perform the mapping_map_writable() check after call_mmap() In order for a F_SEAL_WRITE sealed memfd mapping to have an opportunity to clear VM_MAYWRITE, we must be able to invoke the appropriate vm_ops->mmap() handler to do so. We would otherwise fail the mapping_map_writable() check before we had the opportunity to avoid it. This patch moves this check after the call_mmap() invocation. Only memfd actively denies write access causing a potential failure here (in memfd_add_seals()), so there should be no impact on non-memfd cases. This patch makes the userland-visible change that MAP_SHARED, PROT_READ mappings of an F_SEAL_WRITE sealed memfd mapping will now succeed. There is a delicate situation with cleanup paths assuming that a writable mapping must have occurred in circumstances where it may now not have. In order to ensure we do not accidentally mark a writable file unwritable by mistake, we explicitly track whether we have a writable mapping and unmap only if we do. ` We also verified that reverting the patch fixes the issue. We didn't see the issue on next-20231018. Is there a fix already available for this? If not, could you please check why this patch causes the regression and if we can find a solution for it soon? [1] https://intel-gfx-ci.01.org/tree/linux-next/combined-alt.html? [2] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20231016 [3] https://intel-gfx-ci.01.org/tree/linux-next/next-20231016/bat-rpls-1/boot0.txt [4] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20231016=1db41d29b79ad271674081c752961edd064bbbac
[Intel-gfx] [PATCH v2 5/9] drm/ci: clean up xfails (specially flakes list)
Since the script that collected the list of the expectation files was bogus and placing test to the flakes list incorrectly, restart the expectation files with the correct script. This reduces a lot the number of tests in the flakes list. Signed-off-by: Helen Koike Reviewed-by: David Heidelberg --- v2: - fix typo in the commit message - re-add kms_cursor_legacy@flip-vs-cursor-toggle back to msm-sdm845-flakes.txt - removed kms_async_flips@crc,Fail from i915-cml-fails.txt --- .../gpu/drm/ci/xfails/amdgpu-stoney-fails.txt | 13 -- .../drm/ci/xfails/amdgpu-stoney-flakes.txt| 20 - drivers/gpu/drm/ci/xfails/i915-amly-fails.txt | 9 .../gpu/drm/ci/xfails/i915-amly-flakes.txt| 32 --- drivers/gpu/drm/ci/xfails/i915-apl-fails.txt | 11 - drivers/gpu/drm/ci/xfails/i915-apl-flakes.txt | 1 - drivers/gpu/drm/ci/xfails/i915-cml-fails.txt | 14 ++- drivers/gpu/drm/ci/xfails/i915-cml-flakes.txt | 38 - drivers/gpu/drm/ci/xfails/i915-glk-fails.txt | 17 drivers/gpu/drm/ci/xfails/i915-glk-flakes.txt | 41 --- drivers/gpu/drm/ci/xfails/i915-kbl-fails.txt | 7 drivers/gpu/drm/ci/xfails/i915-kbl-flakes.txt | 26 drivers/gpu/drm/ci/xfails/i915-tgl-fails.txt | 1 - drivers/gpu/drm/ci/xfails/i915-tgl-flakes.txt | 5 --- drivers/gpu/drm/ci/xfails/i915-whl-flakes.txt | 1 - .../drm/ci/xfails/mediatek-mt8173-flakes.txt | 0 .../drm/ci/xfails/mediatek-mt8183-fails.txt | 5 ++- .../drm/ci/xfails/mediatek-mt8183-flakes.txt | 14 --- .../gpu/drm/ci/xfails/meson-g12b-fails.txt| 14 --- .../gpu/drm/ci/xfails/meson-g12b-flakes.txt | 4 -- .../gpu/drm/ci/xfails/msm-apq8016-flakes.txt | 4 -- .../gpu/drm/ci/xfails/msm-apq8096-fails.txt | 2 + .../gpu/drm/ci/xfails/msm-apq8096-flakes.txt | 4 -- .../gpu/drm/ci/xfails/msm-sc7180-fails.txt| 15 --- .../gpu/drm/ci/xfails/msm-sc7180-flakes.txt | 24 +++ .../gpu/drm/ci/xfails/msm-sc7180-skips.txt| 18 +--- .../gpu/drm/ci/xfails/msm-sdm845-fails.txt| 9 +--- .../gpu/drm/ci/xfails/msm-sdm845-flakes.txt | 19 + .../drm/ci/xfails/rockchip-rk3288-fails.txt | 6 +++ .../drm/ci/xfails/rockchip-rk3288-flakes.txt | 9 .../drm/ci/xfails/rockchip-rk3399-fails.txt | 40 +- .../drm/ci/xfails/rockchip-rk3399-flakes.txt | 28 +++-- .../drm/ci/xfails/virtio_gpu-none-flakes.txt | 0 33 files changed, 162 insertions(+), 289 deletions(-) delete mode 100644 drivers/gpu/drm/ci/xfails/i915-amly-flakes.txt delete mode 100644 drivers/gpu/drm/ci/xfails/i915-apl-flakes.txt delete mode 100644 drivers/gpu/drm/ci/xfails/i915-cml-flakes.txt delete mode 100644 drivers/gpu/drm/ci/xfails/i915-glk-flakes.txt delete mode 100644 drivers/gpu/drm/ci/xfails/i915-kbl-flakes.txt delete mode 100644 drivers/gpu/drm/ci/xfails/i915-tgl-flakes.txt delete mode 100644 drivers/gpu/drm/ci/xfails/i915-whl-flakes.txt delete mode 100644 drivers/gpu/drm/ci/xfails/mediatek-mt8173-flakes.txt delete mode 100644 drivers/gpu/drm/ci/xfails/mediatek-mt8183-flakes.txt delete mode 100644 drivers/gpu/drm/ci/xfails/meson-g12b-flakes.txt delete mode 100644 drivers/gpu/drm/ci/xfails/msm-apq8016-flakes.txt delete mode 100644 drivers/gpu/drm/ci/xfails/msm-apq8096-flakes.txt delete mode 100644 drivers/gpu/drm/ci/xfails/rockchip-rk3288-flakes.txt delete mode 100644 drivers/gpu/drm/ci/xfails/virtio_gpu-none-flakes.txt diff --git a/drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt b/drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt index bd9392536e7c..aa57aaa8869b 100644 --- a/drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt +++ b/drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt @@ -1,8 +1,14 @@ kms_addfb_basic@bad-pitch-65536,Fail kms_addfb_basic@bo-too-small,Fail +kms_addfb_basic@too-high,Fail +kms_async_flips@async-flip-with-page-flip-events,Fail +kms_async_flips@crc,Fail kms_async_flips@invalid-async-flip,Fail -kms_atomic@plane-immutable-zpos,Fail +kms_atomic_transition@plane-all-modeset-transition-internal-panels,Fail +kms_atomic_transition@plane-all-transition,Fail +kms_atomic_transition@plane-all-transition-nonblocking,Fail kms_atomic_transition@plane-toggle-modeset-transition,Fail +kms_atomic_transition@plane-use-after-nonblocking-unbind,Fail kms_bw@linear-tiling-1-displays-2560x1440p,Fail kms_bw@linear-tiling-1-displays-3840x2160p,Fail kms_bw@linear-tiling-2-displays-3840x2160p,Fail @@ -11,9 +17,10 @@ kms_color@degamma,Fail kms_cursor_crc@cursor-size-change,Fail kms_cursor_crc@pipe-A-cursor-size-change,Fail kms_cursor_crc@pipe-B-cursor-size-change,Fail -kms_cursor_legacy@forked-move,Fail +kms_flip@flip-vs-modeset-vs-hang,Fail +kms_flip@flip-vs-panning-vs-hang,Fail kms_hdr@bpc-switch,Fail kms_hdr@bpc-switch-dpms,Fail +kms_plane@pixel-format,Fail kms_plane_multiple@atomic-pipe-A-tiling-none,Fail -kms_rmfb@close-fd,Fail kms_rotation_crc@primary-rotation-180,Fail diff --git
Re: [Intel-gfx] linux-next: build failure after merge of the drm-misc tree
Hi all,
On Thu, 12 Oct 2023 12:27:49 +1100 Stephen Rothwell
wrote:
>
> On Thu, 12 Oct 2023 12:22:09 +1100 Stephen Rothwell
> wrote:
> >
> > After merging the drm-misc tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > drivers/usb/typec/altmodes/displayport.c: In function 'dp_altmode_vdm':
> > drivers/usb/typec/altmodes/displayport.c:309:33: error: too few arguments
> > to function 'drm_connector_oob_hotplug_event'
> > 309 |
> > drm_connector_oob_hotplug_event(dp->connector_fwnode);
> > | ^~~
> > In file included from drivers/usb/typec/altmodes/displayport.c:17:
> > include/drm/drm_connector.h:1984:6: note: declared here
> > 1984 | void drm_connector_oob_hotplug_event(struct fwnode_handle
> > *connector_fwnode,
> > | ^~~
> >
> > Caused by commit
> >
> > fc93835bb0d7 ("drm: Add HPD state to drm_connector_oob_hotplug_event()")
> >
> > interacting with commit
> >
> > 89434b069e46 ("usb: typec: altmodes/displayport: Signal hpd low when
> > exiting mode")
> >
> > from the usb.current tree.
> >
> > I have applied the following merge fix patch.
> >
> > From: Stephen Rothwell
> > Date: Thu, 12 Oct 2023 12:17:31 +1100
> > Subject: [PATCH] fix up for "drm: Add HPD state to
> > drm_connector_oob_hotplug_event()"
> >
> > interacting with commit
> >
> > 89434b069e46 ("usb: typec: altmodes/displayport: Signal hpd low when
> > exiting mode")
> >
> > Signed-off-by: Stephen Rothwell
> > ---
> > drivers/usb/typec/altmodes/displayport.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/usb/typec/altmodes/displayport.c
> > b/drivers/usb/typec/altmodes/displayport.c
> > index ddfb5b6ace4f..eb0bf08fc97a 100644
> > --- a/drivers/usb/typec/altmodes/displayport.c
> > +++ b/drivers/usb/typec/altmodes/displayport.c
> > @@ -306,7 +306,8 @@ static int dp_altmode_vdm(struct typec_altmode *alt,
> > dp->data.status = 0;
> > dp->data.conf = 0;
> > if (dp->hpd) {
> > -
> > drm_connector_oob_hotplug_event(dp->connector_fwnode);
> > +
> > drm_connector_oob_hotplug_event(dp->connector_fwnode
>
> Pretend that there is a comma at the end of the above line :-)
>
> > +
> > connector_status_disconnected);
> > dp->hpd = false;
> > sysfs_notify(>alt->dev.kobj, "displayport",
> > "hpd");
> > }
> > --
> > 2.40.1
This is now a conflict between the drm tree and Linus' tree.
--
Cheers,
Stephen Rothwell
pgpFVfiQsTIH1.pgp
Description: OpenPGP digital signature
Re: [Intel-gfx] [PATCH 3/3] drm/i915/mtl: Add counters for engine busyness ticks
On 10/19/2023 09:21, Dong, Zhanjun wrote:
See comments inline below.
Zhanjun
On 2023-09-22 6:25 p.m., john.c.harri...@intel.com wrote:
From: Umesh Nerlige Ramappa
In new version of GuC engine busyness, GuC provides engine busyness
ticks as a 64 bit counter. Add a new counter to relay this value to the
user as is.
Signed-off-by: Umesh Nerlige Ramappa
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/intel_engine.h | 1 +
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 16 +
drivers/gpu/drm/i915/gt/intel_engine_types.h | 12
drivers/gpu/drm/i915/gt/intel_engine_user.c | 1 +
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 67 ++-
drivers/gpu/drm/i915/i915_pmu.c | 25 ++-
drivers/gpu/drm/i915/i915_pmu.h | 2 +-
include/uapi/drm/i915_drm.h | 13 +++-
8 files changed, 116 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index b58c30ac8ef02..57af7ec8ecd82 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -249,6 +249,7 @@ void intel_engine_dump_active_requests(struct
list_head *requests,
ktime_t intel_engine_get_busy_time(struct intel_engine_cs *engine,
ktime_t *now);
+u64 intel_engine_get_busy_ticks(struct intel_engine_cs *engine);
void intel_engine_get_hung_entity(struct intel_engine_cs *engine,
struct intel_context **ce, 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 84a75c95f3f7d..1c9ffb1ae9889 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -2426,6 +2426,22 @@ ktime_t intel_engine_get_busy_time(struct
intel_engine_cs *engine, ktime_t *now)
return engine->busyness(engine, now);
}
+/**
+ * intel_engine_get_busy_ticks() - Return current accumulated engine
busyness
+ * ticks
+ * @engine: engine to report on
+ *
+ * Returns accumulated ticks @engine was busy since engine stats
were enabled.
+ */
+u64 intel_engine_get_busy_ticks(struct intel_engine_cs *engine)
+{
+ if (!engine->busyness_ticks ||
+ !(engine->flags & I915_ENGINE_SUPPORTS_TICKS_STATS))
+ return 0;
+
+ return engine->busyness_ticks(engine);
+}
+
struct intel_context *
intel_engine_create_virtual(struct intel_engine_cs **siblings,
unsigned int count, unsigned long flags)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 40fd8f984d64b..a88d40c74d604 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -548,6 +548,11 @@ struct intel_engine_cs {
ktime_t (*busyness)(struct intel_engine_cs *engine,
ktime_t *now);
+ /*
+ * Get engine busyness ticks
+ */
+ u64 (*busyness_ticks)(struct intel_engine_cs *engine);
+
struct intel_engine_execlists execlists;
/*
@@ -574,6 +579,7 @@ struct intel_engine_cs {
#define I915_ENGINE_HAS_EU_PRIORITY BIT(10)
#define I915_ENGINE_FIRST_RENDER_COMPUTE BIT(11)
#define I915_ENGINE_USES_WA_HOLD_CCS_SWITCHOUT BIT(12)
+#define I915_ENGINE_SUPPORTS_TICKS_STATS BIT(13)
unsigned int flags;
/*
@@ -649,6 +655,12 @@ intel_engine_supports_stats(const struct
intel_engine_cs *engine)
return engine->flags & I915_ENGINE_SUPPORTS_STATS;
}
+static inline bool
+intel_engine_supports_tick_stats(const struct intel_engine_cs *engine)
+{
+ return engine->flags & I915_ENGINE_SUPPORTS_TICKS_STATS;
+}
+
static inline bool
intel_engine_has_preemption(const struct intel_engine_cs *engine)
{
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
b/drivers/gpu/drm/i915/gt/intel_engine_user.c
index dcedff41a825f..69eb610b5ab0a 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
@@ -100,6 +100,7 @@ static void set_scheduler_caps(struct
drm_i915_private *i915)
MAP(HAS_PREEMPTION, PREEMPTION),
MAP(HAS_SEMAPHORES, SEMAPHORES),
MAP(SUPPORTS_STATS, ENGINE_BUSY_STATS),
+ MAP(SUPPORTS_TICKS_STATS, ENGINE_BUSY_TICKS_STATS),
#undef MAP
};
struct intel_engine_cs *engine;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 0c1fee5360777..71749fb9ad35b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1289,12 +1289,7 @@ static void
busy_v1_guc_update_pm_timestamp(struct intel_guc *guc, ktime_t *now)
guc->busy.v1.gt_stamp = ((u64)gt_stamp_hi << 32) | gt_stamp_lo;
}
-/*
- * Unlike the execlist mode of submission total and active times are
in terms of
- * gt clocks. The *now parameter
[Intel-gfx] [PATCH] drm/i915/pmu: Check if pmu is closed before stopping event
When the driver unbinds, pmu is unregistered and i915->uabi_engines is
set to RB_ROOT. Due to this, when i915 PMU tries to stop the engine
events, it issues a warn_on because engine lookup fails.
All perf hooks are taking care of this using a pmu->closed flag that is
set when PMU unregisters. The stop event seems to have been left out.
Check for pmu->closed in pmu_event_stop as well.
Based on discussion here -
https://patchwork.freedesktop.org/patch/492079/?series=105790=2
v2: s/is/if/ in commit title
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/i915_pmu.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 108b675088ba..f861863eb7c1 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -831,9 +831,18 @@ static void i915_pmu_event_start(struct perf_event *event,
int flags)
static void i915_pmu_event_stop(struct perf_event *event, int flags)
{
+ struct drm_i915_private *i915 =
+ container_of(event->pmu, typeof(*i915), pmu.base);
+ struct i915_pmu *pmu = >pmu;
+
+ if (pmu->closed)
+ goto out;
+
if (flags & PERF_EF_UPDATE)
i915_pmu_event_read(event);
i915_pmu_disable(event);
+
+out:
event->hw.state = PERF_HES_STOPPED;
}
--
2.38.1
[Intel-gfx] [PATCH] drm/i915/pmu: Check is pmu is closed before stopping event
When the driver unbinds, pmu is unregistered and i915->uabi_engines is
set to RB_ROOT. Due to this, when i915 PMU tries to stop the engine
events, it issues a warn_on because engine lookup fails.
All perf hooks are taking care of this using a pmu->closed flag that is
set when PMU unregisters. The stop event seems to have been left out.
Check for pmu->closed in pmu_event_stop as well.
Based on discussion here -
https://patchwork.freedesktop.org/patch/492079/?series=105790=2
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/i915_pmu.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 108b675088ba..f861863eb7c1 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -831,9 +831,18 @@ static void i915_pmu_event_start(struct perf_event *event,
int flags)
static void i915_pmu_event_stop(struct perf_event *event, int flags)
{
+ struct drm_i915_private *i915 =
+ container_of(event->pmu, typeof(*i915), pmu.base);
+ struct i915_pmu *pmu = >pmu;
+
+ if (pmu->closed)
+ goto out;
+
if (flags & PERF_EF_UPDATE)
i915_pmu_event_read(event);
i915_pmu_disable(event);
+
+out:
event->hw.state = PERF_HES_STOPPED;
}
--
2.38.1
[Intel-gfx] [PATCH] drm/i915/pmu: Check is pmu is closed before stopping event
When the driver unbinds, pmu is unregistered and i915->uabi_engines is
set to RB_ROOT. Due to this, when i915 PMU tries to stop the engine
events, it issues a warn_on because engine lookup fails.
All perf hooks are taking care of this using a pmu->closed flag that is
set when PMU unregisters. The stop event seems to have been left out.
Check for pmu->closed in pmu_event_stop as well.
Based on discussion here -
https://patchwork.freedesktop.org/patch/492079/?series=105790=2
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/i915_pmu.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 108b675088ba..f861863eb7c1 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -831,9 +831,18 @@ static void i915_pmu_event_start(struct perf_event *event,
int flags)
static void i915_pmu_event_stop(struct perf_event *event, int flags)
{
+ struct drm_i915_private *i915 =
+ container_of(event->pmu, typeof(*i915), pmu.base);
+ struct i915_pmu *pmu = >pmu;
+
+ if (pmu->closed)
+ goto out;
+
if (flags & PERF_EF_UPDATE)
i915_pmu_event_read(event);
i915_pmu_disable(event);
+
+out:
event->hw.state = PERF_HES_STOPPED;
}
--
2.38.1
[Intel-gfx] [PATCH v2] drm/i915/mcr: Hold GT forcewake during steering operations
The steering control and semaphore registers are inside an "always on"
power domain with respect to RC6. However there are some issues if
higher-level platform sleep states are entering/exiting at the same time
these registers are accessed. Grabbing GT forcewake and holding it over
the entire lock/steer/unlock cycle ensures that those sleep states have
been fully exited before we access these registers.
This is expected to become a formally documented/numbered workaround
soon.
Note that this patch alone isn't expected to have an immediately
noticeable impact on MCR (mis)behavior; an upcoming pcode firmware
update will also be necessary to provide the other half of this
workaround.
v2:
- Move the forcewake inside the Xe_LPG-specific IP version check. This
should only be necessary on platforms that have a steering semaphore.
Fixes: 4186e2185b4f ("drm/i915/gt: Add dedicated MCR lock")
Cc: Radhakrishna Sripada
Cc: Jonathan Cavitt
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 24 ++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
index 326c2ed1d99b..34913912d8ae 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
@@ -376,9 +376,26 @@ void intel_gt_mcr_lock(struct intel_gt *gt, unsigned long
*flags)
* driver threads, but also with hardware/firmware agents. A dedicated
* locking register is used.
*/
- if (GRAPHICS_VER_FULL(gt->i915) >= IP_VER(12, 70))
+ if (GRAPHICS_VER_FULL(gt->i915) >= IP_VER(12, 70)) {
+ /*
+* The steering control and semaphore registers are inside an
+* "always on" power domain with respect to RC6. However there
+* are some issues if higher-level platform sleep states are
+* entering/exiting at the same time these registers are
+* accessed. Grabbing GT forcewake and holding it over the
+* entire lock/steer/unlock cycle ensures that those sleep
+* states have been fully exited before we access these
+* registers. This wakeref will be released in the unlock
+* routine.
+*
+* This is expected to become a formally documented/numbered
+* workaround soon.
+*/
+ intel_uncore_forcewake_get(gt->uncore, FORCEWAKE_GT);
+
err = wait_for(intel_uncore_read_fw(gt->uncore,
MTL_STEER_SEMAPHORE) ==
0x1, 100);
+ }
/*
* Even on platforms with a hardware lock, we'll continue to grab
@@ -415,8 +432,11 @@ void intel_gt_mcr_unlock(struct intel_gt *gt, unsigned
long flags)
{
spin_unlock_irqrestore(>mcr_lock, flags);
- if (GRAPHICS_VER_FULL(gt->i915) >= IP_VER(12, 70))
+ if (GRAPHICS_VER_FULL(gt->i915) >= IP_VER(12, 70)) {
intel_uncore_write_fw(gt->uncore, MTL_STEER_SEMAPHORE, 0x1);
+
+ intel_uncore_forcewake_put(gt->uncore, FORCEWAKE_GT);
+ }
}
/**
--
2.41.0
Re: [Intel-gfx] [PATCH 2/2] drm/i915/display: Abstract C10/C20 pll calculation
Quoting Lucas De Marchi (2023-10-18 19:28:31-03:00)
>As done with the hw readout, properly abstract the C10/C20 phy details
>inside intel_cx0_phy.c.
>
>Signed-off-by: Lucas De Marchi
Reviewed-by: Gustavo Sousa
>---
> drivers/gpu/drm/i915/display/intel_cx0_phy.c | 20
> drivers/gpu/drm/i915/display/intel_cx0_phy.h | 6 ++
> drivers/gpu/drm/i915/display/intel_ddi.c | 7 +--
> drivers/gpu/drm/i915/display/intel_dpll.c| 7 +--
> 4 files changed, 20 insertions(+), 20 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
>b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
>index 252492ec6111..8ffa52464516 100644
>--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
>+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
>@@ -2378,8 +2378,8 @@ static void intel_c20_pll_program(struct
>drm_i915_private *i915,
> BIT(0), cntx ? 0 : 1, MB_WRITE_COMMITTED);
> }
>
>-int intel_c10pll_calc_port_clock(struct intel_encoder *encoder,
>- const struct intel_c10pll_state *pll_state)
>+static int intel_c10pll_calc_port_clock(struct intel_encoder *encoder,
>+const struct intel_c10pll_state
>*pll_state)
> {
> unsigned int frac_quot = 0, frac_rem = 0, frac_den = 1;
> unsigned int multiplier, tx_clk_div, hdmi_div, refclk = 38400;
>@@ -2405,8 +2405,8 @@ int intel_c10pll_calc_port_clock(struct intel_encoder
>*encoder,
> return tmpclk;
> }
>
>-int intel_c20pll_calc_port_clock(struct intel_encoder *encoder,
>- const struct intel_c20pll_state *pll_state)
>+static int intel_c20pll_calc_port_clock(struct intel_encoder *encoder,
>+const struct intel_c20pll_state
>*pll_state)
> {
> unsigned int frac, frac_en, frac_quot, frac_rem, frac_den;
> unsigned int multiplier, refclk = 38400;
>@@ -3065,3 +3065,15 @@ void intel_cx0pll_readout_hw_state(struct intel_encoder
>*encoder,
> else
> intel_c20pll_readout_hw_state(encoder, _state->c20);
> }
>+
>+int intel_cx0pll_calc_port_clock(struct intel_encoder *encoder,
>+ const struct intel_cx0pll_state *pll_state)
>+{
>+struct drm_i915_private *i915 = to_i915(encoder->base.dev);
>+enum phy phy = intel_port_to_phy(i915, encoder->port);
>+
>+if (intel_is_c10phy(i915, phy))
>+return intel_c10pll_calc_port_clock(encoder, _state->c10);
>+
>+return intel_c20pll_calc_port_clock(encoder, _state->c20);
>+}
>diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.h
>b/drivers/gpu/drm/i915/display/intel_cx0_phy.h
>index ff7ccb7855aa..222aed16e739 100644
>--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.h
>+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.h
>@@ -33,17 +33,15 @@ intel_mtl_port_pll_type(struct intel_encoder *encoder,
> int intel_cx0pll_calc_state(struct intel_crtc_state *crtc_state, struct
> intel_encoder *encoder);
> void intel_cx0pll_readout_hw_state(struct intel_encoder *encoder,
>struct intel_cx0pll_state *pll_state);
>+int intel_cx0pll_calc_port_clock(struct intel_encoder *encoder,
>+ const struct intel_cx0pll_state *pll_state);
>
> void intel_c10pll_dump_hw_state(struct drm_i915_private *dev_priv,
> const struct intel_c10pll_state *hw_state);
>-int intel_c10pll_calc_port_clock(struct intel_encoder *encoder,
>- const struct intel_c10pll_state *pll_state);
> void intel_c10pll_state_verify(struct intel_atomic_state *state,
>struct intel_crtc *crtc);
> void intel_c20pll_dump_hw_state(struct drm_i915_private *i915,
> const struct intel_c20pll_state *hw_state);
>-int intel_c20pll_calc_port_clock(struct intel_encoder *encoder,
>- const struct intel_c20pll_state *pll_state);
> void intel_cx0_phy_set_signal_levels(struct intel_encoder *encoder,
> const struct intel_crtc_state
> *crtc_state);
> int intel_cx0_phy_check_hdmi_link_rate(struct intel_hdmi *hdmi, int clock);
>diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
>b/drivers/gpu/drm/i915/display/intel_ddi.c
>index 80a8ab7874db..c4dc1f71da4b 100644
>--- a/drivers/gpu/drm/i915/display/intel_ddi.c
>+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
>@@ -3854,18 +3854,13 @@ void intel_ddi_get_clock(struct intel_encoder *encoder,
> static void mtl_ddi_get_config(struct intel_encoder *encoder,
>struct intel_crtc_state *crtc_state)
> {
>-struct drm_i915_private *i915 = to_i915(encoder->base.dev);
>-enum phy phy = intel_port_to_phy(i915, encoder->port);
> struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
>
> if (intel_tc_port_in_tbt_alt_mode(dig_port))
Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: Abstract C10/C20 pll hw readout
Quoting Lucas De Marchi (2023-10-18 19:28:30-03:00)
>intel_cx0_phy.[ch] should contain the details about C10/C20, not leaking
>it to the rest of the driver. Start abstracting this by exporting a
>single PLL hw readout that handles the differences between C20 and C10
>internally to that compilation unit.
>
>Signed-off-by: Lucas De Marchi
Reviewed-by: Gustavo Sousa
>---
> drivers/gpu/drm/i915/display/intel_cx0_phy.c | 20
> drivers/gpu/drm/i915/display/intel_cx0_phy.h | 8 +---
> drivers/gpu/drm/i915/display/intel_ddi.c | 4 ++--
> 3 files changed, 23 insertions(+), 9 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
>b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
>index e775f4721158..252492ec6111 100644
>--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
>+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
>@@ -1850,8 +1850,8 @@ static int intel_c10pll_calc_state(struct
>intel_crtc_state *crtc_state,
> return -EINVAL;
> }
>
>-void intel_c10pll_readout_hw_state(struct intel_encoder *encoder,
>- struct intel_c10pll_state *pll_state)
>+static void intel_c10pll_readout_hw_state(struct intel_encoder *encoder,
>+ struct intel_c10pll_state
>*pll_state)
> {
> struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> u8 lane = INTEL_CX0_LANE0;
>@@ -2103,8 +2103,8 @@ static bool intel_c20_use_mplla(u32 clock)
> return false;
> }
>
>-void intel_c20pll_readout_hw_state(struct intel_encoder *encoder,
>- struct intel_c20pll_state *pll_state)
>+static void intel_c20pll_readout_hw_state(struct intel_encoder *encoder,
>+ struct intel_c20pll_state
>*pll_state)
> {
> struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> bool cntx;
>@@ -3053,3 +3053,15 @@ void intel_c10pll_state_verify(struct
>intel_atomic_state *state,
> crtc->base.base.id, crtc->base.name,
> mpllb_sw_state->cmn, mpllb_hw_state.cmn);
> }
>+
>+void intel_cx0pll_readout_hw_state(struct intel_encoder *encoder,
>+ struct intel_cx0pll_state *pll_state)
>+{
>+struct drm_i915_private *i915 = to_i915(encoder->base.dev);
>+enum phy phy = intel_port_to_phy(i915, encoder->port);
>+
>+if (intel_is_c10phy(i915, phy))
>+intel_c10pll_readout_hw_state(encoder, _state->c10);
>+else
>+intel_c20pll_readout_hw_state(encoder, _state->c20);
>+}
>diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.h
>b/drivers/gpu/drm/i915/display/intel_cx0_phy.h
>index 0e0a38dac8cd..ff7ccb7855aa 100644
>--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.h
>+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.h
>@@ -16,6 +16,7 @@ struct drm_i915_private;
> struct intel_atomic_state;
> struct intel_c10pll_state;
> struct intel_c20pll_state;
>+struct intel_cx0pll_state;
> struct intel_crtc;
> struct intel_crtc_state;
> struct intel_encoder;
>@@ -28,16 +29,17 @@ void intel_mtl_pll_disable(struct intel_encoder *encoder);
> enum icl_port_dpll_id
> intel_mtl_port_pll_type(struct intel_encoder *encoder,
> const struct intel_crtc_state *crtc_state);
>-void intel_c10pll_readout_hw_state(struct intel_encoder *encoder, struct
>intel_c10pll_state *pll_state);
>+
> int intel_cx0pll_calc_state(struct intel_crtc_state *crtc_state, struct
> intel_encoder *encoder);
>+void intel_cx0pll_readout_hw_state(struct intel_encoder *encoder,
>+ struct intel_cx0pll_state *pll_state);
>+
> void intel_c10pll_dump_hw_state(struct drm_i915_private *dev_priv,
> const struct intel_c10pll_state *hw_state);
> int intel_c10pll_calc_port_clock(struct intel_encoder *encoder,
> const struct intel_c10pll_state *pll_state);
> void intel_c10pll_state_verify(struct intel_atomic_state *state,
>struct intel_crtc *crtc);
>-void intel_c20pll_readout_hw_state(struct intel_encoder *encoder,
>- struct intel_c20pll_state *pll_state);
> void intel_c20pll_dump_hw_state(struct drm_i915_private *i915,
> const struct intel_c20pll_state *hw_state);
> int intel_c20pll_calc_port_clock(struct intel_encoder *encoder,
>diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
>b/drivers/gpu/drm/i915/display/intel_ddi.c
>index 9151d5add960..80a8ab7874db 100644
>--- a/drivers/gpu/drm/i915/display/intel_ddi.c
>+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
>@@ -3861,10 +3861,10 @@ static void mtl_ddi_get_config(struct intel_encoder
>*encoder,
> if (intel_tc_port_in_tbt_alt_mode(dig_port)) {
> crtc_state->port_clock =
> intel_mtl_tbt_calc_port_clock(encoder);
> } else if (intel_is_c10phy(i915, phy)) {
>-
[Intel-gfx] [PATCH] drm/i915/mcr: Hold GT forcewake during steering operations
The steering control and semaphore registers are inside an "always on"
power domain with respect to RC6. However there are some issues if
higher-level platform sleep states are entering/exiting at the same time
these registers are accessed. Grabbing GT forcewake and holding it over
the entire lock/steer/unlock cycle ensures that those sleep states have
been fully exited before we access these registers.
This is expected to become a formally documented/numbered workaround
soon.
Note that this patch alone isn't expected to have an immediately
noticeable impact on MCR (mis)behavior; an upcoming pcode firmware
update will also be necessary to provide the other half of this
workaround.
Fixes: 4186e2185b4f ("drm/i915/gt: Add dedicated MCR lock")
Cc: Radhakrishna Sripada
Cc: Jonathan Cavitt
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
index 326c2ed1d99b..83bb0575b426 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
@@ -371,6 +371,21 @@ void intel_gt_mcr_lock(struct intel_gt *gt, unsigned long
*flags)
lockdep_assert_not_held(>uncore->lock);
+ /*
+* The steering control and semaphore registers are inside an
+* "always on" power domain with respect to RC6. However there are
+* some issues if higher-level platform sleep states are
+* entering/exiting at the same time these registers are accessed.
+* Grabbing GT forcewake and holding it over the entire
+* lock/steer/unlock cycle ensures that those sleep states have been
+* fully exited before we access these registers. This
+* wakeref will be released in the unlock routine.
+*
+* This is expected to become a formally documented/numbered workaround
+* soon.
+*/
+ intel_uncore_forcewake_get(gt->uncore, FORCEWAKE_GT);
+
/*
* Starting with MTL, we need to coordinate not only with other
* driver threads, but also with hardware/firmware agents. A dedicated
@@ -417,6 +432,8 @@ void intel_gt_mcr_unlock(struct intel_gt *gt, unsigned long
flags)
if (GRAPHICS_VER_FULL(gt->i915) >= IP_VER(12, 70))
intel_uncore_write_fw(gt->uncore, MTL_STEER_SEMAPHORE, 0x1);
+
+ intel_uncore_forcewake_put(gt->uncore, FORCEWAKE_GT);
}
/**
--
2.41.0
Re: [Intel-gfx] [PATCH 3/3] drm/i915/mtl: Add counters for engine busyness ticks
See comments inline below.
Zhanjun
On 2023-09-22 6:25 p.m., john.c.harri...@intel.com wrote:
From: Umesh Nerlige Ramappa
In new version of GuC engine busyness, GuC provides engine busyness
ticks as a 64 bit counter. Add a new counter to relay this value to the
user as is.
Signed-off-by: Umesh Nerlige Ramappa
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/intel_engine.h| 1 +
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 16 +
drivers/gpu/drm/i915/gt/intel_engine_types.h | 12
drivers/gpu/drm/i915/gt/intel_engine_user.c | 1 +
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 67 ++-
drivers/gpu/drm/i915/i915_pmu.c | 25 ++-
drivers/gpu/drm/i915/i915_pmu.h | 2 +-
include/uapi/drm/i915_drm.h | 13 +++-
8 files changed, 116 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index b58c30ac8ef02..57af7ec8ecd82 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -249,6 +249,7 @@ void intel_engine_dump_active_requests(struct list_head
*requests,
ktime_t intel_engine_get_busy_time(struct intel_engine_cs *engine,
ktime_t *now);
+u64 intel_engine_get_busy_ticks(struct intel_engine_cs *engine);
void intel_engine_get_hung_entity(struct intel_engine_cs *engine,
struct intel_context **ce, 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 84a75c95f3f7d..1c9ffb1ae9889 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -2426,6 +2426,22 @@ ktime_t intel_engine_get_busy_time(struct
intel_engine_cs *engine, ktime_t *now)
return engine->busyness(engine, now);
}
+/**
+ * intel_engine_get_busy_ticks() - Return current accumulated engine busyness
+ * ticks
+ * @engine: engine to report on
+ *
+ * Returns accumulated ticks @engine was busy since engine stats were enabled.
+ */
+u64 intel_engine_get_busy_ticks(struct intel_engine_cs *engine)
+{
+ if (!engine->busyness_ticks ||
+ !(engine->flags & I915_ENGINE_SUPPORTS_TICKS_STATS))
+ return 0;
+
+ return engine->busyness_ticks(engine);
+}
+
struct intel_context *
intel_engine_create_virtual(struct intel_engine_cs **siblings,
unsigned int count, unsigned long flags)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 40fd8f984d64b..a88d40c74d604 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -548,6 +548,11 @@ struct intel_engine_cs {
ktime_t (*busyness)(struct intel_engine_cs *engine,
ktime_t *now);
+ /*
+* Get engine busyness ticks
+*/
+ u64 (*busyness_ticks)(struct intel_engine_cs *engine);
+
struct intel_engine_execlists execlists;
/*
@@ -574,6 +579,7 @@ struct intel_engine_cs {
#define I915_ENGINE_HAS_EU_PRIORITYBIT(10)
#define I915_ENGINE_FIRST_RENDER_COMPUTE BIT(11)
#define I915_ENGINE_USES_WA_HOLD_CCS_SWITCHOUT BIT(12)
+#define I915_ENGINE_SUPPORTS_TICKS_STATS BIT(13)
unsigned int flags;
/*
@@ -649,6 +655,12 @@ intel_engine_supports_stats(const struct intel_engine_cs
*engine)
return engine->flags & I915_ENGINE_SUPPORTS_STATS;
}
+static inline bool
+intel_engine_supports_tick_stats(const struct intel_engine_cs *engine)
+{
+ return engine->flags & I915_ENGINE_SUPPORTS_TICKS_STATS;
+}
+
static inline bool
intel_engine_has_preemption(const struct intel_engine_cs *engine)
{
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
b/drivers/gpu/drm/i915/gt/intel_engine_user.c
index dcedff41a825f..69eb610b5ab0a 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
@@ -100,6 +100,7 @@ static void set_scheduler_caps(struct drm_i915_private
*i915)
MAP(HAS_PREEMPTION, PREEMPTION),
MAP(HAS_SEMAPHORES, SEMAPHORES),
MAP(SUPPORTS_STATS, ENGINE_BUSY_STATS),
+ MAP(SUPPORTS_TICKS_STATS, ENGINE_BUSY_TICKS_STATS),
#undef MAP
};
struct intel_engine_cs *engine;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 0c1fee5360777..71749fb9ad35b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1289,12 +1289,7 @@ static void busy_v1_guc_update_pm_timestamp(struct
intel_guc *guc, ktime_t *now)
guc->busy.v1.gt_stamp = ((u64)gt_stamp_hi << 32) | gt_stamp_lo;
}
-/*
- * Unlike the execlist mode of
[Intel-gfx] [PULL] drm-intel-fixes
Hi Dave and Daniel, Here goes drm-intel-fixes-2023-10-19: - Fix display issue that was blocking S0ix (Khaled) - Retry gtt fault when out of fence registers (Ville) Thanks, Rodrigo. The following changes since commit 58720809f52779dc0f08e53e54b014209d13eebb: Linux 6.6-rc6 (2023-10-15 13:34:39 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2023-10-19 for you to fetch changes up to e339c6d628fe66c9b64bf31040a55770952aec57: drm/i915: Retry gtt fault when out of fence registers (2023-10-17 22:08:54 -0400) - Fix display issue that was blocking S0ix (Khaled) - Retry gtt fault when out of fence registers (Ville) Khaled Almahallawy (1): drm/i915/cx0: Only clear/set the Pipe Reset bit of the PHY Lanes Owned Ville Syrjälä (1): drm/i915: Retry gtt fault when out of fence registers drivers/gpu/drm/i915/display/intel_cx0_phy.c | 3 +-- drivers/gpu/drm/i915/gem/i915_gem_mman.c | 1 + 2 files changed, 2 insertions(+), 2 deletions(-)
[Intel-gfx] [PULL] drm-intel-next
Hi Dave and Daniel, This is our last pull request towards 6.7. I'm sending this on behalf of Jani, who was covering this round. The main reason for this extra PR is to ensure that we get MTL force_probe removed on 6.7. The platform has a good green picture in our BAT CI currently and is stable. Please notice that this is highly dependent on fixes that are coming through drm-intel-gt-next pull-request that Tvrtko just sent: https://lore.kernel.org/all/ZTFDFSbd%2FU7YP+hI@tursulin-desk/ Here goes drm-intel-next-2023-10-19: - Add new DG2 PCI IDs (Shekhar) - Remove watchdog timers for PSR on Lunar Lake (Mika Kahola) - DSB changes for proper handling of LUT programming (Ville) - Store DSC DPCD capabilities in the connector (Imre) - Clean up zero initializers (Ville) - Remove Meteor Lake force_probe protection (RK) Thanks, Rodrigo. The following changes since commit a6028afef98a6e3f059a014452914eb01035d530: drm/i915/dsi: Add some debug logging to mipi_exec_i2c (v2) (2023-10-12 12:41:54 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2023-10-19 for you to fetch changes up to 213c43676beb5f5a63cb27a0c8e8e71035b08445: drm/i915/mtl: Remove the 'force_probe' requirement for Meteor Lake (2023-10-18 06:23:41 +0200) - Add new DG2 PCI IDs (Shekhar) - Remove watchdog timers for PSR on Lunar Lake (Mika Kahola) - DSB changes for proper handling of LUT programming (Ville) - Store DSC DPCD capabilities in the connector (Imre) - Clean up zero initializers (Ville) - Remove Meteor Lake force_probe protection (RK) Imre Deak (19): drm/i915/dp: Sanitize DPCD revision check in intel_dp_get_dsc_sink_cap() drm/i915/dp: Store DSC DPCD capabilities in the connector drm/i915/dp_mst: Set connector DSC capabilities and decompression AUX drm/i915/dp: Use i915/intel connector local variables in i915_dsc_fec_support_show() drm/i915/dp: Use connector DSC DPCD in i915_dsc_fec_support_show() drm/i915/dp: Use connector DSC DPCD in intel_dp_dsc_compute_max_bpp() drm/i915/dp: Use connector DSC DPCD in intel_dp_supports_fec() drm/i915/dp: Use connector DSC DPCD in intel_dp_supports_dsc() drm/i915/dp: Use connector DSC DPCD in intel_dp_dsc_max_sink_compressed_bppx16() drm/i915/dp: Pass connector DSC DPCD to drm_dp_dsc_sink_supported_input_bpcs() drm/i915/dp: Pass only the required i915 to intel_dp_source_dsc_version_minor() drm/i915/dp: Pass only the required DSC DPCD to intel_dp_sink_dsc_version_minor() drm/i915/dp: Use connector DSC DPCD in intel_dp_dsc_compute_params() drm/i915/dp: Use connector DSC DPCD in intel_dp_dsc_supports_format() drm/i915/dp: Use connector DSC DPCD in intel_dp_dsc_get_slice_count() drm/i915/dp: Use connector DSC DPCD in intel_dp_mode_valid() drm/i915/dp: Use connector DSC DPCD in intel_dp_dsc_compute_config() drm/i915/dp_mst: Use connector DSC DPCD in intel_dp_mst_mode_valid_ctx() drm/i915/dp: Remove unused DSC caps from intel_dp Mika Kahola (1): drm/i915/lnl: Remove watchdog timers for PSR Radhakrishna Sripada (1): drm/i915/mtl: Remove the 'force_probe' requirement for Meteor Lake Shekhar Chauhan (1): drm/i915: Add new DG2 PCI IDs Ville Syrjälä (6): drm/i915/dsb: Allocate command buffer from local memory drm/i915/dsb: Correct DSB command buffer cache coherency settings drm/i915/dsb: Re-instate DSB for LUT updates drm/i915/display: Clean up zero initializers drm/i915/hdcp: Clean up zero initializers drm/i915/pci: Clean up zero initializers drivers/gpu/drm/i915/display/intel_acpi.c | 2 +- drivers/gpu/drm/i915/display/intel_color.c | 3 - drivers/gpu/drm/i915/display/intel_cx0_phy.c | 2 +- .../gpu/drm/i915/display/intel_display_debugfs.c | 22 +-- drivers/gpu/drm/i915/display/intel_display_types.h | 8 +- drivers/gpu/drm/i915/display/intel_dp.c| 212 - drivers/gpu/drm/i915/display/intel_dp.h| 7 +- .../gpu/drm/i915/display/intel_dp_aux_backlight.c | 4 +- drivers/gpu/drm/i915/display/intel_dp_mst.c| 37 +++- drivers/gpu/drm/i915/display/intel_dsb.c | 18 +- drivers/gpu/drm/i915/display/intel_gmbus.c | 2 +- .../gpu/drm/i915/display/intel_hdcp_gsc_message.c | 44 ++--- drivers/gpu/drm/i915/display/intel_plane_initial.c | 2 +- drivers/gpu/drm/i915/display/intel_psr.c | 10 +- drivers/gpu/drm/i915/display/intel_sdvo.c | 2 +- drivers/gpu/drm/i915/display/intel_snps_phy.c | 2 +- drivers/gpu/drm/i915/display/intel_wm.c| 2 +- drivers/gpu/drm/i915/i915_pci.c| 3 +- include/drm/i915_pciids.h | 6 +- 19 files changed, 235 insertions(+),
Re: [Intel-gfx] [PATCH 2/2] drm/i915/lnl: Fix check for TC phy
Quoting Lucas De Marchi (2023-10-18 19:24:41-03:00)
>With MTL adding PICA between the port and the real phy, the path
>add for DG2 stopped being followed and newer platforms are simply using
>the older path for TC phys. LNL is no different than MTL in this aspect,
>so just add it to the mess. In future the phy and port designation and
>deciding if it's TC should better be cleaned up.
>
>To make it just a bit better, also change intel_phy_is_snps() to show
>this is DG2-only.
>
>Signed-off-by: Lucas De Marchi
>---
> drivers/gpu/drm/i915/display/intel_display.c | 29 ++--
> 1 file changed, 15 insertions(+), 14 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/display/intel_display.c
>b/drivers/gpu/drm/i915/display/intel_display.c
>index 28d85e1e858e..0797ace31417 100644
>--- a/drivers/gpu/drm/i915/display/intel_display.c
>+++ b/drivers/gpu/drm/i915/display/intel_display.c
>@@ -1784,31 +1784,32 @@ bool intel_phy_is_combo(struct drm_i915_private
>*dev_priv, enum phy phy)
>
> bool intel_phy_is_tc(struct drm_i915_private *dev_priv, enum phy phy)
> {
>+/* DG2's "TC1" output uses a SNPS PHY and is handled separately */
> if (IS_DG2(dev_priv))
>-/* DG2's "TC1" output uses a SNPS PHY */
> return false;
>-else if (IS_ALDERLAKE_P(dev_priv) || DISPLAY_VER_FULL(dev_priv) ==
>IP_VER(14, 0))
>+
>+/*
>+ * TODO: This should mostly match intel_port_to_phy(), considering the
>+ * ports already encode if they are connected to a TC phy in their
>name.
>+ */
>+if (IS_LUNARLAKE(dev_priv) || IS_METEORLAKE(dev_priv) ||
>+IS_ALDERLAKE_P(dev_priv))
Just like already done with the previous patch, I think we should have a
paragraph in the commit message justifying s/DISPLAY_VER_FULL(dev_priv) ==
IP_VER(14, 0)/IS_METEORLAKE(dev_priv)/.
With that in place,
Reviewed-by: Gustavo Sousa
> return phy >= PHY_F && phy <= PHY_I;
> else if (IS_TIGERLAKE(dev_priv))
> return phy >= PHY_D && phy <= PHY_I;
> else if (IS_ICELAKE(dev_priv))
> return phy >= PHY_C && phy <= PHY_F;
>-else
>-return false;
>+
>+return false;
> }
>
> bool intel_phy_is_snps(struct drm_i915_private *dev_priv, enum phy phy)
> {
>-if (phy == PHY_NONE)
>-return false;
>-else if (IS_DG2(dev_priv))
>-/*
>- * All four "combo" ports and the TC1 port (PHY E) use
>- * Synopsis PHYs.
>- */
>-return phy <= PHY_E;
>-
>-return false;
>+/*
>+ * For DG2, and for DG2 only, all four "combo" ports and the TC1 port
>+ * (PHY E) use Synopsis PHYs.
>+ */
>+return IS_DG2(dev_priv) && phy > PHY_NONE && phy <= PHY_E;
> }
>
> enum phy intel_port_to_phy(struct drm_i915_private *i915, enum port port)
>--
>2.40.1
>
Re: [Intel-gfx] [PATCH 1/2] drm/i915/lnl: Extend C10/C20 phy
Quoting Lucas De Marchi (2023-10-18 19:24:40-03:00)
>For Lunar Lake, DDI-A is connected to C10 PHY, while TC1-TC3 are connected
>to C20 phy, like in Meteor Lake. Update the check in intel_is_c10phy()
>accordingly.
>
>This reverts the change in commit e388ae97e225 ("drm/i915/display:
>Eliminate IS_METEORLAKE checks") that turned that into a display engine
>version check. The phy <-> port connection is very SoC-specific and not
>related to that version.
>
>IS_LUNARLAKE() is defined to 0 in i915 as it's expected that the
>(upcoming) xe driver is the one defining the platform, with i915 only
>driving the display side.
>
>Bspec: 70818
>Signed-off-by: Lucas De Marchi
Reviewed-by: Gustavo Sousa
>---
> drivers/gpu/drm/i915/display/intel_cx0_phy.c | 2 +-
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
>b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
>index d414f6b7f993..e775f4721158 100644
>--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
>+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
>@@ -31,7 +31,7 @@
>
> bool intel_is_c10phy(struct drm_i915_private *i915, enum phy phy)
> {
>-if (DISPLAY_VER_FULL(i915) == IP_VER(14, 0) && phy < PHY_C)
>+if ((IS_LUNARLAKE(i915) || IS_METEORLAKE(i915)) && phy < PHY_C)
> return true;
>
> return false;
>diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
>index 6a2a78c61f21..259884b10d9a 100644
>--- a/drivers/gpu/drm/i915/i915_drv.h
>+++ b/drivers/gpu/drm/i915/i915_drv.h
>@@ -575,6 +575,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
> #define IS_DG2(i915)IS_PLATFORM(i915, INTEL_DG2)
> #define IS_PONTEVECCHIO(i915) IS_PLATFORM(i915, INTEL_PONTEVECCHIO)
> #define IS_METEORLAKE(i915) IS_PLATFORM(i915, INTEL_METEORLAKE)
>+#define IS_LUNARLAKE(i915) 0
>
> #define IS_DG2_G10(i915) \
> IS_SUBPLATFORM(i915, INTEL_DG2, INTEL_SUBPLATFORM_G10)
>--
>2.40.1
>
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/mtl: Don't set PIPE_CONTROL_FLUSH_L3 (rev5)
Hi Nirmoy, > > > > Possible regressions > > > > > > > > • igt@gem_exec_nop@basic-series: > > > > > > > > □ shard-glk: PASS -> INCOMPLETE +1 other test incomplete > > > > • > > > > igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-0-hflip-async-flip: > > > > > > > > □ shard-dg2: PASS -> TIMEOUT > > > > • igt@kms_cursor_crc@cursor-onscreen-64x21@pipe-d-hdmi-a-1: > > > > > > > > □ shard-tglu: PASS -> INCOMPLETE > > > > • igt@kms_psr@psr2_suspend: > > > > > > > > □ shard-mtlp: NOTRUN -> FAIL > > > > > > these failures look unrelated and besides they are not related to > > > MTL. > > > > There is something new on the shards which _seems_ to be implicating > > this patch. > > > > This previously all green test started failing in a bad way: > > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13775/shard-mtlp-6/igt@sysfs_preempt_timeout@time...@vecs0.html > > > > > > <5> [97.816201] Fence expiration time out > > i915-:00:02.0:sysfs_preempt_t[1166]:2! > > <3> [187.682308] INFO: task kworker/0:3:165 blocked for more than 61 > > seconds. > > <3> [187.689294] Tainted: G W > > 6.6.0-rc6-CI_DRM_13775-ge69e078f7bef+ #1 > > <3> [187.697375] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" > > disables this message. > > <6> [187.705354] task:kworker/0:3 state:D stack:13504 pid:165 > > ppid:2 flags:0x4000 > > <6> [187.705375] Workqueue: i915-unordered intel_gt_watchdog_work [i915] > > <6> [187.705671] Call Trace: > > <6> [187.705675] > > <6> [187.705683] __schedule+0x3a0/0xd70 > > <6> [187.705704] schedule+0x5c/0xd0 > > <6> [187.705713] guc_context_cancel_request+0x45e/0x9f0 [i915] > > <6> [187.706078] ? __pfx_autoremove_wake_function+0x10/0x10 > > <6> [187.706091] ? intel_gt_watchdog_work+0x20/0x260 [i915] > > <6> [187.706377] intel_gt_watchdog_work+0xd1/0x260 [i915] > > <6> [187.706624] ? process_scheduled_works+0x264/0x530 > > <6> [187.706635] process_scheduled_works+0x2db/0x530 > > <6> [187.706650] ? __pfx_worker_thread+0x10/0x10 > > <6> [187.706656] worker_thread+0x18c/0x350 > > <6> [187.706664] ? __pfx_worker_thread+0x10/0x10 > > <6> [187.706670] kthread+0xfe/0x130 > > <6> [187.706678] ? __pfx_kthread+0x10/0x10 > > <6> [187.706687] ret_from_fork+0x2c/0x50 > > <6> [187.706696] ? __pfx_kthread+0x10/0x10 > > <6> [187.706704] ret_from_fork_asm+0x1b/0x30 > > <6> [187.706724] > > > > I am not claiming it is at fault but the transition from green to timing > > out looks clear. > > https://jira.devtools.intel.com/browse/VLK-52300 This happening for a while > as per the filter. > > (machines are broken so cibuglog will not work till Tuesday) Thanks, that's what I thought, but I haven't had the chance to verify it. Andi
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/mtl: Don't set PIPE_CONTROL_FLUSH_L3 (rev5)
On 10/19/2023 10:14 AM, Tvrtko Ursulin wrote: On 18/10/2023 17:43, Andi Shyti wrote: Hi Vinay, Possible regressions • igt@gem_exec_nop@basic-series: □ shard-glk: PASS -> INCOMPLETE +1 other test incomplete • igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-0-hflip-async-flip: □ shard-dg2: PASS -> TIMEOUT • igt@kms_cursor_crc@cursor-onscreen-64x21@pipe-d-hdmi-a-1: □ shard-tglu: PASS -> INCOMPLETE • igt@kms_psr@psr2_suspend: □ shard-mtlp: NOTRUN -> FAIL these failures look unrelated and besides they are not related to MTL. There is something new on the shards which _seems_ to be implicating this patch. This previously all green test started failing in a bad way: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13775/shard-mtlp-6/igt@sysfs_preempt_timeout@time...@vecs0.html <5> [97.816201] Fence expiration time out i915-:00:02.0:sysfs_preempt_t[1166]:2! <3> [187.682308] INFO: task kworker/0:3:165 blocked for more than 61 seconds. <3> [187.689294] Tainted: G W 6.6.0-rc6-CI_DRM_13775-ge69e078f7bef+ #1 <3> [187.697375] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. <6> [187.705354] task:kworker/0:3 state:D stack:13504 pid:165 ppid:2 flags:0x4000 <6> [187.705375] Workqueue: i915-unordered intel_gt_watchdog_work [i915] <6> [187.705671] Call Trace: <6> [187.705675] <6> [187.705683] __schedule+0x3a0/0xd70 <6> [187.705704] schedule+0x5c/0xd0 <6> [187.705713] guc_context_cancel_request+0x45e/0x9f0 [i915] <6> [187.706078] ? __pfx_autoremove_wake_function+0x10/0x10 <6> [187.706091] ? intel_gt_watchdog_work+0x20/0x260 [i915] <6> [187.706377] intel_gt_watchdog_work+0xd1/0x260 [i915] <6> [187.706624] ? process_scheduled_works+0x264/0x530 <6> [187.706635] process_scheduled_works+0x2db/0x530 <6> [187.706650] ? __pfx_worker_thread+0x10/0x10 <6> [187.706656] worker_thread+0x18c/0x350 <6> [187.706664] ? __pfx_worker_thread+0x10/0x10 <6> [187.706670] kthread+0xfe/0x130 <6> [187.706678] ? __pfx_kthread+0x10/0x10 <6> [187.706687] ret_from_fork+0x2c/0x50 <6> [187.706696] ? __pfx_kthread+0x10/0x10 <6> [187.706704] ret_from_fork_asm+0x1b/0x30 <6> [187.706724] I am not claiming it is at fault but the transition from green to timing out looks clear. https://jira.devtools.intel.com/browse/VLK-52300 This happening for a while as per the filter. (machines are broken so cibuglog will not work till Tuesday) Regards, Tvrtko
[Intel-gfx] [PULL] drm-intel-gt-next
Hi Dave, Daniel, Here is the final pull request for 6.7. As indicated that it may happen in the last pull, the remaining missing functionality for Meteorlake, enabling the GuC based TLB invalidation, has since been merged and platform thought to be ready for lifting out of force probe status. Also for Meteorlake a correction on how L3 flushing is done landed. Otherwise one fix for perf/OA and one for mmap gtt handling and some code base cleanups. Regards, Tvrtko drm-intel-gt-next-2023-10-19: Driver Changes: Fixes/improvements/new stuff: - Retry gtt fault when out of fence registers (Ville Syrjälä) - Determine context valid in OA reports [perf] (Umesh Nerlige Ramappa) Future platform enablement: - GuC based TLB invalidation for Meteorlake (Jonathan Cavitt, Prathap Kumar Valsan) - Don't set PIPE_CONTROL_FLUSH_L3 [mtl] (Vinay Belgaumkar) Miscellaneous: - Clean up zero initializers [guc,pxp] (Ville Syrjälä) - Prevent potential null-ptr-deref in engine_init_common (Nirmoy Das) The following changes since commit 039adf3947252693f7c882607dac2dc67e7f7ab2: drm/i915: More use of GT specific print helpers (2023-10-10 15:40:26 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-gt-next-2023-10-19 for you to fetch changes up to 7eeaedf79989a8f131939782832e21e9218ed2a0: drm/i915/perf: Determine context valid in OA reports (2023-10-18 16:19:56 -0700) Driver Changes: Fixes/improvements/new stuff: - Retry gtt fault when out of fence registers (Ville Syrjälä) - Determine context valid in OA reports [perf] (Umesh Nerlige Ramappa) Future platform enablement: - GuC based TLB invalidation for Meteorlake (Jonathan Cavitt, Prathap Kumar Valsan) - Don't set PIPE_CONTROL_FLUSH_L3 [mtl] (Vinay Belgaumkar) Miscellaneous: - Clean up zero initializers [guc,pxp] (Ville Syrjälä) - Prevent potential null-ptr-deref in engine_init_common (Nirmoy Das) Jonathan Cavitt (6): drm/i915: Add GuC TLB Invalidation device info flags drm/i915/guc: Add CT size delay helper drm/i915: No TLB invalidation on suspended GT drm/i915: No TLB invalidation on wedged GT drm/i915/gt: Increase sleep in gt_tlb selftest sanitycheck drm/i915: Enable GuC TLB invalidations for MTL Nirmoy Das (1): drm/i915: Prevent potential null-ptr-deref in engine_init_common Prathap Kumar Valsan (1): drm/i915: Define and use GuC and CTB TLB invalidation routines Umesh Nerlige Ramappa (1): drm/i915/perf: Determine context valid in OA reports Ville Syrjälä (3): drm/i915: Retry gtt fault when out of fence registers drm/i915/guc: Clean up zero initializers drm/i915/pxp: Clean up zero initializers Vinay Belgaumkar (1): drm/i915/mtl: Don't set PIPE_CONTROL_FLUSH_L3 drivers/gpu/drm/i915/gem/i915_gem_mman.c | 1 + drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 7 +- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 3 +- drivers/gpu/drm/i915/gt/intel_ggtt.c | 30 ++- drivers/gpu/drm/i915/gt/intel_tlb.c | 16 +- drivers/gpu/drm/i915/gt/selftest_tlb.c| 11 +- drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 33 +++ drivers/gpu/drm/i915/gt/uc/intel_guc.h| 23 +++ drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c| 4 +- drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 38 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 2 + drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 1 + drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 233 +- drivers/gpu/drm/i915/gt/uc/intel_uc.c | 7 + drivers/gpu/drm/i915/i915_drv.h | 2 + drivers/gpu/drm/i915/i915_pci.c | 1 + drivers/gpu/drm/i915/i915_perf.c | 4 +- drivers/gpu/drm/i915/intel_device_info.h | 1 + drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c| 8 +- drivers/gpu/drm/i915/pxp/intel_pxp_huc.c | 4 +- drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 8 +- 21 files changed, 407 insertions(+), 30 deletions(-)
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/mtl: Don't set PIPE_CONTROL_FLUSH_L3 (rev5)
On Thu, Oct 19, 2023 at 09:14:13AM +0100, Tvrtko Ursulin wrote: > > On 18/10/2023 17:43, Andi Shyti wrote: > > Hi Vinay, > > > > > Possible regressions > > > > > >• igt@gem_exec_nop@basic-series: > > > > > >□ shard-glk: PASS -> INCOMPLETE +1 other test incomplete > > >• igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-0-hflip-async-flip: > > > > > >□ shard-dg2: PASS -> TIMEOUT > > >• igt@kms_cursor_crc@cursor-onscreen-64x21@pipe-d-hdmi-a-1: > > > > > >□ shard-tglu: PASS -> INCOMPLETE > > >• igt@kms_psr@psr2_suspend: > > > > > >□ shard-mtlp: NOTRUN -> FAIL > > > > these failures look unrelated and besides they are not related to > > MTL. > > There is something new on the shards which _seems_ to be implicating this > patch. > > This previously all green test started failing in a bad way: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13775/shard-mtlp-6/igt@sysfs_preempt_timeout@time...@vecs0.html > > <5> [97.816201] Fence expiration time out > i915-:00:02.0:sysfs_preempt_t[1166]:2! > <3> [187.682308] INFO: task kworker/0:3:165 blocked for more than 61 seconds. > <3> [187.689294] Tainted: GW > 6.6.0-rc6-CI_DRM_13775-ge69e078f7bef+ #1 > <3> [187.697375] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables > this message. > <6> [187.705354] task:kworker/0:3 state:D stack:13504 pid:165 ppid:2 > flags:0x4000 > <6> [187.705375] Workqueue: i915-unordered intel_gt_watchdog_work [i915] > <6> [187.705671] Call Trace: > <6> [187.705675] > <6> [187.705683] __schedule+0x3a0/0xd70 > <6> [187.705704] schedule+0x5c/0xd0 > <6> [187.705713] guc_context_cancel_request+0x45e/0x9f0 [i915] > <6> [187.706078] ? __pfx_autoremove_wake_function+0x10/0x10 > <6> [187.706091] ? intel_gt_watchdog_work+0x20/0x260 [i915] > <6> [187.706377] intel_gt_watchdog_work+0xd1/0x260 [i915] > <6> [187.706624] ? process_scheduled_works+0x264/0x530 > <6> [187.706635] process_scheduled_works+0x2db/0x530 > <6> [187.706650] ? __pfx_worker_thread+0x10/0x10 > <6> [187.706656] worker_thread+0x18c/0x350 > <6> [187.706664] ? __pfx_worker_thread+0x10/0x10 > <6> [187.706670] kthread+0xfe/0x130 > <6> [187.706678] ? __pfx_kthread+0x10/0x10 > <6> [187.706687] ret_from_fork+0x2c/0x50 > <6> [187.706696] ? __pfx_kthread+0x10/0x10 > <6> [187.706704] ret_from_fork_asm+0x1b/0x30 > <6> [187.706724] > > I am not claiming it is at fault but the transition from green to timing out > looks clear. This looks an unrelated failure to me... Before merging this patch I did consult with Vinay. Vinay, could you please double check here? Andi
[Intel-gfx] [PATCH v3 1/3] pwm: make it possible to apply pwm changes in atomic context
Some drivers require sleeping, for example if the pwm device is connected
over i2c. The pwm-ir-tx requires precise timing, and sleeping causes havoc
with the generated IR signal when sleeping occurs.
This patch makes it possible to use pwm when the driver does not sleep,
by introducing the pwm_can_sleep() function.
Signed-off-by: Sean Young
---
Documentation/driver-api/pwm.rst | 16 +++-
.../gpu/drm/i915/display/intel_backlight.c| 6 +-
drivers/gpu/drm/solomon/ssd130x.c | 2 +-
drivers/hwmon/pwm-fan.c | 8 +-
drivers/input/misc/da7280.c | 4 +-
drivers/input/misc/pwm-beeper.c | 4 +-
drivers/input/misc/pwm-vibra.c| 8 +-
drivers/leds/leds-pwm.c | 2 +-
drivers/leds/rgb/leds-pwm-multicolor.c| 4 +-
drivers/media/rc/pwm-ir-tx.c | 4 +-
drivers/platform/x86/lenovo-yogabook.c| 2 +-
drivers/pwm/core.c| 75 ++-
drivers/pwm/pwm-renesas-tpu.c | 1 -
drivers/pwm/pwm-twl-led.c | 2 +-
drivers/pwm/pwm-vt8500.c | 2 +-
drivers/pwm/sysfs.c | 10 +--
drivers/regulator/pwm-regulator.c | 4 +-
drivers/video/backlight/lm3630a_bl.c | 2 +-
drivers/video/backlight/lp855x_bl.c | 2 +-
drivers/video/backlight/pwm_bl.c | 6 +-
drivers/video/fbdev/ssd1307fb.c | 2 +-
include/linux/pwm.h | 57 ++
22 files changed, 147 insertions(+), 76 deletions(-)
diff --git a/Documentation/driver-api/pwm.rst b/Documentation/driver-api/pwm.rst
index 3fdc95f7a1d15..a2fb5f8f6e1f8 100644
--- a/Documentation/driver-api/pwm.rst
+++ b/Documentation/driver-api/pwm.rst
@@ -41,7 +41,15 @@ the getter, devm_pwm_get() and devm_fwnode_pwm_get(), also
exist.
After being requested, a PWM has to be configured using::
- int pwm_apply_state(struct pwm_device *pwm, struct pwm_state *state);
+ int pwm_apply_cansleep(struct pwm_device *pwm, struct pwm_state *state);
+
+If the PWM support atomic mode, which can be determined with::
+
+bool pwm_is_atomic(struct pwm_device *pwm);
+
+Then the PWM can be configured with::
+
+ int pwm_apply(struct pwm_device *pwm, struct pwm_state *state);
This API controls both the PWM period/duty_cycle config and the
enable/disable state.
@@ -57,13 +65,13 @@ If supported by the driver, the signal can be optimized,
for example to improve
EMI by phase shifting the individual channels of a chip.
The pwm_config(), pwm_enable() and pwm_disable() functions are just wrappers
-around pwm_apply_state() and should not be used if the user wants to change
+around pwm_apply_cansleep() and should not be used if the user wants to change
several parameter at once. For example, if you see pwm_config() and
pwm_{enable,disable}() calls in the same function, this probably means you
-should switch to pwm_apply_state().
+should switch to pwm_apply_cansleep().
The PWM user API also allows one to query the PWM state that was passed to the
-last invocation of pwm_apply_state() using pwm_get_state(). Note this is
+last invocation of pwm_apply_cansleep() using pwm_get_state(). Note this is
different to what the driver has actually implemented if the request cannot be
satisfied exactly with the hardware in use. There is currently no way for
consumers to get the actually implemented settings.
diff --git a/drivers/gpu/drm/i915/display/intel_backlight.c
b/drivers/gpu/drm/i915/display/intel_backlight.c
index 2e8f17c045222..cf516190cde8f 100644
--- a/drivers/gpu/drm/i915/display/intel_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_backlight.c
@@ -274,7 +274,7 @@ static void ext_pwm_set_backlight(const struct
drm_connector_state *conn_state,
struct intel_panel *panel =
_intel_connector(conn_state->connector)->panel;
pwm_set_relative_duty_cycle(>backlight.pwm_state, level, 100);
- pwm_apply_state(panel->backlight.pwm, >backlight.pwm_state);
+ pwm_apply_cansleep(panel->backlight.pwm, >backlight.pwm_state);
}
static void
@@ -427,7 +427,7 @@ static void ext_pwm_disable_backlight(const struct
drm_connector_state *old_conn
intel_backlight_set_pwm_level(old_conn_state, level);
panel->backlight.pwm_state.enabled = false;
- pwm_apply_state(panel->backlight.pwm, >backlight.pwm_state);
+ pwm_apply_cansleep(panel->backlight.pwm, >backlight.pwm_state);
}
void intel_backlight_disable(const struct drm_connector_state *old_conn_state)
@@ -749,7 +749,7 @@ static void ext_pwm_enable_backlight(const struct
intel_crtc_state *crtc_state,
pwm_set_relative_duty_cycle(>backlight.pwm_state, level, 100);
panel->backlight.pwm_state.enabled = true;
- pwm_apply_state(panel->backlight.pwm, >backlight.pwm_state);
+
[Intel-gfx] [PULL] drm-misc-fixes
Hi Dave and Daniel, this is the PR for drm-misc-fixes. Best regards Thomas drm-misc-fixes-2023-10-19: Short summary of fixes pull: amdgpu: - Disable AMD_CTX_PRIORITY_UNSET bridge: - ti-sn65dsi86: Fix device lifetime edid: - Add quirk for BenQ GW2765 ivpu: - Extend address range for MMU mmap nouveau: - DP-connector fixes - Documentation fixes panel: - Move AUX B116XW03 into panel-simple scheduler: - Eliminate DRM_SCHED_PRIORITY_UNSET ttm: - Fix possible NULL-ptr deref in cleanup The following changes since commit c1165df2be2fffe3adeeaa68f4ee4325108c5e4e: drm/tiny: correctly print `struct resource *` on error (2023-10-12 10:57:07 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2023-10-19 for you to fetch changes up to 8f5ad367e8b884772945c6c9fb622ac94b7d3e32: accel/ivpu: Extend address range for MMU mmap (2023-10-19 08:01:20 +0200) Short summary of fixes pull: amdgpu: - Disable AMD_CTX_PRIORITY_UNSET bridge: - ti-sn65dsi86: Fix device lifetime edid: - Add quirk for BenQ GW2765 ivpu: - Extend address range for MMU mmap nouveau: - DP-connector fixes - Documentation fixes panel: - Move AUX B116XW03 into panel-simple scheduler: - Eliminate DRM_SCHED_PRIORITY_UNSET ttm: - Fix possible NULL-ptr deref in cleanup Douglas Anderson (1): drm/panel: Move AUX B116XW03 out of panel-edp back to panel-simple Hamza Mahfooz (1): drm/edid: add 8 bpc quirk to the BenQ GW2765 Jacek Lawrynowicz (1): accel/ivpu: Don't enter d0i3 during FLR Karol Herbst (1): drm/nouveau/disp: fix DP capable DSM connectors Karolina Stolarek (1): drm/ttm: Reorder sys manager cleanup step Luben Tuikov (2): drm/amdgpu: Unset context priority is now invalid gpu/drm: Eliminate DRM_SCHED_PRIORITY_UNSET Randy Dunlap (1): drm/nouveau: exec: fix ioctl kernel-doc warning Stanislaw Gruszka (1): Revert "accel/ivpu: Use cached buffers for FW loading" Stephen Boyd (1): drm/bridge: ti-sn65dsi86: Associate DSI device lifetime with auxiliary device Wludzik, Jozef (1): accel/ivpu: Extend address range for MMU mmap drivers/accel/ivpu/ivpu_drv.c| 11 ++-- drivers/accel/ivpu/ivpu_drv.h| 1 + drivers/accel/ivpu/ivpu_fw.c | 9 +++--- drivers/accel/ivpu/ivpu_gem.h| 5 drivers/accel/ivpu/ivpu_hw.h | 8 ++ drivers/accel/ivpu/ivpu_hw_37xx.c| 1 + drivers/accel/ivpu/ivpu_hw_40xx.c| 1 + drivers/accel/ivpu/ivpu_mmu_context.c| 9 ++ drivers/accel/ivpu/ivpu_pm.c | 3 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 5 ++-- drivers/gpu/drm/bridge/ti-sn65dsi86.c| 14 +- drivers/gpu/drm/drm_edid.c | 3 ++ drivers/gpu/drm/nouveau/nvkm/engine/disp/uconn.c | 14 +- drivers/gpu/drm/panel/panel-edp.c| 29 drivers/gpu/drm/panel/panel-simple.c | 35 drivers/gpu/drm/ttm/ttm_device.c | 8 +++--- include/drm/gpu_scheduler.h | 3 +- include/uapi/drm/nouveau_drm.h | 4 +-- 18 files changed, 96 insertions(+), 67 deletions(-) -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg)
[Intel-gfx] [PULL] drm-misc-next
drm-misc-next-2023-10-19: drm-misc-next for v6.7-rc1: UAPI Changes: Cross-subsystem Changes: - Update maintainers entry for megachips STDPx-GE-B850V3-FW. Core Changes: - Add VM_BIND async document. - Dual-license drm_gpuvm to GPL-2.0 OR MIT. Driver Changes: - Assorted small fixes in ivpu, bridge/megachips, ssd130x, st7703, bridge/lt9611uxc, rockchip. - Handle differences between various adv7511 chips better, and improve HPD handling. - Clock fixes for bridge/synopsis dw-mipi-dsi. - Add Powkiddy RGB30 support to st7703. - Add driver and DT support for ssd132x OLED controller to ssd130x. The following changes since commit c395c83aafbb9cdbe4230f044d5b8eaf9080c0c5: drm/simpledrm: Fix power domain device link validity check (2023-10-12 10:39:48 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2023-10-19 for you to fetch changes up to 2d23e7d6bacb779c4a740dbd5e18978fb075d15e: dt-bindings: display: Add SSD132x OLED controllers (2023-10-18 09:53:33 +0200) drm-misc-next for v6.7-rc1: UAPI Changes: Cross-subsystem Changes: - Update maintainers entry for megachips STDPx-GE-B850V3-FW. Core Changes: - Add VM_BIND async document. - Dual-license drm_gpuvm to GPL-2.0 OR MIT. Driver Changes: - Assorted small fixes in ivpu, bridge/megachips, ssd130x, st7703, bridge/lt9611uxc, rockchip. - Handle differences between various adv7511 chips better, and improve HPD handling. - Clock fixes for bridge/synopsis dw-mipi-dsi. - Add Powkiddy RGB30 support to st7703. - Add driver and DT support for ssd132x OLED controller to ssd130x. Andy Yan (2): drm/rockchip: remove unused struct in vop2 drm/rockchip: remove NR_LAYERS macro on vop2 Biju Das (8): drm: adv7511: Add struct adv7511_chip_info and use i2c_get_match_data() drm: adv7511: Add max_mode_clock_khz variable to struct adv7511_chip_info drm: adv7511: Add max_lane_freq_khz variable to struct adv7511_chip_info drm: adv7511: Add supply_names and num_supplies variables to struct adv7511_chip_info drm: adv7511: Add reg_cec_offset variable to struct adv7511_chip_info drm: adv7511: Add has_dsi variable to struct adv7511_chip_info drm: adv7511: Add link_config variable to struct adv7511_chip_info drm: adv7511: Add hpd_override_enable variable to struct adv7511_chip_info Chris Morgan (3): dt-bindings: vendor-prefixes: document Powkiddy dt-bindings: panel: Add Powkiddy RGB30 panel compatible drm/panel: st7703: Add Powkiddy RGB30 Panel Support Dan Carpenter (1): drm/rockchip: Fix type promotion bug in rockchip_gem_iommu_map() Dmitry Baryshkov (1): drm/bridge: lt9611uxc: fix the race in the error path Frank Oltmanns (1): drm/panel: st7703: Fix timings when entering/exiting sleep Ian Ray (2): drm/bridge: megachips-stdp-ge-b850v3-fw: switch to drm_do_get_edid() MAINTAINERS: Update entry for megachips-stdp-ge-b850v3-fw Jacek Lawrynowicz (1): accel/ivpu: Add ivpu_bo_vaddr() and ivpu_bo_size() Javier Martinez Canillas (6): drm/ssd130x: Replace .page_height field in device info with a constant drm/ssd130x: Add a controller family id to the device info data drm/ssd130x: Rename commands that are shared across chip families drm/ssd130x: Add support for the SSD132x OLED controller family dt-bindings: display: Split common Solomon properties in their own schema dt-bindings: display: Add SSD132x OLED controllers Liu Ying (9): drm/bridge: synopsys: dw-mipi-dsi: Add dw_mipi_dsi_get_bridge() helper drm/bridge: synopsys: dw-mipi-dsi: Add input bus format negotiation support drm/bridge: synopsys: dw-mipi-dsi: Force input bus flags drm/bridge: synopsys: dw-mipi-dsi: Add mode fixup support drm/bridge: synopsys: dw-mipi-dsi: Use pixel clock rate to calculate lbcc drm/bridge: synopsys: dw-mipi-dsi: Set minimum lane byte clock cycles for HSA and HBP drm/bridge: synopsys: dw-mipi-dsi: Disable HSTX and LPRX timeout check dt-bindings: display: bridge: Document Freescale i.MX93 MIPI DSI drm/bridge: imx: Add i.MX93 MIPI DSI support Ondrej Jirman (1): drm/panel: st7703: Pick different reset sequence Thomas Hellström (2): Documentation/gpu: Add a VM_BIND async document drm/gpuvm: Dual-licence the drm_gpuvm code GPL-2.0 OR MIT Thomas Zimmermann (1): drm/ssd130x: Fix atomic_check for disabled planes .../display/bridge/fsl,imx93-mipi-dsi.yaml | 115 +++ .../display/panel/rocktech,jh057n00900.yaml| 2 + .../bindings/display/solomon,ssd-common.yaml | 42 + .../bindings/display/solomon,ssd1307fb.yaml| 28 +- .../bindings/display/solomon,ssd132x.yaml | 89 ++
Re: [Intel-gfx] [CI] PR for new GuC v70.13.1
Already merged. josh On Wed, Oct 18, 2023 at 3:11 PM John Harrison wrote: > > Apologies, I sent this with the wrong subject. Please ignore. Will > resend with the correct subject. > > John. > > > On 10/18/2023 12:07, john.c.harri...@intel.com wrote: > > The following changes since commit 7727f7e3b3358713c7c91c64a835e80c331a6b8b: > > > >Merge branch 'patch-1696561325' into 'main' (2023-10-06 03:04:57 +) > > > > are available in the Git repository at: > > > >git://anongit.freedesktop.org/drm/drm-firmware guc_70.13.1 > > > > for you to fetch changes up to 44a9510c94ac0334931b6c89dd240ffe5bf1e5fa: > > > >i915: Add GuC v70.13.1 for DG2, TGL, ADL-P and MTL (2023-10-13 11:34:26 > > -0700) > > > > > > John Harrison (1): > >i915: Add GuC v70.13.1 for DG2, TGL, ADL-P and MTL > > > > WHENCE | 8 > > i915/adlp_guc_70.bin | Bin 297984 -> 342848 bytes > > i915/dg2_guc_70.bin | Bin 385856 -> 443200 bytes > > i915/mtl_guc_70.bin | Bin 308032 -> 365376 bytes > > i915/tgl_guc_70.bin | Bin 285888 -> 330304 bytes > > 5 files changed, 4 insertions(+), 4 deletions(-) >
Re: [Intel-gfx] [PATCH v3 1/3] pwm: make it possible to apply pwm changes in atomic context
On Wed, Oct 18, 2023 at 03:57:48PM +0200, Hans de Goede wrote: > Hi Sean, > > On 10/17/23 11:17, Sean Young wrote: > > Some drivers require sleeping, for example if the pwm device is connected > > over i2c. The pwm-ir-tx requires precise timing, and sleeping causes havoc > > with the generated IR signal when sleeping occurs. > > > > This patch makes it possible to use pwm when the driver does not sleep, > > by introducing the pwm_can_sleep() function. > > > > Signed-off-by: Sean Young > > I have no objection to this patch by itself, but it seems a bit > of unnecessary churn to change all current callers of pwm_apply_state() > to a new API. The idea is to improve the semantic of the function name, see https://lore.kernel.org/linux-pwm/20231013180449.mcdmklbsz2rly...@pengutronix.de for more context. I think it's very subjective if you consider this churn or not. While it's nice to have every caller converted in a single step, I'd go for #define pwm_apply_state(pwm, state) pwm_apply_cansleep(pwm, state) , keep that macro for a while and convert all users step by step. This way we don't needlessly break oot code and the changes to convert to the new API can go via their usual trees without time pressure. > Why not just keep pwm_apply_state() as is and introduce a new > pwm_apply_state_atomic() for callers which want to apply state > in a case where sleeping is not allowed ? There is a big spontaneous growth of function name patterns. I didn't claim having done a complete research, but not using a suffix for the fast variant and _cansleep for the sleeping one at least aligns to how the gpio subsystem names things. Grepping a bit more: - regmap has: regmap_might_sleep() and struct regmap::can_sleep The actual API doesn't have different functions to differentiate sleeping and non-sleeping calls. (Though there is regmap_read_poll_timeout_atomic().) - kmap() + kmap_atomic() - set_pte() + set_pte_atomic() - There is scmi_is_transport_atomic() and scmi_handle::is_transport_atomic() (Is this also about sleeping?) - There are quite a lot more symbols ending in _atomic and in _cansleep, but several of them don't exists to differentiate a slow and a fast procedure. (e.g. drm_mode_atomic) Not entirely sure what to read out of that. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Re: [Intel-gfx] [PATCH v2] debugobjects: stop accessing objects after releasing spinlock
On 13.10.2023 15:15, Thomas Gleixner wrote: On Mon, Sep 25 2023 at 15:13, Andrzej Hajda wrote: After spinlock release object can be modified/freed by concurrent thread. Using it in such case is error prone, even for printing object state. It cannot be freed. If that happens then the calling code will have an UAF problem on the tracked item too. Yes, and I have assumed that debugobjects are created also for detecting UAFs. They should be able to handle/detect 'issues due to incorrectly serialized concurrent accesses' scenarios as well, at least some of them. And even if it cannot recover it should at least provide reliable reporting. Now we can have scenario: 1. Thread tries to deactivate destroyed object, debugobjects detects it, spin lock is released, thread is preempted. 2. Other thread frees debugobject, then allocates new one on the same memory location, ie 'obj' variable from 1st thread point to it - it is possible because there is no locking. 3. Then preemption occurs, and 1st thread reports error for wrong object. This seems the most drastic for me, but also with lowest chances to happen due to delayed freeing, but there are also other more probable scenarios when we print the same object but in state different from the one when debugobject detected issue, due to modification by concurrent thread. If there is a concurrent modification then again, the calling code is lacking serialization on the tracked object. debugobject fundamentally relies on the call site being consistent simply because it _cannot_ invoke the fixup callbacks with the hash bucket lock held. Hmm, if call site is consistent then 'fixup' seems unnecessary, together with debugobjects. I guess 'fixup' users should take care of locking on they own in such case, as it is currently, nothing changed. What's the actualy problem you are trying to solve here. The changelog does not explain anything except of handwaving about modified/freed. Presented above. Regards Andrzej Thanks, tglx
Re: [Intel-gfx] [PATCH v4 2/2] drm/i915: remove display device info from i915 capabilities
> -Original Message- > From: Govindapillai, Vinod > Sent: Wednesday, October 18, 2023 3:57 PM > To: intel-gfx@lists.freedesktop.org > Cc: Govindapillai, Vinod ; Sharma, Swati2 > ; Borah, Chaitanya Kumar > > Subject: [PATCH v4 2/2] drm/i915: remove display device info from i915 > capabilities > > Display device and display runtime info is exposed as part of > i915_display_capabilities debugfs entry. Remove this information from i915_ > capabilities as it is now reduntant. > > Signed-off-by: Vinod Govindapillai LGTM. Reviewed-by: Chaitanya Kumar Borah > --- > drivers/gpu/drm/i915/i915_debugfs.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c > b/drivers/gpu/drm/i915/i915_debugfs.c > index e9b79c2c37d8..bb48feb3b12e 100644 > --- a/drivers/gpu/drm/i915/i915_debugfs.c > +++ b/drivers/gpu/drm/i915/i915_debugfs.c > @@ -67,7 +67,6 @@ static int i915_capabilities(struct seq_file *m, void *data) > seq_printf(m, "pch: %d\n", INTEL_PCH_TYPE(i915)); > > intel_device_info_print(INTEL_INFO(i915), RUNTIME_INFO(i915), ); > - intel_display_device_info_print(DISPLAY_INFO(i915), > DISPLAY_RUNTIME_INFO(i915), ); > i915_print_iommu_status(i915, ); > intel_gt_info_print(_gt(i915)->info, ); > intel_driver_caps_print(>caps, ); > -- > 2.34.1
Re: [Intel-gfx] [PATCH v4 1/2] drm/i915/display: debugfs entry to list display capabilities
> -Original Message-
> From: Govindapillai, Vinod
> Sent: Wednesday, October 18, 2023 3:57 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Govindapillai, Vinod ; Sharma, Swati2
> ; Borah, Chaitanya Kumar
>
> Subject: [PATCH v4 1/2] drm/i915/display: debugfs entry to list display
> capabilities
>
> Create a separate debugfs entry to list the display capabilities IGT can rely
> on
> this debugfs entry for tests that depend on display device and display runtime
> info for both xe and i915 drivers.
>
> v2: rename the entry to i915_display_capabilities (Chaitanya)
>
> Signed-off-by: Vinod Govindapillai
Assuming that it has no other impact in user-space. The change looks LGTM.
Reviewed-by: Chaitanya Kumar Borah
> ---
> drivers/gpu/drm/i915/display/intel_display_debugfs.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index fbe75d47a165..b0248dfa8dea 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -641,6 +641,17 @@ static int i915_display_info(struct seq_file *m, void
> *unused)
> return 0;
> }
>
> +static int i915_display_capabilities(struct seq_file *m, void *unused)
> +{
> + struct drm_i915_private *i915 = node_to_i915(m->private);
> + struct drm_printer p = drm_seq_file_printer(m);
> +
> + intel_display_device_info_print(DISPLAY_INFO(i915),
> + DISPLAY_RUNTIME_INFO(i915), );
> +
> + return 0;
> +}
> +
> static int i915_shared_dplls_info(struct seq_file *m, void *unused) {
> struct drm_i915_private *dev_priv = node_to_i915(m->private); @@
> -1059,6 +1070,7 @@ static const struct drm_info_list
> intel_display_debugfs_list[] = {
> {"i915_gem_framebuffer", i915_gem_framebuffer_info, 0},
> {"i915_power_domain_info", i915_power_domain_info, 0},
> {"i915_display_info", i915_display_info, 0},
> + {"i915_display_capabilities", i915_display_capabilities, 0},
> {"i915_shared_dplls_info", i915_shared_dplls_info, 0},
> {"i915_dp_mst_info", i915_dp_mst_info, 0},
> {"i915_ddb_info", i915_ddb_info, 0},
> --
> 2.34.1
Re: [Intel-gfx] [PATCH v2 9/9] drm/i915: Use kmap_local_page() in gem/i915_gem_execbuffer.c
Hi,
On 18/10/2023 17:19, Zhao Liu wrote:
Hi Rodrigo and Tvrtko,
It seems this series is missed in v6.5.
This work should not be forgotten. Let me rebase and refresh the version.
Right it seems we did not manage to social engineer any reviews. Please
do respin and we will try again.
Regards,
Tvrtko
Regards,
Zhao
On Mon, Apr 17, 2023 at 10:53:28AM -0400, Rodrigo Vivi wrote:
Date: Mon, 17 Apr 2023 10:53:28 -0400
From: Rodrigo Vivi
Subject: Re: [PATCH v2 9/9] drm/i915: Use kmap_local_page() in
gem/i915_gem_execbuffer.c
On Mon, Apr 17, 2023 at 12:24:45PM +0100, Tvrtko Ursulin wrote:
On 14/04/2023 11:45, Zhao Liu wrote:
Hi Tvrtko,
On Wed, Apr 12, 2023 at 04:45:13PM +0100, Tvrtko Ursulin wrote:
[snip]
[snip]
However I am unsure if disabling pagefaulting is needed or not. Thomas,
Matt, being the last to touch this area, perhaps you could have a look?
Because I notice we have a fallback iomap path which still uses
io_mapping_map_atomic_wc. So if kmap_atomic to kmap_local conversion is
safe, does the iomap side also needs converting to
io_mapping_map_local_wc? Or they have separate requirements?
AFAIK, the requirements for io_mapping_map_local_wc() are the same as for
kmap_local_page(): the kernel virtual address is _only_ valid in the caller
context, and map/unmap nesting must be done in stack-based ordering (LIFO).
I think a follow up patch could safely switch to io_mapping_map_local_wc() /
io_mapping_unmap_local_wc since the address is local to context.
However, not being an expert, reading your note now I suspect that I'm missing
something. Can I ask why you think that page-faults disabling might be
necessary?
I am not saying it is, was just unsure and wanted some people who worked on
this code most recently to take a look and confirm.
I guess it will work since the copying is done like this anyway:
/*
* This is the fast path and we cannot handle a pagefault
* whilst holding the struct mutex lest the user pass in the
* relocations contained within a mmaped bo. For in such a case
* we, the page fault handler would call i915_gem_fault() and
* we would try to acquire the struct mutex again. Obviously
* this is bad and so lockdep complains vehemently.
*/
pagefault_disable();
copied = __copy_from_user_inatomic(r, urelocs, count *
sizeof(r[0]));
pagefault_enable();
if (unlikely(copied)) {
remain = -EFAULT;
goto out;
}
Comment is a bit outdated since we don't use that global "struct mutex" any
longer, but in any case, if there is a page fault on the mapping where we need to recurse
into i915 again to satisfy if, we seem to have code already to handle it. So kmap_local
conversion I *think* can't regress anything.
Thanks for your explanation!
Patch to convert the io_mapping_map_atomic_wc can indeed come later.
Okay, I will also look at this.
In terms of logistics - if we landed this series to out branch it would be
queued only for 6.5. Would that work for you?
Yeah, it's ok for me. But could I ask, did I miss the 6.4 merge time?
Yes, but just because we failed to review and merge in time, not because you
did not provide patches in time.
It is worth mentioning that under drm we close the merge window earlier.
Around -rc5.
So, Linus' merge window for 6.4 didn't happen yet. But our drm-next that
is going to be sent there is already closed.
Regards,
Tvrtko
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/mtl: Don't set PIPE_CONTROL_FLUSH_L3 (rev5)
On 18/10/2023 17:43, Andi Shyti wrote: Hi Vinay, Possible regressions • igt@gem_exec_nop@basic-series: □ shard-glk: PASS -> INCOMPLETE +1 other test incomplete • igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-0-hflip-async-flip: □ shard-dg2: PASS -> TIMEOUT • igt@kms_cursor_crc@cursor-onscreen-64x21@pipe-d-hdmi-a-1: □ shard-tglu: PASS -> INCOMPLETE • igt@kms_psr@psr2_suspend: □ shard-mtlp: NOTRUN -> FAIL these failures look unrelated and besides they are not related to MTL. There is something new on the shards which _seems_ to be implicating this patch. This previously all green test started failing in a bad way: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13775/shard-mtlp-6/igt@sysfs_preempt_timeout@time...@vecs0.html <5> [97.816201] Fence expiration time out i915-:00:02.0:sysfs_preempt_t[1166]:2! <3> [187.682308] INFO: task kworker/0:3:165 blocked for more than 61 seconds. <3> [187.689294] Tainted: GW 6.6.0-rc6-CI_DRM_13775-ge69e078f7bef+ #1 <3> [187.697375] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. <6> [187.705354] task:kworker/0:3 state:D stack:13504 pid:165 ppid:2 flags:0x4000 <6> [187.705375] Workqueue: i915-unordered intel_gt_watchdog_work [i915] <6> [187.705671] Call Trace: <6> [187.705675] <6> [187.705683] __schedule+0x3a0/0xd70 <6> [187.705704] schedule+0x5c/0xd0 <6> [187.705713] guc_context_cancel_request+0x45e/0x9f0 [i915] <6> [187.706078] ? __pfx_autoremove_wake_function+0x10/0x10 <6> [187.706091] ? intel_gt_watchdog_work+0x20/0x260 [i915] <6> [187.706377] intel_gt_watchdog_work+0xd1/0x260 [i915] <6> [187.706624] ? process_scheduled_works+0x264/0x530 <6> [187.706635] process_scheduled_works+0x2db/0x530 <6> [187.706650] ? __pfx_worker_thread+0x10/0x10 <6> [187.706656] worker_thread+0x18c/0x350 <6> [187.706664] ? __pfx_worker_thread+0x10/0x10 <6> [187.706670] kthread+0xfe/0x130 <6> [187.706678] ? __pfx_kthread+0x10/0x10 <6> [187.706687] ret_from_fork+0x2c/0x50 <6> [187.706696] ? __pfx_kthread+0x10/0x10 <6> [187.706704] ret_from_fork_asm+0x1b/0x30 <6> [187.706724] I am not claiming it is at fault but the transition from green to timing out looks clear. Regards, Tvrtko
