Re: [Intel-gfx] [PATCH v4 2/9] vfio-iommufd: Create iommufd_access for noiommu devices
> From: Liu, Yi L
> Sent: Friday, April 28, 2023 2:21 PM
>
> On 2023/4/28 02:32, Alex Williamson wrote:
> > On Thu, 27 Apr 2023 06:59:17 +
> > "Liu, Yi L" wrote:
> >
> >>> From: Tian, Kevin
> >>> Sent: Thursday, April 27, 2023 2:39 PM
> >>>
> From: Liu, Yi L
> Sent: Wednesday, April 26, 2023 10:54 PM
> @@ -121,7 +128,8 @@ static void vfio_emulated_unmap(void *data,
> unsigned long iova,
> {
> struct vfio_device *vdev = data;
>
> -if (vdev->ops->dma_unmap)
> +/* noiommu devices cannot do map/unmap */
> +if (vdev->noiommu && vdev->ops->dma_unmap)
> vdev->ops->dma_unmap(vdev, iova, length);
> >>>
> >>> Is it necessary? All mdev devices implementing @dma_unmap won't
> >>> set noiommu flag.
> >>
> >> Hmmm. Yes, and all the devices set noiommu is not implementing
> @dma_unmap
> >> as far as I see. Maybe this noiommu check can be removed.
> >
> > Not to mention that the polarity of the noiommu test is backwards here!
> > This also seems to be the only performance path where noiommu is tested
> > and therefore I believe the only actual justification of the previous
> > patch.
>
> but this patch needs to use vfio_iommufd_emulated_bind() and
> vfio_iommufd_emulated_unbind() for the noiommu devices when binding
> to iommufd. So needs to check noiommu in the vfio_iommufd_bind()
> and vfio_iommu_unbind() as well.
>
You can continue to use vfio_device_is_noiommu() in this patch. It's not
big deal to drop it from this series and then add back in cdev series.
Re: [Intel-gfx] [PATCH v4 2/9] vfio-iommufd: Create iommufd_access for noiommu devices
On 2023/4/28 15:00, Tian, Kevin wrote:
From: Liu, Yi L
Sent: Friday, April 28, 2023 2:21 PM
On 2023/4/28 02:32, Alex Williamson wrote:
On Thu, 27 Apr 2023 06:59:17 +
"Liu, Yi L" wrote:
From: Tian, Kevin
Sent: Thursday, April 27, 2023 2:39 PM
From: Liu, Yi L
Sent: Wednesday, April 26, 2023 10:54 PM
@@ -121,7 +128,8 @@ static void vfio_emulated_unmap(void *data,
unsigned long iova,
{
struct vfio_device *vdev = data;
- if (vdev->ops->dma_unmap)
+ /* noiommu devices cannot do map/unmap */
+ if (vdev->noiommu && vdev->ops->dma_unmap)
vdev->ops->dma_unmap(vdev, iova, length);
Is it necessary? All mdev devices implementing @dma_unmap won't
set noiommu flag.
Hmmm. Yes, and all the devices set noiommu is not implementing
@dma_unmap
as far as I see. Maybe this noiommu check can be removed.
Not to mention that the polarity of the noiommu test is backwards here!
This also seems to be the only performance path where noiommu is tested
and therefore I believe the only actual justification of the previous
patch.
but this patch needs to use vfio_iommufd_emulated_bind() and
vfio_iommufd_emulated_unbind() for the noiommu devices when binding
to iommufd. So needs to check noiommu in the vfio_iommufd_bind()
and vfio_iommu_unbind() as well.
You can continue to use vfio_device_is_noiommu() in this patch. It's not
big deal to drop it from this series and then add back in cdev series.
yes.:-) patch 01 of this series was added more per the cdev series reviews.
--
Regards,
Yi Liu
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: use pat_index instead of cache_level
== Series Details ==
Series: drm/i915: use pat_index instead of cache_level
URL : https://patchwork.freedesktop.org/series/117082/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_13071_full -> Patchwork_117082v1_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_117082v1_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_117082v1_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (7 -> 7)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_117082v1_full:
### IGT changes ###
Possible regressions
* igt@i915_pm_rps@reset:
- shard-snb: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-snb6/igt@i915_pm_...@reset.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117082v1/shard-snb4/igt@i915_pm_...@reset.html
Known issues
Here are the changes found in Patchwork_117082v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_barrier_race@remote-request@rcs0:
- shard-apl: [PASS][3] -> [ABORT][4] ([i915#7461] / [i915#8234])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-apl2/igt@gem_barrier_race@remote-requ...@rcs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117082v1/shard-apl1/igt@gem_barrier_race@remote-requ...@rcs0.html
* igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-apl: [PASS][5] -> [FAIL][6] ([i915#2842]) +1 similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-apl4/igt@gem_exec_fair@basic-none-s...@rcs0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117082v1/shard-apl3/igt@gem_exec_fair@basic-none-s...@rcs0.html
* igt@gem_huc_copy@huc-copy:
- shard-apl: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#2190])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117082v1/shard-apl2/igt@gem_huc_c...@huc-copy.html
* igt@kms_big_fb@4-tiled-max-hw-stride-32bpp-rotate-180-hflip-async-flip:
- shard-apl: NOTRUN -> [SKIP][8] ([fdo#109271]) +25 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117082v1/shard-apl2/igt@kms_big...@4-tiled-max-hw-stride-32bpp-rotate-180-hflip-async-flip.html
* igt@kms_cdclk@mode-transition:
- shard-glk: NOTRUN -> [SKIP][9] ([fdo#109271]) +6 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117082v1/shard-glk8/igt@kms_cd...@mode-transition.html
* igt@kms_content_protection@atomic@pipe-a-dp-1:
- shard-apl: NOTRUN -> [TIMEOUT][10] ([i915#7173])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117082v1/shard-apl2/igt@kms_content_protection@ato...@pipe-a-dp-1.html
* igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@bc-hdmi-a1-hdmi-a2:
- shard-glk: [PASS][11] -> [FAIL][12] ([i915#79])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-glk3/igt@kms_flip@2x-flip-vs-expired-vblank-interrupti...@bc-hdmi-a1-hdmi-a2.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117082v1/shard-glk1/igt@kms_flip@2x-flip-vs-expired-vblank-interrupti...@bc-hdmi-a1-hdmi-a2.html
*
igt@kms_plane_scaling@planes-downscale-factor-0-25-upscale-0-25@pipe-a-hdmi-a-1:
- shard-snb: NOTRUN -> [SKIP][13] ([fdo#109271]) +22 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117082v1/shard-snb1/igt@kms_plane_scaling@planes-downscale-factor-0-25-upscale-0...@pipe-a-hdmi-a-1.html
* igt@kms_psr2_sf@overlay-plane-move-continuous-sf:
- shard-glk: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#658])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117082v1/shard-glk8/igt@kms_psr2...@overlay-plane-move-continuous-sf.html
Possible fixes
* igt@drm_fdinfo@most-busy-check-all@rcs0:
- {shard-rkl}:[FAIL][15] ([i915#7742]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-rkl-3/igt@drm_fdinfo@most-busy-check-...@rcs0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117082v1/shard-rkl-4/igt@drm_fdinfo@most-busy-check-...@rcs0.html
* igt@gem_barrier_race@remote-request@rcs0:
- {shard-dg1}:[ABORT][17] ([i915#7461] / [i915#8234]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-dg1-16/igt@gem_barrier_race@remote-requ...@rcs0.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117082v1/shard-dg1-18/igt@gem_barrier_race@remote-requ...@rcs0.html
* igt@gem_ctx_exec@basic-noh
[Intel-gfx] [PULL] gvt-next-fixes
Hi, Here's one single change for gvt to use idr based dmabuf object reference instead of old adhoc code. We've verified no regression for internal test. Thanks. -- The following changes since commit d944eafed618a8507270b324ad9d5405bb7f0b3e: drm/i915: Check pipe source size when using skl+ scalers (2023-04-24 14:48:42 +0300) are available in the Git repository at: https://github.com/intel/gvt-linux.git tags/gvt-next-fixes-2023-04-28 for you to fetch changes up to 004040fdb55fa55463730c95d1384cb67f9396c3: drm/i915/gvt: Make use of idr_find and idr_for_each_entry in dmabuf (2023-04-28 15:21:17 +0800) gvt-next-fixes-2023-04-28 - Use idr based dmabuf object reference (Cai Huoqing) Cai Huoqing (1): drm/i915/gvt: Make use of idr_find and idr_for_each_entry in dmabuf drivers/gpu/drm/i915/gvt/dmabuf.c | 58 --- drivers/gpu/drm/i915/gvt/dmabuf.h | 1 - drivers/gpu/drm/i915/gvt/gvt.h| 1 - drivers/gpu/drm/i915/gvt/vgpu.c | 1 - 4 files changed, 12 insertions(+), 49 deletions(-) signature.asc Description: PGP signature
[Intel-gfx] [RFC v2 0/4] Expose RPS thresholds in sysfs
From: Tvrtko Ursulin >From patch 4: User feedback indicates significant performance gains are possible in specific games with non default RPS up/down thresholds. Expose these tunables via sysfs which will allow users to achieve best performance when running games and best power efficiency elsewhere. Note this patch supports non GuC based platforms only. References: https://gitlab.freedesktop.org/drm/intel/-/issues/8389 Issue 8389 suggests 10-15% performance gains are possible with tweaked thresholds. One question is are we able to find a "one size fits all" values. However regardless of that, given we already expose frequency controls in sysfs with the same reasoning of allowing system owners explicit control if so wanted, I think exposing the thresholds can be equally justified. v2: * Hopefully fixed the debug build issue. * Re-program the hw registers on change too! Tvrtko Ursulin (4): drm/i915: Move setting of rps thresholds to init drm/i915: Record default rps threshold values drm/i915: Add helpers for managing rps thresholds drm/i915: Expose RPS thresholds in sysfs drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 104 drivers/gpu/drm/i915/gt/intel_gt_types.h| 3 + drivers/gpu/drm/i915/gt/intel_rps.c | 70 ++--- drivers/gpu/drm/i915/gt/intel_rps.h | 4 + 4 files changed, 170 insertions(+), 11 deletions(-) -- 2.37.2
[Intel-gfx] [RFC 1/4] drm/i915: Move setting of rps thresholds to init
From: Tvrtko Ursulin
Since 36d516be867c ("drm/i915/gt: Switch to manual evaluation of RPS")
thresholds are invariant so lets move their setting to init time.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_rps.c | 27 ---
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c
b/drivers/gpu/drm/i915/gt/intel_rps.c
index 80968e49e2c3..d78699e2b13b 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -670,7 +670,6 @@ static void rps_set_power(struct intel_rps *rps, int
new_power)
{
struct intel_gt *gt = rps_to_gt(rps);
struct intel_uncore *uncore = gt->uncore;
- u32 threshold_up = 0, threshold_down = 0; /* in % */
u32 ei_up = 0, ei_down = 0;
lockdep_assert_held(&rps->power.mutex);
@@ -678,9 +677,6 @@ static void rps_set_power(struct intel_rps *rps, int
new_power)
if (new_power == rps->power.mode)
return;
- threshold_up = 95;
- threshold_down = 85;
-
/* Note the units here are not exactly 1us, but 1280ns. */
switch (new_power) {
case LOW_POWER:
@@ -707,17 +703,22 @@ static void rps_set_power(struct intel_rps *rps, int
new_power)
GT_TRACE(gt,
"changing power mode [%d], up %d%% @ %dus, down %d%% @ %dus\n",
-new_power, threshold_up, ei_up, threshold_down, ei_down);
+new_power,
+rps->power.up_threshold, ei_up,
+rps->power.down_threshold, ei_down);
set(uncore, GEN6_RP_UP_EI,
intel_gt_ns_to_pm_interval(gt, ei_up * 1000));
set(uncore, GEN6_RP_UP_THRESHOLD,
- intel_gt_ns_to_pm_interval(gt, ei_up * threshold_up * 10));
+ intel_gt_ns_to_pm_interval(gt,
+ ei_up * rps->power.up_threshold * 10));
set(uncore, GEN6_RP_DOWN_EI,
intel_gt_ns_to_pm_interval(gt, ei_down * 1000));
set(uncore, GEN6_RP_DOWN_THRESHOLD,
- intel_gt_ns_to_pm_interval(gt, ei_down * threshold_down * 10));
+ intel_gt_ns_to_pm_interval(gt,
+ ei_down *
+ rps->power.down_threshold * 10));
set(uncore, GEN6_RP_CONTROL,
(GRAPHICS_VER(gt->i915) > 9 ? 0 : GEN6_RP_MEDIA_TURBO) |
@@ -729,8 +730,6 @@ static void rps_set_power(struct intel_rps *rps, int
new_power)
skip_hw_write:
rps->power.mode = new_power;
- rps->power.up_threshold = threshold_up;
- rps->power.down_threshold = threshold_down;
}
static void gen6_rps_set_thresholds(struct intel_rps *rps, u8 val)
@@ -1556,10 +1555,12 @@ void intel_rps_enable(struct intel_rps *rps)
return;
GT_TRACE(rps_to_gt(rps),
-"min:%x, max:%x, freq:[%d, %d]\n",
+"min:%x, max:%x, freq:[%d, %d], thresholds:[%u, %u]\n",
rps->min_freq, rps->max_freq,
intel_gpu_freq(rps, rps->min_freq),
-intel_gpu_freq(rps, rps->max_freq));
+intel_gpu_freq(rps, rps->max_freq),
+rps->power.up_threshold,
+rps->power.down_threshold);
GEM_BUG_ON(rps->max_freq < rps->min_freq);
GEM_BUG_ON(rps->idle_freq > rps->max_freq);
@@ -2012,6 +2013,10 @@ void intel_rps_init(struct intel_rps *rps)
}
}
+ /* Set default thresholds in % */
+ rps->power.up_threshold = 95;
+ rps->power.down_threshold = 85;
+
/* Finally allow us to boost to max by default */
rps->boost_freq = rps->max_freq;
rps->idle_freq = rps->min_freq;
--
2.37.2
[Intel-gfx] [RFC 2/4] drm/i915: Record default rps threshold values
From: Tvrtko Ursulin
Record the default values as preparation for exposing the sysfs controls.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 +++
drivers/gpu/drm/i915/gt/intel_rps.c | 2 ++
2 files changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index f08c2556aa25..1b22d7a50665 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -83,6 +83,9 @@ enum intel_submission_method {
struct gt_defaults {
u32 min_freq;
u32 max_freq;
+
+ u8 rps_up_threshold;
+ u8 rps_down_threshold;
};
enum intel_gt_type {
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c
b/drivers/gpu/drm/i915/gt/intel_rps.c
index d78699e2b13b..a39eee444849 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -2015,7 +2015,9 @@ void intel_rps_init(struct intel_rps *rps)
/* Set default thresholds in % */
rps->power.up_threshold = 95;
+ rps_to_gt(rps)->defaults.rps_up_threshold = rps->power.up_threshold;
rps->power.down_threshold = 85;
+ rps_to_gt(rps)->defaults.rps_down_threshold = rps->power.down_threshold;
/* Finally allow us to boost to max by default */
rps->boost_freq = rps->max_freq;
--
2.37.2
[Intel-gfx] [RFC 3/4] drm/i915: Add helpers for managing rps thresholds
From: Tvrtko Ursulin
In preparation for exposing via sysfs add helpers for managing rps
thresholds.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_rps.c | 36 +
drivers/gpu/drm/i915/gt/intel_rps.h | 4
2 files changed, 40 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c
b/drivers/gpu/drm/i915/gt/intel_rps.c
index a39eee444849..a5a7315f5ace 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -2573,6 +2573,42 @@ int intel_rps_set_min_frequency(struct intel_rps *rps,
u32 val)
return set_min_freq(rps, val);
}
+u8 intel_rps_get_up_threshold(struct intel_rps *rps)
+{
+ return rps->power.up_threshold;
+}
+
+static int rps_set_threshold(struct intel_rps *rps, u8 *threshold, u8 val)
+{
+ int ret;
+
+ if (val > 100)
+ return -EINVAL;
+
+ ret = mutex_lock_interruptible(&rps->lock);
+ if (ret)
+ return ret;
+ *threshold = val;
+ mutex_unlock(&rps->lock);
+
+ return 0;
+}
+
+int intel_rps_set_up_threshold(struct intel_rps *rps, u8 threshold)
+{
+ return rps_set_threshold(rps, &rps->power.up_threshold, threshold);
+}
+
+u8 intel_rps_get_down_threshold(struct intel_rps *rps)
+{
+ return rps->power.down_threshold;
+}
+
+int intel_rps_set_down_threshold(struct intel_rps *rps, u8 threshold)
+{
+ return rps_set_threshold(rps, &rps->power.down_threshold, threshold);
+}
+
static void intel_rps_set_manual(struct intel_rps *rps, bool enable)
{
struct intel_uncore *uncore = rps_to_uncore(rps);
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.h
b/drivers/gpu/drm/i915/gt/intel_rps.h
index a3fa987aa91f..92fb01f5a452 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.h
+++ b/drivers/gpu/drm/i915/gt/intel_rps.h
@@ -37,6 +37,10 @@ void intel_rps_mark_interactive(struct intel_rps *rps, bool
interactive);
int intel_gpu_freq(struct intel_rps *rps, int val);
int intel_freq_opcode(struct intel_rps *rps, int val);
+u8 intel_rps_get_up_threshold(struct intel_rps *rps);
+int intel_rps_set_up_threshold(struct intel_rps *rps, u8 threshold);
+u8 intel_rps_get_down_threshold(struct intel_rps *rps);
+int intel_rps_set_down_threshold(struct intel_rps *rps, u8 threshold);
u32 intel_rps_read_actual_frequency(struct intel_rps *rps);
u32 intel_rps_read_actual_frequency_fw(struct intel_rps *rps);
u32 intel_rps_get_requested_frequency(struct intel_rps *rps);
--
2.37.2
[Intel-gfx] [RFC 4/4] drm/i915: Expose RPS thresholds in sysfs
From: Tvrtko Ursulin
User feedback indicates significant performance gains are possible in
specific games with non default RPS up/down thresholds.
Expose these tunables via sysfs which will allow users to achieve best
performance when running games and best power efficiency elsewhere.
Note this patch supports non GuC based platforms only.
Signed-off-by: Tvrtko Ursulin
References: https://gitlab.freedesktop.org/drm/intel/-/issues/8389
---
drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 104
drivers/gpu/drm/i915/gt/intel_rps.c | 7 +-
2 files changed, 110 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
index 28f27091cd3b..df1f9ef08475 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
@@ -671,6 +671,76 @@ static const struct attribute *media_perf_power_attrs[] = {
NULL
};
+static ssize_t
+rps_up_threshold_pct_show(struct kobject *kobj, struct kobj_attribute *attr,
+ char *buf)
+{
+ struct intel_gt *gt = intel_gt_sysfs_get_drvdata(kobj, attr->attr.name);
+ struct intel_rps *rps = >->rps;
+
+ return sysfs_emit(buf, "%u\n", intel_rps_get_up_threshold(rps));
+}
+
+static ssize_t
+rps_up_threshold_pct_store(struct kobject *kobj, struct kobj_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct intel_gt *gt = intel_gt_sysfs_get_drvdata(kobj, attr->attr.name);
+ struct intel_rps *rps = >->rps;
+ int ret;
+ u8 val;
+
+ ret = kstrtou8(buf, 10, &val);
+ if (ret)
+ return ret;
+
+ ret = intel_rps_set_up_threshold(rps, val);
+
+ return ret == 0 ? count : ret;
+}
+
+static struct kobj_attribute rps_up_threshold_pct =
+__ATTR(rps_up_threshold_pct, 0664,
+ rps_up_threshold_pct_show, rps_up_threshold_pct_store);
+
+static ssize_t
+rps_down_threshold_pct_show(struct kobject *kobj, struct kobj_attribute *attr,
+ char *buf)
+{
+ struct intel_gt *gt = intel_gt_sysfs_get_drvdata(kobj, attr->attr.name);
+ struct intel_rps *rps = >->rps;
+
+ return sysfs_emit(buf, "%u\n", intel_rps_get_down_threshold(rps));
+}
+
+static ssize_t
+rps_down_threshold_pct_store(struct kobject *kobj, struct kobj_attribute *attr,
+const char *buf, size_t count)
+{
+ struct intel_gt *gt = intel_gt_sysfs_get_drvdata(kobj, attr->attr.name);
+ struct intel_rps *rps = >->rps;
+ int ret;
+ u8 val;
+
+ ret = kstrtou8(buf, 10, &val);
+ if (ret)
+ return ret;
+
+ ret = intel_rps_set_down_threshold(rps, val);
+
+ return ret == 0 ? count : ret;
+}
+
+static struct kobj_attribute rps_down_threshold_pct =
+__ATTR(rps_down_threshold_pct, 0664,
+ rps_down_threshold_pct_show, rps_down_threshold_pct_store);
+
+static const struct attribute * const gen6_gt_rps_attrs[] = {
+ &rps_up_threshold_pct.attr,
+ &rps_down_threshold_pct.attr,
+ NULL
+};
+
static ssize_t
default_min_freq_mhz_show(struct kobject *kobj, struct kobj_attribute *attr,
char *buf)
{
@@ -693,9 +763,37 @@ default_max_freq_mhz_show(struct kobject *kobj, struct
kobj_attribute *attr, cha
static struct kobj_attribute default_max_freq_mhz =
__ATTR(rps_max_freq_mhz, 0444, default_max_freq_mhz_show, NULL);
+static ssize_t
+default_rps_up_threshold_pct_show(struct kobject *kobj,
+ struct kobj_attribute *attr,
+ char *buf)
+{
+ struct intel_gt *gt = kobj_to_gt(kobj->parent);
+
+ return sysfs_emit(buf, "%u\n", gt->defaults.rps_up_threshold);
+}
+
+static struct kobj_attribute default_rps_up_threshold_pct =
+__ATTR(rps_up_threshold_pct, 0444, default_rps_up_threshold_pct_show, NULL);
+
+static ssize_t
+default_rps_down_threshold_pct_show(struct kobject *kobj,
+ struct kobj_attribute *attr,
+ char *buf)
+{
+ struct intel_gt *gt = kobj_to_gt(kobj->parent);
+
+ return sysfs_emit(buf, "%u\n", gt->defaults.rps_down_threshold);
+}
+
+static struct kobj_attribute default_rps_down_threshold_pct =
+__ATTR(rps_down_threshold_pct, 0444, default_rps_down_threshold_pct_show,
NULL);
+
static const struct attribute * const rps_defaults_attrs[] = {
&default_min_freq_mhz.attr,
&default_max_freq_mhz.attr,
+ &default_rps_up_threshold_pct.attr,
+ &default_rps_down_threshold_pct.attr,
NULL
};
@@ -723,6 +821,12 @@ static int intel_sysfs_rps_init(struct intel_gt *gt,
struct kobject *kobj)
if (IS_VALLEYVIEW(gt->i915) || IS_CHERRYVIEW(gt->i915))
ret = sysfs_create_file(kobj, vlv_attr);
+ if (is_object_gt(kobj) && !intel_uc_uses_guc_slpc(>->uc)) {
+ ret = sysfs_create_files(kobj, gen6_gt_rps_attrs);
+
Re: [Intel-gfx] [PATCH v3 0/5] drm/i915: Allow user to set cache at BO creation
On 4/28/23 07:47, fei.y...@intel.com wrote: From: Fei Yang The first three patches in this series are taken from https://patchwork.freedesktop.org/series/116868/ These patches are included here because the last patch has dependency on the pat_index refactor. This series is focusing on uAPI changes, 1. end support for set caching ioctl [PATCH 4/5] 2. add set_pat extension for gem_create [PATCH 5/5] v2: drop one patch that was merged separately 341ad0e8e254 drm/i915/mtl: Add PTE encode function v3: rebase on https://patchwork.freedesktop.org/series/117082/ Hi, Fei. Does this uAPI update also affect any discrete GPUs supported by i915, And in that case, does it allow setting non-snooping PAT indices on those devices? If so, since the uAPI for discrete GPU devices doesn't allow incoherency between GPU and CPU (apart from write-combining buffering), the correct CPU caching mode matching the PAT index needs to be selected for the buffer object in i915_ttm_select_tt_caching(). Thanks, Thomas Fei Yang (5): drm/i915: preparation for using PAT index drm/i915: use pat_index instead of cache_level drm/i915: make sure correct pte encode is used drm/i915/mtl: end support for set caching ioctl drm/i915: Allow user to set cache at BO creation drivers/gpu/drm/i915/display/intel_dpt.c | 12 +-- drivers/gpu/drm/i915/gem/i915_gem_create.c| 36 + drivers/gpu/drm/i915/gem/i915_gem_domain.c| 46 ++- .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 10 ++- drivers/gpu/drm/i915/gem/i915_gem_mman.c | 3 +- drivers/gpu/drm/i915/gem/i915_gem_object.c| 67 +++- drivers/gpu/drm/i915/gem/i915_gem_object.h| 8 ++ .../gpu/drm/i915/gem/i915_gem_object_types.h | 26 +- drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 9 ++- drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 2 - drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 4 +- drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 16 ++-- .../gpu/drm/i915/gem/selftests/huge_pages.c | 2 +- .../drm/i915/gem/selftests/i915_gem_migrate.c | 2 +- .../drm/i915/gem/selftests/i915_gem_mman.c| 2 +- drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 10 ++- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 73 + drivers/gpu/drm/i915/gt/gen8_ppgtt.h | 3 +- drivers/gpu/drm/i915/gt/intel_ggtt.c | 76 +- drivers/gpu/drm/i915/gt/intel_gtt.h | 20 +++-- drivers/gpu/drm/i915/gt/intel_migrate.c | 47 ++- drivers/gpu/drm/i915/gt/intel_migrate.h | 13 ++- drivers/gpu/drm/i915/gt/intel_ppgtt.c | 6 +- drivers/gpu/drm/i915/gt/selftest_migrate.c| 47 +-- drivers/gpu/drm/i915/gt/selftest_reset.c | 8 +- drivers/gpu/drm/i915/gt/selftest_timeline.c | 2 +- drivers/gpu/drm/i915/gt/selftest_tlb.c| 4 +- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 10 ++- drivers/gpu/drm/i915/i915_debugfs.c | 55 ++--- drivers/gpu/drm/i915/i915_gem.c | 16 +++- drivers/gpu/drm/i915/i915_gpu_error.c | 8 +- drivers/gpu/drm/i915/i915_pci.c | 79 --- drivers/gpu/drm/i915/i915_vma.c | 16 ++-- drivers/gpu/drm/i915/i915_vma.h | 2 +- drivers/gpu/drm/i915/i915_vma_types.h | 2 - drivers/gpu/drm/i915/intel_device_info.h | 5 ++ drivers/gpu/drm/i915/selftests/i915_gem.c | 5 +- .../gpu/drm/i915/selftests/i915_gem_evict.c | 4 +- drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 15 ++-- .../drm/i915/selftests/intel_memory_region.c | 4 +- .../gpu/drm/i915/selftests/mock_gem_device.c | 9 +++ drivers/gpu/drm/i915/selftests/mock_gtt.c | 8 +- include/uapi/drm/i915_drm.h | 36 + tools/include/uapi/drm/i915_drm.h | 36 + 44 files changed, 621 insertions(+), 243 deletions(-)
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Expose RPS thresholds in sysfs (rev2)
== Series Details ==
Series: Expose RPS thresholds in sysfs (rev2)
URL : https://patchwork.freedesktop.org/series/117054/
State : warning
== Summary ==
Error: dim checkpatch failed
561c9fe0d33c drm/i915: Move setting of rps thresholds to init
-:6: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 36d516be867c ("drm/i915/gt:
Switch to manual evaluation of RPS")'
#6:
Since 36d516be867c ("drm/i915/gt: Switch to manual evaluation of RPS")
total: 1 errors, 0 warnings, 0 checks, 73 lines checked
da670c452e89 drm/i915: Record default rps threshold values
3d681b908892 drm/i915: Add helpers for managing rps thresholds
19cabe9996b2 drm/i915: Expose RPS thresholds in sysfs
-:55: WARNING:LEADING_SPACE: please, no spaces at the start of a line
#55: FILE: drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c:704:
+ rps_up_threshold_pct_show, rps_up_threshold_pct_store);$
-:87: WARNING:LEADING_SPACE: please, no spaces at the start of a line
#87: FILE: drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c:736:
+ rps_down_threshold_pct_show, rps_down_threshold_pct_store);$
total: 0 errors, 2 warnings, 0 checks, 138 lines checked
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Expose RPS thresholds in sysfs (rev2)
== Series Details == Series: Expose RPS thresholds in sysfs (rev2) URL : https://patchwork.freedesktop.org/series/117054/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [RFC 4/4] drm/i915: Expose RPS thresholds in sysfs
On 28/04/2023 09:14, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
User feedback indicates significant performance gains are possible in
specific games with non default RPS up/down thresholds.
Expose these tunables via sysfs which will allow users to achieve best
performance when running games and best power efficiency elsewhere.
Note this patch supports non GuC based platforms only.
Signed-off-by: Tvrtko Ursulin
References: https://gitlab.freedesktop.org/drm/intel/-/issues/8389
[snip]
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c
b/drivers/gpu/drm/i915/gt/intel_rps.c
index a5a7315f5ace..f790e81546ff 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -2588,7 +2588,12 @@ static int rps_set_threshold(struct intel_rps *rps, u8
*threshold, u8 val)
ret = mutex_lock_interruptible(&rps->lock);
if (ret)
return ret;
- *threshold = val;
+ if (*threshold != val) {
+ *threshold = val;
+ intel_rps_set(rps, clamp(rps->cur_freq,
+rps->min_freq_softlimit,
+rps->max_freq_softlimit));
+ }
mutex_unlock(&rps->lock);
return 0;
This hunk belongs to a previous patch - moved locally.
Regards,
Tvrtko
Re: [Intel-gfx] [PATCH v8 1/2] drm/i915: Migrate platform-dependent mock hugepage selftests to live
Hi Andrzej, On Wed, Apr 26, 2023 at 11:28:48PM +0200, Andrzej Hajda wrote: > From: Jonathan Cavitt > > Convert the igt_mock_ppgtt_huge_fill and igt_mock_ppgtt_64K mock selftests > into live selftests as their requirements have recently become > platform-dependent. Additionally, apply necessary platform dependency > checks to these tests. > > v8: > - handle properly 64K and 2M pages > v9: > - do not expect 64K pages if 2M are present > - fix hex printing > - obey commit message line limit > > Signed-off-by: Jonathan Cavitt > Co-developed-by: Andrzej Hajda > Signed-off-by: Andrzej Hajda Reviewed-by: Andi Shyti Andi
[Intel-gfx] ✗ Fi.CI.BAT: failure for Expose RPS thresholds in sysfs (rev2)
== Series Details == Series: Expose RPS thresholds in sysfs (rev2) URL : https://patchwork.freedesktop.org/series/117054/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13071 -> Patchwork_117054v2 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_117054v2 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_117054v2, 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_117054v2/index.html Participating hosts (38 -> 37) -- Additional (1): fi-kbl-soraka Missing(2): bat-mtlp-8 fi-snb-2520m Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_117054v2: ### IGT changes ### Possible regressions * igt@gem_lmem_swapping@verify-random: - fi-kbl-soraka: NOTRUN -> [INCOMPLETE][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117054v2/fi-kbl-soraka/igt@gem_lmem_swapp...@verify-random.html Known issues Here are the changes found in Patchwork_117054v2 that come from known issues: ### IGT changes ### Issues hit * igt@gem_huc_copy@huc-copy: - fi-kbl-soraka: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#2190]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117054v2/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - fi-kbl-soraka: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#4613]) +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117054v2/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: NOTRUN -> [FAIL][4] ([i915#7913] / [i915#8383]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117054v2/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@kms_chamelium_frames@hdmi-crc-fast: - fi-kbl-soraka: NOTRUN -> [SKIP][5] ([fdo#109271]) +16 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117054v2/fi-kbl-soraka/igt@kms_chamelium_fra...@hdmi-crc-fast.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - bat-rpls-1: NOTRUN -> [SKIP][6] ([i915#7828]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117054v2/bat-rpls-1/igt@kms_chamelium_...@common-hpd-after-suspend.html * igt@kms_pipe_crc_basic@nonblocking-crc@pipe-d-dp-1: - bat-dg2-8: [PASS][7] -> [FAIL][8] ([i915#7932]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117054v2/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html * igt@kms_pipe_crc_basic@suspend-read-crc: - bat-rpls-1: NOTRUN -> [SKIP][9] ([i915#1845]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117054v2/bat-rpls-1/igt@kms_pipe_crc_ba...@suspend-read-crc.html Possible fixes * igt@gem_exec_suspend@basic-s3@smem: - bat-rpls-1: [ABORT][10] ([i915#6687]) -> [PASS][11] [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117054v2/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html * igt@i915_selftest@live@gt_heartbeat: - fi-glk-j4005: [FAIL][12] ([i915#7916]) -> [PASS][13] [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117054v2/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html Warnings * igt@core_hotunplug@unbind-rebind: - fi-kbl-8809g: [ABORT][14] ([i915#8299]) -> [ABORT][15] ([i915#8299] / [i915#8397]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/fi-kbl-8809g/igt@core_hotunp...@unbind-rebind.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117054v2/fi-kbl-8809g/igt@core_hotunp...@unbind-rebind.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845 [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190 [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613 [i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687 [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828 [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913 [i915#7916]: https://gitlab.freedesktop.org/drm/intel/issues/7916 [i915#7932]: https://gitlab.freedesktop.org/drm/intel/issues/7932 [i915#8299]: https://gitlab.fr
Re: [Intel-gfx] [PATCH v8 7/7] drm/i915: Track gt pm wakerefs
Hi Andrzej, On Tue, Apr 25, 2023 at 12:05:44AM +0200, Andrzej Hajda wrote: > Track every intel_gt_pm_get() until its corresponding release in > intel_gt_pm_put() by returning a cookie to the caller for acquire that > must be passed by on released. When there is an imbalance, we can see who > either tried to free a stale wakeref, or who forgot to free theirs. > > Signed-off-by: Andrzej Hajda Reviewed-by: Andi Shyti Andi
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Allow user to set cache at BO creation (rev3)
== Series Details ==
Series: drm/i915: Allow user to set cache at BO creation (rev3)
URL : https://patchwork.freedesktop.org/series/116870/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13071_full -> Patchwork_116870v3_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (7 -> 7)
--
No changes in participating hosts
Known issues
Here are the changes found in Patchwork_116870v3_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-deadline:
- shard-glk: [PASS][1] -> [FAIL][2] ([i915#2846])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-glk9/igt@gem_exec_f...@basic-deadline.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116870v3/shard-glk7/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-apl: [PASS][3] -> [FAIL][4] ([i915#2842]) +2 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-apl4/igt@gem_exec_fair@basic-none-s...@rcs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116870v3/shard-apl4/igt@gem_exec_fair@basic-none-s...@rcs0.html
* igt@gem_huc_copy@huc-copy:
- shard-apl: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#2190])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116870v3/shard-apl7/igt@gem_huc_c...@huc-copy.html
* igt@kms_big_fb@4-tiled-max-hw-stride-32bpp-rotate-180-hflip-async-flip:
- shard-apl: NOTRUN -> [SKIP][6] ([fdo#109271]) +25 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116870v3/shard-apl7/igt@kms_big...@4-tiled-max-hw-stride-32bpp-rotate-180-hflip-async-flip.html
* igt@kms_cdclk@mode-transition:
- shard-glk: NOTRUN -> [SKIP][7] ([fdo#109271]) +6 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116870v3/shard-glk3/igt@kms_cd...@mode-transition.html
* igt@kms_content_protection@atomic@pipe-a-dp-1:
- shard-apl: NOTRUN -> [TIMEOUT][8] ([i915#7173])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116870v3/shard-apl7/igt@kms_content_protection@ato...@pipe-a-dp-1.html
* igt@kms_plane_scaling@plane-upscale-with-modifiers-factor-0-25@pipe-a-vga-1:
- shard-snb: NOTRUN -> [SKIP][9] ([fdo#109271]) +28 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116870v3/shard-snb4/igt@kms_plane_scaling@plane-upscale-with-modifiers-factor-0...@pipe-a-vga-1.html
* igt@kms_psr2_sf@overlay-plane-move-continuous-sf:
- shard-glk: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#658])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116870v3/shard-glk3/igt@kms_psr2...@overlay-plane-move-continuous-sf.html
Possible fixes
* igt@drm_fdinfo@idle@rcs0:
- {shard-rkl}:[FAIL][11] ([i915#7742]) -> [PASS][12] +1 similar
issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-rkl-7/igt@drm_fdinfo@i...@rcs0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116870v3/shard-rkl-2/igt@drm_fdinfo@i...@rcs0.html
* igt@gem_barrier_race@remote-request@rcs0:
- {shard-dg1}:[ABORT][13] ([i915#7461] / [i915#8234]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-dg1-16/igt@gem_barrier_race@remote-requ...@rcs0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116870v3/shard-dg1-18/igt@gem_barrier_race@remote-requ...@rcs0.html
* igt@gem_ctx_exec@basic-nohangcheck:
- {shard-tglu}: [FAIL][15] ([i915#6268]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-tglu-5/igt@gem_ctx_e...@basic-nohangcheck.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116870v3/shard-tglu-8/igt@gem_ctx_e...@basic-nohangcheck.html
* igt@gem_eio@hibernate:
- shard-apl: [ABORT][17] ([i915#8213]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-apl3/igt@gem_...@hibernate.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116870v3/shard-apl7/igt@gem_...@hibernate.html
* igt@gem_exec_fair@basic-deadline:
- {shard-rkl}:[FAIL][19] ([i915#2846]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-rkl-7/igt@gem_exec_f...@basic-deadline.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116870v3/shard-rkl-7/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-pace@rcs0:
- {shard-rkl}:[FAIL][21] ([i915#2842]) -> [PASS][22] +1 similar
issue
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13071/shard-rkl-7/igt@gem_exec_fair@basic-p...@rcs0.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116870v3/shard-rkl-2/igt@gem_exec_fair@basic-p...@rcs0.html
Re: [Intel-gfx] [PATCH 01/13] drm/i915/mtl: C20 PLL programming
Hi Mika,
> +static void intel_c20_pll_program(struct drm_i915_private *i915,
> + const struct intel_crtc_state *crtc_state,
> + struct intel_encoder *encoder)
> +{
> + const struct intel_c20pll_state *pll_state =
> &crtc_state->cx0pll_state.c20;
> + bool dp = false;
> + int lane = crtc_state->lane_count == 4 ? INTEL_CX0_BOTH_LANES :
> INTEL_CX0_LANE0;
> + bool cntx;
> + int i;
> +
> + if (intel_crtc_has_dp_encoder(crtc_state))
> + dp = true;
> +
> + /* 1. Read current context selection */
> + cntx = intel_cx0_read(i915, encoder->port, INTEL_CX0_LANE0,
> PHY_C20_VDR_CUSTOM_SERDES_RATE) &
> + PHY_C20_CONTEXT_TOGGLE;
> +
> + /* 2. If there is a protocol switch from HDMI to DP or vice versa, clear
> + * the lane #0 MPLLB CAL_DONE_BANK DP2.0 10G and 20G rates enable MPLLA.
> + * Protocol switch is only applicable for MPLLA
> + */
> + if (intel_c20_protocol_switch_valid(encoder)) {
> + for (i = 0; i < 4; i++)
> + intel_c20_sram_write(i915, encoder->port,
> INTEL_CX0_LANE0, RAWLANEAONX_DIG_TX_MPLLB_CAL_DONE_BANK(i), 0);
> + msleep(4);
can you use usleep_range() here?
Andi
Re: [Intel-gfx] [PATCH v8 2/2] drm/i915: Use correct huge page manager for MTL
Hi Andrzej, > MTL currently uses gen8_ppgtt_insert_huge when managing huge pages. > This is because MTL reports as not supporting 64K pages, or more > accurately, the system that reports whether a platform has 64K pages > reports false for MTL. This is only half correct, as the 64K page support > reporting system only cares about 64K page support for LMEM, which MTL > doesn't have. > > MTL should be using xehpsdv_ppgtt_insert_huge. However, simply changing > over to using that manager doesn't resolve the issue because MTL is > expecting the virtual address space for the page table to be flushed after > initialization, so we must also add a flush statement there. > > Signed-off-by: Jonathan Cavitt > Reviewed-by: Matthew Auld > Signed-off-by: Andrzej Hajda Reviewed-by: Andi Shyti Andi
Re: [Intel-gfx] [PATCH 01/13] drm/i915/mtl: C20 PLL programming
> -Original Message-
> From: Andi Shyti
> Sent: Friday, April 28, 2023 12:07 PM
> To: Kahola, Mika
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 01/13] drm/i915/mtl: C20 PLL programming
>
> Hi Mika,
>
> > +static void intel_c20_pll_program(struct drm_i915_private *i915,
> > + const struct intel_crtc_state *crtc_state,
> > + struct intel_encoder *encoder)
> > +{
> > + const struct intel_c20pll_state *pll_state = &crtc_state-
> >cx0pll_state.c20;
> > + bool dp = false;
> > + int lane = crtc_state->lane_count == 4 ? INTEL_CX0_BOTH_LANES :
> INTEL_CX0_LANE0;
> > + bool cntx;
> > + int i;
> > +
> > + if (intel_crtc_has_dp_encoder(crtc_state))
> > + dp = true;
> > +
> > + /* 1. Read current context selection */
> > + cntx = intel_cx0_read(i915, encoder->port, INTEL_CX0_LANE0,
> PHY_C20_VDR_CUSTOM_SERDES_RATE) &
> > + PHY_C20_CONTEXT_TOGGLE;
> > +
> > + /* 2. If there is a protocol switch from HDMI to DP or vice versa, clear
> > +* the lane #0 MPLLB CAL_DONE_BANK DP2.0 10G and 20G rates enable
> MPLLA.
> > +* Protocol switch is only applicable for MPLLA
> > +*/
> > + if (intel_c20_protocol_switch_valid(encoder)) {
> > + for (i = 0; i < 4; i++)
> > + intel_c20_sram_write(i915, encoder->port,
> INTEL_CX0_LANE0, RAWLANEAONX_DIG_TX_MPLLB_CAL_DONE_BANK(i), 0);
> > + msleep(4);
>
> can you use usleep_range() here?
I think we should use usleep_range() here. If I remember right, the msleep() is
not that accurate.
Thanks for spotting!
-Mika-
>
> Andi
Re: [Intel-gfx] [PATCH 02/13] drm/i915/mtl: C20 HW readout
Hi Mika,
[...]
> +static int intel_c20_phy_check_hdmi_link_rate(int clock)
> +{
> + const struct intel_c20pll_state * const *tables = mtl_c20_hdmi_tables;
> + int i;
> +
> + for (i = 0; tables[i]; i++) {
> + if (clock == tables[i]->link_bit_rate)
> + return MODE_OK;
> + }
because you are going to resend it... you could remove these
braces here... there are a few cases below, as well.
Andi
Re: [Intel-gfx] [PATCH 03/13] drm/i915/mtl: Dump C20 pll hw state
Hi Mika,
> +
> + if (intel_c20_use_mplla(hw_state->clock)) {
> + for (i = 0; i < ARRAY_SIZE(hw_state->mplla); i++)
> + drm_dbg_kms(&i915->drm, "mplla[%d] = 0x%.4x\n", i,
> hw_state->mplla[i]);
> + } else {
> + for (i = 0; i < ARRAY_SIZE(hw_state->mpllb); i++)
> + drm_dbg_kms(&i915->drm, "mpllb[%d] = 0x%.4x\n", i,
> hw_state->mpllb[i]);
> + }
if you're going to resend it, brackets are nnot needed here.
Andi
Re: [Intel-gfx] [PATCH 07/13] drm/i915/mtl: Enabling/disabling sequence Thunderbolt pll
Hi Mika, On Thu, Apr 20, 2023 at 03:40:44PM +0300, Mika Kahola wrote: > Enabling and disabling sequence for Thunderbolt PLL. if you will resend it: /Enabling/Enable/ Andi
Re: [Intel-gfx] [PATCH 1/6] drm/uapi: Document CTM matrix better
Acked-by: Simon Ser
Re: [Intel-gfx] [PATCH v4 0/9] Enhance vfio PCI hot reset for vfio cdev device
> VFIO_DEVICE_PCI_HOT_RESET requires user to pass an array of group fds to > prove that it owns all devices affected by resetting the calling device. > While for > cdev devices, user can use an iommufd-based ownership checking model and > invoke VFIO_DEVICE_PCI_HOT_RESET with a zero-length fd array. > > This series first creates iommufd_access for noiommu devices to fill the gap > for > adding iommufd-based ownership checking model, then extends > VFIO_DEVICE_GET_PCI_HOT_RESET_INFO to check ownership and return the > check result and the devid of affected devices to user. In the end, extends > the > VFIO_DEVICE_PCI_HOT_RESET to accept zero-length fd array for hot-reset with > cdev devices. > > The new hot reset method and updated _INFO ioctl are tested with the below > qemu: > > https://github.com/yiliu1765/qemu/tree/iommufd_rfcv4.mig.reset.v4_var3 > (requires to test with the cdev kernel) > Tested NIC passthrough on Intel platform. Result looks good hence, Tested-by: Yanting Jiang Thanks, Yanting
Re: [Intel-gfx] [PATCH v10 00/22] Add vfio_device cdev for iommufd support
> Subject: [PATCH v10 00/22] Add vfio_device cdev for iommufd support > > Existing VFIO provides group-centric user APIs for userspace. Userspace opens > the /dev/vfio/$group_id first before getting device fd and hence getting > access > to device. This is not the desired model for iommufd. Per the conclusion of > community discussion[1], iommufd provides device-centric kAPIs and requires > its > consumer (like VFIO) to be device-centric user APIs. Such user APIs are used > to > associate device with iommufd and also the I/O address spaces managed by the > iommufd. > > This series first introduces a per device file structure to be prepared for > further > enhancement and refactors the kvm-vfio code to be prepared for accepting > device file from userspace. After this, adds a mechanism for blocking device > access before iommufd bind. Then refactors the vfio to be able to handle cdev > path (e.g. iommufd binding, no-iommufd, [de]attach ioas). > This refactor includes making the device_open exclusive between the group and > the cdev path, only allow single device open in cdev path; vfio-iommufd code > is > also refactored to support cdev. e.g. split the vfio_iommufd_bind() into two > steps. Eventually, adds the cdev support for vfio device and the new ioctls, > then > makes group infrastructure optional as it is not needed when vfio device cdev > is > compiled. > > This series is based on some preparation works done to vfio emulated > devices[2] > and vfio pci hot reset enhancements[3]. > > This series is a prerequisite for iommu nesting for vfio device[4] [5]. > > The complete code can be found in below branch, simple tests done to the > legacy group path and the cdev path. Draft QEMU branch can be found at[6] > However, the noiommu mode test is only done with some hacks in kernel and > qemu to check if qemu can boot with noiommu devices. > > https://github.com/yiliu1765/iommufd/tree/vfio_device_cdev_v10 > (config CONFIG_IOMMUFD=y CONFIG_VFIO_DEVICE_CDEV=y) > > base-commit: c3822365940319ad86487cc1daf6f1a4c271191e > (based on Alex's next branch and merged the vfio_mdev_ops branch from > Jason's repo) > Tested NIC passthrough on Intel platform. Result looks good hence, Tested-by: Yanting Jiang Thanks, Yanting
Re: [Intel-gfx] [PATCH v2 0/5] drm/i915: Allow user to set cache at BO creation
On 27/04/2023 17:07, Yang, Fei wrote: > On 26/04/2023 16:41, Yang, Fei wrote: >>> On 26/04/2023 07:24, fei.y...@intel.com wrote: From: Fei Yang The first three patches in this series are taken from https://patchwork.freedesktop.org/series/116868/ These patches are included here because the last patch has dependency on the pat_index refactor. This series is focusing on uAPI changes, 1. end support for set caching ioctl [PATCH 4/5] 2. add set_pat extension for gem_create [PATCH 5/5] v2: drop one patch that was merged separately 341ad0e8e254 drm/i915/mtl: Add PTE encode function >>> >>> Are the re-sends for stabilizing the series, or focusing on merge? >> >> v2 was sent just to drop one of patches that has already been merged. >> >>> If the latter then opens are: >>> >>> 1) Link to Mesa MR reviewed and ready to merge. >>> >>> 2) IGT reviewed. >>> >>> 3) I raised an open that get/set_caching should not "lie" but return an >>> error if set pat extension has been used. I don't see a good reason not >>> to do that. >> >> I don't think it's "lying" to the userspace. the comparison is only valid >> for objects created by KMD because only such object uses the pat_index >> from the cachelevel_to_pat table. > > Lets double check my understanding is correct. Userspace sequence of > operations: > 1) > obj = gem_create()+set_pat(PAT_UC) > > 2a) > get_caching(obj) What gets reported? I see your point here. nice catch. That should be handled by, if (obj->cachel_level == I915_CACHE_INVAL) /* indicated pat-index is set by userspace */ return -EOPNOTSUPP; Will update the patch. > > 2b) > set_caching(obj, I915_CACHE_LLC) What is the return code? This will either return -EOPNOTSUPP, or ignored because set_pat extension was called. I see that you made it fail instead of fake success in the latest respin and I definitely agree with that. > > If answer to 2a is I915_CACHING_CACHED and to 2b) success, then please > state a good reason why both shouldn't return an error. > >> >>> + Joonas on this one. >>> >>> 4) Refactoring as done is not very pretty and I proposed an idea for a >>> nicer approach. Feasible or not, open for discussion. >> >> Still digesting your proposal. but not sure how would you define things >> like PAT_UC as that is platform dependent, not a constant. > > "PAT_UC" in my outline was purely a driver specific value, similarly as > I915_CACHE_... are. Okay. Then you were suggesting to add a translation table for pat_index-to-(PAT-UC/WB/WT)? It's going to be a N:1 mapping. PAT index to a value, probably a bitmask, built out of bits which define caching modes. Like "PAT_WB | PAT_1WAY_COHERENT", or just PAT_WB. Would that approach be enough to express everything? > With the whole point that driver can ask if > something is uncached, WT or whatever. Using the platform specific > mapping table which converts platform specific obj->pat_index to driver > representation of caching modes (PAT_UC etc). Are you suggesting completely remove i915_cache_level and use (PAT-UC/WB/WT) instead? Not completely but throughout the most internal code paths, which would all just work on PAT index. Basically object always has PAT index set, with a separate boolean saying whether it came from gem_create_ext or set_cache_level. Let's say a KMD object wants to be set as WB, how you get the exact pat_index to use? Note that there are multiple PAT indices having caching mod WB, but they are different, e.g. do you want just WB or WB with 1-way-coherency or WB with 2-way coherency? Just use the cache_level to pat_index mapping you added in the series? Also, in case a checking of pat_index is needed, do we say WB with 1-way-coherency is equal to WB or not? You mean the call sites where i915 is checking the object caching mode? We have two call sites which check for !I915_CACHE_NONE. Those would just check if PAT_UC is not set. Then the one in gpu_write_needs_clflush is checking for neither UC nor WT, which also directly translates. For the WB case there aren't any callers but if we just checked for "base" PAT_WB bit being set that would work. So in all cases helper which does "return bits_required | bits_set" seems would work fine. BTW, isn't PAT-UC/WB/WT the same kind of abstraction as enum i915_cache_level, I'm not sure how that would simplify anything. As I wrote before, I *think* it provides a way of not needing to sprinkle around i915_gem_get_pat_index and a simpler "has_cache_level". Conceptually cache_level->pat_index is done only in gem_create_ext and set_cache_level. Lower level code does not have to consult cache_level at all. And existence of tables simplifies the pretty printing code to a platform agnostic loop. I *think* at least.. We can leave it all for later. My main concern was that UAPI needs to be clear and solid
Re: [Intel-gfx] [PATCH v3 5/5] drm/i915: Allow user to set cache at BO creation
On 28/04/2023 06:47, fei.y...@intel.com wrote:
From: Fei Yang
To comply with the design that buffer objects shall have immutable
cache setting through out their life cycle, {set, get}_caching ioctl's
are no longer supported from MTL onward. With that change caching
policy can only be set at object creation time. The current code
applies a default (platform dependent) cache setting for all objects.
However this is not optimal for performance tuning. The patch extends
the existing gem_create uAPI to let user set PAT index for the object
at creation time.
The new extension is platform independent, so UMD's can switch to using
this extension for older platforms as well, while {set, get}_caching are
still supported on these legacy paltforms for compatibility reason.
Cc: Chris Wilson
Cc: Matt Roper
Cc: Andi Shyti
Signed-off-by: Fei Yang
Reviewed-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_create.c | 36 ++
drivers/gpu/drm/i915/gem/i915_gem_object.c | 6
include/uapi/drm/i915_drm.h| 36 ++
tools/include/uapi/drm/i915_drm.h | 36 ++
4 files changed, 114 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index bfe1dbda4cb7..723c3ddd6c74 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -245,6 +245,7 @@ struct create_ext {
unsigned int n_placements;
unsigned int placement_mask;
unsigned long flags;
+ unsigned int pat_index;
};
static void repr_placements(char *buf, size_t size,
@@ -394,11 +395,39 @@ static int ext_set_protected(struct i915_user_extension
__user *base, void *data
return 0;
}
+static int ext_set_pat(struct i915_user_extension __user *base, void *data)
+{
+ struct create_ext *ext_data = data;
+ struct drm_i915_private *i915 = ext_data->i915;
+ struct drm_i915_gem_create_ext_set_pat ext;
+ unsigned int max_pat_index;
+
+ BUILD_BUG_ON(sizeof(struct drm_i915_gem_create_ext_set_pat) !=
+offsetofend(struct drm_i915_gem_create_ext_set_pat, rsvd));
+
+ if (copy_from_user(&ext, base, sizeof(ext)))
+ return -EFAULT;
+
+ max_pat_index = INTEL_INFO(i915)->max_pat_index;
+
+ if (ext.pat_index > max_pat_index) {
+ drm_dbg(&i915->drm, "PAT index is invalid: %u\n",
+ ext.pat_index);
+ return -EINVAL;
+ }
+
+ ext_data->pat_index = ext.pat_index;
+
+ return 0;
+}
+
static const i915_user_extension_fn create_extensions[] = {
[I915_GEM_CREATE_EXT_MEMORY_REGIONS] = ext_set_placements,
[I915_GEM_CREATE_EXT_PROTECTED_CONTENT] = ext_set_protected,
+ [I915_GEM_CREATE_EXT_SET_PAT] = ext_set_pat,
};
+#define PAT_INDEX_NOT_SET 0x
/**
* i915_gem_create_ext_ioctl - Creates a new mm object and returns a handle
to it.
* @dev: drm device pointer
@@ -418,6 +447,7 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void
*data,
if (args->flags & ~I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS)
return -EINVAL;
+ ext_data.pat_index = PAT_INDEX_NOT_SET;
ret = i915_user_extensions(u64_to_user_ptr(args->extensions),
create_extensions,
ARRAY_SIZE(create_extensions),
@@ -454,5 +484,11 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void
*data,
if (IS_ERR(obj))
return PTR_ERR(obj);
+ if (ext_data.pat_index != PAT_INDEX_NOT_SET) {
+ i915_gem_object_set_pat_index(obj, ext_data.pat_index);
+ /* Mark pat_index is set by UMD */
+ obj->cache_level = I915_CACHE_INVAL;
+ }
+
return i915_gem_publish(obj, file, &args->size, &args->handle);
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 27c948350b5b..61651f7e5806 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -209,6 +209,12 @@ bool i915_gem_object_can_bypass_llc(struct
drm_i915_gem_object *obj)
if (!(obj->flags & I915_BO_ALLOC_USER))
return false;
+ /*
+* Always flush cache for UMD objects at creation time.
+*/
+ if (obj->cache_level == I915_CACHE_INVAL)
+ return true;
Can this affect performance? Would you be able to make the check smarter
if the driver had that translation table we talked about (per platform
pat index to caching modes)?
+
/*
* EHL and JSL add the 'Bypass LLC' MOCS entry, which should make it
* possible for userspace to bypass the GTT caching bits set by the
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index dba7c5a5b25e..03c5c314846e 100644
--- a/include/uapi/drm/i915_drm.h
[Intel-gfx] [PATCH v2 00/13] drm/i915/mtl: Add support for C20 phy
Add support for C20 phy for Type-C connections. C20 phy differs from C10 and hence we need to separately handle this case. v2: Fixes for C20 pll programming and hw readout Signed-off-by: Mika Kahola Anusha Srivatsa (1): drm/i915/mtl: Pin assignment for TypeC Gustavo Sousa (1): drm/i915/mtl: Define mask for DDI AUX interrupts Imre Deak (1): drm/i915/mtl: TypeC HPD live status query Mika Kahola (10): drm/i915/mtl: C20 PLL programming drm/i915/mtl: C20 HW readout drm/i915/mtl: Dump C20 pll hw state drm/i915/mtl: C20 port clock calculation drm/i915/mtl: Add voltage swing sequence for C20 drm/i915/mtl: For DP2.0 10G and 20G rates use MPLLA drm/i915/mtl: Enabling/disabling sequence Thunderbolt pll drm/i915/mtl: Readout Thunderbolt HW state drm/i915/mtl: Power up TCSS drm/i915/mtl: Enable TC ports drivers/gpu/drm/i915/display/intel_cx0_phy.c | 1137 - drivers/gpu/drm/i915/display/intel_cx0_phy.h | 23 +- .../gpu/drm/i915/display/intel_cx0_phy_regs.h | 41 + drivers/gpu/drm/i915/display/intel_ddi.c | 25 +- .../drm/i915/display/intel_ddi_buf_trans.c| 53 +- drivers/gpu/drm/i915/display/intel_display.c |7 +- .../drm/i915/display/intel_display_types.h| 16 +- drivers/gpu/drm/i915/display/intel_dp.c | 12 +- drivers/gpu/drm/i915/display/intel_dpll.c |2 + drivers/gpu/drm/i915/display/intel_hdmi.c |6 +- drivers/gpu/drm/i915/display/intel_hdmi.h |1 + drivers/gpu/drm/i915/display/intel_tc.c | 255 +++- drivers/gpu/drm/i915/i915_irq.c |5 +- 13 files changed, 1510 insertions(+), 73 deletions(-) -- 2.34.1
[Intel-gfx] [PATCH v2 01/13] drm/i915/mtl: C20 PLL programming
C20 phy PLL programming sequence for DP, DP2.0, HDMI2.x non-FRL and
HDMI2.x FRL. This enables C20 MPLLA and MPLLB programming sequence. add
4 lane support for c20.
v2: Add 6.48Gbps and 6.75Gbps modes for eDP (RK)
Fix lane check (RK)
Fix multiline commenting (Arun)
use usleep_range() instead of msleep() (Andi)
Reviewed-by: Arun R Murthy
Signed-off-by: José Roberto de Souza
Signed-off-by: Mika Kahola
Signed-off-by: Bhanuprakash Modem
Signed-off-by: Imre Deak
Signed-off-by: Arun R Murthy
---
drivers/gpu/drm/i915/display/intel_cx0_phy.c | 288 +++---
.../gpu/drm/i915/display/intel_cx0_phy_regs.h | 33 ++
drivers/gpu/drm/i915/display/intel_ddi.c | 3 +-
.../drm/i915/display/intel_display_types.h| 15 +-
drivers/gpu/drm/i915/display/intel_dp.c | 12 +-
5 files changed, 309 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index 83180074b512..71163bc5bbf5 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -273,6 +273,18 @@ static void intel_cx0_write(struct drm_i915_private *i915,
enum port port,
__intel_cx0_write(i915, port, lane, addr, data, committed);
}
+static void intel_c20_sram_write(struct drm_i915_private *i915, enum port port,
+int lane, u16 addr, u16 data)
+{
+ assert_dc_off(i915);
+
+ intel_cx0_write(i915, port, lane, PHY_C20_WR_ADDRESS_H, addr >> 8, 0);
+ intel_cx0_write(i915, port, lane, PHY_C20_WR_ADDRESS_L, addr & 0xff, 0);
+
+ intel_cx0_write(i915, port, lane, PHY_C20_WR_DATA_H, data >> 8, 0);
+ intel_cx0_write(i915, port, lane, PHY_C20_WR_DATA_L, data & 0xff, 1);
+}
+
static void __intel_cx0_rmw(struct drm_i915_private *i915, enum port port,
int lane, u16 addr, u8 clear, u8 set, bool
committed)
{
@@ -1415,6 +1427,215 @@ void intel_c10pll_dump_hw_state(struct drm_i915_private
*i915,
i + 2, hw_state->pll[i + 2], i + 3, hw_state->pll[i
+ 3]);
}
+static bool intel_c20_use_mplla(u32 clock)
+{
+ /* 10G and 20G rates use MPLLA */
+ if (clock == 312500 || clock == 625000)
+ return true;
+
+ return false;
+}
+
+static u8 intel_c20_get_dp_rate(u32 clock)
+{
+ switch (clock) {
+ case 162000: /* 1.62 Gbps DP1.4 */
+ return 0;
+ case 27: /* 2.7 Gbps DP1.4 */
+ return 1;
+ case 54: /* 5.4 Gbps DP 1.4 */
+ return 2;
+ case 81: /* 8.1 Gbps DP1.4 */
+ return 3;
+ case 216000: /* 2.16 Gbps eDP */
+ return 4;
+ case 243000: /* 2.43 Gbps eDP */
+ return 5;
+ case 324000: /* 3.24 Gbps eDP */
+ return 6;
+ case 432000: /* 4.32 Gbps eDP */
+ return 7;
+ case 312500: /* 10 Gbps DP2.0 */
+ return 8;
+ case 421875: /* 13.5 Gbps DP2.0 */
+ return 9;
+ case 625000: /* 20 Gbps DP2.0*/
+ return 10;
+ case 648000: /* 6.48 Gbps eDP*/
+ return 11;
+ case 675000: /* 6.75 Gbps eDP*/
+ return 12;
+ default:
+ MISSING_CASE(clock);
+ return 0;
+ }
+}
+
+static u8 intel_c20_get_hdmi_rate(u32 clock)
+{
+ switch (clock) {
+ case 25175:
+ case 27000:
+ case 74250:
+ case 148500:
+ case 594000:
+ return 0;
+ case 166670: /* 3 Gbps */
+ case 30: /* 6 Gbps */
+ case 70: /* 12 Gbps */
+ return 1;
+ case 40: /* 8 Gbps */
+ return 2;
+ case 60: /* 10 Gbps */
+ return 3;
+ default:
+ MISSING_CASE(clock);
+ return 0;
+ }
+}
+
+static bool is_dp2(u32 clock)
+{
+ /* DP2.0 clock rates */
+ if (clock == 312500 || clock == 421875 || clock == 625000)
+ return true;
+
+ return false;
+}
+
+static bool is_hdmi_frl(u32 clock)
+{
+ switch (clock) {
+ case 166670: /* 3 Gbps */
+ case 30: /* 6 Gbps */
+ case 40: /* 8 Gbps */
+ case 60: /* 10 Gbps */
+ case 70: /* 12 Gbps */
+ return true;
+ default:
+ return false;
+ }
+}
+
+static bool intel_c20_protocol_switch_valid(struct intel_encoder *encoder)
+{
+ struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
+
+ /* banks should not be cleared for DPALT/USB4/TBT modes */
+ /* TODO: optimize re-calibration in legacy mode */
+ return intel_tc_port_in_legacy_mode(intel_dig_port);
+}
+
+static int intel_get_c20_custom_width(u32 clock, bool dp)
+{
+ if (dp && is_dp2(clock))
+ return 2;
+ else if (is_hdmi_frl(clock))
+ return 1;
+ else
+
[Intel-gfx] [PATCH v2 02/13] drm/i915/mtl: C20 HW readout
Create a table for C20 DP1.4, DP2.0 and HDMI2.1 rates.
The PLL settings are based on table, not for algorithmic alternative.
For DP 1.4 only MPLLB is in use.
Once register settings are done, we read back C20 HW state.
BSpec: 64568
v2: Updated pll tables (RK)
MPLLB selection fix (RK)
Signed-off-by: Mika Kahola
Signed-off-by: Arun R Murthy
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_cx0_phy.c | 624 +-
drivers/gpu/drm/i915/display/intel_cx0_phy.h | 8 +-
.../gpu/drm/i915/display/intel_cx0_phy_regs.h | 1 +
drivers/gpu/drm/i915/display/intel_ddi.c | 9 +-
.../drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/display/intel_hdmi.c | 6 +-
drivers/gpu/drm/i915/display/intel_hdmi.h | 1 +
7 files changed, 630 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 71163bc5bbf5..f58b3112baea 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -11,6 +11,7 @@
#include "intel_de.h"
#include "intel_display_types.h"
#include "intel_dp.h"
+#include "intel_hdmi.h"
#include "intel_panel.h"
#include "intel_psr.h"
#include "intel_tc.h"
@@ -285,6 +286,23 @@ static void intel_c20_sram_write(struct drm_i915_private
*i915, enum port port,
intel_cx0_write(i915, port, lane, PHY_C20_WR_DATA_L, data & 0xff, 1);
}
+static u16 intel_c20_sram_read(struct drm_i915_private *i915, enum port port,
+ int lane, u16 addr)
+{
+ u16 val;
+
+ assert_dc_off(i915);
+
+ intel_cx0_write(i915, port, lane, PHY_C20_RD_ADDRESS_H, addr >> 8, 0);
+ intel_cx0_write(i915, port, lane, PHY_C20_RD_ADDRESS_L, addr & 0xff, 1);
+
+ val = intel_cx0_read(i915, port, lane, PHY_C20_RD_DATA_H);
+ val <<= 8;
+ val |= intel_cx0_read(i915, port, lane, PHY_C20_RD_DATA_L);
+
+ return val;
+}
+
static void __intel_cx0_rmw(struct drm_i915_private *i915, enum port port,
int lane, u16 addr, u8 clear, u8 set, bool
committed)
{
@@ -659,6 +677,199 @@ static const struct intel_c10pll_state * const
mtl_c10_edp_tables[] = {
NULL,
};
+/* C20 basic DP 1.4 tables */
+static const struct intel_c20pll_state mtl_c20_dp_rbr = {
+ .link_bit_rate = 162000,
+ .clock = 162000,
+ .tx = { 0xbe88, /* tx cfg0 */
+ 0x5800, /* tx cfg1 */
+ 0x, /* tx cfg2 */
+ },
+ .cmn = {0x0500, /* cmn cfg0*/
+ 0x0005, /* cmn cfg1 */
+ 0x, /* cmn cfg2 */
+ 0x, /* cmn cfg3 */
+ },
+ .mpllb = { 0x50a8, /* mpllb cfg0 */
+ 0x2120, /* mpllb cfg1 */
+ 0xcd9a, /* mpllb cfg2 */
+ 0xbfc1, /* mpllb cfg3 */
+ 0x5ab8, /* mpllb cfg4 */
+ 0x4c34, /* mpllb cfg5 */
+ 0x2000, /* mpllb cfg6 */
+ 0x0001, /* mpllb cfg7 */
+ 0x6000, /* mpllb cfg8 */
+ 0x, /* mpllb cfg9 */
+ 0x, /* mpllb cfg10 */
+ },
+};
+
+static const struct intel_c20pll_state mtl_c20_dp_hbr1 = {
+ .link_bit_rate = 27,
+ .clock = 27,
+ .tx = { 0xbe88, /* tx cfg0 */
+ 0x4800, /* tx cfg1 */
+ 0x, /* tx cfg2 */
+ },
+ .cmn = {0x0500, /* cmn cfg0*/
+ 0x0005, /* cmn cfg1 */
+ 0x, /* cmn cfg2 */
+ 0x, /* cmn cfg3 */
+ },
+ .mpllb = { 0x308c, /* mpllb cfg0 */
+ 0x2110, /* mpllb cfg1 */
+ 0xcc9c, /* mpllb cfg2 */
+ 0xbfc1, /* mpllb cfg3 */
+ 0x4b9a, /* mpllb cfg4 */
+ 0x3f81, /* mpllb cfg5 */
+ 0x2000, /* mpllb cfg6 */
+ 0x0001, /* mpllb cfg7 */
+ 0x5000, /* mpllb cfg8 */
+ 0x, /* mpllb cfg9 */
+ 0x, /* mpllb cfg10 */
+ },
+};
+
+static const struct intel_c20pll_state mtl_c20_dp_hbr2 = {
+ .link_bit_rate = 54,
+ .clock = 54,
+ .tx = { 0xbe88, /* tx cfg0 */
+ 0x4800, /* tx cfg1 */
+ 0x, /* tx cfg2 */
+ },
+ .cmn = {0x0500, /* cmn cfg0*/
+ 0x0005, /* cmn cfg1 */
+ 0x, /* cmn cfg2 */
+ 0x, /* cmn cfg3 */
+ },
+ .mpllb = { 0x108c, /* mpllb cfg0 */
+ 0x2108, /* mpllb cfg1 */
+ 0xcc9c, /* mpllb cfg2 */
+ 0xbfc1, /* mpllb cfg3 */
+ 0x4b9a, /* mpllb cfg4 */
+ 0x3f81, /* mpllb cf
[Intel-gfx] [PATCH v2 04/13] drm/i915/mtl: C20 port clock calculation
Calculate port clock with C20 phy.
BSpec: 64568
Reviewed-by: Radhakrishna Sripada
Reviewed-by: Arun R Murthy
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/display/intel_cx0_phy.c | 45 +++
drivers/gpu/drm/i915/display/intel_cx0_phy.h | 2 +
.../gpu/drm/i915/display/intel_cx0_phy_regs.h | 3 ++
drivers/gpu/drm/i915/display/intel_ddi.c | 4 +-
drivers/gpu/drm/i915/display/intel_dpll.c | 2 +
5 files changed, 54 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index 8920263cacd7..5409be0d5812 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -2283,6 +2283,51 @@ 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)
+{
+ unsigned int frac, frac_en, frac_quot, frac_rem, frac_den;
+ unsigned int multiplier, refclk = 38400;
+ unsigned int tx_clk_div;
+ unsigned int ref_clk_mpllb_div;
+ unsigned int fb_clk_div4_en;
+ unsigned int ref, vco;
+ unsigned int tx_rate_mult;
+ unsigned int tx_rate = REG_FIELD_GET(C20_PHY_TX_RATE, pll_state->tx[0]);
+
+ if (pll_state->tx[0] & C20_PHY_USE_MPLLB) {
+ tx_rate_mult = 1;
+ frac_en = REG_FIELD_GET(C20_MPLLB_FRACEN, pll_state->mpllb[6]);
+ frac_quot = pll_state->mpllb[8];
+ frac_rem = pll_state->mpllb[9];
+ frac_den = pll_state->mpllb[7];
+ multiplier = REG_FIELD_GET(C20_MULTIPLIER_MASK,
pll_state->mpllb[0]);
+ tx_clk_div = REG_FIELD_GET(C20_MPLLB_TX_CLK_DIV_MASK,
pll_state->mpllb[0]);
+ ref_clk_mpllb_div = REG_FIELD_GET(C20_REF_CLK_MPLLB_DIV_MASK,
pll_state->mpllb[6]);
+ fb_clk_div4_en = 0;
+ } else {
+ tx_rate_mult = 2;
+ frac_en = REG_FIELD_GET(C20_MPLLA_FRACEN, pll_state->mplla[6]);
+ frac_quot = pll_state->mplla[8];
+ frac_rem = pll_state->mplla[9];
+ frac_den = pll_state->mplla[7];
+ multiplier = REG_FIELD_GET(C20_MULTIPLIER_MASK,
pll_state->mplla[0]);
+ tx_clk_div = REG_FIELD_GET(C20_MPLLA_TX_CLK_DIV_MASK,
pll_state->mplla[1]);
+ ref_clk_mpllb_div = REG_FIELD_GET(C20_REF_CLK_MPLLB_DIV_MASK,
pll_state->mplla[6]);
+ fb_clk_div4_en = REG_FIELD_GET(C20_FB_CLK_DIV4_EN,
pll_state->mplla[0]);
+ }
+
+ if (frac_en)
+ frac = frac_quot + DIV_ROUND_CLOSEST(frac_rem, frac_den);
+ else
+ frac = 0;
+
+ ref = DIV_ROUND_CLOSEST(refclk * (1 << (1 + fb_clk_div4_en)), 1 <<
ref_clk_mpllb_div);
+ vco = DIV_ROUND_CLOSEST_ULL(mul_u32_u32(ref, (multiplier << (17 - 2)) +
frac) >> 17, 10);
+
+ return vco << tx_rate_mult >> tx_clk_div >> tx_rate;
+}
+
static void intel_program_port_clock_ctl(struct intel_encoder *encoder,
const struct intel_crtc_state
*crtc_state,
bool lane_reversal)
diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.h
b/drivers/gpu/drm/i915/display/intel_cx0_phy.h
index c643aae27bac..83bd3500091b 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.h
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.h
@@ -34,6 +34,8 @@ 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,
+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_cx0_phy_regs.h
b/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
index bfb39bce3b04..d3de4df2b682 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
@@ -196,16 +196,19 @@
#define PHY_C20_CUSTOM_WIDTH(val)
REG_FIELD_PREP8(PHY_C20_CUSTOM_WIDTH_MASK, val)
#define PHY_C20_A_TX_CNTX_CFG(idx) (0xCF2E - (idx))
#define PHY_C20_B_TX_CNTX_CFG(idx) (0xCF2A - (idx))
+#define C20_PHY_TX_RATE REG_GENMASK(2, 0)
#define PHY_C20_A_CMN_CNTX_CFG(idx)(0xCDAA - (idx))
#define PHY_C20_B_CMN_CNTX_CFG(idx)(0xCDA5 - (idx))
#define PHY_C20_A_MPLLA_CNTX_CFG(idx) (0xCCF0 - (idx))
#define PHY_C20_B_MPLLA_CNTX_CFG(idx) (0xCCE5 - (idx))
#define C20_MPLLA_FR
[Intel-gfx] [PATCH v2 03/13] drm/i915/mtl: Dump C20 pll hw state
As we already do with C10 chip, let's dump the pll
hw state for C20 as well.
Reviewed-by: Radhakrishna Sripada
Reviewed-by: Arun R Murthy
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/display/intel_cx0_phy.c | 20
drivers/gpu/drm/i915/display/intel_cx0_phy.h | 2 ++
drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
3 files changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index f58b3112baea..8920263cacd7 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -2036,6 +2036,26 @@ void intel_c20pll_readout_hw_state(struct intel_encoder
*encoder,
intel_cx0_phy_transaction_end(encoder, wakeref);
}
+void intel_c20pll_dump_hw_state(struct drm_i915_private *i915,
+ const struct intel_c20pll_state *hw_state)
+{
+ int i;
+
+ drm_dbg_kms(&i915->drm, "c20pll_hw_state:\n");
+ drm_dbg_kms(&i915->drm, "tx[0] = 0x%.4x, tx[1] = 0x%.4x, tx[2] =
0x%.4x\n",
+ hw_state->tx[0], hw_state->tx[1], hw_state->tx[2]);
+ drm_dbg_kms(&i915->drm, "cmn[0] = 0x%.4x, cmn[1] = 0x%.4x, cmn[2] =
0x%.4x, cmn[3] = 0x%.4x\n",
+ hw_state->cmn[0], hw_state->cmn[1], hw_state->cmn[2],
hw_state->cmn[3]);
+
+ if (intel_c20_use_mplla(hw_state->clock)) {
+ for (i = 0; i < ARRAY_SIZE(hw_state->mplla); i++)
+ drm_dbg_kms(&i915->drm, "mplla[%d] = 0x%.4x\n", i,
hw_state->mplla[i]);
+ } else {
+ for (i = 0; i < ARRAY_SIZE(hw_state->mpllb); i++)
+ drm_dbg_kms(&i915->drm, "mpllb[%d] = 0x%.4x\n", i,
hw_state->mpllb[i]);
+ }
+}
+
static u8 intel_c20_get_dp_rate(u32 clock)
{
switch (clock) {
diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.h
b/drivers/gpu/drm/i915/display/intel_cx0_phy.h
index 9760c6292c81..c643aae27bac 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.h
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.h
@@ -32,6 +32,8 @@ void intel_c10pll_state_verify(struct intel_atomic_state
*state,
struct intel_crtc_state *new_crtc_state);
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);
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 44f07011245b..d414dd8c26bf 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3858,6 +3858,7 @@ static void mtl_ddi_get_config(struct intel_encoder
*encoder,
intel_c10pll_dump_hw_state(i915, &crtc_state->cx0pll_state.c10);
} else {
intel_c20pll_readout_hw_state(encoder,
&crtc_state->cx0pll_state.c20);
+ intel_c20pll_dump_hw_state(i915, &crtc_state->cx0pll_state.c20);
}
crtc_state->port_clock = intel_c10pll_calc_port_clock(encoder,
&crtc_state->cx0pll_state.c10);
--
2.34.1
[Intel-gfx] [PATCH v2 06/13] drm/i915/mtl: For DP2.0 10G and 20G rates use MPLLA
Use MPLLA for DP2.0 rates 10G and 20G, when ssc is enabled. v2: Fix typo in commit message (Animesh) Reviewed-by: Radhakrishna Sripada Reviewed-by: Arun R Murthy Signed-off-by: Mika Kahola --- drivers/gpu/drm/i915/display/intel_cx0_phy.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c b/drivers/gpu/drm/i915/display/intel_cx0_phy.c index 5409be0d5812..63d63c23647e 100644 --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c @@ -2349,8 +2349,11 @@ static void intel_program_port_clock_ctl(struct intel_encoder *encoder, val |= XELPDP_DDI_CLOCK_SELECT(XELPDP_DDI_CLOCK_SELECT_MAXPCLK); /* TODO: HDMI FRL */ - /* TODO: DP2.0 10G and 20G rates enable MPLLA*/ - val |= crtc_state->cx0pll_state.ssc_enabled ? XELPDP_SSC_ENABLE_PLLB : 0; + /* DP2.0 10G and 20G rates enable MPLLA*/ + if (crtc_state->port_clock == 100 || crtc_state->port_clock == 200) + val |= crtc_state->cx0pll_state.ssc_enabled ? XELPDP_SSC_ENABLE_PLLA : 0; + else + val |= crtc_state->cx0pll_state.ssc_enabled ? XELPDP_SSC_ENABLE_PLLB : 0; intel_de_rmw(i915, XELPDP_PORT_CLOCK_CTL(encoder->port), XELPDP_LANE1_PHY_CLOCK_SELECT | XELPDP_FORWARD_CLOCK_UNGATE | -- 2.34.1
[Intel-gfx] [PATCH v2 05/13] drm/i915/mtl: Add voltage swing sequence for C20
DP1.4 and DP20 voltage swing sequence for C20 phy.
Bspec: 65449, 67636, 67610
Reviewed-by: Arun R Murthy
Signed-off-by: Mika Kahola
Signed-off-by: Clint Taylor
Signed-off-by: Radhakrishna Sripada
---
.../gpu/drm/i915/display/intel_cx0_phy_regs.h | 4 ++
.../drm/i915/display/intel_ddi_buf_trans.c| 53 ++-
2 files changed, 55 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
b/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
index d3de4df2b682..ab9d1d983b88 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
@@ -212,6 +212,10 @@
#define C20_MULTIPLIER_MASK REG_GENMASK(11, 0)
#define C20_PHY_USE_MPLLBREG_BIT(7)
+/* C20 Phy VSwing Masks */
+#define C20_PHY_VSWING_PREEMPH_MASKREG_GENMASK8(5, 0)
+#define C20_PHY_VSWING_PREEMPH(val)
REG_FIELD_PREP8(C20_PHY_VSWING_PREEMPH_MASK, val)
+
#define RAWLANEAONX_DIG_TX_MPLLB_CAL_DONE_BANK(idx) (0x303D + (idx))
#endif /* __INTEL_CX0_REG_DEFS_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
index cd4becbae098..b7d20485bde5 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
@@ -9,6 +9,7 @@
#include "intel_de.h"
#include "intel_display_types.h"
#include "intel_dp.h"
+#include "intel_cx0_phy.h"
/* HDMI/DVI modes ignore everything but the last 2 items. So we share
* them for both DP and FDI transports, allowing those ports to
@@ -1048,12 +1049,52 @@ static const union intel_ddi_buf_trans_entry
_mtl_c10_trans_dp14[] = {
{ .snps = { 62, 0, 0 } }, /* preset 9 */
};
-static const struct intel_ddi_buf_trans mtl_cx0c10_trans = {
+static const struct intel_ddi_buf_trans mtl_cx0_trans = {
.entries = _mtl_c10_trans_dp14,
.num_entries = ARRAY_SIZE(_mtl_c10_trans_dp14),
.hdmi_default_entry = ARRAY_SIZE(_mtl_c10_trans_dp14) - 1,
};
+/* DP2.0 */
+static const union intel_ddi_buf_trans_entry _mtl_c20_trans_uhbr[] = {
+ { .snps = { 48, 0, 0 } }, /* preset 0 */
+ { .snps = { 43, 0, 5 } }, /* preset 1 */
+ { .snps = { 40, 0, 8 } }, /* preset 2 */
+ { .snps = { 37, 0, 11 } }, /* preset 3 */
+ { .snps = { 33, 0, 15 } }, /* preset 4 */
+ { .snps = { 46, 2, 0 } }, /* preset 5 */
+ { .snps = { 42, 2, 4 } }, /* preset 6 */
+ { .snps = { 38, 2, 8 } }, /* preset 7 */
+ { .snps = { 35, 2, 11 } }, /* preset 8 */
+ { .snps = { 33, 2, 13 } }, /* preset 9 */
+ { .snps = { 44, 4, 0 } }, /* preset 10 */
+ { .snps = { 40, 4, 4 } }, /* preset 11 */
+ { .snps = { 37, 4, 7 } }, /* preset 12 */
+ { .snps = { 33, 4, 11 } }, /* preset 13 */
+ { .snps = { 40, 8, 0 } }, /* preset 14 */
+ { .snps = { 28, 2, 2 } }, /* preset 15 */
+};
+
+/* HDMI2.0 */
+static const union intel_ddi_buf_trans_entry _mtl_c20_trans_hdmi[] = {
+ { .snps = { 48, 0, 0 } }, /* preset 0 */
+ { .snps = { 38, 4, 6 } }, /* preset 1 */
+ { .snps = { 36, 4, 8 } }, /* preset 2 */
+ { .snps = { 34, 4, 10 } }, /* preset 3 */
+ { .snps = { 32, 4, 12 } }, /* preset 4 */
+};
+
+static const struct intel_ddi_buf_trans mtl_c20_trans_hdmi = {
+ .entries = _mtl_c20_trans_hdmi,
+ .num_entries = ARRAY_SIZE(_mtl_c20_trans_hdmi),
+ .hdmi_default_entry = 0,
+};
+
+static const struct intel_ddi_buf_trans mtl_c20_trans_uhbr = {
+ .entries = _mtl_c20_trans_uhbr,
+ .num_entries = ARRAY_SIZE(_mtl_c20_trans_uhbr),
+};
+
bool is_hobl_buf_trans(const struct intel_ddi_buf_trans *table)
{
return table == &tgl_combo_phy_trans_edp_hbr2_hobl;
@@ -1630,7 +1671,15 @@ mtl_get_cx0_buf_trans(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state,
int *n_entries)
{
- return intel_get_buf_trans(&mtl_cx0c10_trans, n_entries);
+ struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+ enum phy phy = intel_port_to_phy(i915, encoder->port);
+
+ if (intel_crtc_has_dp_encoder(crtc_state) && crtc_state->port_clock >=
100)
+ return intel_get_buf_trans(&mtl_c20_trans_uhbr, n_entries);
+ else if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI) &&
!(intel_is_c10phy(i915, phy)))
+ return intel_get_buf_trans(&mtl_c20_trans_hdmi, n_entries);
+ else
+ return intel_get_buf_trans(&mtl_cx0_trans, n_entries);
}
void intel_ddi_buf_trans_init(struct intel_encoder *encoder)
--
2.34.1
[Intel-gfx] [PATCH v2 10/13] drm/i915/mtl: Power up TCSS
Add register writes to enable powering up Type-C subsystem i.e. TCSS.
For MeteorLake we need to request TCSS to power up and check the TCSS
power state after 500 us.
In addition, for PICA we need to set/clear the Type-C PHY ownnership
bit when Type-C device is connected/disconnected.
Reviewed-by: Matt Atwood
Signed-off-by: Mika Kahola
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_cx0_phy.c | 19 ++
drivers/gpu/drm/i915/display/intel_cx0_phy.h | 4 +
drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
drivers/gpu/drm/i915/display/intel_tc.c | 199 ++-
5 files changed, 216 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 2a364ae538f6..ae559897c3ac 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -2893,6 +2893,25 @@ void intel_mtl_pll_disable(struct intel_encoder *encoder)
intel_cx0pll_disable(encoder);
}
+enum icl_port_dpll_id
+intel_mtl_port_pll_type(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state)
+{
+ struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+ /*
+* TODO: Determine the PLL type from the SW state, once MTL PLL
+* handling is done via the standard shared DPLL framework.
+*/
+ u32 val = intel_de_read(i915, XELPDP_PORT_CLOCK_CTL(encoder->port));
+ u32 clock = REG_FIELD_GET(XELPDP_DDI_CLOCK_SELECT_MASK, val);
+
+ if (clock == XELPDP_DDI_CLOCK_SELECT_MAXPCLK ||
+ clock == XELPDP_DDI_CLOCK_SELECT_DIV18CLK)
+ return ICL_PORT_DPLL_MG_PHY;
+ else
+ return ICL_PORT_DPLL_DEFAULT;
+}
+
void intel_c10pll_state_verify(struct intel_atomic_state *state,
struct intel_crtc_state *new_crtc_state)
{
diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.h
b/drivers/gpu/drm/i915/display/intel_cx0_phy.h
index c1b8f7980f69..f99809af257d 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.h
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.h
@@ -16,12 +16,16 @@
struct drm_i915_private;
struct intel_encoder;
struct intel_crtc_state;
+enum icl_port_dpll_id;
enum phy;
bool intel_is_c10phy(struct drm_i915_private *dev_priv, enum phy phy);
void intel_mtl_pll_enable(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state);
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_c10pll_dump_hw_state(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 8f0f858cde31..55f36d9d509c 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4784,6 +4784,7 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
enum port port)
if (DISPLAY_VER(dev_priv) >= 14) {
encoder->enable_clock = intel_mtl_pll_enable;
encoder->disable_clock = intel_mtl_pll_disable;
+ encoder->port_pll_type = intel_mtl_port_pll_type;
encoder->get_config = mtl_ddi_get_config;
} else if (IS_DG2(dev_priv)) {
encoder->enable_clock = intel_mpllb_enable;
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index bf391a6cd8d6..0b9ae5759ffa 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1756,7 +1756,7 @@ bool intel_phy_is_tc(struct drm_i915_private *dev_priv,
enum phy phy)
if (IS_DG2(dev_priv))
/* DG2's "TC1" output uses a SNPS PHY */
return false;
- else if (IS_ALDERLAKE_P(dev_priv))
+ else if (IS_ALDERLAKE_P(dev_priv) || IS_METEORLAKE(dev_priv))
return phy >= PHY_F && phy <= PHY_I;
else if (IS_TIGERLAKE(dev_priv))
return phy >= PHY_D && phy <= PHY_I;
diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
b/drivers/gpu/drm/i915/display/intel_tc.c
index 3b60995e9dfb..951b12ac51dc 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -5,6 +5,7 @@
#include "i915_drv.h"
#include "i915_reg.h"
+#include "intel_cx0_phy_regs.h"
#include "intel_ddi.h"
#include "intel_de.h"
#include "intel_display.h"
@@ -59,6 +60,7 @@ static enum intel_display_power_domain
tc_phy_cold_off_domain(struct intel_tc_port *);
static u32
[Intel-gfx] [PATCH v2 07/13] drm/i915/mtl: Enabling/disabling sequence Thunderbolt pll
Enabling and disabling sequence for Thunderbolt PLL.
Bspec: 64568
v2: Use intel_de_wait_for_register() (RK)
Reviewed-by: Radhakrishna Sripada
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/display/intel_cx0_phy.c | 135 ++-
drivers/gpu/drm/i915/display/intel_cx0_phy.h | 7 +-
drivers/gpu/drm/i915/display/intel_ddi.c | 4 +-
3 files changed, 138 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index 63d63c23647e..7a2bf624eba7 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -2609,8 +2609,8 @@ static u32 intel_cx0_get_pclk_pll_ack(u8 lane_mask)
return val;
}
-void intel_cx0pll_enable(struct intel_encoder *encoder,
-const struct intel_crtc_state *crtc_state)
+static void intel_cx0pll_enable(struct intel_encoder *encoder,
+ const 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);
@@ -2685,7 +2685,86 @@ void intel_cx0pll_enable(struct intel_encoder *encoder,
intel_cx0_phy_transaction_end(encoder, wakeref);
}
-void intel_cx0pll_disable(struct intel_encoder *encoder)
+static int intel_mtl_tbt_clock_select(struct drm_i915_private *i915, int clock)
+{
+ switch (clock) {
+ case 162000:
+ return XELPDP_DDI_CLOCK_SELECT_TBT_162;
+ case 27:
+ return XELPDP_DDI_CLOCK_SELECT_TBT_270;
+ case 54:
+ return XELPDP_DDI_CLOCK_SELECT_TBT_540;
+ case 81:
+ return XELPDP_DDI_CLOCK_SELECT_TBT_810;
+ default:
+ MISSING_CASE(clock);
+ return XELPDP_DDI_CLOCK_SELECT_TBT_162;
+ }
+}
+
+static void intel_mtl_tbt_pll_enable(struct intel_encoder *encoder,
+const 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);
+ u32 val = 0;
+
+ /*
+* 1. Program PORT_CLOCK_CTL REGISTER to configure
+* clock muxes, gating and SSC
+*/
+ val |= XELPDP_DDI_CLOCK_SELECT(intel_mtl_tbt_clock_select(i915,
crtc_state->port_clock));
+ val |= XELPDP_FORWARD_CLOCK_UNGATE;
+ intel_de_rmw(i915, XELPDP_PORT_CLOCK_CTL(encoder->port),
+XELPDP_DDI_CLOCK_SELECT_MASK |
XELPDP_FORWARD_CLOCK_UNGATE, val);
+
+ /* 2. Read back PORT_CLOCK_CTL REGISTER */
+ val = intel_de_read(i915, XELPDP_PORT_CLOCK_CTL(encoder->port));
+
+ /*
+* 3. Follow the Display Voltage Frequency Switching - Sequence
+* Before Frequency Change. We handle this step in bxt_set_cdclk().
+*/
+
+ /*
+* 4. Set PORT_CLOCK_CTL register TBT CLOCK Request to "1" to enable
PLL.
+*/
+ val |= XELPDP_TBT_CLOCK_REQUEST;
+ intel_de_write(i915, XELPDP_PORT_CLOCK_CTL(encoder->port), val);
+
+ /* 5. Poll on PORT_CLOCK_CTL TBT CLOCK Ack == "1". */
+ if (__intel_de_wait_for_register(i915,
XELPDP_PORT_CLOCK_CTL(encoder->port),
+XELPDP_TBT_CLOCK_ACK,
+XELPDP_TBT_CLOCK_ACK,
+100, 0, NULL))
+ drm_warn(&i915->drm, "[ENCODER:%d:%s][%c] PHY PLL not locked
after 100us.\n",
+encoder->base.base.id, encoder->base.name,
phy_name(phy));
+
+ /*
+* 6. Follow the Display Voltage Frequency Switching Sequence After
+* Frequency Change. We handle this step in bxt_set_cdclk().
+*/
+
+ /*
+* 7. Program DDI_CLK_VALFREQ to match intended DDI
+* clock frequency.
+*/
+ intel_de_write(i915, DDI_CLK_VALFREQ(encoder->port),
+ crtc_state->port_clock);
+}
+
+void intel_mtl_pll_enable(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state)
+{
+ struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
+
+ if (intel_tc_port_in_tbt_alt_mode(dig_port))
+ intel_mtl_tbt_pll_enable(encoder, crtc_state);
+ else
+ intel_cx0pll_enable(encoder, crtc_state);
+}
+
+static void intel_cx0pll_disable(struct intel_encoder *encoder)
{
struct drm_i915_private *i915 = to_i915(encoder->base.dev);
enum phy phy = intel_port_to_phy(i915, encoder->port);
@@ -2737,6 +2816,56 @@ void intel_cx0pll_disable(struct intel_encoder *encoder)
intel_cx0_phy_transaction_end(encoder, wakeref);
}
+static void intel_mtl_tbt_pll_disable(struct intel_encoder *encoder)
+{
+ struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+ enum phy phy = intel_port_to_phy(i915, encoder->port);
+
+
[Intel-gfx] [PATCH v2 11/13] drm/i915/mtl: TypeC HPD live status query
From: Imre Deak
The HPD live status for MTL has to be read from different set of
registers. MTL deserves a new function for this purpose
and cannot reuse the existing HPD live status detection
Reviewed-by: Matt Atwood
Signed-off-by: Anusha Srivatsa
Signed-off-by: Imre Deak
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/display/intel_tc.c | 30 -
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
b/drivers/gpu/drm/i915/display/intel_tc.c
index 951b12ac51dc..b192265a3d78 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -886,6 +886,34 @@ static const struct intel_tc_phy_ops adlp_tc_phy_ops = {
* XELPDP TC PHY handlers
* --
*/
+static u32 xelpdp_tc_phy_hpd_live_status(struct intel_tc_port *tc)
+{
+ struct drm_i915_private *i915 = tc_to_i915(tc);
+ struct intel_digital_port *dig_port = tc->dig_port;
+ enum hpd_pin hpd_pin = dig_port->base.hpd_pin;
+ u32 pica_isr_bits = i915->display.hotplug.hpd[hpd_pin];
+ u32 pch_isr_bit = i915->display.hotplug.pch_hpd[hpd_pin];
+ intel_wakeref_t wakeref;
+ u32 pica_isr;
+ u32 pch_isr;
+ u32 mask = 0;
+
+ with_intel_display_power(i915, POWER_DOMAIN_DISPLAY_CORE, wakeref) {
+ pica_isr = intel_de_read(i915, PICAINTERRUPT_ISR);
+ pch_isr = intel_de_read(i915, SDEISR);
+ }
+
+ if (pica_isr & (pica_isr_bits & XELPDP_DP_ALT_HOTPLUG_MASK))
+ mask |= BIT(TC_PORT_DP_ALT);
+ if (pica_isr & (pica_isr_bits & XELPDP_TBT_HOTPLUG_MASK))
+ mask |= BIT(TC_PORT_TBT_ALT);
+
+ if (tc->legacy_port && (pch_isr & pch_isr_bit))
+ mask |= BIT(TC_PORT_LEGACY);
+
+ return mask;
+}
+
static bool
xelpdp_tc_phy_tcss_power_is_enabled(struct intel_tc_port *tc)
{
@@ -1039,7 +1067,7 @@ static void xelpdp_tc_phy_disconnect(struct intel_tc_port
*tc)
static const struct intel_tc_phy_ops xelpdp_tc_phy_ops = {
.cold_off_domain = tgl_tc_phy_cold_off_domain,
- .hpd_live_status = adlp_tc_phy_hpd_live_status,
+ .hpd_live_status = xelpdp_tc_phy_hpd_live_status,
.is_ready = adlp_tc_phy_is_ready,
.is_owned = xelpdp_tc_phy_is_owned,
.get_hw_state = xelpdp_tc_phy_get_hw_state,
--
2.34.1
[Intel-gfx] [PATCH v2 08/13] drm/i915/mtl: Readout Thunderbolt HW state
Readout hw state for Thunderbolt.
Reviewed-by: Radhakrishna Sripada
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/display/intel_cx0_phy.c | 27
drivers/gpu/drm/i915/display/intel_cx0_phy.h | 2 +-
drivers/gpu/drm/i915/display/intel_ddi.c | 5 +++-
3 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index 7a2bf624eba7..2a364ae538f6 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -2685,6 +2685,33 @@ static void intel_cx0pll_enable(struct intel_encoder
*encoder,
intel_cx0_phy_transaction_end(encoder, wakeref);
}
+int intel_mtl_tbt_calc_port_clock(struct intel_encoder *encoder)
+{
+ struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+ u32 clock;
+ u32 val = intel_de_read(i915, XELPDP_PORT_CLOCK_CTL(encoder->port));
+
+ clock = REG_FIELD_GET(XELPDP_DDI_CLOCK_SELECT_MASK, val);
+
+ drm_WARN_ON(&i915->drm, !(val & XELPDP_FORWARD_CLOCK_UNGATE));
+ drm_WARN_ON(&i915->drm, !(val & XELPDP_TBT_CLOCK_REQUEST));
+ drm_WARN_ON(&i915->drm, !(val & XELPDP_TBT_CLOCK_ACK));
+
+ switch (clock) {
+ case XELPDP_DDI_CLOCK_SELECT_TBT_162:
+ return 162000;
+ case XELPDP_DDI_CLOCK_SELECT_TBT_270:
+ return 27;
+ case XELPDP_DDI_CLOCK_SELECT_TBT_540:
+ return 54;
+ case XELPDP_DDI_CLOCK_SELECT_TBT_810:
+ return 81;
+ default:
+ MISSING_CASE(clock);
+ return 162000;
+ }
+}
+
static int intel_mtl_tbt_clock_select(struct drm_i915_private *i915, int clock)
{
switch (clock) {
diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.h
b/drivers/gpu/drm/i915/display/intel_cx0_phy.h
index 9ea6310b6d79..c1b8f7980f69 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.h
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.h
@@ -42,5 +42,5 @@ int intel_cx0_phy_check_hdmi_link_rate(struct intel_hdmi
*hdmi, int clock);
void intel_cx0_phy_ddi_vswing_sequence(struct intel_encoder *encoder,
const struct intel_crtc_state
*crtc_state,
u32 level);
-int intel_mtl_tbt_readout_hw_state(struct intel_encoder *encoder);
+int intel_mtl_tbt_calc_port_clock(struct intel_encoder *encoder);
#endif /* __INTEL_CX0_PHY_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index c18226edacac..8f0f858cde31 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3852,8 +3852,11 @@ static void mtl_ddi_get_config(struct intel_encoder
*encoder,
{
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_is_c10phy(i915, phy)) {
+ 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_c10pll_readout_hw_state(encoder,
&crtc_state->cx0pll_state.c10);
intel_c10pll_dump_hw_state(i915, &crtc_state->cx0pll_state.c10);
crtc_state->port_clock = intel_c10pll_calc_port_clock(encoder,
&crtc_state->cx0pll_state.c10);
--
2.34.1
[Intel-gfx] [PATCH v2 13/13] drm/i915/mtl: Enable TC ports
Finally, we can enable TC ports for Meteorlake.
Reviewed-by: Clint Taylor
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/display/intel_display.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 0b9ae5759ffa..3d3483e6f836 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7336,9 +7336,12 @@ void intel_setup_outputs(struct drm_i915_private
*dev_priv)
return;
if (IS_METEORLAKE(dev_priv)) {
- /* TODO: initialize TC ports as well */
intel_ddi_init(dev_priv, PORT_A);
intel_ddi_init(dev_priv, PORT_B);
+ intel_ddi_init(dev_priv, PORT_TC1);
+ intel_ddi_init(dev_priv, PORT_TC2);
+ intel_ddi_init(dev_priv, PORT_TC3);
+ intel_ddi_init(dev_priv, PORT_TC4);
} else if (IS_DG2(dev_priv)) {
intel_ddi_init(dev_priv, PORT_A);
intel_ddi_init(dev_priv, PORT_B);
--
2.34.1
[Intel-gfx] [PATCH v2 12/13] drm/i915/mtl: Pin assignment for TypeC
From: Anusha Srivatsa
Unlike previous platforms that used PORT_TX_DFLEXDPSP
for max_lane calculation, MTL uses only PORT_TX_DFLEXPA1
from which the max_lanes has to be calculated.
Bspec: 50235, 65380
Reviewed-by: Matt Atwood
Signed-off-by: Anusha Srivatsa
Signed-off-by: Jose Roberto de Souza
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/display/intel_tc.c | 28 +
1 file changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
b/drivers/gpu/drm/i915/display/intel_tc.c
index b192265a3d78..4fca711a58bc 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -16,6 +16,10 @@
#include "intel_mg_phy_regs.h"
#include "intel_tc.h"
+#define DP_PIN_ASSIGNMENT_C0x3
+#define DP_PIN_ASSIGNMENT_D0x4
+#define DP_PIN_ASSIGNMENT_E0x5
+
enum tc_port_mode {
TC_PORT_DISCONNECTED,
TC_PORT_TBT_ALT,
@@ -281,6 +285,27 @@ u32 intel_tc_port_get_pin_assignment_mask(struct
intel_digital_port *dig_port)
DP_PIN_ASSIGNMENT_SHIFT(tc->phy_fia_idx);
}
+static int mtl_tc_port_get_pin_assignment_mask(struct intel_digital_port
*dig_port)
+{
+ struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
+ intel_wakeref_t wakeref;
+ u32 pin_mask;
+
+ with_intel_display_power(i915, POWER_DOMAIN_DISPLAY_CORE, wakeref)
+ pin_mask = intel_tc_port_get_pin_assignment_mask(dig_port);
+
+ switch (pin_mask) {
+ default:
+ MISSING_CASE(pin_mask);
+ fallthrough;
+ case DP_PIN_ASSIGNMENT_D:
+ return 2;
+ case DP_PIN_ASSIGNMENT_C:
+ case DP_PIN_ASSIGNMENT_E:
+ return 4;
+ }
+}
+
int intel_tc_port_fia_max_lane_count(struct intel_digital_port *dig_port)
{
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
@@ -294,6 +319,9 @@ int intel_tc_port_fia_max_lane_count(struct
intel_digital_port *dig_port)
assert_tc_cold_blocked(tc);
+ if (DISPLAY_VER(i915) >= 14)
+ return mtl_tc_port_get_pin_assignment_mask(dig_port);
+
lane_mask = 0;
with_intel_display_power(i915, POWER_DOMAIN_DISPLAY_CORE, wakeref)
lane_mask = intel_tc_port_get_lane_mask(dig_port);
--
2.34.1
[Intel-gfx] [PATCH v2 09/13] drm/i915/mtl: Define mask for DDI AUX interrupts
From: Gustavo Sousa
Xe_LPD+ defines interrupt bits for only DDI ports in the DE Port
Interrupt registers. The bits for Type-C ports are defined in the PICA
interrupt registers.
BSpec: 50064
Reviewed-by: Radhakrishna Sripada
Signed-off-by: Gustavo Sousa
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/i915_irq.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 2b94b8ca8ec9..e5f12aa141f6 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1938,7 +1938,10 @@ static u32 gen8_de_port_aux_mask(struct drm_i915_private
*dev_priv)
{
u32 mask;
- if (DISPLAY_VER(dev_priv) >= 13)
+ if (DISPLAY_VER(dev_priv) >= 14)
+ return TGL_DE_PORT_AUX_DDIA |
+ TGL_DE_PORT_AUX_DDIB;
+ else if (DISPLAY_VER(dev_priv) >= 13)
return TGL_DE_PORT_AUX_DDIA |
TGL_DE_PORT_AUX_DDIB |
TGL_DE_PORT_AUX_DDIC |
--
2.34.1
Re: [Intel-gfx] [RFC PATCH] x86/mm: Fix PAT bit missing from page protection modify mask
Hi Janusz,
On Mon, Apr 24, 2023 at 02:35:24PM +0200, Janusz Krzysztofik wrote:
> Visible glitches have been observed when running graphics applications on
> Linux under Xen hypervisor. Those observations have been confirmed with
> failures from kms_pwrite_crc Intel GPU test that verifies data coherency
> of DRM frame buffer objects using hardware CRC checksums calculated by
> display controllers, exposed to userspace via debugfs. Affected
> processing paths have then been identified with new test variants that
> mmap the objects using different methods and caching modes.
>
> When running as a Xen PV guest, Linux uses Xen provided PAT configuration
> which is different from its native one. In particular, Xen specific PTE
> encoding of write-combining caching, likely used by graphics applications,
> differs from the Linux default one found among statically defined minimal
> set of supported modes. Since Xen defines PTE encoding of the WC mode as
> _PAGE_PAT, it no longer belongs to the minimal set, depends on correct
> handling of _PAGE_PAT bit, and can be mismatched with write-back caching.
>
> When a user calls mmap() for a DRM buffer object, DRM device specific
> .mmap file operation, called from mmap_region(), takes care of setting PTE
> encoding bits in a vm_page_prot field of an associated virtual memory area
> structure. Unfortunately, _PAGE_PAT bit is not preserved when the vma's
> .vm_flags are then applied to .vm_page_prot via vm_set_page_prot(). Bits
> to be preserved are determined with _PAGE_CHG_MASK symbol that doesn't
> cover _PAGE_PAT. As a consequence, WB caching is requested instead of WC
> when running under Xen (also, WP is silently changed to WT, and UC
> downgraded to UC_MINUS). When running on bare metal, WC is not affected,
> but WP and WT extra modes are unintentionally replaced with WC and UC,
> respectively.
>
> WP and WT modes, encoded with _PAGE_PAT bit set, were introduced by commit
> 281d4078bec3 ("x86: Make page cache mode a real type"). Care was taken
> to extend _PAGE_CACHE_MASK symbol with that additional bit, but that
> symbol has never been used for identification of bits preserved when
> applying page protection flags. Support for all cache modes under Xen,
> including the problematic WC mode, was then introduced by commit
> 47591df50512 ("xen: Support Xen pv-domains using PAT").
>
> Extend bitmask used by pgprot_modify() for selecting bits to be preserved
> with _PAGE_PAT bit. However, since that bit can be reused as _PAGE_PSE,
> and the _PAGE_CHG_MASK symbol, primarly used by pte_modify(), is likely
> intentionally defined with that bit not set, keep that symbol unchanged.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7648
> Fixes: 281d4078bec3 ("x86: Make page cache mode a real type")
> Signed-off-by: Janusz Krzysztofik
> Cc: sta...@vger.kernel.org # v3.19+
> ---
> arch/x86/include/asm/pgtable.h | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
> index 7425f32e52932..f797f8da2e5b6 100644
> --- a/arch/x86/include/asm/pgtable.h
> +++ b/arch/x86/include/asm/pgtable.h
> @@ -654,8 +654,10 @@ static inline pmd_t pmd_modify(pmd_t pmd, pgprot_t
> newprot)
> #define pgprot_modify pgprot_modify
> static inline pgprot_t pgprot_modify(pgprot_t oldprot, pgprot_t newprot)
> {
> - pgprotval_t preservebits = pgprot_val(oldprot) & _PAGE_CHG_MASK;
> - pgprotval_t addbits = pgprot_val(newprot) & ~_PAGE_CHG_MASK;
> + unsigned long mask = _PAGE_CHG_MASK | _PAGE_CACHE_MASK;
nice catch!
Reviewed-by: Andi Shyti
Thanks,
Andi
> +
> + pgprotval_t preservebits = pgprot_val(oldprot) & mask;
> + pgprotval_t addbits = pgprot_val(newprot) & ~mask;
> return __pgprot(preservebits | addbits);
> }
>
> --
> 2.40.0
Re: [Intel-gfx] [PATCH 05/13] drm/i915/psr: Bring back HSW/BDW PSR AUX CH registers/setup
Hello,
Please check my inline comments below.
On Fri, 2023-04-21 at 15:02 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Reintroduce the special PSR AUX CH setup for hsw/bdw. Not all
> of it was even removed (BDW AUX data registers were left behind).
> Update the code to use REG_BIT() & co. while at it.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_dp_aux.c | 2 +-
> drivers/gpu/drm/i915/display/intel_dp_aux.h | 4 ++
> drivers/gpu/drm/i915/display/intel_psr.c | 61
> +++
> drivers/gpu/drm/i915/display/intel_psr_regs.h | 11
> 4 files changed, 77 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c
> b/drivers/gpu/drm/i915/display/intel_dp_aux.c
> index abf77ba76972..847fd6bfa7e4 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c
> @@ -14,7 +14,7 @@
> #include "intel_pps.h"
> #include "intel_tc.h"
>
> -static u32 intel_dp_aux_pack(const u8 *src, int src_bytes)
> +u32 intel_dp_aux_pack(const u8 *src, int src_bytes)
> {
> int i;
> u32 v = 0;
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.h
> b/drivers/gpu/drm/i915/display/intel_dp_aux.h
> index 138e340f94ee..3bc529a23dd6 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux.h
> @@ -6,6 +6,8 @@
> #ifndef __INTEL_DP_AUX_H__
> #define __INTEL_DP_AUX_H__
>
> +#include
> +
> enum aux_ch;
> struct intel_dp;
> struct intel_encoder;
> @@ -15,4 +17,6 @@ void intel_dp_aux_init(struct intel_dp *intel_dp);
>
> enum aux_ch intel_dp_aux_ch(struct intel_encoder *encoder);
>
> +u32 intel_dp_aux_pack(const u8 *src, int src_bytes);
> +
> #endif /* __INTEL_DP_AUX_H__ */
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 7f748c7a71f3..2ff6f75c2bee 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -288,6 +288,24 @@ static i915_reg_t psr_iir_reg(struct
> drm_i915_private *dev_priv,
> return EDP_PSR_IIR;
> }
>
> +static i915_reg_t psr_aux_ctl_reg(struct drm_i915_private *dev_priv,
> + enum transcoder cpu_transcoder)
> +{
> + if (DISPLAY_VER(dev_priv) >= 8)
> + return EDP_PSR_AUX_CTL(cpu_transcoder);
> + else
> + return HSW_SRD_AUX_CTL;
> +}
> +
> +static i915_reg_t psr_aux_data_reg(struct drm_i915_private
> *dev_priv,
> + enum transcoder cpu_transcoder,
> int i)
> +{
> + if (DISPLAY_VER(dev_priv) >= 8)
> + return EDP_PSR_AUX_DATA(cpu_transcoder, i);
> + else
> + return HSW_SRD_AUX_DATA(i);
> +}
> +
> static void psr_irq_control(struct intel_dp *intel_dp)
> {
> struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> @@ -512,6 +530,42 @@ void intel_psr_init_dpcd(struct intel_dp
> *intel_dp)
> }
> }
>
> +static void hsw_psr_setup_aux(struct intel_dp *intel_dp)
> +{
> + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> + enum transcoder cpu_transcoder = intel_dp->psr.transcoder;
> + u32 aux_clock_divider, aux_ctl;
> + static const u8 aux_msg[] = {
> + [0] = (DP_AUX_NATIVE_WRITE << 4) | ((DP_SET_POWER >>
> 16) & 0xf),
> + [1] = (DP_SET_POWER >> 8) & 0xff,
> + [2] = DP_SET_POWER & 0xff,
> + [3] = 1 - 1,
> + [4] = DP_SET_POWER_D0,
> + };
Could you please add some description or provide some pointer which
would help to parse what you are doing here?
> + int i;
> +
> + BUILD_BUG_ON(sizeof(aux_msg) > 20);
> + for (i = 0; i < sizeof(aux_msg); i += 4)
> + intel_de_write(dev_priv,
> + psr_aux_data_reg(dev_priv,
> cpu_transcoder, i >> 2),
> + intel_dp_aux_pack(&aux_msg[i],
> sizeof(aux_msg) - i));
> +
> + aux_clock_divider = intel_dp->get_aux_clock_divider(intel_dp,
> 0);
> +
> + /* Start with bits set for DDI_AUX_CTL register */
> + aux_ctl = intel_dp->get_aux_send_ctl(intel_dp,
> sizeof(aux_msg),
> + aux_clock_divider);
> +
> + /* Select only valid bits for SRD_AUX_CTL */
> + aux_ctl &= EDP_PSR_AUX_CTL_TIME_OUT_MASK |
> + EDP_PSR_AUX_CTL_MESSAGE_SIZE_MASK |
> + EDP_PSR_AUX_CTL_PRECHARGE_2US_MASK |
> + EDP_PSR_AUX_CTL_BIT_CLOCK_2X_MASK;
How about using definitions from
drivers/gpu/drm/i915/display/intel_dp_aux_regs.h? Or just refer these
being identical definitions to aux_send_ctl bits?
> +
> + intel_de_write(dev_priv, psr_aux_ctl_reg(dev_priv,
> cpu_transcoder),
> + aux_ctl);
> +}
> +
> static void intel_psr_enable_sink(struct intel_dp *intel_dp)
> {
> struct drm_i915_priva
Re: [Intel-gfx] [PATCH 08/13] drm/i915/psr: Implement WaPsrDPAMaskVBlankInSRD:hsw
On Fri, 2023-04-21 at 15:03 +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > Implement WaPsrDPAMaskVBlankInSRD:hsw, which makes the hardware > generate the extra vblank between link training and first frame > being transmitted. This is the same thing that's controlled by > TRANS_CHICKEN[21] on skl+ (but due to the funky double buffering > it's effectively always at the rest value after DC5 exit). So > for consistent behaviour we want every platform to generate said > vblank. BDW is already setting this up correctly. I couldn't find this from Bspec. I'll guess you have some offline documentation? WaPsrDPRSUnmaskVBlankInSRD seems to be in Bspec. > > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/intel_clock_gating.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_clock_gating.c > b/drivers/gpu/drm/i915/intel_clock_gating.c > index a27600bc5976..9682323510cd 100644 > --- a/drivers/gpu/drm/i915/intel_clock_gating.c > +++ b/drivers/gpu/drm/i915/intel_clock_gating.c > @@ -562,6 +562,9 @@ static void hsw_init_clock_gating(struct > drm_i915_private *i915) > /* WaFbcAsynchFlipDisableFbcQueue:hsw,bdw */ > intel_uncore_rmw(&i915->uncore, CHICKEN_PIPESL_1(PIPE_A), 0, > HSW_FBCQ_DIS); > > + /* WaPsrDPAMaskVBlankInSRD:hsw */ > + intel_uncore_rmw(&i915->uncore, CHICKEN_PAR1_1, 0, > HSW_MASK_VBL_TO_PIPE_IN_SRD); > + > /* This is required by WaCatErrorRejectionIssue:hsw */ > intel_uncore_rmw(&i915->uncore, > GEN7_SQ_CHICKEN_MBCUNIT_CONFIG, > 0, GEN7_SQ_CHICKEN_MBCUNIT_SQINTMOB); BR, Jouni Högander
Re: [Intel-gfx] [PATCH 08/13] drm/i915/psr: Implement WaPsrDPAMaskVBlankInSRD:hsw
On Fri, Apr 28, 2023 at 10:36:17AM +, Hogander, Jouni wrote: > On Fri, 2023-04-21 at 15:03 +0300, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Implement WaPsrDPAMaskVBlankInSRD:hsw, which makes the hardware > > generate the extra vblank between link training and first frame > > being transmitted. This is the same thing that's controlled by > > TRANS_CHICKEN[21] on skl+ (but due to the funky double buffering > > it's effectively always at the rest value after DC5 exit). So > > for consistent behaviour we want every platform to generate said > > vblank. BDW is already setting this up correctly. > > I couldn't find this from Bspec. I'll guess you have some offline > documentation? WaPsrDPRSUnmaskVBlankInSRD seems to be in Bspec. Bspec has lost the human readable name at some point. It's still there though as w/a #0503. > > > > > Signed-off-by: Ville Syrjälä > > --- > > drivers/gpu/drm/i915/intel_clock_gating.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/intel_clock_gating.c > > b/drivers/gpu/drm/i915/intel_clock_gating.c > > index a27600bc5976..9682323510cd 100644 > > --- a/drivers/gpu/drm/i915/intel_clock_gating.c > > +++ b/drivers/gpu/drm/i915/intel_clock_gating.c > > @@ -562,6 +562,9 @@ static void hsw_init_clock_gating(struct > > drm_i915_private *i915) > > /* WaFbcAsynchFlipDisableFbcQueue:hsw,bdw */ > > intel_uncore_rmw(&i915->uncore, CHICKEN_PIPESL_1(PIPE_A), 0, > > HSW_FBCQ_DIS); > > > > + /* WaPsrDPAMaskVBlankInSRD:hsw */ > > + intel_uncore_rmw(&i915->uncore, CHICKEN_PAR1_1, 0, > > HSW_MASK_VBL_TO_PIPE_IN_SRD); > > + > > /* This is required by WaCatErrorRejectionIssue:hsw */ > > intel_uncore_rmw(&i915->uncore, > > GEN7_SQ_CHICKEN_MBCUNIT_CONFIG, > > 0, GEN7_SQ_CHICKEN_MBCUNIT_SQINTMOB); > > BR, > > Jouni Högander -- Ville Syrjälä Intel
Re: [Intel-gfx] [PATCH 05/13] drm/i915/psr: Bring back HSW/BDW PSR AUX CH registers/setup
On Fri, Apr 28, 2023 at 10:18:34AM +, Hogander, Jouni wrote:
> Hello,
>
> Please check my inline comments below.
>
> On Fri, 2023-04-21 at 15:02 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Reintroduce the special PSR AUX CH setup for hsw/bdw. Not all
> > of it was even removed (BDW AUX data registers were left behind).
> > Update the code to use REG_BIT() & co. while at it.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/display/intel_dp_aux.c | 2 +-
> > drivers/gpu/drm/i915/display/intel_dp_aux.h | 4 ++
> > drivers/gpu/drm/i915/display/intel_psr.c | 61
> > +++
> > drivers/gpu/drm/i915/display/intel_psr_regs.h | 11
> > 4 files changed, 77 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c
> > b/drivers/gpu/drm/i915/display/intel_dp_aux.c
> > index abf77ba76972..847fd6bfa7e4 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_aux.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c
> > @@ -14,7 +14,7 @@
> > #include "intel_pps.h"
> > #include "intel_tc.h"
> >
> > -static u32 intel_dp_aux_pack(const u8 *src, int src_bytes)
> > +u32 intel_dp_aux_pack(const u8 *src, int src_bytes)
> > {
> > int i;
> > u32 v = 0;
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.h
> > b/drivers/gpu/drm/i915/display/intel_dp_aux.h
> > index 138e340f94ee..3bc529a23dd6 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_aux.h
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux.h
> > @@ -6,6 +6,8 @@
> > #ifndef __INTEL_DP_AUX_H__
> > #define __INTEL_DP_AUX_H__
> >
> > +#include
> > +
> > enum aux_ch;
> > struct intel_dp;
> > struct intel_encoder;
> > @@ -15,4 +17,6 @@ void intel_dp_aux_init(struct intel_dp *intel_dp);
> >
> > enum aux_ch intel_dp_aux_ch(struct intel_encoder *encoder);
> >
> > +u32 intel_dp_aux_pack(const u8 *src, int src_bytes);
> > +
> > #endif /* __INTEL_DP_AUX_H__ */
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > b/drivers/gpu/drm/i915/display/intel_psr.c
> > index 7f748c7a71f3..2ff6f75c2bee 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -288,6 +288,24 @@ static i915_reg_t psr_iir_reg(struct
> > drm_i915_private *dev_priv,
> > return EDP_PSR_IIR;
> > }
> >
> > +static i915_reg_t psr_aux_ctl_reg(struct drm_i915_private *dev_priv,
> > + enum transcoder cpu_transcoder)
> > +{
> > + if (DISPLAY_VER(dev_priv) >= 8)
> > + return EDP_PSR_AUX_CTL(cpu_transcoder);
> > + else
> > + return HSW_SRD_AUX_CTL;
> > +}
> > +
> > +static i915_reg_t psr_aux_data_reg(struct drm_i915_private
> > *dev_priv,
> > + enum transcoder cpu_transcoder,
> > int i)
> > +{
> > + if (DISPLAY_VER(dev_priv) >= 8)
> > + return EDP_PSR_AUX_DATA(cpu_transcoder, i);
> > + else
> > + return HSW_SRD_AUX_DATA(i);
> > +}
> > +
> > static void psr_irq_control(struct intel_dp *intel_dp)
> > {
> > struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > @@ -512,6 +530,42 @@ void intel_psr_init_dpcd(struct intel_dp
> > *intel_dp)
> > }
> > }
> >
> > +static void hsw_psr_setup_aux(struct intel_dp *intel_dp)
> > +{
> > + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > + enum transcoder cpu_transcoder = intel_dp->psr.transcoder;
> > + u32 aux_clock_divider, aux_ctl;
> > + static const u8 aux_msg[] = {
> > + [0] = (DP_AUX_NATIVE_WRITE << 4) | ((DP_SET_POWER >>
> > 16) & 0xf),
> > + [1] = (DP_SET_POWER >> 8) & 0xff,
> > + [2] = DP_SET_POWER & 0xff,
> > + [3] = 1 - 1,
> > + [4] = DP_SET_POWER_D0,
> > + };
>
> Could you please add some description or provide some pointer which
> would help to parse what you are doing here?
It's just crafting a DP_SET_POWER=D0 DPCD write by hand.
I was thinking of refactoring the AUX msg packing code
to make thig something like
struct drm_dp_aux_msg {
...
};
intel_dp_aux_pack_msg(msg)
but that would require some actual though so not something
I want to do in this patch. So for now I just restored
this to (more or less) what we had before.
>
> > + int i;
> > +
> > + BUILD_BUG_ON(sizeof(aux_msg) > 20);
> > + for (i = 0; i < sizeof(aux_msg); i += 4)
> > + intel_de_write(dev_priv,
> > + psr_aux_data_reg(dev_priv,
> > cpu_transcoder, i >> 2),
> > + intel_dp_aux_pack(&aux_msg[i],
> > sizeof(aux_msg) - i));
> > +
> > + aux_clock_divider = intel_dp->get_aux_clock_divider(intel_dp,
> > 0);
> > +
> > + /* Start with bits set for DDI_AUX_CTL register */
> > + aux_ctl = intel_dp->get_aux_send_ctl(intel_dp,
> > sizeof(aux_msg),
> > +
Re: [Intel-gfx] [PATCH v2] drm/i915/dsi: Use unconditional msleep() instead of intel_dsi_msleep()
On Tue, Apr 25, 2023 at 09:44:41PM +0200, Hans de Goede wrote:
> The intel_dsi_msleep() helper skips sleeping if the MIPI-sequences have
> a version of 3 or newer and the panel is in vid-mode.
>
> This is based on the big comment around line 730 which starts with
> "Panel enable/disable sequences from the VBT spec.", where
> the "v3 video mode seq" column does not have any wait t# entries.
>
> Checking the Windows driver shows that it does always honor
> the VBT delays independent of the version of the VBT sequences.
>
> Commit 6fdb335f1c9c ("drm/i915/dsi: Use unconditional msleep for
> the panel_on_delay when there is no reset-deassert MIPI-sequence")
> switched to a direct msleep() instead of intel_dsi_msleep()
> when there is no MIPI_SEQ_DEASSERT_RESET sequence, to fix
> the panel on an Acer Aspire Switch 10 E SW3-016 not turning on.
>
> And now testing on a Nextbook Ares 8A shows that panel_on_delay
> must always be honored otherwise the panel will not turn on.
>
> Instead of only always using regular msleep() for panel_on_delay
> do as Windows does and always use regular msleep() everywhere
> were intel_dsi_msleep() is used and drop the intel_dsi_msleep()
> helper.
>
> Changes in v2:
> - Replace all intel_dsi_msleep() calls instead of just
> the intel_dsi_msleep(panel_on_delay) call
>
> Fixes: 6fdb335f1c9c ("drm/i915/dsi: Use unconditional msleep for the
> panel_on_delay when there is no reset-deassert MIPI-sequence")
> Signed-off-by: Hans de Goede
Thanks. Added cc:stable and pushed to drm-intel-next.
> ---
> drivers/gpu/drm/i915/display/icl_dsi.c | 2 +-
> drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 11 --
> drivers/gpu/drm/i915/display/intel_dsi_vbt.h | 1 -
> drivers/gpu/drm/i915/display/vlv_dsi.c | 22 +---
> 4 files changed, 6 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> b/drivers/gpu/drm/i915/display/icl_dsi.c
> index fc0eaf40dc94..6dd942522021 100644
> --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> @@ -1211,7 +1211,7 @@ static void gen11_dsi_powerup_panel(struct
> intel_encoder *encoder)
>
> /* panel power on related mipi dsi vbt sequences */
> intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_POWER_ON);
> - intel_dsi_msleep(intel_dsi, intel_dsi->panel_on_delay);
> + msleep(intel_dsi->panel_on_delay);
> intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET);
> intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_INIT_OTP);
> intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_DISPLAY_ON);
> diff --git a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
> b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
> index 2cbc1292ab38..f102c13cb959 100644
> --- a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
> +++ b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
> @@ -762,17 +762,6 @@ void intel_dsi_vbt_exec_sequence(struct intel_dsi
> *intel_dsi,
> gpiod_set_value_cansleep(intel_dsi->gpio_backlight, 0);
> }
>
> -void intel_dsi_msleep(struct intel_dsi *intel_dsi, int msec)
> -{
> - struct intel_connector *connector = intel_dsi->attached_connector;
> -
> - /* For v3 VBTs in vid-mode the delays are part of the VBT sequences */
> - if (is_vid_mode(intel_dsi) && connector->panel.vbt.dsi.seq_version >= 3)
> - return;
> -
> - msleep(msec);
> -}
> -
> void intel_dsi_log_params(struct intel_dsi *intel_dsi)
> {
> struct drm_i915_private *i915 = to_i915(intel_dsi->base.base.dev);
> diff --git a/drivers/gpu/drm/i915/display/intel_dsi_vbt.h
> b/drivers/gpu/drm/i915/display/intel_dsi_vbt.h
> index dc642c1fe7ef..468d873fab1a 100644
> --- a/drivers/gpu/drm/i915/display/intel_dsi_vbt.h
> +++ b/drivers/gpu/drm/i915/display/intel_dsi_vbt.h
> @@ -16,7 +16,6 @@ void intel_dsi_vbt_gpio_init(struct intel_dsi *intel_dsi,
> bool panel_is_on);
> void intel_dsi_vbt_gpio_cleanup(struct intel_dsi *intel_dsi);
> void intel_dsi_vbt_exec_sequence(struct intel_dsi *intel_dsi,
>enum mipi_seq seq_id);
> -void intel_dsi_msleep(struct intel_dsi *intel_dsi, int msec);
> void intel_dsi_log_params(struct intel_dsi *intel_dsi);
>
> #endif /* __INTEL_DSI_VBT_H__ */
> diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c
> b/drivers/gpu/drm/i915/display/vlv_dsi.c
> index 2289f6b1b4eb..37efeab52581 100644
> --- a/drivers/gpu/drm/i915/display/vlv_dsi.c
> +++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
> @@ -783,7 +783,6 @@ static void intel_dsi_pre_enable(struct
> intel_atomic_state *state,
> {
> struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder);
> struct intel_crtc *crtc = to_intel_crtc(pipe_config->uapi.crtc);
> - struct intel_connector *connector =
> to_intel_connector(conn_state->connector);
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> enum pipe pipe = crtc->pipe;
> enum port port;
> @@ -831,21 +830,10 @@ static void int
Re: [Intel-gfx] [PATCH 13/13] drm/i915/psr: Re-enable PSR1 on hdw/bdw
On Fri, 2023-04-21 at 15:03 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> All known issues fixed now, so re-enable PSR1 on hsw/bdw.
Please note s/hdw/hsw/ in subject.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_pci.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c
> b/drivers/gpu/drm/i915/i915_pci.c
> index 272a8ba37b64..923e24044967 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -562,6 +562,8 @@ static const struct intel_device_info vlv_info =
> {
> BIT(TRANSCODER_C) | BIT(TRANSCODER_EDP), \
> .display.has_ddi = 1, \
> .display.has_fpga_dbg = 1, \
> + .display.has_psr = 1, \
> + .display.has_psr_hw_tracking = 1, \
Isn't this has_psr_hw_tracking about PSR2 with hw tracking mechanism in
e.g. ICL? See Bspec: 4289. More recent platforms have manual tracking
mechanism. In TGL there were both.
> .display.has_dp_mst = 1, \
> .has_rc6p = 0 /* RC6p removed-by HSW */, \
> HSW_PIPE_OFFSETS, \
> @@ -665,8 +667,6 @@ static const struct intel_device_info chv_info =
> {
> .has_gt_uc = 1, \
> .__runtime.has_hdcp = 1, \
> .display.has_ipc = 1, \
> - .display.has_psr = 1, \
> - .display.has_psr_hw_tracking = 1, \
> .display.dbuf.size = 896 - 4, /* 4 blocks for bypass path
> allocation */ \
> .display.dbuf.slice_mask = BIT(DBUF_S1)
>
BR,
Jouni Högander
Re: [Intel-gfx] [PATCH 08/13] drm/i915/psr: Implement WaPsrDPAMaskVBlankInSRD:hsw
On Fri, 2023-04-28 at 13:55 +0300, Ville Syrjälä wrote: > On Fri, Apr 28, 2023 at 10:36:17AM +, Hogander, Jouni wrote: > > On Fri, 2023-04-21 at 15:03 +0300, Ville Syrjala wrote: > > > From: Ville Syrjälä > > > > > > Implement WaPsrDPAMaskVBlankInSRD:hsw, which makes the hardware > > > generate the extra vblank between link training and first frame > > > being transmitted. This is the same thing that's controlled by > > > TRANS_CHICKEN[21] on skl+ (but due to the funky double buffering > > > it's effectively always at the rest value after DC5 exit). So > > > for consistent behaviour we want every platform to generate said > > > vblank. BDW is already setting this up correctly. > > > > I couldn't find this from Bspec. I'll guess you have some offline > > documentation? WaPsrDPRSUnmaskVBlankInSRD seems to be in Bspec. > > Bspec has lost the human readable name at some point. > It's still there though as w/a #0503. Ok, found it now. Thank you for pointing it out. > > > > > > > > > Signed-off-by: Ville Syrjälä > > > --- > > > drivers/gpu/drm/i915/intel_clock_gating.c | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/drivers/gpu/drm/i915/intel_clock_gating.c > > > b/drivers/gpu/drm/i915/intel_clock_gating.c > > > index a27600bc5976..9682323510cd 100644 > > > --- a/drivers/gpu/drm/i915/intel_clock_gating.c > > > +++ b/drivers/gpu/drm/i915/intel_clock_gating.c > > > @@ -562,6 +562,9 @@ static void hsw_init_clock_gating(struct > > > drm_i915_private *i915) > > > /* WaFbcAsynchFlipDisableFbcQueue:hsw,bdw */ > > > intel_uncore_rmw(&i915->uncore, CHICKEN_PIPESL_1(PIPE_A), > > > 0, > > > HSW_FBCQ_DIS); > > > > > > + /* WaPsrDPAMaskVBlankInSRD:hsw */ > > > + intel_uncore_rmw(&i915->uncore, CHICKEN_PAR1_1, 0, > > > HSW_MASK_VBL_TO_PIPE_IN_SRD); > > > + > > > /* This is required by WaCatErrorRejectionIssue:hsw */ > > > intel_uncore_rmw(&i915->uncore, > > > GEN7_SQ_CHICKEN_MBCUNIT_CONFIG, > > > 0, GEN7_SQ_CHICKEN_MBCUNIT_SQINTMOB); > > > > BR, > > > > Jouni Högander >
Re: [Intel-gfx] [PATCH 05/13] drm/i915/psr: Bring back HSW/BDW PSR AUX CH registers/setup
On Fri, 2023-04-28 at 14:03 +0300, Ville Syrjälä wrote:
> On Fri, Apr 28, 2023 at 10:18:34AM +, Hogander, Jouni wrote:
> > Hello,
> >
> > Please check my inline comments below.
> >
> > On Fri, 2023-04-21 at 15:02 +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Reintroduce the special PSR AUX CH setup for hsw/bdw. Not all
> > > of it was even removed (BDW AUX data registers were left behind).
> > > Update the code to use REG_BIT() & co. while at it.
> > >
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/i915/display/intel_dp_aux.c | 2 +-
> > > drivers/gpu/drm/i915/display/intel_dp_aux.h | 4 ++
> > > drivers/gpu/drm/i915/display/intel_psr.c | 61
> > > +++
> > > drivers/gpu/drm/i915/display/intel_psr_regs.h | 11
> > > 4 files changed, 77 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c
> > > b/drivers/gpu/drm/i915/display/intel_dp_aux.c
> > > index abf77ba76972..847fd6bfa7e4 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp_aux.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c
> > > @@ -14,7 +14,7 @@
> > > #include "intel_pps.h"
> > > #include "intel_tc.h"
> > >
> > > -static u32 intel_dp_aux_pack(const u8 *src, int src_bytes)
> > > +u32 intel_dp_aux_pack(const u8 *src, int src_bytes)
> > > {
> > > int i;
> > > u32 v = 0;
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.h
> > > b/drivers/gpu/drm/i915/display/intel_dp_aux.h
> > > index 138e340f94ee..3bc529a23dd6 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp_aux.h
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux.h
> > > @@ -6,6 +6,8 @@
> > > #ifndef __INTEL_DP_AUX_H__
> > > #define __INTEL_DP_AUX_H__
> > >
> > > +#include
> > > +
> > > enum aux_ch;
> > > struct intel_dp;
> > > struct intel_encoder;
> > > @@ -15,4 +17,6 @@ void intel_dp_aux_init(struct intel_dp
> > > *intel_dp);
> > >
> > > enum aux_ch intel_dp_aux_ch(struct intel_encoder *encoder);
> > >
> > > +u32 intel_dp_aux_pack(const u8 *src, int src_bytes);
> > > +
> > > #endif /* __INTEL_DP_AUX_H__ */
> > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > > b/drivers/gpu/drm/i915/display/intel_psr.c
> > > index 7f748c7a71f3..2ff6f75c2bee 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > > @@ -288,6 +288,24 @@ static i915_reg_t psr_iir_reg(struct
> > > drm_i915_private *dev_priv,
> > > return EDP_PSR_IIR;
> > > }
> > >
> > > +static i915_reg_t psr_aux_ctl_reg(struct drm_i915_private
> > > *dev_priv,
> > > + enum transcoder cpu_transcoder)
> > > +{
> > > + if (DISPLAY_VER(dev_priv) >= 8)
> > > + return EDP_PSR_AUX_CTL(cpu_transcoder);
> > > + else
> > > + return HSW_SRD_AUX_CTL;
> > > +}
> > > +
> > > +static i915_reg_t psr_aux_data_reg(struct drm_i915_private
> > > *dev_priv,
> > > + enum transcoder
> > > cpu_transcoder,
> > > int i)
> > > +{
> > > + if (DISPLAY_VER(dev_priv) >= 8)
> > > + return EDP_PSR_AUX_DATA(cpu_transcoder, i);
> > > + else
> > > + return HSW_SRD_AUX_DATA(i);
> > > +}
> > > +
> > > static void psr_irq_control(struct intel_dp *intel_dp)
> > > {
> > > struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > > @@ -512,6 +530,42 @@ void intel_psr_init_dpcd(struct intel_dp
> > > *intel_dp)
> > > }
> > > }
> > >
> > > +static void hsw_psr_setup_aux(struct intel_dp *intel_dp)
> > > +{
> > > + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > > + enum transcoder cpu_transcoder = intel_dp-
> > > >psr.transcoder;
> > > + u32 aux_clock_divider, aux_ctl;
> > > + static const u8 aux_msg[] = {
> > > + [0] = (DP_AUX_NATIVE_WRITE << 4) | ((DP_SET_POWER
> > > >>
> > > 16) & 0xf),
> > > + [1] = (DP_SET_POWER >> 8) & 0xff,
> > > + [2] = DP_SET_POWER & 0xff,
> > > + [3] = 1 - 1,
> > > + [4] = DP_SET_POWER_D0,
> > > + };
> >
> > Could you please add some description or provide some pointer which
> > would help to parse what you are doing here?
>
> It's just crafting a DP_SET_POWER=D0 DPCD write by hand.
>
> I was thinking of refactoring the AUX msg packing code
> to make thig something like
> struct drm_dp_aux_msg {
> ...
> };
> intel_dp_aux_pack_msg(msg)
> but that would require some actual though so not something
> I want to do in this patch. So for now I just restored
> this to (more or less) what we had before.
Ok, that is fine.
>
> >
> > > + int i;
> > > +
> > > + BUILD_BUG_ON(sizeof(aux_msg) > 20);
> > > + for (i = 0; i < sizeof(aux_msg); i += 4)
> > > + intel_de_write(dev_priv,
> > > + psr_aux_data_reg(dev_priv,
> > > cpu_transcoder, i >> 2),
Re: [Intel-gfx] [PATCH v8 0/2] drm/i915: Hugepage manager and test for MTL
On 26.04.2023 23:28, Andrzej Hajda wrote: This patchset patches sent by Jonathan and Andi, with addressed CI failures: 1. Fixed checking alignment of 64K pages on both Pre-Gen12 and Gen12. 2. Fixed start alignment of 2M pages. Regards Andrzej Jonathan Cavitt (2): drm/i915: Migrate platform-dependent mock hugepage selftests to live drm/i915: Use correct huge page manager for MTL .../gpu/drm/i915/gem/selftests/huge_pages.c | 88 +++ drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 3 +- 2 files changed, 71 insertions(+), 20 deletions(-) Cc: intel-gfx@lists.freedesktop.org Cc: linux-ker...@vger.kernel.org Cc: Jonathan Cavitt Cc: Andrzej Hajda Cc: Matthew Auld Thx for comments, pushed. Regards Andrzej
Re: [Intel-gfx] [PATCH 13/13] drm/i915/psr: Re-enable PSR1 on hdw/bdw
On Fri, Apr 28, 2023 at 11:19:39AM +, Hogander, Jouni wrote:
> On Fri, 2023-04-21 at 15:03 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > All known issues fixed now, so re-enable PSR1 on hsw/bdw.
>
> Please note s/hdw/hsw/ in subject.
>
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/i915_pci.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_pci.c
> > b/drivers/gpu/drm/i915/i915_pci.c
> > index 272a8ba37b64..923e24044967 100644
> > --- a/drivers/gpu/drm/i915/i915_pci.c
> > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > @@ -562,6 +562,8 @@ static const struct intel_device_info vlv_info =
> > {
> > BIT(TRANSCODER_C) | BIT(TRANSCODER_EDP), \
> > .display.has_ddi = 1, \
> > .display.has_fpga_dbg = 1, \
> > + .display.has_psr = 1, \
> > + .display.has_psr_hw_tracking = 1, \
>
> Isn't this has_psr_hw_tracking about PSR2 with hw tracking mechanism in
> e.g. ICL? See Bspec: 4289. More recent platforms have manual tracking
> mechanism. In TGL there were both.
I have no idea what people meant by hw tracking in this context.
psr_force_hw_tracking_exit() is the thing that does the
CURSURFLIVE write to force PSR exit/etc. and that is used for
PSR1 and PSR2. So someone should properly document what this is
supposed to indicate, and rename either that function or this
flag to refelct reality.
>
> > .display.has_dp_mst = 1, \
> > .has_rc6p = 0 /* RC6p removed-by HSW */, \
> > HSW_PIPE_OFFSETS, \
> > @@ -665,8 +667,6 @@ static const struct intel_device_info chv_info =
> > {
> > .has_gt_uc = 1, \
> > .__runtime.has_hdcp = 1, \
> > .display.has_ipc = 1, \
> > - .display.has_psr = 1, \
> > - .display.has_psr_hw_tracking = 1, \
> > .display.dbuf.size = 896 - 4, /* 4 blocks for bypass path
> > allocation */ \
> > .display.dbuf.slice_mask = BIT(DBUF_S1)
> >
>
> BR,
>
> Jouni Högander
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [RFC PATCH] x86/mm: Fix PAT bit missing from page protection modify mask
Hi Janusz, On Mon, Apr 24, 2023 at 02:35:24PM +0200, Janusz Krzysztofik wrote: > Visible glitches have been observed when running graphics applications on > Linux under Xen hypervisor. Those observations have been confirmed with > failures from kms_pwrite_crc Intel GPU test that verifies data coherency > of DRM frame buffer objects using hardware CRC checksums calculated by > display controllers, exposed to userspace via debugfs. Affected > processing paths have then been identified with new test variants that > mmap the objects using different methods and caching modes. BTW, are you going to update those tests in IGT? Andi
Re: [Intel-gfx] [PATCH 13/13] drm/i915/psr: Re-enable PSR1 on hdw/bdw
On Fri, 2023-04-28 at 14:36 +0300, Ville Syrjälä wrote:
> On Fri, Apr 28, 2023 at 11:19:39AM +, Hogander, Jouni wrote:
> > On Fri, 2023-04-21 at 15:03 +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > All known issues fixed now, so re-enable PSR1 on hsw/bdw.
> >
> > Please note s/hdw/hsw/ in subject.
> >
> > >
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/i915/i915_pci.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_pci.c
> > > b/drivers/gpu/drm/i915/i915_pci.c
> > > index 272a8ba37b64..923e24044967 100644
> > > --- a/drivers/gpu/drm/i915/i915_pci.c
> > > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > > @@ -562,6 +562,8 @@ static const struct intel_device_info
> > > vlv_info =
> > > {
> > > BIT(TRANSCODER_C) | BIT(TRANSCODER_EDP), \
> > > .display.has_ddi = 1, \
> > > .display.has_fpga_dbg = 1, \
> > > + .display.has_psr = 1, \
> > > + .display.has_psr_hw_tracking = 1, \
> >
> > Isn't this has_psr_hw_tracking about PSR2 with hw tracking
> > mechanism in
> > e.g. ICL? See Bspec: 4289. More recent platforms have manual
> > tracking
> > mechanism. In TGL there were both.
>
> I have no idea what people meant by hw tracking in this context.
> psr_force_hw_tracking_exit() is the thing that does the
> CURSURFLIVE write to force PSR exit/etc. and that is used for
> PSR1 and PSR2. So someone should properly document what this is
> supposed to indicate, and rename either that function or this
> flag to refelct reality.
Ok, anyways this variable seems to be taken into account only in PSR2
context so this should not cause any problems either.
>
> >
> > > .display.has_dp_mst = 1, \
> > > .has_rc6p = 0 /* RC6p removed-by HSW */, \
> > > HSW_PIPE_OFFSETS, \
> > > @@ -665,8 +667,6 @@ static const struct intel_device_info
> > > chv_info =
> > > {
> > > .has_gt_uc = 1, \
> > > .__runtime.has_hdcp = 1, \
> > > .display.has_ipc = 1, \
> > > - .display.has_psr = 1, \
> > > - .display.has_psr_hw_tracking = 1, \
> > > .display.dbuf.size = 896 - 4, /* 4 blocks for bypass path
> > > allocation */ \
> > > .display.dbuf.slice_mask = BIT(DBUF_S1)
> > >
> >
> > BR,
> >
> > Jouni Högander
>
Re: [Intel-gfx] [PATCH v4 2/9] vfio-iommufd: Create iommufd_access for noiommu devices
On Fri, Apr 28, 2023 at 02:21:26PM +0800, Yi Liu wrote: > but this patch needs to use vfio_iommufd_emulated_bind() and > vfio_iommufd_emulated_unbind() for the noiommu devices when binding > to iommufd. So needs to check noiommu in the vfio_iommufd_bind() > and vfio_iommu_unbind() as well. I'm not sure this is strictly necessary, it just needs an access The emulated stuff is for mdev only, it should not be confused with no-iommu Eg if you had a no_iommu_access value to store the access it would be fine and could serve as the 'this is no_iommu' flag The only purpose of the access at this moment is to get an iommufdctx id to return to userspace. Jason
[Intel-gfx] [RFC PATCH] dma-buf/dma-fence: Use a successful read_trylock() annotation for dma_fence_begin_signalling()
Condsider the following call sequence: /* Upper layer */ dma_fence_begin_signalling(); lock(tainted_shared_lock); /* Driver callback */ dma_fence_begin_signalling(); ... The driver might here use a utility that is annotated as intended for the dma-fence signalling critical path. Now if the upper layer isn't correctly annotated yet for whatever reason, resulting in /* Upper layer */ lock(tainted_shared_lock); /* Driver callback */ dma_fence_begin_signalling(); We will receive a false lockdep locking order violation notification from dma_fence_begin_signalling(). However entering a dma-fence signalling critical section itself doesn't block and could not cause a deadlock. So use a successful read_trylock() annotation instead for dma_fence_begin_signalling(). That will make sure that the locking order is correctly registered in the first case, and doesn't register any locking order in the second case. The alternative is of course to make sure that the "Upper layer" is always correctly annotated. But experience shows that's not easily achievable in all cases. Signed-off-by: Thomas Hellström --- drivers/dma-buf/dma-fence.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c index f177c56269bb..17f632768ef9 100644 --- a/drivers/dma-buf/dma-fence.c +++ b/drivers/dma-buf/dma-fence.c @@ -308,8 +308,8 @@ bool dma_fence_begin_signalling(void) if (in_atomic()) return true; - /* ... and non-recursive readlock */ - lock_acquire(&dma_fence_lockdep_map, 0, 0, 1, 1, NULL, _RET_IP_); + /* ... and non-recursive successful read_trylock */ + lock_acquire(&dma_fence_lockdep_map, 0, 1, 1, 1, NULL, _RET_IP_); return false; } @@ -340,7 +340,7 @@ void __dma_fence_might_wait(void) lock_map_acquire(&dma_fence_lockdep_map); lock_map_release(&dma_fence_lockdep_map); if (tmp) - lock_acquire(&dma_fence_lockdep_map, 0, 0, 1, 1, NULL, _THIS_IP_); + lock_acquire(&dma_fence_lockdep_map, 0, 1, 1, 1, NULL, _THIS_IP_); } #endif -- 2.39.2
[Intel-gfx] [PATCH 1/2] drm/i915/gt: Use gt_err for GT info
It will be more informative regarding
GT if we use gt_err instead.
Cc: Andi Shyti
Signed-off-by: Tejas Upadhyay
---
drivers/gpu/drm/i915/gt/selftest_engine_pm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
b/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
index 87c94314cf67..10e556a7eac4 100644
--- a/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
@@ -5,6 +5,7 @@
#include
+#include "gt/intel_gt_print.h"
#include "i915_selftest.h"
#include "intel_engine_regs.h"
#include "intel_gpu_commands.h"
@@ -402,7 +403,7 @@ static int live_engine_pm(void *arg)
/* gt wakeref is async (deferred to workqueue) */
if (intel_gt_pm_wait_for_idle(gt)) {
- pr_err("GT failed to idle\n");
+ gt_err(gt, "GT failed to idle\n");
return -EINVAL;
}
}
--
2.25.1
[Intel-gfx] [PATCH 2/2] drm/i915/selftests: Use gt_err for GT info
It will be more informative regarding
GT if we use gt_err instead.
Cc: Andi Shyti
Signed-off-by: Tejas Upadhyay
---
drivers/gpu/drm/i915/selftests/i915_gem_evict.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_evict.c
b/drivers/gpu/drm/i915/selftests/i915_gem_evict.c
index 37068542aafe..f68ef4074088 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_evict.c
@@ -27,6 +27,7 @@
#include "gem/selftests/igt_gem_utils.h"
#include "gem/selftests/mock_context.h"
#include "gt/intel_gt.h"
+#include "gt/intel_gt_print.h"
#include "i915_selftest.h"
@@ -507,7 +508,8 @@ static int igt_evict_contexts(void *arg)
}
err = intel_gt_wait_for_idle(engine->gt, HZ * 3);
if (err) {
- pr_err("Failed to idle GT (on %s)", engine->name);
+ gt_err(engine->gt, "Failed to idle GT (on %s)",
+ engine->name);
break;
}
}
--
2.25.1
[Intel-gfx] [PATCH 0/2] drm/i915: Use gt_err inplace of pr_err
When we use gt_err we get GT info when that failure hits which helps in debugging. Cc: Andi Shyti Signed-off-by: Tejas Upadhyay Tejas Upadhyay (2): drm/i915/gt: Use gt_err for GT info drm/i915/selftests: Use gt_err for GT info drivers/gpu/drm/i915/gt/selftest_engine_pm.c| 3 ++- drivers/gpu/drm/i915/selftests/i915_gem_evict.c | 4 +++- 2 files changed, 5 insertions(+), 2 deletions(-) -- 2.25.1
Re: [Intel-gfx] [RFC PATCH] dma-buf/dma-fence: Use a successful read_trylock() annotation for dma_fence_begin_signalling()
On 4/28/23 14:52, Thomas Hellström wrote: Condsider the following call sequence: /* Upper layer */ dma_fence_begin_signalling(); lock(tainted_shared_lock); /* Driver callback */ dma_fence_begin_signalling(); ... The "Upper layer" here currently being the drm scheduler and "Driver callback" being an xe scheduler callback. While opt-in annotating the drm scheduler would achieve the same result, I think this patch should be considered anyway, as I don't think we will miss any true lockdep violations as a result of it. /Thomas
Re: [Intel-gfx] [PATCH 1/6] drm/uapi: Document CTM matrix better
On Fri, Apr 28, 2023 at 12:31:10AM +0200, Xaver Hugl wrote: > I can't say anything about the other commits in this series, but > "Document in which order the CTM matrix elements are stored" is > Reviewed-by: Xaver Hugl Thanks for the review+ack. Pushed to drm-misc-next. -- Ville Syrjälä Intel
Re: [Intel-gfx] [PATCH 1/2] drm/i915/gt: Use gt_err for GT info
Hi Tejas, On Fri, Apr 28, 2023 at 06:29:51PM +0530, Tejas Upadhyay wrote: > It will be more informative regarding > GT if we use gt_err instead. > > Cc: Andi Shyti > Signed-off-by: Tejas Upadhyay Thanks for this cleanup! Reviewed-by: Andi Shyti Andi
Re: [Intel-gfx] [PATCH 2/2] drm/i915/selftests: Use gt_err for GT info
Hi Tejas, On Fri, Apr 28, 2023 at 06:29:52PM +0530, Tejas Upadhyay wrote: > It will be more informative regarding > GT if we use gt_err instead. > > Cc: Andi Shyti > Signed-off-by: Tejas Upadhyay Reviewed-by: Andi Shyti Andi
Re: [Intel-gfx] [PATCH 05/11] drm/i915: Add support for disabling any CRTCs during HW readout/sanitization
On Wed, Apr 26, 2023 at 07:52:59PM +0300, Imre Deak wrote:
> During HW readout/sanitization CRTCs can be disabled only if they don't
> have an attached encoder (and so the encoder disable hooks don't need to
> be called). An upcoming patch will need to disable CRTCs also with an
> attached an encoder, so add support for this.
>
> For bigjoiner configs the encoder disabling hooks require the slave CRTC
> states, so add these too to the atomic state. Since the connector atomic
> state is already up-to-date when the CRTC is disabled the connector
> state needs to be updated (reset) after the CRTC is disabled, make this
> so. Follow the proper order of disabling first all bigjoiner slaves,
> then any port synced CRTC slaves followed by the CRTC originally
> requested to be disabled.
>
> Signed-off-by: Imre Deak
> ---
> .../drm/i915/display/intel_modeset_setup.c| 124 --
> 1 file changed, 115 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_modeset_setup.c
> b/drivers/gpu/drm/i915/display/intel_modeset_setup.c
> index a66085cf82bab..f613c074187a2 100644
> --- a/drivers/gpu/drm/i915/display/intel_modeset_setup.c
> +++ b/drivers/gpu/drm/i915/display/intel_modeset_setup.c
> @@ -50,10 +50,39 @@ static void set_encoder_for_connector(struct
> intel_connector *connector,
> }
> }
>
> +static void reset_encoder_connector_state(struct intel_encoder *encoder)
> +{
> + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> + struct intel_connector *connector;
> + struct drm_connector_list_iter conn_iter;
> +
> + drm_connector_list_iter_begin(&i915->drm, &conn_iter);
> + for_each_intel_connector_iter(connector, &conn_iter) {
> + if (connector->base.encoder != &encoder->base)
> + continue;
> +
> + set_encoder_for_connector(connector, NULL);
> +
> + connector->base.dpms = DRM_MODE_DPMS_OFF;
> + connector->base.encoder = NULL;
> + }
> + drm_connector_list_iter_end(&conn_iter);
> +}
> +
> +static void reset_crtc_encoder_state(struct intel_crtc *crtc)
> +{
> + struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> + struct intel_encoder *encoder;
> +
> + for_each_encoder_on_crtc(&i915->drm, &crtc->base, encoder) {
> + reset_encoder_connector_state(encoder);
> + encoder->base.crtc = NULL;
> + }
> +}
> +
> static void intel_crtc_disable_noatomic(struct intel_crtc *crtc,
> struct drm_modeset_acquire_ctx *ctx)
> {
> - struct intel_encoder *encoder;
> struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> struct intel_bw_state *bw_state =
> to_intel_bw_state(i915->display.bw.obj.state);
> @@ -65,9 +94,8 @@ static void intel_crtc_disable_noatomic(struct intel_crtc
> *crtc,
> to_intel_crtc_state(crtc->base.state);
> struct intel_plane *plane;
> struct drm_atomic_state *state;
> - struct intel_crtc_state *temp_crtc_state;
> + struct intel_crtc *temp_crtc;
> enum pipe pipe = crtc->pipe;
> - int ret;
>
> if (!crtc_state->hw.active)
> return;
> @@ -92,10 +120,17 @@ static void intel_crtc_disable_noatomic(struct
> intel_crtc *crtc,
> to_intel_atomic_state(state)->internal = true;
>
> /* Everything's already locked, -EDEADLK can't happen. */
> - temp_crtc_state = intel_atomic_get_crtc_state(state, crtc);
> - ret = drm_atomic_add_affected_connectors(state, &crtc->base);
> + for_each_intel_crtc_in_pipe_mask(&i915->drm, temp_crtc,
> + BIT(pipe) |
> +
> intel_crtc_bigjoiner_slave_pipes(crtc_state)) {
> + struct intel_crtc_state *temp_crtc_state =
> + intel_atomic_get_crtc_state(state, temp_crtc);
> + int ret;
>
> - drm_WARN_ON(&i915->drm, IS_ERR(temp_crtc_state) || ret);
> + ret = drm_atomic_add_affected_connectors(state,
> &temp_crtc->base);
> +
> + drm_WARN_ON(&i915->drm, IS_ERR(temp_crtc_state) || ret);
> + }
It's a bit weird to have this loop inside the function that
otherwise seems to be called individually for each of the
joined pipes. Why do we need this?
>
> i915->display.funcs.display->crtc_disable(to_intel_atomic_state(state),
> crtc);
>
> @@ -120,8 +155,7 @@ static void intel_crtc_disable_noatomic(struct intel_crtc
> *crtc,
> drm_WARN_ON(&i915->drm,
> drm_atomic_set_mode_for_crtc(&crtc_state->uapi, NULL) < 0);
>
> - for_each_encoder_on_crtc(&i915->drm, &crtc->base, encoder)
> - encoder->base.crtc = NULL;
> + reset_crtc_encoder_state(crtc);
>
> intel_fbc_disable(crtc);
> intel_update_watermarks(i915);
> @@ -272,6 +306,77 @@ static void intel_sanitize_fifo_underrun_reporting(const
> struct intel_crtc_state
>
Re: [Intel-gfx] [PATCH 06/11] drm/i915/dp: Add link training debug and error printing helpers
On Wed, Apr 26, 2023 at 07:53:00PM +0300, Imre Deak wrote:
> Add functions for printing link training debug and error messages, both
> to prepare for the next patch, which downgrades an error to debug if the
> sink is disconnected and to remove some code duplication.
>
> Signed-off-by: Imre Deak
> ---
> .../drm/i915/display/intel_dp_link_training.c | 376 +++---
> 1 file changed, 139 insertions(+), 237 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> index 6aa4ae5e7ebe3..12f2880e474ed 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> @@ -26,6 +26,47 @@
> #include "intel_dp.h"
> #include "intel_dp_link_training.h"
>
> +__printf(5, 6)
> +static void lt_msg(struct intel_connector *connector, struct intel_dp
> *intel_dp, enum drm_dp_phy dp_phy,
> +bool is_error, const char *format, ...)
I pretty much hate custom debug/error print functions. Makes it
hard togrep/etc. and just generally causes more "wtf is this?"
moments when reading the code. Unfortunateely the macro hell in
drm_print.h seems to make it really hard to do anything generic
directly :(
> +{
> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> + struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
> + char conn_str[128] = {};
> + struct va_format vaf;
> + va_list args;
> +
> + va_start(args, format);
> + vaf.fmt = format;
> + vaf.va = &args;
> +
> + if (connector)
> + snprintf(conn_str, sizeof(conn_str), "[CONNECTOR:%d:%s]",
> + connector->base.base.id, connector->base.name);
Are there actually places where we don't have/can't get the
connector?
> +
> + if (is_error)
> + drm_err(&i915->drm, "%s[ENCODER:%d:%s][%s] %pV\n",
> + conn_str,
> + encoder->base.base.id, encoder->base.name,
> + drm_dp_phy_name(dp_phy),
> + &vaf);
> + else
> + drm_dbg(&i915->drm, "%s[ENCODER:%d:%s][%s] %pV\n",
That has lost the correct debug category.
> + conn_str,
> + encoder->base.base.id, encoder->base.name,
> + drm_dp_phy_name(dp_phy),
> + &vaf);
Hmm. ___drm_dev_dbg() already uses this vaf stuff.
Does chaining it like that work correctly?
> +}
> +
> +#define lt_err(intel_dp, dp_phy, format, ...) \
> + lt_msg(NULL, intel_dp, dp_phy, true, format, ## __VA_ARGS__)
> +
> +#define lt_dbg(intel_dp, dp_phy, format, ...) \
> + lt_msg(NULL, intel_dp, dp_phy, false, format, ## __VA_ARGS__)
> +
> +#define lt_conn_dbg(connector, intel_dp, dp_phy, format, ...) \
> + lt_msg(connector, intel_dp, dp_phy, false, format, ## __VA_ARGS__)
> +
> static void intel_dp_reset_lttpr_common_caps(struct intel_dp *intel_dp)
> {
> memset(intel_dp->lttpr_common_caps, 0,
> sizeof(intel_dp->lttpr_common_caps));
> @@ -47,29 +88,21 @@ static void intel_dp_read_lttpr_phy_caps(struct intel_dp
> *intel_dp,
>const u8 dpcd[DP_RECEIVER_CAP_SIZE],
>enum drm_dp_phy dp_phy)
> {
> - struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
> u8 *phy_caps = intel_dp_lttpr_phy_caps(intel_dp, dp_phy);
>
> if (drm_dp_read_lttpr_phy_caps(&intel_dp->aux, dpcd, dp_phy, phy_caps)
> < 0) {
> - drm_dbg_kms(&dp_to_i915(intel_dp)->drm,
> - "[ENCODER:%d:%s][%s] failed to read the PHY caps\n",
> - encoder->base.base.id, encoder->base.name,
> - drm_dp_phy_name(dp_phy));
> + lt_dbg(intel_dp, dp_phy, "failed to read the PHY caps\n");
> return;
> }
>
> - drm_dbg_kms(&dp_to_i915(intel_dp)->drm,
> - "[ENCODER:%d:%s][%s] PHY capabilities: %*ph\n",
> - encoder->base.base.id, encoder->base.name,
> - drm_dp_phy_name(dp_phy),
> - (int)sizeof(intel_dp->lttpr_phy_caps[0]),
> - phy_caps);
> + lt_dbg(intel_dp, dp_phy, "PHY capabilities: %*ph\n",
> +(int)sizeof(intel_dp->lttpr_phy_caps[0]),
> +phy_caps);
> }
>
> static bool intel_dp_read_lttpr_common_caps(struct intel_dp *intel_dp,
> const u8 dpcd[DP_RECEIVER_CAP_SIZE])
> {
> - struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
> int ret;
>
> ret = drm_dp_read_lttpr_common_caps(&intel_dp->aux, dpcd,
> @@ -77,11 +110,9 @@ static bool intel_dp_read_lttpr_common_caps(struct
> intel_dp *intel_dp,
> if (ret < 0)
> goto reset_caps;
>
> - drm_dbg_kms(&dp_to_i915(intel_dp)->drm,
> - "[ENCODER:%d:%s] LTTPR common capabilities: %*ph\n",
>
Re: [Intel-gfx] [PATCH 0/8] drm/i915: HuC loading and authentication for MTL
On 4/27/2023 10:25 PM, Saarinen, Jani wrote: Hi, -Original Message- From: Intel-gfx On Behalf Of Ye, Tony Sent: perjantai 28. huhtikuuta 2023 6.11 To: Ceraolo Spurio, Daniele ; intel- g...@lists.freedesktop.org Cc: Teres Alexis, Alan Previn ; dri- de...@lists.freedesktop.org; Zhang, Carl Subject: Re: [Intel-gfx] [PATCH 0/8] drm/i915: HuC loading and authentication for MTL Acked-by: Tony Ye CI results would be also good to look at before... https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117080v1/index.html? For some reason no single MTL tests and many aborts... Is there any way to know if the MTLs where just offline or if they failed driver load? This is working fine in my local MTL testing, so not sure what might be broken. Regarding the aborts, looks like I have broken DG2 reset. I tested a previous local version of this on DG2 but not the latest, so I must've broken something when refactoring the code. I'll figure it out and fix it up. Daniele Thanks, Tony On 4/27/2023 7:34 PM, Daniele Ceraolo Spurio wrote: The HuC loading and authentication flow is once again changing and a new "clear-media only" authentication step is introduced. The flow is as follows: 1) The HuC is loaded via DMA - same as all non-GSC HuC binaries. 2) The HuC is authenticated by the GuC - this is the same step as performed for all non-GSC HuC binaries and re-uses the same code, but it is now resulting in a partial authentication that only allows clear-media workloads. 3) The HuC is fully authenticated for all workloads by the GSC - this is done via a new PXP command, submitted via the GSCCS. The advantage of this new flow is that we can start processing clear-media workloads without having to wait for the GSC to be ready, which can take several seconds. As part of this change, the HuC status getparam has been updated with a new value to indicate a partial authentication. Note tha the media driver is checking for value > 0 for clear media workloads, so no changes are required in userspace for that to work. The SW proxy series [1] has been included, squashed in a single patch, as some of some of the patches in this series depend on it. This is not a functional dependencies, the patches just touch the same code; the proxy patches are planned to be merged first, so it is easier to base the new patches on top of it to avoid having to rebase them later. [1]https://patchwork.freedesktop.org/series/115806/ Cc: Alan Previn Cc: Tony Ye Daniele Ceraolo Spurio (8): DO NOT REVIEW: drm/i915: Add support for MTL GSC SW Proxy drm/i915/uc: perma-pin firmwares drm/i915/huc: Parse the GSC-enabled HuC binary drm/i915/huc: Load GSC-enabled HuC via DMA xfer if the fuse says so drm/i915/huc: differentiate the 2 steps of the MTL HuC auth flow drm/i915/mtl/huc: auth HuC via GSC drm/i915/mtl/huc: Use the media gt for the HuC getparam drm/i915/huc: define HuC FW version for MTL drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/gt/intel_ggtt.c | 3 + drivers/gpu/drm/i915/gt/intel_gt_irq.c| 22 +- drivers/gpu/drm/i915/gt/intel_gt_regs.h | 3 + .../drm/i915/gt/uc/intel_gsc_meu_headers.h| 74 +++ drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c | 424 ++ drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.h | 18 + drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c | 89 +++- drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h | 17 +- .../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c | 2 +- .../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h | 1 + drivers/gpu/drm/i915/gt/uc/intel_guc.c| 2 +- drivers/gpu/drm/i915/gt/uc/intel_huc.c| 182 +--- drivers/gpu/drm/i915/gt/uc/intel_huc.h| 26 +- drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 214 - drivers/gpu/drm/i915/gt/uc/intel_huc_fw.h | 6 +- drivers/gpu/drm/i915/gt/uc/intel_huc_print.h | 21 + drivers/gpu/drm/i915/gt/uc/intel_uc.c | 10 +- drivers/gpu/drm/i915/gt/uc/intel_uc.h | 2 + drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 120 ++--- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 9 +- drivers/gpu/drm/i915/i915_getparam.c | 6 +- drivers/gpu/drm/i915/i915_reg.h | 3 + .../drm/i915/pxp/intel_pxp_cmd_interface_43.h | 14 +- drivers/gpu/drm/i915/pxp/intel_pxp_huc.c | 2 +- drivers/misc/mei/Kconfig | 2 +- drivers/misc/mei/Makefile | 1 + drivers/misc/mei/gsc_proxy/Kconfig| 14 + drivers/misc/mei/gsc_proxy/Makefile | 7 + drivers/misc/mei/gsc_proxy/mei_gsc_proxy.c| 208 + include/drm/i915_component.h | 3 +- include/drm/i915_gsc_proxy_mei_interface.h| 53 +++ include/uapi/drm/i915_drm.h | 3 +- 33 files changed, 1428 insertions(+), 134 deletions(-) create mode 100644 drivers/gpu/dr
Re: [Intel-gfx] [PATCH 10/11] drm/i915: Factor out call_with_modeset_ctx()
On Wed, Apr 26, 2023 at 07:53:04PM +0300, Imre Deak wrote:
> Factor out a helper to call a function with the atomic locks held,
> required by a follow-up patch resetting an active DP link.
>
> No functional changes.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 53 ++--
> 1 file changed, 31 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 29e4bfab46358..0c8bc32f293b0 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -4370,35 +4370,18 @@ static int intel_hdmi_reset_link(struct intel_encoder
> *encoder,
> return modeset_pipe(&crtc->base, ctx);
> }
>
> -static enum intel_hotplug_state
> -intel_ddi_hotplug(struct intel_encoder *encoder,
> - struct intel_connector *connector)
> +static void call_with_modeset_ctx(int (*fn)(struct intel_encoder *encoder,
> + struct drm_modeset_acquire_ctx
> *ctx),
> + struct intel_encoder *encoder)
> {
> struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> - struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
> - struct intel_dp *intel_dp = &dig_port->dp;
> - enum phy phy = intel_port_to_phy(i915, encoder->port);
> - bool is_tc = intel_phy_is_tc(i915, phy);
> struct drm_modeset_acquire_ctx ctx;
> - enum intel_hotplug_state state;
> int ret;
>
> - if (intel_dp->compliance.test_active &&
> - intel_dp->compliance.test_type == DP_TEST_LINK_PHY_TEST_PATTERN) {
> - intel_dp_phy_test(encoder);
> - /* just do the PHY test and nothing else */
> - return INTEL_HOTPLUG_UNCHANGED;
> - }
> -
> - state = intel_encoder_hotplug(encoder, connector);
> -
> drm_modeset_acquire_init(&ctx, 0);
>
> for (;;) {
> - if (connector->base.connector_type == DRM_MODE_CONNECTOR_HDMIA)
> - ret = intel_hdmi_reset_link(encoder, &ctx);
> - else
> - ret = intel_dp_retrain_link(encoder, &ctx);
> + ret = fn(encoder, &ctx);
>
> if (ret == -EDEADLK) {
> drm_modeset_backoff(&ctx);
> @@ -4410,8 +4393,34 @@ intel_ddi_hotplug(struct intel_encoder *encoder,
>
> drm_modeset_drop_locks(&ctx);
> drm_modeset_acquire_fini(&ctx);
> - drm_WARN(encoder->base.dev, ret,
> + drm_WARN(&i915->drm, ret,
>"Acquiring modeset locks failed with %i\n", ret);
> +}
Seems pretty much a less general version of
https://patchwork.freedesktop.org/series/92607/
Unfortuantely that died in the bikeshed.
Maybe we should look into doing something like that
just for i915 initially...
> +
> +static enum intel_hotplug_state
> +intel_ddi_hotplug(struct intel_encoder *encoder,
> + struct intel_connector *connector)
> +{
> + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> + struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
> + struct intel_dp *intel_dp = &dig_port->dp;
> + enum phy phy = intel_port_to_phy(i915, encoder->port);
> + bool is_tc = intel_phy_is_tc(i915, phy);
> + enum intel_hotplug_state state;
> +
> + if (intel_dp->compliance.test_active &&
> + intel_dp->compliance.test_type == DP_TEST_LINK_PHY_TEST_PATTERN) {
> + intel_dp_phy_test(encoder);
> + /* just do the PHY test and nothing else */
> + return INTEL_HOTPLUG_UNCHANGED;
> + }
> +
> + state = intel_encoder_hotplug(encoder, connector);
> +
> + if (connector->base.connector_type == DRM_MODE_CONNECTOR_HDMIA)
> + call_with_modeset_ctx(intel_hdmi_reset_link, encoder);
> + else
> + call_with_modeset_ctx(intel_dp_retrain_link, encoder);
>
> /*
>* Unpowered type-c dongles can take some time to boot and be
> --
> 2.37.2
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH v3 0/5] drm/i915: Allow user to set cache at BO creation
> On 4/28/23 07:47, fei.y...@intel.com wrote: >> From: Fei Yang >> >> The first three patches in this series are taken from >> https://patchwork.freedesktop.org/series/116868/ >> These patches are included here because the last patch >> has dependency on the pat_index refactor. >> >> This series is focusing on uAPI changes, >> 1. end support for set caching ioctl [PATCH 4/5] >> 2. add set_pat extension for gem_create [PATCH 5/5] >> >> v2: drop one patch that was merged separately >> 341ad0e8e254 drm/i915/mtl: Add PTE encode function >> v3: rebase on https://patchwork.freedesktop.org/series/117082/ > > Hi, Fei. > > Does this uAPI update also affect any discrete GPUs supported by i915, It does. > And in that case, does it allow setting non-snooping PAT indices on > those devices? It allows setting PAT indices specified in https://gfxspecs.intel.com/Predator/Home/Index/45101 . KMD does a sanity check so that it won't go over the max recommended by bspec. > If so, since the uAPI for discrete GPU devices doesn't allow incoherency > between GPU and CPU (apart from write-combining buffering), the correct > CPU caching mode matching the PAT index needs to be selected for the > buffer object in i915_ttm_select_tt_caching(). The patch doesn't affect the CPU caching mode setting logic though. And the caching settings for objects created by kernel should remain the same for both CPU and GPU, objects created by userspace are managed completely by userspace. One question though, what do you mean by non-snooping PAT indices? The PAT index registers don't really control coherency mode in the past, I believe MTL is the first one that has COH_MODE in the PAT registers. Aren't discrete GPUs snooping CPU cache automatically? -Fei > Thanks, > Thomas > >> >> Fei Yang (5): >>drm/i915: preparation for using PAT index >>drm/i915: use pat_index instead of cache_level >>drm/i915: make sure correct pte encode is used >>drm/i915/mtl: end support for set caching ioctl >>drm/i915: Allow user to set cache at BO creation >> >> drivers/gpu/drm/i915/display/intel_dpt.c | 12 +-- >> drivers/gpu/drm/i915/gem/i915_gem_create.c| 36 + >> drivers/gpu/drm/i915/gem/i915_gem_domain.c| 46 ++- >> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 10 ++- >> drivers/gpu/drm/i915/gem/i915_gem_mman.c | 3 +- >> drivers/gpu/drm/i915/gem/i915_gem_object.c| 67 +++- >> drivers/gpu/drm/i915/gem/i915_gem_object.h| 8 ++ >> .../gpu/drm/i915/gem/i915_gem_object_types.h | 26 +- >> drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 9 ++- >> drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 2 - >> drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 4 +- >> drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 16 ++-- >> .../gpu/drm/i915/gem/selftests/huge_pages.c | 2 +- >> .../drm/i915/gem/selftests/i915_gem_migrate.c | 2 +- >> .../drm/i915/gem/selftests/i915_gem_mman.c| 2 +- >> drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 10 ++- >> drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 73 + >> drivers/gpu/drm/i915/gt/gen8_ppgtt.h | 3 +- >> drivers/gpu/drm/i915/gt/intel_ggtt.c | 76 +- >> drivers/gpu/drm/i915/gt/intel_gtt.h | 20 +++-- >> drivers/gpu/drm/i915/gt/intel_migrate.c | 47 ++- >> drivers/gpu/drm/i915/gt/intel_migrate.h | 13 ++- >> drivers/gpu/drm/i915/gt/intel_ppgtt.c | 6 +- >> drivers/gpu/drm/i915/gt/selftest_migrate.c| 47 +-- >> drivers/gpu/drm/i915/gt/selftest_reset.c | 8 +- >> drivers/gpu/drm/i915/gt/selftest_timeline.c | 2 +- >> drivers/gpu/drm/i915/gt/selftest_tlb.c| 4 +- >> drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 10 ++- >> drivers/gpu/drm/i915/i915_debugfs.c | 55 ++--- >> drivers/gpu/drm/i915/i915_gem.c | 16 +++- >> drivers/gpu/drm/i915/i915_gpu_error.c | 8 +- >> drivers/gpu/drm/i915/i915_pci.c | 79 --- >> drivers/gpu/drm/i915/i915_vma.c | 16 ++-- >> drivers/gpu/drm/i915/i915_vma.h | 2 +- >> drivers/gpu/drm/i915/i915_vma_types.h | 2 - >> drivers/gpu/drm/i915/intel_device_info.h | 5 ++ >> drivers/gpu/drm/i915/selftests/i915_gem.c | 5 +- >> .../gpu/drm/i915/selftests/i915_gem_evict.c | 4 +- >> drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 15 ++-- >> .../drm/i915/selftests/intel_memory_region.c | 4 +- >> .../gpu/drm/i915/selftests/mock_gem_device.c | 9 +++ >> drivers/gpu/drm/i915/selftests/mock_gtt.c | 8 +- >> include/uapi/drm/i915_drm.h | 36 + >> tools/include/uapi/drm/i915_drm.h | 36 + >> 44 files changed, 621 insertions(+), 243 deletions(-) >>
Re: [Intel-gfx] [PATCH v10 00/22] Add vfio_device cdev for iommufd support
> -Original Message- > From: Jiang, Yanting [mailto:yanting.ji...@intel.com] > Sent: 28 April 2023 10:30 > To: Liu, Yi L ; alex.william...@redhat.com; > j...@nvidia.com; Tian, Kevin > Cc: j...@8bytes.org; robin.mur...@arm.com; coh...@redhat.com; > eric.au...@redhat.com; nicol...@nvidia.com; k...@vger.kernel.org; > mjros...@linux.ibm.com; chao.p.p...@linux.intel.com; > yi.y@linux.intel.com; pet...@redhat.com; jasow...@redhat.com; > Shameerali Kolothum Thodi ; > l...@redhat.com; suravee.suthikulpa...@amd.com; > intel-gvt-...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; > linux-s...@vger.kernel.org; Hao, Xudong ; Zhao, > Yan Y ; Xu, Terrence ; Duan, > Zhenzhong > Subject: RE: [PATCH v10 00/22] Add vfio_device cdev for iommufd support > > > Subject: [PATCH v10 00/22] Add vfio_device cdev for iommufd support > > > > Existing VFIO provides group-centric user APIs for userspace. Userspace > opens > > the /dev/vfio/$group_id first before getting device fd and hence getting > access > > to device. This is not the desired model for iommufd. Per the conclusion of > > community discussion[1], iommufd provides device-centric kAPIs and > requires its > > consumer (like VFIO) to be device-centric user APIs. Such user APIs are > used to > > associate device with iommufd and also the I/O address spaces managed > by the > > iommufd. > > > > This series first introduces a per device file structure to be prepared for > further > > enhancement and refactors the kvm-vfio code to be prepared for accepting > > device file from userspace. After this, adds a mechanism for blocking > device > > access before iommufd bind. Then refactors the vfio to be able to handle > cdev > > path (e.g. iommufd binding, no-iommufd, [de]attach ioas). > > This refactor includes making the device_open exclusive between the > group and > > the cdev path, only allow single device open in cdev path; vfio-iommufd > code is > > also refactored to support cdev. e.g. split the vfio_iommufd_bind() into two > > steps. Eventually, adds the cdev support for vfio device and the new ioctls, > then > > makes group infrastructure optional as it is not needed when vfio device > cdev is > > compiled. > > > > This series is based on some preparation works done to vfio emulated > devices[2] > > and vfio pci hot reset enhancements[3]. > > > > This series is a prerequisite for iommu nesting for vfio device[4] [5]. > > > > The complete code can be found in below branch, simple tests done to the > > legacy group path and the cdev path. Draft QEMU branch can be found > at[6] > > However, the noiommu mode test is only done with some hacks in kernel > and > > qemu to check if qemu can boot with noiommu devices. > > > > https://github.com/yiliu1765/iommufd/tree/vfio_device_cdev_v10 > > (config CONFIG_IOMMUFD=y CONFIG_VFIO_DEVICE_CDEV=y) > > > > base-commit: c3822365940319ad86487cc1daf6f1a4c271191e > > (based on Alex's next branch and merged the vfio_mdev_ops branch from > > Jason's repo) > > > > Tested NIC passthrough on Intel platform. > Result looks good hence, > Tested-by: Yanting Jiang Likewise, tested on HiSilicon D06(ARM64) platform with a NIC pass-through device and looks fine. FWIW, Tested-by: Shameer Kolothum Thanks, Shameer
Re: [Intel-gfx] [PATCH v4 2/9] vfio-iommufd: Create iommufd_access for noiommu devices
On 2023/4/28 20:07, Jason Gunthorpe wrote: On Fri, Apr 28, 2023 at 02:21:26PM +0800, Yi Liu wrote: but this patch needs to use vfio_iommufd_emulated_bind() and vfio_iommufd_emulated_unbind() for the noiommu devices when binding to iommufd. So needs to check noiommu in the vfio_iommufd_bind() and vfio_iommu_unbind() as well. I'm not sure this is strictly necessary, it just needs an access The emulated stuff is for mdev only, it should not be confused with no-iommu hmmm. I guess the confusion is due to the reuse of vfio_iommufd_emulated_bind(). Eg if you had a no_iommu_access value to store the access it would be fine and could serve as the 'this is no_iommu' flag So this no_iommu_access shall be created per iommufd bind, and call the iommufd_access_create() with iommufd_access_ops. is it? If so, this is not 100% the same with no_iommu flag as this flag is static after device registration. The only purpose of the access at this moment is to get an iommufdctx id to return to userspace. yes. and it is the iommufd_access ID to be returned to userspace. -- Regards, Yi Liu
Re: [Intel-gfx] [PATCH v3 0/5] drm/i915: Allow user to set cache at BO creation
On 4/28/23 17:19, Yang, Fei wrote: > On 4/28/23 07:47, fei.y...@intel.com wrote: >> From: Fei Yang >> >> The first three patches in this series are taken from >> https://patchwork.freedesktop.org/series/116868/ >> These patches are included here because the last patch >> has dependency on the pat_index refactor. >> >> This series is focusing on uAPI changes, >> 1. end support for set caching ioctl [PATCH 4/5] >> 2. add set_pat extension for gem_create [PATCH 5/5] >> >> v2: drop one patch that was merged separately >> 341ad0e8e254 drm/i915/mtl: Add PTE encode function >> v3: rebase on https://patchwork.freedesktop.org/series/117082/ > > Hi, Fei. > > Does this uAPI update also affect any discrete GPUs supported by i915, It does. > And in that case, does it allow setting non-snooping PAT indices on > those devices? It allows setting PAT indices specified in KMD does a sanity check so that it won't go over the max recommended by bspec. > If so, since the uAPI for discrete GPU devices doesn't allow incoherency > between GPU and CPU (apart from write-combining buffering), the correct > CPU caching mode matching the PAT index needs to be selected for the > buffer object in i915_ttm_select_tt_caching(). The patch doesn't affect the CPU caching mode setting logic though. And the caching settings for objects created by kernel should remain the same for both CPU and GPU, objects created by userspace are managed completely by userspace. One question though, what do you mean by non-snooping PAT indices? The PAT index registers don't really control coherency mode in the past, I believe MTL is the first one that has COH_MODE in the PAT registers. Aren't discrete GPUs snooping CPU cache automatically? Yes, that was actually the bottom question: What do these PAT settings allow you to do WRT the snooping on supported discrete devices (DG2) on i915? If they indeed don't allow disabling snooping, then that's not a problem. If they do, the ttm code there needs some modification. Thanks, Thomas -Fei > Thanks, > Thomas > >> >> Fei Yang (5): >> drm/i915: preparation for using PAT index >> drm/i915: use pat_index instead of cache_level >> drm/i915: make sure correct pte encode is used >> drm/i915/mtl: end support for set caching ioctl >> drm/i915: Allow user to set cache at BO creation >> >> drivers/gpu/drm/i915/display/intel_dpt.c | 12 +-- >> drivers/gpu/drm/i915/gem/i915_gem_create.c | 36 + >> drivers/gpu/drm/i915/gem/i915_gem_domain.c | 46 ++- >> .../gpu/drm/i915/gem/i915_gem_execbuffer.c | 10 ++- >> drivers/gpu/drm/i915/gem/i915_gem_mman.c | 3 +- >> drivers/gpu/drm/i915/gem/i915_gem_object.c | 67 +++- >> drivers/gpu/drm/i915/gem/i915_gem_object.h | 8 ++ >> .../gpu/drm/i915/gem/i915_gem_object_types.h | 26 +- >> drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 9 ++- >> drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 2 - >> drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 4 +- >> drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 16 ++-- >> .../gpu/drm/i915/gem/selftests/huge_pages.c | 2 +- >> .../drm/i915/gem/selftests/i915_gem_migrate.c | 2 +- >> .../drm/i915/gem/selftests/i915_gem_mman.c | 2 +- >> drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 10 ++- >> drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 73 + >> drivers/gpu/drm/i915/gt/gen8_ppgtt.h | 3 +- >> drivers/gpu/drm/i915/gt/intel_ggtt.c | 76 +- >> drivers/gpu/drm/i915/gt/intel_gtt.h | 20 +++-- >> drivers/gpu/drm/i915/gt/intel_migrate.c | 47 ++- >> drivers/gpu/drm/i915/gt/intel_migrate.h | 13 ++- >> drivers/gpu/drm/i915/gt/intel_ppgtt.c | 6 +- >> drivers/gpu/drm/i915/gt/selftest_migrate.c | 47 +-- >> drivers/gpu/drm/i915/gt/selftest_reset.c | 8 +- >> drivers/gpu/drm/i915/gt/selftest_timeline.c | 2 +- >> drivers/gpu/drm/i915/gt/selftest_tlb.c | 4 +- >> drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 10 ++- >> drivers/gpu/drm/i915/i915_debugfs.c | 55 ++--- >> drivers/gpu/drm/i915/i915_gem.c | 16 +++- >> drivers/gpu/drm/i915/i915_gpu_error.c | 8 +- >> drivers/gpu/drm/i915/i915_pci.c | 79 --- >> drivers/gpu/drm/i915/i915_vma.c | 16 ++-- >> drivers/gpu/drm/i915/i915_vma.h | 2 +- >> drivers/gpu/drm/i915/i915_vma_types.h | 2 - >> drivers/gpu/drm/i915/intel_device_info.h | 5 ++ >> drivers/gpu/drm/i915/selftests/i915_gem.c | 5 +- >> .../gpu/drm/i915/selftests/i915_gem_evict.c | 4 +- >> drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 15 ++-- >> .../drm/i915/selftests/intel_memory_region.c | 4 +- >> .../gpu/drm/i915/selftests/mock_gem_device.c | 9 +++ >> drivers/gpu/drm/i915/selftests/mock_gtt.c | 8 +- >> include/uapi/drm/i915_drm.h | 36 + >> tools/include/uapi/drm/i915_drm.h | 36 +
Re: [Intel-gfx] [PATCH v4 2/9] vfio-iommufd: Create iommufd_access for noiommu devices
On 2023/4/28 02:32, Alex Williamson wrote: On Thu, 27 Apr 2023 06:59:17 + "Liu, Yi L" wrote: [...] I'm not quite sure about it so far. For mdev devices, the device driver may use vfio_pin_pages/vfio_dma_rw () to pin page. Hence such drivers need to listen to dma_unmap() event. But for noiommu users, does the device driver also participate in the page pin? At least for vfio-pci driver, it does not, or maybe it will in the future when enabling noiommu userspace to pin pages. It looks to me such userspace should order the DMA before calling ioctl to unpin page instead of letting device driver listen to unmap. Whoa, noiommu is inherently unsafe an only meant to expose the vfio device interface for userspace drivers that are going to do unsafe things regardless. Enabling noiommu to work with mdev, pin pages, or anything else should not be on our agenda. Userspaces relying on niommu get the minimum viable interface and must impose a minuscule incremental maintenance burden. The only reason we're spending so much effort on it here is to make iommufd noiommu support equivalent to group/container noiommu support. We should stop at that. Thanks, btw. I asked a question in [1] to check if we should allow attach/detach on noiommu devices. Jason has replied it. If in future noiommu userspace can pin page, then such userspace will need to attach/detach ioas. So I made cdev series[2] to allow attach ioas on noiommu devices. Supporting it from cdev day-1 may avoid probing if attach/detach is supported or not for specific devices when adding pin page for noiommu userspace. But now, I think such a support will not in plan, is it? If so, will it be better to disallow attach/detach on noiommu devices in patch [2]? [1] https://lore.kernel.org/kvm/zea+khh0tufst...@nvidia.com/ [2] https://lore.kernel.org/kvm/20230426150321.454465-21-yi.l@intel.com/ -- Regards, Yi Liu
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/mtl: Add support for C20 phy (rev2)
== Series Details == Series: drm/i915/mtl: Add support for C20 phy (rev2) URL : https://patchwork.freedesktop.org/series/116755/ State : warning == Summary == Error: dim checkpatch failed 7bd367a64eec drm/i915/mtl: C20 PLL programming -:175: WARNING:LONG_LINE: line length of 109 exceeds 100 columns #175: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:1553: + cntx = intel_cx0_read(i915, encoder->port, INTEL_CX0_LANE0, PHY_C20_VDR_CUSTOM_SERDES_RATE) & BIT(0); -:184: WARNING:LONG_LINE: line length of 129 exceeds 100 columns #184: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:1562: + intel_c20_sram_write(i915, encoder->port, INTEL_CX0_LANE0, RAWLANEAONX_DIG_TX_MPLLB_CAL_DONE_BANK(i), 0); -:192: WARNING:LONG_LINE: line length of 127 exceeds 100 columns #192: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:1570: + intel_c20_sram_write(i915, encoder->port, INTEL_CX0_LANE0, PHY_C20_A_TX_CNTX_CFG(i), pll_state->tx[i]); -:194: WARNING:LONG_LINE: line length of 127 exceeds 100 columns #194: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:1572: + intel_c20_sram_write(i915, encoder->port, INTEL_CX0_LANE0, PHY_C20_B_TX_CNTX_CFG(i), pll_state->tx[i]); -:200: WARNING:LONG_LINE: line length of 129 exceeds 100 columns #200: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:1578: + intel_c20_sram_write(i915, encoder->port, INTEL_CX0_LANE0, PHY_C20_A_CMN_CNTX_CFG(i), pll_state->cmn[i]); -:202: WARNING:LONG_LINE: line length of 129 exceeds 100 columns #202: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:1580: + intel_c20_sram_write(i915, encoder->port, INTEL_CX0_LANE0, PHY_C20_B_CMN_CNTX_CFG(i), pll_state->cmn[i]); -:240: WARNING:LONG_LINE: line length of 102 exceeds 100 columns #240: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:1618: + BIT(6) | PHY_C20_CUSTOM_SERDES(intel_c20_get_dp_rate(pll_state->clock)), total: 0 errors, 7 warnings, 0 checks, 469 lines checked 09766635af47 drm/i915/mtl: C20 HW readout -:620: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #620: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:1962: +int intel_cx0pll_calc_state(struct intel_crtc_state *crtc_state, +struct intel_encoder *encoder) -:648: WARNING:LONG_LINE: line length of 125 exceeds 100 columns #648: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:1992: + cntx = intel_cx0_read(i915, encoder->port, INTEL_CX0_LANE0, PHY_C20_VDR_CUSTOM_SERDES_RATE) & PHY_C20_CONTEXT_TOGGLE; -:663: WARNING:LONG_LINE: line length of 101 exceeds 100 columns #663: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:2007: + pll_state->cmn[i] = intel_c20_sram_read(i915, encoder->port, INTEL_CX0_LANE0, -:666: WARNING:LONG_LINE: line length of 101 exceeds 100 columns #666: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:2010: + pll_state->cmn[i] = intel_c20_sram_read(i915, encoder->port, INTEL_CX0_LANE0, -:674: WARNING:LONG_LINE: line length of 111 exceeds 100 columns #674: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:2018: + pll_state->mpllb[i] = intel_c20_sram_read(i915, encoder->port, INTEL_CX0_LANE0, -:675: WARNING:LONG_LINE: line length of 103 exceeds 100 columns #675: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:2019: + PHY_C20_B_MPLLB_CNTX_CFG(i)); -:677: WARNING:LONG_LINE: line length of 111 exceeds 100 columns #677: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:2021: + pll_state->mpllb[i] = intel_c20_sram_read(i915, encoder->port, INTEL_CX0_LANE0, -:678: WARNING:LONG_LINE: line length of 103 exceeds 100 columns #678: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:2022: + PHY_C20_A_MPLLB_CNTX_CFG(i)); -:684: WARNING:LONG_LINE: line length of 111 exceeds 100 columns #684: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:2028: + pll_state->mplla[i] = intel_c20_sram_read(i915, encoder->port, INTEL_CX0_LANE0, -:685: WARNING:LONG_LINE: line length of 103 exceeds 100 columns #685: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:2029: + PHY_C20_B_MPLLA_CNTX_CFG(i)); -:687: WARNING:LONG_LINE: line length of 111 exceeds 100 columns #687: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:2031: + pll_state->mplla[i] = intel_c20_sram_read(i915, encoder->port, INTEL_CX0_LANE0, -:688: WARNING:LONG_LINE: line length of 103 exceeds 100 columns #688: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:2032: + PHY_C20_A_MPLLA_CNTX_CFG(i)); total
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/mtl: Add support for C20 phy (rev2)
== Series Details == Series: drm/i915/mtl: Add support for C20 phy (rev2) URL : https://patchwork.freedesktop.org/series/116755/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/includ
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/mtl: Add support for C20 phy (rev2)
== Series Details ==
Series: drm/i915/mtl: Add support for C20 phy (rev2)
URL : https://patchwork.freedesktop.org/series/116755/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13073 -> Patchwork_116755v2
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116755v2/index.html
Participating hosts (39 -> 37)
--
Missing(2): fi-kbl-soraka fi-snb-2520m
Known issues
Here are the changes found in Patchwork_116755v2 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@reset:
- bat-rpls-1: [PASS][1] -> [ABORT][2] ([i915#4983] / [i915#7461] /
[i915#8384])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13073/bat-rpls-1/igt@i915_selftest@l...@reset.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116755v2/bat-rpls-1/igt@i915_selftest@l...@reset.html
* igt@i915_selftest@live@slpc:
- bat-adln-1: NOTRUN -> [DMESG-FAIL][3] ([i915#6997])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116755v2/bat-adln-1/igt@i915_selftest@l...@slpc.html
* igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-adln-1: NOTRUN -> [SKIP][4] ([i915#7828])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116755v2/bat-adln-1/igt@kms_chamelium_...@common-hpd-after-suspend.html
* igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-d-dp-1:
- bat-dg2-8: [PASS][5] -> [FAIL][6] ([i915#7932])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13073/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-d-dp-1.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116755v2/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-d-dp-1.html
Possible fixes
* igt@i915_selftest@live@gt_lrc:
- bat-adln-1: [INCOMPLETE][7] ([i915#4983] / [i915#7609]) ->
[PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13073/bat-adln-1/igt@i915_selftest@live@gt_lrc.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116755v2/bat-adln-1/igt@i915_selftest@live@gt_lrc.html
* igt@kms_pipe_crc_basic@nonblocking-crc@pipe-d-dp-1:
- bat-dg2-8: [FAIL][9] ([i915#7932]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13073/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116755v2/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
[i915#7461]: https://gitlab.freedesktop.org/drm/intel/issues/7461
[i915#7609]: https://gitlab.freedesktop.org/drm/intel/issues/7609
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
[i915#7920]: https://gitlab.freedesktop.org/drm/intel/issues/7920
[i915#7932]: https://gitlab.freedesktop.org/drm/intel/issues/7932
[i915#8384]: https://gitlab.freedesktop.org/drm/intel/issues/8384
Build changes
-
* Linux: CI_DRM_13073 -> Patchwork_116755v2
CI-20190529: 20190529
CI_DRM_13073: d4602c57ac02d66526e4785b80c2e01dea122f33 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7275: c284bd66d7b416b4eaca456d6085b9180ad58058 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_116755v2: d4602c57ac02d66526e4785b80c2e01dea122f33 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
cfe10aa9f670 drm/i915/mtl: Enable TC ports
a76a271e840c drm/i915/mtl: Pin assignment for TypeC
af5b94a2f2cb drm/i915/mtl: TypeC HPD live status query
73e409d6e8e9 drm/i915/mtl: Power up TCSS
89031c1f2c58 drm/i915/mtl: Define mask for DDI AUX interrupts
01f19c8138fa drm/i915/mtl: Readout Thunderbolt HW state
6a8a44923092 drm/i915/mtl: Enabling/disabling sequence Thunderbolt pll
ed0bd3453efe drm/i915/mtl: For DP2.0 10G and 20G rates use MPLLA
ecd48801a943 drm/i915/mtl: Add voltage swing sequence for C20
5777f9bceb6a drm/i915/mtl: C20 port clock calculation
357247eb8025 drm/i915/mtl: Dump C20 pll hw state
dc0e2e2381d3 drm/i915/mtl: C20 HW readout
39ba77b93b8f drm/i915/mtl: C20 PLL programming
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116755v2/index.html
Re: [Intel-gfx] [PATCH 05/11] drm/i915: Add support for disabling any CRTCs during HW readout/sanitization
On Fri, Apr 28, 2023 at 05:02:35PM +0300, Ville Syrjälä wrote:
> On Wed, Apr 26, 2023 at 07:52:59PM +0300, Imre Deak wrote:
> > During HW readout/sanitization CRTCs can be disabled only if they don't
> > have an attached encoder (and so the encoder disable hooks don't need to
> > be called). An upcoming patch will need to disable CRTCs also with an
> > attached an encoder, so add support for this.
> >
> > For bigjoiner configs the encoder disabling hooks require the slave CRTC
> > states, so add these too to the atomic state. Since the connector atomic
> > state is already up-to-date when the CRTC is disabled the connector
> > state needs to be updated (reset) after the CRTC is disabled, make this
> > so. Follow the proper order of disabling first all bigjoiner slaves,
> > then any port synced CRTC slaves followed by the CRTC originally
> > requested to be disabled.
> >
> > Signed-off-by: Imre Deak
> > ---
> > .../drm/i915/display/intel_modeset_setup.c| 124 --
> > 1 file changed, 115 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_modeset_setup.c
> > b/drivers/gpu/drm/i915/display/intel_modeset_setup.c
> > index a66085cf82bab..f613c074187a2 100644
> > --- a/drivers/gpu/drm/i915/display/intel_modeset_setup.c
> > +++ b/drivers/gpu/drm/i915/display/intel_modeset_setup.c
> > @@ -50,10 +50,39 @@ static void set_encoder_for_connector(struct
> > intel_connector *connector,
> > }
> > }
> >
> > +static void reset_encoder_connector_state(struct intel_encoder *encoder)
> > +{
> > + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> > + struct intel_connector *connector;
> > + struct drm_connector_list_iter conn_iter;
> > +
> > + drm_connector_list_iter_begin(&i915->drm, &conn_iter);
> > + for_each_intel_connector_iter(connector, &conn_iter) {
> > + if (connector->base.encoder != &encoder->base)
> > + continue;
> > +
> > + set_encoder_for_connector(connector, NULL);
> > +
> > + connector->base.dpms = DRM_MODE_DPMS_OFF;
> > + connector->base.encoder = NULL;
> > + }
> > + drm_connector_list_iter_end(&conn_iter);
> > +}
> > +
> > +static void reset_crtc_encoder_state(struct intel_crtc *crtc)
> > +{
> > + struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> > + struct intel_encoder *encoder;
> > +
> > + for_each_encoder_on_crtc(&i915->drm, &crtc->base, encoder) {
> > + reset_encoder_connector_state(encoder);
> > + encoder->base.crtc = NULL;
> > + }
> > +}
> > +
> > static void intel_crtc_disable_noatomic(struct intel_crtc *crtc,
> > struct drm_modeset_acquire_ctx *ctx)
> > {
> > - struct intel_encoder *encoder;
> > struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> > struct intel_bw_state *bw_state =
> > to_intel_bw_state(i915->display.bw.obj.state);
> > @@ -65,9 +94,8 @@ static void intel_crtc_disable_noatomic(struct intel_crtc
> > *crtc,
> > to_intel_crtc_state(crtc->base.state);
> > struct intel_plane *plane;
> > struct drm_atomic_state *state;
> > - struct intel_crtc_state *temp_crtc_state;
> > + struct intel_crtc *temp_crtc;
> > enum pipe pipe = crtc->pipe;
> > - int ret;
> >
> > if (!crtc_state->hw.active)
> > return;
> > @@ -92,10 +120,17 @@ static void intel_crtc_disable_noatomic(struct
> > intel_crtc *crtc,
> > to_intel_atomic_state(state)->internal = true;
> >
> > /* Everything's already locked, -EDEADLK can't happen. */
> > - temp_crtc_state = intel_atomic_get_crtc_state(state, crtc);
> > - ret = drm_atomic_add_affected_connectors(state, &crtc->base);
> > + for_each_intel_crtc_in_pipe_mask(&i915->drm, temp_crtc,
> > +BIT(pipe) |
> > +
> > intel_crtc_bigjoiner_slave_pipes(crtc_state)) {
> > + struct intel_crtc_state *temp_crtc_state =
> > + intel_atomic_get_crtc_state(state, temp_crtc);
> > + int ret;
> >
> > - drm_WARN_ON(&i915->drm, IS_ERR(temp_crtc_state) || ret);
> > + ret = drm_atomic_add_affected_connectors(state,
> > &temp_crtc->base);
> > +
> > + drm_WARN_ON(&i915->drm, IS_ERR(temp_crtc_state) || ret);
> > + }
>
> It's a bit weird to have this loop inside the function that
> otherwise seems to be called individually for each of the
> joined pipes. Why do we need this?
If this is called for the master pipe, calling its encoders, it will go
through the slave pipes using their CRTC states, at least in
intel_ddi_post_disable().
> > i915->display.funcs.display->crtc_disable(to_intel_atomic_state(state),
> > crtc);
> >
> > @@ -120,8 +155,7 @@ static void intel_crtc_disable_noatomic(struct
> > intel_crtc *crtc,
> > drm_WARN_ON(&i915->drm,
> > drm_atomic_set_mode_for_crtc(&crtc_state->uapi, NULL) < 0);
> >
> > - for_each_enco
Re: [Intel-gfx] [PATCH v3 0/5] drm/i915: Allow user to set cache at BO creation
>> On 4/28/23 17:19, Yang, Fei wrote: >>> On 4/28/23 07:47, fei.y...@intel.com wrote: From: Fei Yang The first three patches in this series are taken from https://patchwork.freedesktop.org/series/116868/ These patches are included here because the last patch has dependency on the pat_index refactor. This series is focusing on uAPI changes, 1. end support for set caching ioctl [PATCH 4/5] 2. add set_pat extension for gem_create [PATCH 5/5] v2: drop one patch that was merged separately 341ad0e8e254 drm/i915/mtl: Add PTE encode function v3: rebase on https://patchwork.freedesktop.org/series/117082/ >>> >>> Hi, Fei. >>> >>> Does this uAPI update also affect any discrete GPUs supported by i915, >> >> It does. >> >>> And in that case, does it allow setting non-snooping PAT indices on >>> those devices? >> >> It allows setting PAT indices specified in >> KMD does a sanity check so that it won't go over the max recommended >> by bspec. >> >>> If so, since the uAPI for discrete GPU devices doesn't allow incoherency >>> between GPU and CPU (apart from write-combining buffering), the correct >>> CPU caching mode matching the PAT index needs to be selected for the >>> buffer object in i915_ttm_select_tt_caching(). >> >> The patch doesn't affect the CPU caching mode setting logic though. >> And the caching settings for objects created by kernel should remain >> the same for both CPU and GPU, objects created by userspace are >> managed completely by userspace. >> >> One question though, what do you mean by non-snooping PAT indices? > > Yes, that was actually the bottom question: What do these PAT settings > allow you to do WRT the snooping on supported discrete devices (DG2) on > i915? > If they indeed don't allow disabling snooping, then that's not a problem. When dGPU's access SysMem, the PCIe default is for that access to snoop the host's caches. All of our current dGPU's do that -- independent of PAT setting. > If they do, the ttm code there needs some modification. I'm not familiar with ttm, but if your concern is that certain PAT index could disable snooping, that is not possible for current dGPU's. I think it is possible for Xe2/3 though, because there will be COH_MODE defined in the PAT registers going forward. -Fei
Re: [Intel-gfx] [PATCH 05/11] drm/i915: Add support for disabling any CRTCs during HW readout/sanitization
On Fri, Apr 28, 2023 at 08:22:54PM +0300, Imre Deak wrote:
> On Fri, Apr 28, 2023 at 05:02:35PM +0300, Ville Syrjälä wrote:
> > On Wed, Apr 26, 2023 at 07:52:59PM +0300, Imre Deak wrote:
> > > During HW readout/sanitization CRTCs can be disabled only if they don't
> > > have an attached encoder (and so the encoder disable hooks don't need to
> > > be called). An upcoming patch will need to disable CRTCs also with an
> > > attached an encoder, so add support for this.
> > >
> > > For bigjoiner configs the encoder disabling hooks require the slave CRTC
> > > states, so add these too to the atomic state. Since the connector atomic
> > > state is already up-to-date when the CRTC is disabled the connector
> > > state needs to be updated (reset) after the CRTC is disabled, make this
> > > so. Follow the proper order of disabling first all bigjoiner slaves,
> > > then any port synced CRTC slaves followed by the CRTC originally
> > > requested to be disabled.
> > >
> > > Signed-off-by: Imre Deak
> > > ---
> > > .../drm/i915/display/intel_modeset_setup.c| 124 --
> > > 1 file changed, 115 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_modeset_setup.c
> > > b/drivers/gpu/drm/i915/display/intel_modeset_setup.c
> > > index a66085cf82bab..f613c074187a2 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_modeset_setup.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_modeset_setup.c
> > > @@ -50,10 +50,39 @@ static void set_encoder_for_connector(struct
> > > intel_connector *connector,
> > > }
> > > }
> > >
> > > +static void reset_encoder_connector_state(struct intel_encoder *encoder)
> > > +{
> > > + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> > > + struct intel_connector *connector;
> > > + struct drm_connector_list_iter conn_iter;
> > > +
> > > + drm_connector_list_iter_begin(&i915->drm, &conn_iter);
> > > + for_each_intel_connector_iter(connector, &conn_iter) {
> > > + if (connector->base.encoder != &encoder->base)
> > > + continue;
> > > +
> > > + set_encoder_for_connector(connector, NULL);
> > > +
> > > + connector->base.dpms = DRM_MODE_DPMS_OFF;
> > > + connector->base.encoder = NULL;
> > > + }
> > > + drm_connector_list_iter_end(&conn_iter);
> > > +}
> > > +
> > > +static void reset_crtc_encoder_state(struct intel_crtc *crtc)
> > > +{
> > > + struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> > > + struct intel_encoder *encoder;
> > > +
> > > + for_each_encoder_on_crtc(&i915->drm, &crtc->base, encoder) {
> > > + reset_encoder_connector_state(encoder);
> > > + encoder->base.crtc = NULL;
> > > + }
> > > +}
> > > +
> > > static void intel_crtc_disable_noatomic(struct intel_crtc *crtc,
> > > struct drm_modeset_acquire_ctx *ctx)
> > > {
> > > - struct intel_encoder *encoder;
> > > struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> > > struct intel_bw_state *bw_state =
> > > to_intel_bw_state(i915->display.bw.obj.state);
> > > @@ -65,9 +94,8 @@ static void intel_crtc_disable_noatomic(struct
> > > intel_crtc *crtc,
> > > to_intel_crtc_state(crtc->base.state);
> > > struct intel_plane *plane;
> > > struct drm_atomic_state *state;
> > > - struct intel_crtc_state *temp_crtc_state;
> > > + struct intel_crtc *temp_crtc;
> > > enum pipe pipe = crtc->pipe;
> > > - int ret;
> > >
> > > if (!crtc_state->hw.active)
> > > return;
> > > @@ -92,10 +120,17 @@ static void intel_crtc_disable_noatomic(struct
> > > intel_crtc *crtc,
> > > to_intel_atomic_state(state)->internal = true;
> > >
> > > /* Everything's already locked, -EDEADLK can't happen. */
> > > - temp_crtc_state = intel_atomic_get_crtc_state(state, crtc);
> > > - ret = drm_atomic_add_affected_connectors(state, &crtc->base);
> > > + for_each_intel_crtc_in_pipe_mask(&i915->drm, temp_crtc,
> > > + BIT(pipe) |
> > > +
> > > intel_crtc_bigjoiner_slave_pipes(crtc_state)) {
> > > + struct intel_crtc_state *temp_crtc_state =
> > > + intel_atomic_get_crtc_state(state, temp_crtc);
> > > + int ret;
> > >
> > > - drm_WARN_ON(&i915->drm, IS_ERR(temp_crtc_state) || ret);
> > > + ret = drm_atomic_add_affected_connectors(state,
> > > &temp_crtc->base);
> > > +
> > > + drm_WARN_ON(&i915->drm, IS_ERR(temp_crtc_state) || ret);
> > > + }
> >
> > It's a bit weird to have this loop inside the function that
> > otherwise seems to be called individually for each of the
> > joined pipes. Why do we need this?
>
> If this is called for the master pipe, calling its encoders, it will go
> through the slave pipes using their CRTC states, at least in
> intel_ddi_post_disable().
>
> > > i915->display.funcs.display->crtc_disable(to_intel_atomic_state(state),
> > > crtc);
> > >
> > > @@ -120,8 +155,7 @@ static void intel_cr
[Intel-gfx] ✓ Fi.CI.BAT: success for dma-buf/dma-fence: Use a successful read_trylock() annotation for dma_fence_begin_signalling()
== Series Details ==
Series: dma-buf/dma-fence: Use a successful read_trylock() annotation for
dma_fence_begin_signalling()
URL : https://patchwork.freedesktop.org/series/117115/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13073 -> Patchwork_117115v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117115v1/index.html
Participating hosts (39 -> 37)
--
Missing(2): fi-snb-2520m bat-mtlp-6
Known issues
Here are the changes found in Patchwork_117115v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@gt_heartbeat:
- fi-apl-guc: [PASS][1] -> [DMESG-FAIL][2] ([i915#5334])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13073/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117115v1/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@hangcheck:
- fi-skl-guc: [PASS][3] -> [DMESG-WARN][4] ([i915#8073])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13073/fi-skl-guc/igt@i915_selftest@l...@hangcheck.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117115v1/fi-skl-guc/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@slpc:
- bat-adln-1: NOTRUN -> [DMESG-FAIL][5] ([i915#6997])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117115v1/bat-adln-1/igt@i915_selftest@l...@slpc.html
* igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-adln-1: NOTRUN -> [SKIP][6] ([i915#7828])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117115v1/bat-adln-1/igt@kms_chamelium_...@common-hpd-after-suspend.html
* igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence:
- bat-dg2-11: NOTRUN -> [SKIP][7] ([i915#1845] / [i915#5354])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117115v1/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html
Possible fixes
* igt@i915_selftest@live@gt_lrc:
- bat-adln-1: [INCOMPLETE][8] ([i915#4983] / [i915#7609]) ->
[PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13073/bat-adln-1/igt@i915_selftest@live@gt_lrc.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117115v1/bat-adln-1/igt@i915_selftest@live@gt_lrc.html
* igt@kms_pipe_crc_basic@nonblocking-crc@pipe-d-dp-1:
- bat-dg2-8: [FAIL][10] ([i915#7932]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13073/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117115v1/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html
Warnings
* igt@i915_selftest@live@slpc:
- bat-rpls-1: [DMESG-FAIL][12] ([i915#6367] / [i915#6997]) ->
[DMESG-FAIL][13] ([i915#6367] / [i915#6997] / [i915#7996])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13073/bat-rpls-1/igt@i915_selftest@l...@slpc.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117115v1/bat-rpls-1/igt@i915_selftest@l...@slpc.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
[i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
[i915#7609]: https://gitlab.freedesktop.org/drm/intel/issues/7609
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
[i915#7920]: https://gitlab.freedesktop.org/drm/intel/issues/7920
[i915#7932]: https://gitlab.freedesktop.org/drm/intel/issues/7932
[i915#7996]: https://gitlab.freedesktop.org/drm/intel/issues/7996
[i915#8073]: https://gitlab.freedesktop.org/drm/intel/issues/8073
Build changes
-
* Linux: CI_DRM_13073 -> Patchwork_117115v1
CI-20190529: 20190529
CI_DRM_13073: d4602c57ac02d66526e4785b80c2e01dea122f33 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7275: c284bd66d7b416b4eaca456d6085b9180ad58058 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_117115v1: d4602c57ac02d66526e4785b80c2e01dea122f33 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
75770c0f4f54 dma-buf/dma-fence: Use a successful read_trylock() annotation for
dma_fence_begin_signalling()
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117115v1/index.html
Re: [Intel-gfx] [PATCH v2 01/13] drm/i915/mtl: C20 PLL programming
On Fri, Apr 28, 2023 at 12:54:21PM +0300, Mika Kahola wrote:
> C20 phy PLL programming sequence for DP, DP2.0, HDMI2.x non-FRL and
> HDMI2.x FRL. This enables C20 MPLLA and MPLLB programming sequence. add
> 4 lane support for c20.
>
> v2: Add 6.48Gbps and 6.75Gbps modes for eDP (RK)
> Fix lane check (RK)
> Fix multiline commenting (Arun)
> use usleep_range() instead of msleep() (Andi)
>
> Reviewed-by: Arun R Murthy
LGTM,
Reviewed-by: Radhakrishna Sripada
> Signed-off-by: José Roberto de Souza
> Signed-off-by: Mika Kahola
> Signed-off-by: Bhanuprakash Modem
> Signed-off-by: Imre Deak
> Signed-off-by: Arun R Murthy
> ---
> drivers/gpu/drm/i915/display/intel_cx0_phy.c | 288 +++---
> .../gpu/drm/i915/display/intel_cx0_phy_regs.h | 33 ++
> drivers/gpu/drm/i915/display/intel_ddi.c | 3 +-
> .../drm/i915/display/intel_display_types.h| 15 +-
> drivers/gpu/drm/i915/display/intel_dp.c | 12 +-
> 5 files changed, 309 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> index 83180074b512..71163bc5bbf5 100644
> --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> @@ -273,6 +273,18 @@ static void intel_cx0_write(struct drm_i915_private
> *i915, enum port port,
> __intel_cx0_write(i915, port, lane, addr, data, committed);
> }
>
> +static void intel_c20_sram_write(struct drm_i915_private *i915, enum port
> port,
> + int lane, u16 addr, u16 data)
> +{
> + assert_dc_off(i915);
> +
> + intel_cx0_write(i915, port, lane, PHY_C20_WR_ADDRESS_H, addr >> 8, 0);
> + intel_cx0_write(i915, port, lane, PHY_C20_WR_ADDRESS_L, addr & 0xff, 0);
> +
> + intel_cx0_write(i915, port, lane, PHY_C20_WR_DATA_H, data >> 8, 0);
> + intel_cx0_write(i915, port, lane, PHY_C20_WR_DATA_L, data & 0xff, 1);
> +}
> +
> static void __intel_cx0_rmw(struct drm_i915_private *i915, enum port port,
> int lane, u16 addr, u8 clear, u8 set, bool
> committed)
> {
> @@ -1415,6 +1427,215 @@ void intel_c10pll_dump_hw_state(struct
> drm_i915_private *i915,
> i + 2, hw_state->pll[i + 2], i + 3, hw_state->pll[i
> + 3]);
> }
>
> +static bool intel_c20_use_mplla(u32 clock)
> +{
> + /* 10G and 20G rates use MPLLA */
> + if (clock == 312500 || clock == 625000)
> + return true;
> +
> + return false;
> +}
> +
> +static u8 intel_c20_get_dp_rate(u32 clock)
> +{
> + switch (clock) {
> + case 162000: /* 1.62 Gbps DP1.4 */
> + return 0;
> + case 27: /* 2.7 Gbps DP1.4 */
> + return 1;
> + case 54: /* 5.4 Gbps DP 1.4 */
> + return 2;
> + case 81: /* 8.1 Gbps DP1.4 */
> + return 3;
> + case 216000: /* 2.16 Gbps eDP */
> + return 4;
> + case 243000: /* 2.43 Gbps eDP */
> + return 5;
> + case 324000: /* 3.24 Gbps eDP */
> + return 6;
> + case 432000: /* 4.32 Gbps eDP */
> + return 7;
> + case 312500: /* 10 Gbps DP2.0 */
> + return 8;
> + case 421875: /* 13.5 Gbps DP2.0 */
> + return 9;
> + case 625000: /* 20 Gbps DP2.0*/
> + return 10;
> + case 648000: /* 6.48 Gbps eDP*/
> + return 11;
> + case 675000: /* 6.75 Gbps eDP*/
> + return 12;
> + default:
> + MISSING_CASE(clock);
> + return 0;
> + }
> +}
> +
> +static u8 intel_c20_get_hdmi_rate(u32 clock)
> +{
> + switch (clock) {
> + case 25175:
> + case 27000:
> + case 74250:
> + case 148500:
> + case 594000:
> + return 0;
> + case 166670: /* 3 Gbps */
> + case 30: /* 6 Gbps */
> + case 70: /* 12 Gbps */
> + return 1;
> + case 40: /* 8 Gbps */
> + return 2;
> + case 60: /* 10 Gbps */
> + return 3;
> + default:
> + MISSING_CASE(clock);
> + return 0;
> + }
> +}
> +
> +static bool is_dp2(u32 clock)
> +{
> + /* DP2.0 clock rates */
> + if (clock == 312500 || clock == 421875 || clock == 625000)
> + return true;
> +
> + return false;
> +}
> +
> +static bool is_hdmi_frl(u32 clock)
> +{
> + switch (clock) {
> + case 166670: /* 3 Gbps */
> + case 30: /* 6 Gbps */
> + case 40: /* 8 Gbps */
> + case 60: /* 10 Gbps */
> + case 70: /* 12 Gbps */
> + return true;
> + default:
> + return false;
> + }
> +}
> +
> +static bool intel_c20_protocol_switch_valid(struct intel_encoder *encoder)
> +{
> + struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
> +
> + /* banks should not be cleared for DPALT/USB4/TBT modes */
> + /* TODO: optimize re-calibration in legacy mode */
> + return intel_tc_por
Re: [Intel-gfx] [PATCH 1/5] drm/i915/guc: Don't capture Gen8 regs on Xe devices
On 4/26/2023 14:14, Teres Alexis, Alan Previn wrote:
On Wed, 2023-04-26 at 10:23 -0700, Harrison, John C wrote:
On 4/25/2023 10:55, Teres Alexis, Alan Previn wrote:
On Thu, 2023-04-06 at 15:26 -0700, Harrison, John C wrote:
From: John Harrison
A pair of pre-Xe registers were being included in the Xe capture list.
GuC was rejecting those as being invalid and logging errors about
them. So, stop doing it.
alan:snip
#define COMMON_GEN9BASE_GLOBAL \
- { GEN8_FAULT_TLB_DATA0, 0, 0, "GEN8_FAULT_TLB_DATA0" }, \
- { GEN8_FAULT_TLB_DATA1, 0, 0, "GEN8_FAULT_TLB_DATA1" }, \
{ ERROR_GEN6, 0, 0, "ERROR_GEN6" }, \
{ DONE_REG, 0, 0, "DONE_REG" }, \
{ HSW_GTT_CACHE_EN, 0, 0, "HSW_GTT_CACHE_EN" }
+#define GEN9_GLOBAL \
+ { GEN8_FAULT_TLB_DATA0, 0, 0, "GEN8_FAULT_TLB_DATA0" }, \
+ { GEN8_FAULT_TLB_DATA1, 0, 0, "GEN8_FAULT_TLB_DATA1" }
+
#define COMMON_GEN12BASE_GLOBAL \
{ GEN12_FAULT_TLB_DATA0,0, 0, "GEN12_FAULT_TLB_DATA0" }, \
{ GEN12_FAULT_TLB_DATA1,0, 0, "GEN12_FAULT_TLB_DATA1" }, \
@@ -142,6 +144,7 @@ static const struct __guc_mmio_reg_descr
xe_lpd_gsc_inst_regs[] = {
static const struct __guc_mmio_reg_descr default_global_regs[] = {
COMMON_BASE_GLOBAL,
COMMON_GEN9BASE_GLOBAL,
+ GEN9_GLOBAL,
};
alan: splitting out a couple registers from COMMON_GEN9BASE_GLOBAL into
GEN9_GLOBAL
doesn't seem to communicate the intent of fix for this patch. This is more of a
naming,
thing and i am not sure what counter-proposal will work well in terms of
readibility.
One idea: perhaps we rename "COMMON_GEN9BASE_GLOBAL" to
"COMMON_GEN9PLUS_BASE_GLOBAL"
and rename GEN9_GLOBAL to COMMON_GEN9LEGACY_GLOBAL. so we would have two
gen9-global
with a clear distinction in naming where one is "GEN9PLUS" and the other is
"GEN9LEGACY".
But since this is a list-naming thing, i am okay either above change... OR...
keeping the same but with the condition of adding a comment under
COMMON_GEN9BASE_GLOBAL and GEN9_GLOBAL names that explain the differences where
one
is gen9-legacy and the other is gen9-and-future that carries over to beyond
Gen9.
(side note: coding style wise, is it possible to add the comment right under
the #define
line as opposed to under the entire list?)
(conditional) Reviewed-by: Alan Previn
I'm not entirely sure what you are arguing here.
My reading of the original code is that COMMON_GENX_ means the registers
were introduced on the named device but a are common to later devices.
Whereas GENX_ means the registers are specific to that device alone.
That seems a pretty straight forward and simple naming scheme to me.
John.
alan: you said "reading of the original code is that COMMON_GENX_
means the registers were introduced on the named device but a are
common to later devices".
That wasnt the original intent when authored. The original intent
was list names and its comments to corresponded to what platforms we
supported (thats why the first patch was all of Gen12 registers in a
single list that included Gen8/9 register definitions and Gen9 sublists
got abstracted out later).
I'm okay with changing the intent of the list naming - but your code still
looks a bit off considering you have at least one list with two sublists
that carry the term "GEN9":
static const struct __guc_mmio_reg_descr default_global_regs[] = {
COMMON_BASE_GLOBAL,
COMMON_GEN9BASE_GLOBAL,
GEN9_GLOBAL,
Again, i feel the name of these two sublists ("COMMON_GEN9BASE_GLOBAL" vs
"GEN9_GLOBAL") dont easily portray differences and why they were separated
out. If they both reflect "when the named register got introduced", then
why not just have them in the same list? Since this patch is not
about "when a register got introduced" but "pre-Xe registers are not
recognized by GuC on Xe", then perhaps we can change the names to:
COMMON_GEN9BASE_GLOBAL -> [same]
GEN9_GLOBAL -> PREXE_GEN9_GLOBAL
PREXE_GEN9_... just sounds confused to me. What is Gen9 if it is not PreXe?
The point is to ensure that platform specific register lists are
constructed from the sublists that apply to that platform. Therefore the
sublists are named for the platform they apply to. Thus the gen8 list
should only contain gen8 sub-lists. The Xe list can contain Xe sublists
together with gen8 sublists that are still applicable. Those sublists
have a COMMON_ prefix if they are expected to be multi-platform and
don't if they are specific to their one named platform.
Note that you can't get hung on 'the end result looks odd' when only
looking at the first step of a whole series of cleanups. This patch is
specifically about moving the pre-Xe registers out of the COMMON_ define
so that they are not used on Xe. It is not trying to fix up all the
naming and other issues.
John.
Either way, i rather not argue about varia
Re: [Intel-gfx] [PATCH 10/11] drm/i915: Factor out call_with_modeset_ctx()
On Fri, Apr 28, 2023 at 05:32:44PM +0300, Ville Syrjälä wrote:
> On Wed, Apr 26, 2023 at 07:53:04PM +0300, Imre Deak wrote:
> > Factor out a helper to call a function with the atomic locks held,
> > required by a follow-up patch resetting an active DP link.
> >
> > No functional changes.
> >
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/display/intel_ddi.c | 53 ++--
> > 1 file changed, 31 insertions(+), 22 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index 29e4bfab46358..0c8bc32f293b0 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -4370,35 +4370,18 @@ static int intel_hdmi_reset_link(struct
> > intel_encoder *encoder,
> > return modeset_pipe(&crtc->base, ctx);
> > }
> >
> > -static enum intel_hotplug_state
> > -intel_ddi_hotplug(struct intel_encoder *encoder,
> > - struct intel_connector *connector)
> > +static void call_with_modeset_ctx(int (*fn)(struct intel_encoder *encoder,
> > + struct drm_modeset_acquire_ctx
> > *ctx),
> > + struct intel_encoder *encoder)
> > {
> > struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> > - struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
> > - struct intel_dp *intel_dp = &dig_port->dp;
> > - enum phy phy = intel_port_to_phy(i915, encoder->port);
> > - bool is_tc = intel_phy_is_tc(i915, phy);
> > struct drm_modeset_acquire_ctx ctx;
> > - enum intel_hotplug_state state;
> > int ret;
> >
> > - if (intel_dp->compliance.test_active &&
> > - intel_dp->compliance.test_type == DP_TEST_LINK_PHY_TEST_PATTERN) {
> > - intel_dp_phy_test(encoder);
> > - /* just do the PHY test and nothing else */
> > - return INTEL_HOTPLUG_UNCHANGED;
> > - }
> > -
> > - state = intel_encoder_hotplug(encoder, connector);
> > -
> > drm_modeset_acquire_init(&ctx, 0);
> >
> > for (;;) {
> > - if (connector->base.connector_type == DRM_MODE_CONNECTOR_HDMIA)
> > - ret = intel_hdmi_reset_link(encoder, &ctx);
> > - else
> > - ret = intel_dp_retrain_link(encoder, &ctx);
> > + ret = fn(encoder, &ctx);
> >
> > if (ret == -EDEADLK) {
> > drm_modeset_backoff(&ctx);
> > @@ -4410,8 +4393,34 @@ intel_ddi_hotplug(struct intel_encoder *encoder,
> >
> > drm_modeset_drop_locks(&ctx);
> > drm_modeset_acquire_fini(&ctx);
> > - drm_WARN(encoder->base.dev, ret,
> > + drm_WARN(&i915->drm, ret,
> > "Acquiring modeset locks failed with %i\n", ret);
> > +}
>
> Seems pretty much a less general version of
> https://patchwork.freedesktop.org/series/92607/
> Unfortuantely that died in the bikeshed.
>
> Maybe we should look into doing something like that
> just for i915 initially...
Yes, looks better, can adopt an i915 version of that unless you want to
do that.
>
> > +
> > +static enum intel_hotplug_state
> > +intel_ddi_hotplug(struct intel_encoder *encoder,
> > + struct intel_connector *connector)
> > +{
> > + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> > + struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
> > + struct intel_dp *intel_dp = &dig_port->dp;
> > + enum phy phy = intel_port_to_phy(i915, encoder->port);
> > + bool is_tc = intel_phy_is_tc(i915, phy);
> > + enum intel_hotplug_state state;
> > +
> > + if (intel_dp->compliance.test_active &&
> > + intel_dp->compliance.test_type == DP_TEST_LINK_PHY_TEST_PATTERN) {
> > + intel_dp_phy_test(encoder);
> > + /* just do the PHY test and nothing else */
> > + return INTEL_HOTPLUG_UNCHANGED;
> > + }
> > +
> > + state = intel_encoder_hotplug(encoder, connector);
> > +
> > + if (connector->base.connector_type == DRM_MODE_CONNECTOR_HDMIA)
> > + call_with_modeset_ctx(intel_hdmi_reset_link, encoder);
> > + else
> > + call_with_modeset_ctx(intel_dp_retrain_link, encoder);
> >
> > /*
> > * Unpowered type-c dongles can take some time to boot and be
> > --
> > 2.37.2
>
> --
> Ville Syrjälä
> Intel
[Intel-gfx] [PATCH v2 4/4] drm/i915/guc: Fix error capture for virtual engines
From: John Harrison
GuC based register dumps in error capture logs were basically broken
for virtual engines. This can be seen in igt@gem_exec_balancer@hang:
[IGT] gem_exec_balancer: starting subtest hang
[drm] GPU HANG: ecode 12:4:e1524110, in gem_exec_balanc [6388]
[drm] GT0: GUC: No register capture node found for 0x1005 / 0xFEDC311D
[drm] GPU HANG: ecode 12:4:, in gem_exec_balanc [6388]
[IGT] gem_exec_balancer: exiting, ret=0
The test causes a hang on both engines of a virtual engine context.
The engine instance zero hang gets a valid error capture but the
non-instance-zero hang does not.
Fix that by scanning through the list of pending register captures
when a hang notification for a virtual engine is received. That way,
the hang can be assigned to the correct physical engine prior to
starting the error capture process. So later on, when the error capture
handler tries to find the engine register list, it looks for one on
the correct engine.
Also, sneak in a missing blank line before a comment in the node
search code.
v2: Fix null pointer deref on non-GuC platforms.
Signed-off-by: John Harrison
Reviewed-by: Alan Previn
---
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 31 ++
.../gpu/drm/i915/gt/uc/intel_guc_capture.h| 3 ++
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 32 ---
drivers/gpu/drm/i915/i915_gpu_error.c | 11 +--
4 files changed, 70 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
index 729a8fcf20dda..1def0b6467c79 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
@@ -1540,6 +1540,36 @@ void intel_guc_capture_free_node(struct
intel_engine_coredump *ee)
ee->guc_capture_node = NULL;
}
+bool intel_guc_capture_is_matching_engine(struct intel_gt *gt,
+ struct intel_context *ce,
+ struct intel_engine_cs *engine)
+{
+ struct __guc_capture_parsed_output *n;
+ struct intel_guc *guc;
+
+ if (!gt || !ce || !engine)
+ return false;
+
+ guc = >->uc.guc;
+ if (!guc->capture)
+ return false;
+
+ /*
+* Look for a matching GuC reported error capture node from
+* the internal output link-list based on lrca, guc-id and engine
+* identification.
+*/
+ list_for_each_entry(n, &guc->capture->outlist, link) {
+ if (n->eng_inst == GUC_ID_TO_ENGINE_INSTANCE(engine->guc_id) &&
+ n->eng_class == GUC_ID_TO_ENGINE_CLASS(engine->guc_id) &&
+ n->guc_id == ce->guc_id.id &&
+ (n->lrca & CTX_GTT_ADDRESS_MASK) == (ce->lrc.lrca &
CTX_GTT_ADDRESS_MASK))
+ return true;
+ }
+
+ return false;
+}
+
void intel_guc_capture_get_matching_node(struct intel_gt *gt,
struct intel_engine_coredump *ee,
struct intel_context *ce)
@@ -1555,6 +1585,7 @@ void intel_guc_capture_get_matching_node(struct intel_gt
*gt,
return;
GEM_BUG_ON(ee->guc_capture_node);
+
/*
* Look for a matching GuC reported error capture node from
* the internal output link-list based on lrca, guc-id and engine
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.h
index fbd3713c7832d..302256d45431d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.h
@@ -11,6 +11,7 @@
struct drm_i915_error_state_buf;
struct guc_gt_system_info;
struct intel_engine_coredump;
+struct intel_engine_cs;
struct intel_context;
struct intel_gt;
struct intel_guc;
@@ -20,6 +21,8 @@ int intel_guc_capture_print_engine_node(struct
drm_i915_error_state_buf *m,
const struct intel_engine_coredump *ee);
void intel_guc_capture_get_matching_node(struct intel_gt *gt, struct
intel_engine_coredump *ee,
struct intel_context *ce);
+bool intel_guc_capture_is_matching_engine(struct intel_gt *gt, struct
intel_context *ce,
+ struct intel_engine_cs *engine);
void intel_guc_capture_process(struct intel_guc *guc);
int intel_guc_capture_getlist(struct intel_guc *guc, u32 owner, u32 type, u32
classid,
void **outptr);
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 ee3e8352637f2..b93fe27b4eaae 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -4697,13 +4697,37 @@ static void capture_error_state(struct intel_guc *guc,
{
struct intel_gt *gt = gu
[Intel-gfx] [PATCH v2 2/4] drm/i915/guc: Consolidate duplicated capture list code
From: John Harrison
Remove 99% duplicated steered register list code. Also, include the
pre-Xe steered registers in the pre-Xe list generation.
Signed-off-by: John Harrison
Reviewed-by: Alan Previn
---
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 112 +-
1 file changed, 29 insertions(+), 83 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
index e0e793167d61b..9184d2595e4ce 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
@@ -260,11 +260,15 @@ struct __ext_steer_reg {
i915_mcr_reg_t reg;
};
-static const struct __ext_steer_reg xe_extregs[] = {
+static const struct __ext_steer_reg gen8_extregs[] = {
{"GEN8_SAMPLER_INSTDONE", GEN8_SAMPLER_INSTDONE},
{"GEN8_ROW_INSTDONE", GEN8_ROW_INSTDONE}
};
+static const struct __ext_steer_reg xehpg_extregs[] = {
+ {"XEHPG_INSTDONE_GEOM_SVG", XEHPG_INSTDONE_GEOM_SVG}
+};
+
static void __fill_ext_reg(struct __guc_mmio_reg_descr *ext,
const struct __ext_steer_reg *extlist,
int slice_id, int subslice_id)
@@ -295,8 +299,8 @@ __alloc_ext_regs(struct __guc_mmio_reg_descr_group *newlist,
}
static void
-guc_capture_alloc_steered_lists_xe_lpd(struct intel_guc *guc,
- const struct __guc_mmio_reg_descr_group
*lists)
+guc_capture_alloc_steered_lists(struct intel_guc *guc,
+ const struct __guc_mmio_reg_descr_group *lists)
{
struct intel_gt *gt = guc_to_gt(guc);
int slice, subslice, iter, i, num_steer_regs, num_tot_regs = 0;
@@ -304,74 +308,19 @@ guc_capture_alloc_steered_lists_xe_lpd(struct intel_guc
*guc,
struct __guc_mmio_reg_descr_group *extlists;
struct __guc_mmio_reg_descr *extarray;
struct sseu_dev_info *sseu;
+ bool has_xehpg_extregs;
- /* In XE_LPD we only have steered registers for the render-class */
+ /* steered registers currently only exist for the render-class */
list = guc_capture_get_one_list(lists, GUC_CAPTURE_LIST_INDEX_PF,
GUC_CAPTURE_LIST_TYPE_ENGINE_CLASS,
GUC_RENDER_CLASS);
/* skip if extlists was previously allocated */
if (!list || guc->capture->extlists)
return;
- num_steer_regs = ARRAY_SIZE(xe_extregs);
-
- sseu = >->info.sseu;
- for_each_ss_steering(iter, gt, slice, subslice)
- num_tot_regs += num_steer_regs;
-
- if (!num_tot_regs)
- return;
-
- /* allocate an extra for an end marker */
- extlists = kcalloc(2, sizeof(struct __guc_mmio_reg_descr_group),
GFP_KERNEL);
- if (!extlists)
- return;
-
- if (__alloc_ext_regs(&extlists[0], list, num_tot_regs)) {
- kfree(extlists);
- return;
- }
-
- extarray = extlists[0].extlist;
- for_each_ss_steering(iter, gt, slice, subslice) {
- for (i = 0; i < num_steer_regs; ++i) {
- __fill_ext_reg(extarray, &xe_extregs[i], slice,
subslice);
- ++extarray;
- }
- }
-
- guc->capture->extlists = extlists;
-}
-
-static const struct __ext_steer_reg xehpg_extregs[] = {
- {"XEHPG_INSTDONE_GEOM_SVG", XEHPG_INSTDONE_GEOM_SVG}
-};
-
-static bool __has_xehpg_extregs(u32 ipver)
-{
- return (ipver >= IP_VER(12, 55));
-}
-
-static void
-guc_capture_alloc_steered_lists_xe_hpg(struct intel_guc *guc,
- const struct __guc_mmio_reg_descr_group
*lists,
- u32 ipver)
-{
- struct intel_gt *gt = guc_to_gt(guc);
- struct sseu_dev_info *sseu;
- int slice, subslice, i, iter, num_steer_regs, num_tot_regs = 0;
- const struct __guc_mmio_reg_descr_group *list;
- struct __guc_mmio_reg_descr_group *extlists;
- struct __guc_mmio_reg_descr *extarray;
-
- /* In XE_LP / HPG we only have render-class steering registers during
error-capture */
- list = guc_capture_get_one_list(lists, GUC_CAPTURE_LIST_INDEX_PF,
- GUC_CAPTURE_LIST_TYPE_ENGINE_CLASS,
GUC_RENDER_CLASS);
- /* skip if extlists was previously allocated */
- if (!list || guc->capture->extlists)
- return;
+ has_xehpg_extregs = GRAPHICS_VER_FULL(gt->i915) >= IP_VER(12, 55);
- num_steer_regs = ARRAY_SIZE(xe_extregs);
- if (__has_xehpg_extregs(ipver))
+ num_steer_regs = ARRAY_SIZE(gen8_extregs);
+ if (has_xehpg_extregs)
num_steer_regs += ARRAY_SIZE(xehpg_extregs);
sseu = >->info.sseu;
@@ -393,11 +342,12 @@ guc_capture_alloc_steered_lists_xe_hpg(struct intel_guc
*guc,
extarray = extlists[0].extlist;
for_each_ss_steering(iter, gt, slice, subslice) {
-
[Intel-gfx] [PATCH v2 1/4] drm/i915/guc: Don't capture Gen8 regs on Xe devices
From: John Harrison
A pair of pre-Xe registers were being included in the Xe capture list.
GuC was rejecting those as being invalid and logging errors about
them. So, stop doing it.
Signed-off-by: John Harrison
Reviewed-by: Alan Previn
Fixes: dce2bd542337 ("drm/i915/guc: Add Gen9 registers for GuC error state
capture.")
Cc: Alan Previn
Cc: Umesh Nerlige Ramappa
Cc: Lucas De Marchi
Cc: John Harrison
Cc: Jani Nikula
Cc: Matt Roper
Cc: Balasubramani Vivekanandan
Cc: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
index cf49188db6a6e..e0e793167d61b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
@@ -31,12 +31,14 @@
{ FORCEWAKE_MT, 0, 0, "FORCEWAKE" }
#define COMMON_GEN9BASE_GLOBAL \
- { GEN8_FAULT_TLB_DATA0, 0, 0, "GEN8_FAULT_TLB_DATA0" }, \
- { GEN8_FAULT_TLB_DATA1, 0, 0, "GEN8_FAULT_TLB_DATA1" }, \
{ ERROR_GEN6, 0, 0, "ERROR_GEN6" }, \
{ DONE_REG, 0, 0, "DONE_REG" }, \
{ HSW_GTT_CACHE_EN, 0, 0, "HSW_GTT_CACHE_EN" }
+#define GEN9_GLOBAL \
+ { GEN8_FAULT_TLB_DATA0, 0, 0, "GEN8_FAULT_TLB_DATA0" }, \
+ { GEN8_FAULT_TLB_DATA1, 0, 0, "GEN8_FAULT_TLB_DATA1" }
+
#define COMMON_GEN12BASE_GLOBAL \
{ GEN12_FAULT_TLB_DATA0,0, 0, "GEN12_FAULT_TLB_DATA0" }, \
{ GEN12_FAULT_TLB_DATA1,0, 0, "GEN12_FAULT_TLB_DATA1" }, \
@@ -142,6 +144,7 @@ static const struct __guc_mmio_reg_descr
xe_lpd_gsc_inst_regs[] = {
static const struct __guc_mmio_reg_descr default_global_regs[] = {
COMMON_BASE_GLOBAL,
COMMON_GEN9BASE_GLOBAL,
+ GEN9_GLOBAL,
};
static const struct __guc_mmio_reg_descr default_rc_class_regs[] = {
--
2.39.1
[Intel-gfx] [PATCH v2 0/4] Improvements to GuC error capture
From: John Harrison The GuC error capture list creation was including Gen8 registers on Xe platforms. While fixing that, it was noticed that there were other issues. The platform naming was wrong, the naming of lists was misleading, the steered register code was duplicated and steered registers were not included on all supported platforms. Separately, it was noticed that the capture list search was broken for virtual engines. So fix that up too. v2: Swuash the split patches into a single patch ready for merge. Also include an extra patch about capture lists and virtual engines. Signed-off-by: John Harrison John Harrison (4): drm/i915/guc: Don't capture Gen8 regs on Xe devices drm/i915/guc: Consolidate duplicated capture list code drm/i915/guc: Capture list naming clean up drm/i915/guc: Fix error capture for virtual engines .../gpu/drm/i915/gt/uc/intel_guc_capture.c| 242 -- .../gpu/drm/i915/gt/uc/intel_guc_capture.h| 3 + .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 32 ++- drivers/gpu/drm/i915/i915_gpu_error.c | 11 +- 4 files changed, 149 insertions(+), 139 deletions(-) -- 2.39.1
[Intel-gfx] [PATCH v2 3/4] drm/i915/guc: Capture list naming clean up
From: John Harrison
Don't use 'xe_lp*' prefixes for register lists that are common with
Gen8.
Don't add Xe only GSC registers to pre-Xe devices that don't
even have a GSC engine.
Fix Xe_LP name.
Don't use GEN9 as a prefix for register lists that contain all GEN8
registers.
Rename the 'default_' register list prefix to 'gen8_' as that is the
more accurate name.
Signed-off-by: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 100 +-
1 file changed, 49 insertions(+), 51 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
index 9184d2595e4ce..729a8fcf20dda 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
@@ -30,12 +30,12 @@
#define COMMON_BASE_GLOBAL \
{ FORCEWAKE_MT, 0, 0, "FORCEWAKE" }
-#define COMMON_GEN9BASE_GLOBAL \
+#define COMMON_GEN8BASE_GLOBAL \
{ ERROR_GEN6, 0, 0, "ERROR_GEN6" }, \
{ DONE_REG, 0, 0, "DONE_REG" }, \
{ HSW_GTT_CACHE_EN, 0, 0, "HSW_GTT_CACHE_EN" }
-#define GEN9_GLOBAL \
+#define GEN8_GLOBAL \
{ GEN8_FAULT_TLB_DATA0, 0, 0, "GEN8_FAULT_TLB_DATA0" }, \
{ GEN8_FAULT_TLB_DATA1, 0, 0, "GEN8_FAULT_TLB_DATA1" }
@@ -96,67 +96,65 @@
{ GEN12_SFC_DONE(2),0, 0, "SFC_DONE[2]" }, \
{ GEN12_SFC_DONE(3),0, 0, "SFC_DONE[3]" }
-/* XE_LPD - Global */
-static const struct __guc_mmio_reg_descr xe_lpd_global_regs[] = {
+/* XE_LP Global */
+static const struct __guc_mmio_reg_descr xe_lp_global_regs[] = {
COMMON_BASE_GLOBAL,
- COMMON_GEN9BASE_GLOBAL,
+ COMMON_GEN8BASE_GLOBAL,
COMMON_GEN12BASE_GLOBAL,
};
-/* XE_LPD - Render / Compute Per-Class */
-static const struct __guc_mmio_reg_descr xe_lpd_rc_class_regs[] = {
+/* XE_LP Render / Compute Per-Class */
+static const struct __guc_mmio_reg_descr xe_lp_rc_class_regs[] = {
COMMON_BASE_HAS_EU,
COMMON_BASE_RENDER,
COMMON_GEN12BASE_RENDER,
};
-/* GEN9/XE_LPD - Render / Compute Per-Engine-Instance */
-static const struct __guc_mmio_reg_descr xe_lpd_rc_inst_regs[] = {
+/* GEN8+ Render / Compute Per-Engine-Instance */
+static const struct __guc_mmio_reg_descr gen8_rc_inst_regs[] = {
COMMON_BASE_ENGINE_INSTANCE,
};
-/* GEN9/XE_LPD - Media Decode/Encode Per-Engine-Instance */
-static const struct __guc_mmio_reg_descr xe_lpd_vd_inst_regs[] = {
+/* GEN8+ Media Decode/Encode Per-Engine-Instance */
+static const struct __guc_mmio_reg_descr gen8_vd_inst_regs[] = {
COMMON_BASE_ENGINE_INSTANCE,
};
-/* XE_LPD - Video Enhancement Per-Class */
-static const struct __guc_mmio_reg_descr xe_lpd_vec_class_regs[] = {
+/* XE_LP Video Enhancement Per-Class */
+static const struct __guc_mmio_reg_descr xe_lp_vec_class_regs[] = {
COMMON_GEN12BASE_VEC,
};
-/* GEN9/XE_LPD - Video Enhancement Per-Engine-Instance */
-static const struct __guc_mmio_reg_descr xe_lpd_vec_inst_regs[] = {
+/* GEN8+ Video Enhancement Per-Engine-Instance */
+static const struct __guc_mmio_reg_descr gen8_vec_inst_regs[] = {
COMMON_BASE_ENGINE_INSTANCE,
};
-/* GEN9/XE_LPD - Blitter Per-Engine-Instance */
-static const struct __guc_mmio_reg_descr xe_lpd_blt_inst_regs[] = {
+/* GEN8+ Blitter Per-Engine-Instance */
+static const struct __guc_mmio_reg_descr gen8_blt_inst_regs[] = {
COMMON_BASE_ENGINE_INSTANCE,
};
-/* XE_LPD - GSC Per-Engine-Instance */
-static const struct __guc_mmio_reg_descr xe_lpd_gsc_inst_regs[] = {
+/* XE_LP - GSC Per-Engine-Instance */
+static const struct __guc_mmio_reg_descr xe_lp_gsc_inst_regs[] = {
COMMON_BASE_ENGINE_INSTANCE,
};
-/* GEN9 - Global */
-static const struct __guc_mmio_reg_descr default_global_regs[] = {
+/* GEN8 - Global */
+static const struct __guc_mmio_reg_descr gen8_global_regs[] = {
COMMON_BASE_GLOBAL,
- COMMON_GEN9BASE_GLOBAL,
- GEN9_GLOBAL,
+ COMMON_GEN8BASE_GLOBAL,
+ GEN8_GLOBAL,
};
-static const struct __guc_mmio_reg_descr default_rc_class_regs[] = {
+static const struct __guc_mmio_reg_descr gen8_rc_class_regs[] = {
COMMON_BASE_HAS_EU,
COMMON_BASE_RENDER,
};
/*
- * Empty lists:
- * GEN9/XE_LPD - Blitter Per-Class
- * GEN9/XE_LPD - Media Decode/Encode Per-Class
- * GEN9 - VEC Class
+ * Empty list to prevent warnings about unknown class/instance types
+ * as not all class/instanace types have entries on all platforms.
*/
static const struct __guc_mmio_reg_descr empty_regs_list[] = {
};
@@ -174,37 +172,37 @@ static const struct __guc_mmio_reg_descr
empty_regs_list[] = {
}
/* List of lists */
-static const struct __guc_mmio_reg_descr_group default_lists[] = {
- MAKE_REGLIST(default_global_regs, PF, GLOBAL, 0),
- MAKE_REGLIST(default_rc_class_regs, PF, ENGINE_CLASS, GUC_RENDER_CLASS),
- MAKE_REGLIST(xe_lpd_rc_inst_
[Intel-gfx] [PATCH v2 1/8] DO NOT REVIEW: drm/i915: Add support for MTL GSC SW Proxy
This is a squash of the GSC proxy series, which is being reviewed
separately [1]. It's being included here because some of the patches in
this series depend on it. This is not a functional dependencies, the
patches just touch the same code and the proxy patches are planned to be
merged first, so it is easier to base the new patches on top of it.
[1] https://patchwork.freedesktop.org/series/115806/
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gt/intel_gt_irq.c| 22 +-
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 3 +
drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c | 424 ++
drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.h | 18 +
drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c | 66 ++-
drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h | 17 +-
.../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h | 1 +
drivers/misc/mei/Kconfig | 2 +-
drivers/misc/mei/Makefile | 1 +
drivers/misc/mei/gsc_proxy/Kconfig| 14 +
drivers/misc/mei/gsc_proxy/Makefile | 7 +
drivers/misc/mei/gsc_proxy/mei_gsc_proxy.c| 208 +
include/drm/i915_component.h | 3 +-
include/drm/i915_gsc_proxy_mei_interface.h| 53 +++
15 files changed, 830 insertions(+), 10 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c
create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.h
create mode 100644 drivers/misc/mei/gsc_proxy/Kconfig
create mode 100644 drivers/misc/mei/gsc_proxy/Makefile
create mode 100644 drivers/misc/mei/gsc_proxy/mei_gsc_proxy.c
create mode 100644 include/drm/i915_gsc_proxy_mei_interface.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 9af76e376ca9..f2ac803e35b4 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -194,6 +194,7 @@ i915-y += \
# general-purpose microcontroller (GuC) support
i915-y += \
gt/uc/intel_gsc_fw.o \
+ gt/uc/intel_gsc_proxy.o \
gt/uc/intel_gsc_uc.o \
gt/uc/intel_gsc_uc_heci_cmd_submit.o\
gt/uc/intel_guc.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
index c0f3ff4746ad..95e59ed6651d 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
@@ -16,6 +16,7 @@
#include "intel_uncore.h"
#include "intel_rps.h"
#include "pxp/intel_pxp_irq.h"
+#include "uc/intel_gsc_proxy.h"
static void guc_irq_handler(struct intel_guc *guc, u16 iir)
{
@@ -82,6 +83,9 @@ gen11_other_irq_handler(struct intel_gt *gt, const u8
instance,
if (instance == OTHER_GSC_INSTANCE)
return intel_gsc_irq_handler(gt, iir);
+ if (instance == OTHER_GSC_HECI_2_INSTANCE)
+ return intel_gsc_proxy_irq_handler(>->uc.gsc, iir);
+
WARN_ONCE(1, "unhandled other interrupt instance=0x%x, iir=0x%x\n",
instance, iir);
}
@@ -101,6 +105,8 @@ static struct intel_gt *pick_gt(struct intel_gt *gt, u8
class, u8 instance)
case VIDEO_ENHANCEMENT_CLASS:
return media_gt;
case OTHER_CLASS:
+ if (instance == OTHER_GSC_HECI_2_INSTANCE)
+ return media_gt;
if (instance == OTHER_GSC_INSTANCE && HAS_ENGINE(media_gt,
GSC0))
return media_gt;
fallthrough;
@@ -257,6 +263,7 @@ void gen11_gt_irq_postinstall(struct intel_gt *gt)
u32 irqs = GT_RENDER_USER_INTERRUPT;
u32 guc_mask = intel_uc_wants_guc(>->uc) ? GUC_INTR_GUC2HOST : 0;
u32 gsc_mask = 0;
+ u32 heci_mask = 0;
u32 dmask;
u32 smask;
@@ -268,10 +275,16 @@ void gen11_gt_irq_postinstall(struct intel_gt *gt)
dmask = irqs << 16 | irqs;
smask = irqs << 16;
- if (HAS_ENGINE(gt, GSC0))
+ if (HAS_ENGINE(gt, GSC0)) {
+ /*
+* the heci2 interrupt is enabled via the same register as the
+* GSC interrupt, but it has its own mask register.
+*/
gsc_mask = irqs;
- else if (HAS_HECI_GSC(gt->i915))
+ heci_mask = GSC_IRQ_INTF(1); /* HECI2 IRQ for SW Proxy*/
+ } else if (HAS_HECI_GSC(gt->i915)) {
gsc_mask = GSC_IRQ_INTF(0) | GSC_IRQ_INTF(1);
+ }
BUILD_BUG_ON(irqs & 0x);
@@ -281,7 +294,7 @@ void gen11_gt_irq_postinstall(struct intel_gt *gt)
if (CCS_MASK(gt))
intel_uncore_write(uncore, GEN12_CCS_RSVD_INTR_ENABLE, smask);
if (gsc_mask)
- intel_uncore_write(uncore, GEN11_GUNIT_CSME_INTR_ENABLE,
gsc_mask);
+ intel_uncore_write(uncore, GEN11_GUNIT_CSME_INTR_ENABLE,
gsc_mask | heci_mask);
/* Unmask irqs on RCS, BCS, VCS and VECS engines. */
intel_uncore_write(uncore, GEN11_RCS0_RSVD_INTR_MASK, ~smask);
@@ -309,6 +322,9 @@ void
[Intel-gfx] [PATCH v2 0/8] drm/i915: HuC loading and authentication for MTL
The HuC loading and authentication flow is once again changing and a new "clear-media only" authentication step is introduced. The flow is as follows: 1) The HuC is loaded via DMA - same as all non-GSC HuC binaries. 2) The HuC is authenticated by the GuC - this is the same step as performed for all non-GSC HuC binaries and re-uses the same code, but it is now resulting in a partial authentication that only allows clear-media workloads. 3) The HuC is fully authenticated for all workloads by the GSC - this is done via a new PXP command, submitted via the GSCCS. The advantage of this new flow is that we can start processing clear-media workloads without having to wait for the GSC to be ready, which can take several seconds. As part of this change, the HuC status getparam has been updated with a new value to indicate a partial authentication. Note tha the media driver is checking for value > 0 for clear media workloads, so no changes are required in userspace for that to work. The SW proxy series [1] has been included, squashed in a single patch, as some of some of the patches in this series depend on it. This is not a functional dependencies, the patches just touch the same code; the proxy patches are planned to be merged first, so it is easier to base the new patches on top of it to avoid having to rebase them later. v2: fix HuC auth status check for DG2. [1] https://patchwork.freedesktop.org/series/115806/ Cc: Alan Previn Acked-by: Tony Ye Daniele Ceraolo Spurio (8): DO NOT REVIEW: drm/i915: Add support for MTL GSC SW Proxy drm/i915/uc: perma-pin firmwares drm/i915/huc: Parse the GSC-enabled HuC binary drm/i915/huc: Load GSC-enabled HuC via DMA xfer if the fuse says so drm/i915/huc: differentiate the 2 steps of the MTL HuC auth flow drm/i915/mtl/huc: auth HuC via GSC drm/i915/mtl/huc: Use the media gt for the HuC getparam drm/i915/huc: define HuC FW version for MTL drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/gt/intel_ggtt.c | 3 + drivers/gpu/drm/i915/gt/intel_gt_irq.c| 22 +- drivers/gpu/drm/i915/gt/intel_gt_regs.h | 3 + .../drm/i915/gt/uc/intel_gsc_meu_headers.h| 74 +++ drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c | 424 ++ drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.h | 18 + drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c | 89 +++- drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h | 17 +- .../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c | 2 +- .../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h | 1 + drivers/gpu/drm/i915/gt/uc/intel_guc.c| 2 +- drivers/gpu/drm/i915/gt/uc/intel_huc.c| 182 +--- drivers/gpu/drm/i915/gt/uc/intel_huc.h| 26 +- drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 214 - drivers/gpu/drm/i915/gt/uc/intel_huc_fw.h | 6 +- drivers/gpu/drm/i915/gt/uc/intel_huc_print.h | 21 + drivers/gpu/drm/i915/gt/uc/intel_uc.c | 10 +- drivers/gpu/drm/i915/gt/uc/intel_uc.h | 2 + drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 120 ++--- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 9 +- drivers/gpu/drm/i915/i915_getparam.c | 6 +- drivers/gpu/drm/i915/i915_reg.h | 3 + .../drm/i915/pxp/intel_pxp_cmd_interface_43.h | 14 +- drivers/gpu/drm/i915/pxp/intel_pxp_huc.c | 2 +- drivers/misc/mei/Kconfig | 2 +- drivers/misc/mei/Makefile | 1 + drivers/misc/mei/gsc_proxy/Kconfig| 14 + drivers/misc/mei/gsc_proxy/Makefile | 7 + drivers/misc/mei/gsc_proxy/mei_gsc_proxy.c| 208 + include/drm/i915_component.h | 3 +- include/drm/i915_gsc_proxy_mei_interface.h| 53 +++ include/uapi/drm/i915_drm.h | 3 +- 33 files changed, 1428 insertions(+), 134 deletions(-) create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_meu_headers.h create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.h create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_huc_print.h create mode 100644 drivers/misc/mei/gsc_proxy/Kconfig create mode 100644 drivers/misc/mei/gsc_proxy/Makefile create mode 100644 drivers/misc/mei/gsc_proxy/mei_gsc_proxy.c create mode 100644 include/drm/i915_gsc_proxy_mei_interface.h -- 2.40.0
[Intel-gfx] [PATCH v2 2/8] drm/i915/uc: perma-pin firmwares
Now that each FW has its own reserved area, we can keep them always
pinned and skip the pin/unpin dance on reset. This will make things
easier for the 2-step HuC authentication, which requires the FW to be
pinned in GGTT after the xfer is completed.
Given that we use dummy vmas for the pinning, we do need to explicitly
re-pin on resume because the automated helper won't cover us.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Alan Previn
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 3 ++
drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c | 7 -
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 2 +-
drivers/gpu/drm/i915/gt/uc/intel_huc.c| 2 +-
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 8 +
drivers/gpu/drm/i915/gt/uc/intel_uc.h | 2 ++
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 36 ++-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 5 +++-
8 files changed, 53 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 20915edc8bd9..ab71ed11de79 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -1322,6 +1322,9 @@ void i915_ggtt_resume(struct i915_ggtt *ggtt)
ggtt->vm.scratch_range(&ggtt->vm, ggtt->error_capture.start,
ggtt->error_capture.size);
+ list_for_each_entry(gt, &ggtt->gt_list, ggtt_link)
+ intel_uc_resume_mappings(>->uc);
+
ggtt->invalidate(ggtt);
if (flush)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
index 64bff01026e8..af542e3cb3e9 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
@@ -80,7 +80,12 @@ void intel_gsc_uc_init_early(struct intel_gsc_uc *gsc)
{
struct intel_gt *gt = gsc_uc_to_gt(gsc);
- intel_uc_fw_init_early(&gsc->fw, INTEL_UC_FW_TYPE_GSC);
+ /*
+* GSC FW needs to be copied to a dedicated memory allocations for
+* loading (see gsc->local), so we don't need to GGTT map the FW image
+* itself into GGTT.
+*/
+ intel_uc_fw_init_early(&gsc->fw, INTEL_UC_FW_TYPE_GSC, false);
INIT_WORK(&gsc->work, gsc_work);
/* we can arrive here from i915_driver_early_probe for primary
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index c9f20385f6a0..2eb891b270ae 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -164,7 +164,7 @@ void intel_guc_init_early(struct intel_guc *guc)
struct intel_gt *gt = guc_to_gt(guc);
struct drm_i915_private *i915 = gt->i915;
- intel_uc_fw_init_early(&guc->fw, INTEL_UC_FW_TYPE_GUC);
+ intel_uc_fw_init_early(&guc->fw, INTEL_UC_FW_TYPE_GUC, true);
intel_guc_ct_init_early(&guc->ct);
intel_guc_log_init_early(&guc->log);
intel_guc_submission_init_early(guc);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index aefdaa62da99..9721761373fb 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -276,7 +276,7 @@ void intel_huc_init_early(struct intel_huc *huc)
struct drm_i915_private *i915 = huc_to_gt(huc)->i915;
struct intel_gt *gt = huc_to_gt(huc);
- intel_uc_fw_init_early(&huc->fw, INTEL_UC_FW_TYPE_HUC);
+ intel_uc_fw_init_early(&huc->fw, INTEL_UC_FW_TYPE_HUC, true);
/*
* we always init the fence as already completed, even if HuC is not
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 996168312340..b6adfda3761e 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -697,6 +697,12 @@ void intel_uc_suspend(struct intel_uc *uc)
}
}
+static void __uc_resume_mappings(struct intel_uc *uc)
+{
+ intel_uc_fw_resume_mapping(&uc->guc.fw);
+ intel_uc_fw_resume_mapping(&uc->huc.fw);
+}
+
static int __uc_resume(struct intel_uc *uc, bool enable_communication)
{
struct intel_guc *guc = &uc->guc;
@@ -764,4 +770,6 @@ static const struct intel_uc_ops uc_ops_on = {
.init_hw = __uc_init_hw,
.fini_hw = __uc_fini_hw,
+
+ .resume_mappings = __uc_resume_mappings,
};
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.h
b/drivers/gpu/drm/i915/gt/uc/intel_uc.h
index 5d0f1bcc381e..c2783e6e752b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.h
@@ -24,6 +24,7 @@ struct intel_uc_ops {
void (*fini)(struct intel_uc *uc);
int (*init_hw)(struct intel_uc *uc);
void (*fini_hw)(struct intel_uc *uc);
+ void (*resume_mappings)(struct intel_uc *uc);
};
struct intel_uc {
@@ -113,6 +114,7 @@ intel_uc_ops_function(init, init, int, 0);
intel_uc_ops_function(fini, fini, void, );
intel_uc_ops_functio
[Intel-gfx] [PATCH v2 5/8] drm/i915/huc: differentiate the 2 steps of the MTL HuC auth flow
Before we add the second step of the MTL HuC auth (via GSC), we need to
have the ability to differentiate between them. To do so, the huc
authentication check is duplicated for GuC and GSC auth, with meu
binaries being considered fully authenticated only after the GSC auth
step.
To report the difference between the 2 auth steps, a new case is added
to the HuC getparam. This way, the clear media driver can start
submitting before full auth, as partial auth is enough for those
workloads.
v2: fix authentication status check for DG2
Signed-off-by: Daniele Ceraolo Spurio
Cc: Alan Previn
---
drivers/gpu/drm/i915/gt/uc/intel_huc.c| 94 +--
drivers/gpu/drm/i915/gt/uc/intel_huc.h| 16 +++-
drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 4 +-
drivers/gpu/drm/i915/i915_reg.h | 3 +
include/uapi/drm/i915_drm.h | 3 +-
5 files changed, 91 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index c189ede4ef55..60f95d98e5fd 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -10,6 +10,7 @@
#include "intel_huc.h"
#include "intel_huc_print.h"
#include "i915_drv.h"
+#include "i915_reg.h"
#include
#include
@@ -106,7 +107,7 @@ static enum hrtimer_restart
huc_delayed_load_timer_callback(struct hrtimer *hrti
{
struct intel_huc *huc = container_of(hrtimer, struct intel_huc,
delayed_load.timer);
- if (!intel_huc_is_authenticated(huc)) {
+ if (!intel_huc_is_authenticated(huc, INTEL_HUC_AUTH_BY_GSC)) {
if (huc->delayed_load.status == INTEL_HUC_WAITING_ON_GSC)
huc_notice(huc, "timed out waiting for MEI GSC\n");
else if (huc->delayed_load.status == INTEL_HUC_WAITING_ON_PXP)
@@ -124,7 +125,7 @@ static void huc_delayed_load_start(struct intel_huc *huc)
{
ktime_t delay;
- GEM_BUG_ON(intel_huc_is_authenticated(huc));
+ GEM_BUG_ON(intel_huc_is_authenticated(huc, INTEL_HUC_AUTH_BY_GSC));
/*
* On resume we don't have to wait for MEI-GSC to be re-probed, but we
@@ -284,13 +285,23 @@ void intel_huc_init_early(struct intel_huc *huc)
}
if (GRAPHICS_VER(i915) >= 11) {
- huc->status.reg = GEN11_HUC_KERNEL_LOAD_INFO;
- huc->status.mask = HUC_LOAD_SUCCESSFUL;
- huc->status.value = HUC_LOAD_SUCCESSFUL;
+ huc->status[INTEL_HUC_AUTH_BY_GUC].reg =
GEN11_HUC_KERNEL_LOAD_INFO;
+ huc->status[INTEL_HUC_AUTH_BY_GUC].mask = HUC_LOAD_SUCCESSFUL;
+ huc->status[INTEL_HUC_AUTH_BY_GUC].value = HUC_LOAD_SUCCESSFUL;
} else {
- huc->status.reg = HUC_STATUS2;
- huc->status.mask = HUC_FW_VERIFIED;
- huc->status.value = HUC_FW_VERIFIED;
+ huc->status[INTEL_HUC_AUTH_BY_GUC].reg = HUC_STATUS2;
+ huc->status[INTEL_HUC_AUTH_BY_GUC].mask = HUC_FW_VERIFIED;
+ huc->status[INTEL_HUC_AUTH_BY_GUC].value = HUC_FW_VERIFIED;
+ }
+
+ if (IS_DG2(i915)) {
+ huc->status[INTEL_HUC_AUTH_BY_GSC].reg =
GEN11_HUC_KERNEL_LOAD_INFO;
+ huc->status[INTEL_HUC_AUTH_BY_GSC].mask = HUC_LOAD_SUCCESSFUL;
+ huc->status[INTEL_HUC_AUTH_BY_GSC].value = HUC_LOAD_SUCCESSFUL;
+ } else {
+ huc->status[INTEL_HUC_AUTH_BY_GSC].reg =
HECI_FWSTS5(MTL_GSC_HECI1_BASE);
+ huc->status[INTEL_HUC_AUTH_BY_GSC].mask =
HECI_FWSTS5_HUC_AUTH_DONE;
+ huc->status[INTEL_HUC_AUTH_BY_GSC].value =
HECI_FWSTS5_HUC_AUTH_DONE;
}
}
@@ -381,28 +392,39 @@ void intel_huc_suspend(struct intel_huc *huc)
delayed_huc_load_complete(huc);
}
-int intel_huc_wait_for_auth_complete(struct intel_huc *huc)
+static const char *auth_mode_string(struct intel_huc *huc,
+ enum intel_huc_authentication_type type)
+{
+ bool partial = !huc->loaded_via_gsc && huc->fw.is_meu_binary &&
+ type == INTEL_HUC_AUTH_BY_GUC;
+
+ return partial ? "clear media" : "all workloads";
+}
+
+int intel_huc_wait_for_auth_complete(struct intel_huc *huc,
+enum intel_huc_authentication_type type)
{
struct intel_gt *gt = huc_to_gt(huc);
int ret;
ret = __intel_wait_for_register(gt->uncore,
- huc->status.reg,
- huc->status.mask,
- huc->status.value,
+ huc->status[type].reg,
+ huc->status[type].mask,
+ huc->status[type].value,
2, 50, NULL);
/* mark the load process as complete even if the wait failed */
delayed_huc_load_complete(huc);
if (ret
[Intel-gfx] [PATCH v2 3/8] drm/i915/huc: Parse the GSC-enabled HuC binary
The new binaries that support the 2-step authentication have contain the
legacy-style binary, which we can use for loading the HuC via DMA. To
find out where this is located in the image, we need to parse the meu
manifest of the GSC binary. The manifest consist of a partition header
followed by entries, one of which contains the offset we're looking for.
Since we're now parsing the entries, we can extract the HuC version
that way instead of using hardcoded offsets.
Note that the meu structure will be re-used for parsing the GSC binary,
so they've been added in their own header.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Alan Previn
---
.../drm/i915/gt/uc/intel_gsc_meu_headers.h| 74 +++
drivers/gpu/drm/i915/gt/uc/intel_huc.c| 11 +-
drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 116 ++
drivers/gpu/drm/i915/gt/uc/intel_huc_fw.h | 5 +-
drivers/gpu/drm/i915/gt/uc/intel_huc_print.h | 21
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 71 ++-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 2 +
7 files changed, 253 insertions(+), 47 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_meu_headers.h
create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_huc_print.h
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_meu_headers.h
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_meu_headers.h
new file mode 100644
index ..df9c482a8052
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_meu_headers.h
@@ -0,0 +1,74 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2023 Intel Corporation
+ */
+
+#ifndef _INTEL_GSC_MEU_H_
+#define _INTEL_GSC_MEU_H_
+
+#include
+
+/* Code partition structures */
+struct intel_gsc_cpt_directory_header_v2 {
+ u32 header_marker;
+#define INTEL_GSC_CPT_HEADER_MARKER 0x44504324
+
+ u32 num_of_entries;
+ u8 header_version;
+ u8 entry_version;
+ u8 header_length; /* in bytes */
+ u8 flags;
+ u32 partition_name;
+ u32 crc32;
+} __packed;
+
+struct intel_gsc_cpt_directory_entry {
+ u8 name[12];
+
+ /*
+* Bits 0-24: offset from the beginning of the code partition
+* Bit 25: huffman compressed
+* Bits 26-31: reserved
+*/
+ u32 offset;
+#define INTEL_GSC_CPT_ENTRY_OFFSET_MASK GENMASK(24, 0)
+#define INTEL_GSC_CPT_ENTRY_HUFFMAN_COMP BIT(25)
+
+ /*
+* Module/Item length, in bytes. For Huffman-compressed modules, this
+* refers to the uncompressed size. For software-compressed modules,
+* this refers to the compressed size.
+*/
+ u32 length;
+
+ u8 reserved[4];
+} __packed;
+
+struct intel_gsc_meu_version {
+ u16 major;
+ u16 minor;
+ u16 hotfix;
+ u16 build;
+} __packed;
+
+struct intel_gsc_manifest_header {
+ u32 header_type; /* 0x4 for manifest type */
+ u32 header_length; /* in dwords */
+ u32 header_version;
+ u32 flags;
+ u32 vendor;
+ u32 date;
+ u32 size; /* In dwords, size of entire manifest (header + extensions) */
+ u32 header_id;
+ u32 internal_data;
+ struct intel_gsc_meu_version fw_version;
+ u32 security_version;
+ struct intel_gsc_meu_version meu_kit_version;
+ u32 meu_manifest_version;
+ u8 general_data[4];
+ u8 reserved3[56];
+ u32 modulus_size; /* in dwords */
+ u32 exponent_size; /* in dwords */
+} __packed;
+
+#endif
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 9721761373fb..062ff914b274 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -6,23 +6,14 @@
#include
#include "gt/intel_gt.h"
-#include "gt/intel_gt_print.h"
#include "intel_guc_reg.h"
#include "intel_huc.h"
+#include "intel_huc_print.h"
#include "i915_drv.h"
#include
#include
-#define huc_printk(_huc, _level, _fmt, ...) \
- gt_##_level(huc_to_gt(_huc), "HuC: " _fmt, ##__VA_ARGS__)
-#define huc_err(_huc, _fmt, ...) huc_printk((_huc), err, _fmt,
##__VA_ARGS__)
-#define huc_warn(_huc, _fmt, ...) huc_printk((_huc), warn, _fmt,
##__VA_ARGS__)
-#define huc_notice(_huc, _fmt, ...)huc_printk((_huc), notice, _fmt,
##__VA_ARGS__)
-#define huc_info(_huc, _fmt, ...) huc_printk((_huc), info, _fmt,
##__VA_ARGS__)
-#define huc_dbg(_huc, _fmt, ...) huc_printk((_huc), dbg, _fmt,
##__VA_ARGS__)
-#define huc_probe_error(_huc, _fmt, ...) huc_printk((_huc), probe_error, _fmt,
##__VA_ARGS__)
-
/**
* DOC: HuC
*
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
index 534b0aa43316..f1c973e1c676 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
@@ -5,11 +5,127 @@
#include "gt/intel_gsc.h"
#include "gt/intel_gt.h"
+#include "intel_gsc_meu_headers.h"
#include "intel_huc.h"
#include "intel_huc_fw.h"
+#include "int
[Intel-gfx] [PATCH v2 8/8] drm/i915/huc: define HuC FW version for MTL
Follow the same logic as DG2, so just a meu binary with no version number. Signed-off-by: Daniele Ceraolo Spurio Cc: Alan Previn --- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c index 3338dd45e78b..796f54a62eef 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c @@ -102,6 +102,7 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw, fw_def(SKYLAKE, 0, guc_mmp(skl, 70, 1, 1)) #define INTEL_HUC_FIRMWARE_DEFS(fw_def, huc_raw, huc_mmp, huc_gsc) \ + fw_def(METEORLAKE, 0, huc_gsc(mtl)) \ fw_def(DG2, 0, huc_gsc(dg2)) \ fw_def(ALDERLAKE_P, 0, huc_raw(tgl)) \ fw_def(ALDERLAKE_P, 0, huc_mmp(tgl, 7, 9, 3)) \ -- 2.40.0
[Intel-gfx] [PATCH v2 7/8] drm/i915/mtl/huc: Use the media gt for the HuC getparam
On MTL, for obvious reasons, HuC is only available on the media tile. We already disable SW support for HuC on the root gt due to the absence of VCS engines, but we also need to update the getparam to point to the HuC struct in the media GT. Signed-off-by: Daniele Ceraolo Spurio Cc: John Harrison --- drivers/gpu/drm/i915/i915_getparam.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_getparam.c b/drivers/gpu/drm/i915/i915_getparam.c index 2238e096c957..7aa47550e4f2 100644 --- a/drivers/gpu/drm/i915/i915_getparam.c +++ b/drivers/gpu/drm/i915/i915_getparam.c @@ -98,7 +98,11 @@ int i915_getparam_ioctl(struct drm_device *dev, void *data, value = sseu->min_eu_in_pool; break; case I915_PARAM_HUC_STATUS: - value = intel_huc_check_status(&to_gt(i915)->uc.huc); + /* On platform with a media GT, the HuC is on that GT */ + if (i915->media_gt) + value = intel_huc_check_status(&i915->media_gt->uc.huc); + else + value = intel_huc_check_status(&to_gt(i915)->uc.huc); if (value < 0) return value; break; -- 2.40.0
[Intel-gfx] [PATCH v2 4/8] drm/i915/huc: Load GSC-enabled HuC via DMA xfer if the fuse says so
In the previous patch we extracted the offset of the legacy-style HuC
binary located within the GSC-enabled blob, so now we can use that to
load the HuC via DMA if the fuse is set that way.
Note that we now need to differentiate between "GSC-enabled binary" and
"loaded by GSC", so the former case has been renamed to "MEU binary" for
clarity, while the latter is now based on the fuse instead of the binary
format. This way, all the legacy load paths are automatically taken
(including the auth by GuC) without having to implement further code
changes.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Alan Previn
---
drivers/gpu/drm/i915/gt/uc/intel_huc.c| 27 ++-
drivers/gpu/drm/i915/gt/uc/intel_huc.h| 4 +++-
drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 14 ++--
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 2 +-
5 files changed, 29 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 062ff914b274..c189ede4ef55 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -298,31 +298,38 @@ void intel_huc_init_early(struct intel_huc *huc)
static int check_huc_loading_mode(struct intel_huc *huc)
{
struct intel_gt *gt = huc_to_gt(huc);
- bool fw_needs_gsc = intel_huc_is_loaded_by_gsc(huc);
- bool hw_uses_gsc = false;
+ bool fw_is_meu = huc->fw.is_meu_binary;
/*
* The fuse for HuC load via GSC is only valid on platforms that have
* GuC deprivilege.
*/
if (HAS_GUC_DEPRIVILEGE(gt->i915))
- hw_uses_gsc = intel_uncore_read(gt->uncore, GUC_SHIM_CONTROL2) &
- GSC_LOADS_HUC;
+ huc->loaded_via_gsc = intel_uncore_read(gt->uncore,
GUC_SHIM_CONTROL2) &
+ GSC_LOADS_HUC;
- if (fw_needs_gsc != hw_uses_gsc) {
- huc_err(huc, "mismatch between FW (%s) and HW (%s) load
modes\n",
- HUC_LOAD_MODE_STRING(fw_needs_gsc),
HUC_LOAD_MODE_STRING(hw_uses_gsc));
+ if (huc->loaded_via_gsc && !fw_is_meu) {
+ huc_err(huc, "HW requires a MEU blob, but we found a legacy
one\n");
return -ENOEXEC;
}
- /* make sure we can access the GSC via the mei driver if we need it */
+ /*
+* Newer meu blobs contain the old FW structure inside. If we found
+* that, we can use it to load the legacy way.
+*/
+ if (!huc->loaded_via_gsc && fw_is_meu && !huc->fw.dma_start_offset) {
+ huc_err(huc," HW in legacy mode, but we have an incompatible
meu blob\n");
+ return -ENOEXEC;
+ }
+
+ /* make sure we can access the GSC if we need it */
if (!(IS_ENABLED(CONFIG_INTEL_MEI_PXP) &&
IS_ENABLED(CONFIG_INTEL_MEI_GSC)) &&
- fw_needs_gsc) {
+ !HAS_ENGINE(gt, GSC0) && huc->loaded_via_gsc) {
huc_info(huc, "can't load due to missing MEI modules\n");
return -EIO;
}
- huc_dbg(huc, "loaded by GSC = %s\n", str_yes_no(fw_needs_gsc));
+ huc_dbg(huc, "loaded by GSC = %s\n", str_yes_no(huc->loaded_via_gsc));
return 0;
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.h
b/drivers/gpu/drm/i915/gt/uc/intel_huc.h
index db555b3c1f56..345e1b9aa062 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.h
@@ -39,6 +39,8 @@ struct intel_huc {
struct notifier_block nb;
enum intel_huc_delayed_load_status status;
} delayed_load;
+
+ bool loaded_via_gsc;
};
int intel_huc_sanitize(struct intel_huc *huc);
@@ -73,7 +75,7 @@ static inline bool intel_huc_is_used(struct intel_huc *huc)
static inline bool intel_huc_is_loaded_by_gsc(const struct intel_huc *huc)
{
- return huc->fw.loaded_via_gsc;
+ return huc->loaded_via_gsc;
}
static inline bool intel_huc_wait_required(struct intel_huc *huc)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
index f1c973e1c676..88ad2c322c4a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
@@ -34,7 +34,7 @@ int intel_huc_fw_get_binary_info(struct intel_uc_fw *huc_fw,
const void *data, s
size_t min_size = sizeof(*header);
int i;
- if (!huc_fw->loaded_via_gsc) {
+ if (!huc_fw->is_meu_binary) {
huc_err(huc, "Invalid FW type MEU parsing!\n");
return -EINVAL;
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index da6fcfe1d80a..3338dd45e78b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -180,7 +180,7 @@ struct __packed uc_fw_blob {
u8 major;
u8 minor;
[Intel-gfx] [PATCH v2 6/8] drm/i915/mtl/huc: auth HuC via GSC
The full authentication via the GSC requires an heci packet submission
to the GSC FW via the GSC CS. The GSC has new PXP command for this
(literally called NEW_HUC_AUTH).
The intel_huc_auth fuction is also updated to handle both authentication
types.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Alan Previn
---
drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c | 24 -
.../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_huc.c| 50 +++---
drivers/gpu/drm/i915/gt/uc/intel_huc.h| 6 +-
drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 94 +++
drivers/gpu/drm/i915/gt/uc/intel_huc_fw.h | 1 +
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 2 +-
.../drm/i915/pxp/intel_pxp_cmd_interface_43.h | 14 ++-
drivers/gpu/drm/i915/pxp/intel_pxp_huc.c | 2 +-
9 files changed, 173 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
index af542e3cb3e9..b6d0ee1660b2 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
@@ -29,13 +29,29 @@ static void gsc_work(struct work_struct *work)
if (actions & GSC_ACTION_FW_LOAD) {
ret = intel_gsc_uc_fw_upload(gsc);
- if (ret == -EEXIST) /* skip proxy if not a new load */
- actions &= ~GSC_ACTION_FW_LOAD;
- else if (ret)
+ if (!ret)
+ /* setup proxy on a new load */
+ actions |= GSC_ACTION_SW_PROXY;
+ else if (ret != -EEXIST)
goto out_put;
+
+ /*
+* The HuC auth can be done both before or after the proxy init;
+* if done after, a proxy request will be issued and must be
+* serviced before the authentication can complete.
+* Since this worker also handles proxy requests, we can't
+* perform an action that requires the proxy from within it and
+* then stall waiting for it, because we'd be blocking the
+* service path. Therefore, it is easier for us to load HuC
+* first and do proxy later. The GSC will ack the HuC auth and
+* then send the HuC proxy request as part of the proxy init
+* flow.
+*/
+ if (intel_uc_uses_huc(>->uc))
+ intel_huc_auth(>->uc.huc, INTEL_HUC_AUTH_BY_GSC);
}
- if (actions & (GSC_ACTION_FW_LOAD | GSC_ACTION_SW_PROXY)) {
+ if (actions & GSC_ACTION_SW_PROXY) {
if (!intel_gsc_uc_fw_init_done(gsc)) {
gt_err(gt, "Proxy request received with GSC not
loaded!\n");
goto out_put;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c
index ea0da06e2f39..edcfa990239d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c
@@ -98,7 +98,7 @@ void intel_gsc_uc_heci_cmd_emit_mtl_header(struct
intel_gsc_mtl_header *header,
u64 host_session_id)
{
host_session_id &= ~HOST_SESSION_MASK;
- if (heci_client_id == HECI_MEADDRESS_PXP)
+ if (host_session_id && heci_client_id == HECI_MEADDRESS_PXP)
host_session_id |= HOST_SESSION_PXP_SINGLE;
header->validity_marker = GSC_HECI_VALIDITY_MARKER;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 60f95d98e5fd..54411ac33f35 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -347,20 +347,34 @@ static int check_huc_loading_mode(struct intel_huc *huc)
int intel_huc_init(struct intel_huc *huc)
{
+ struct intel_gt *gt = huc_to_gt(huc);
int err;
err = check_huc_loading_mode(huc);
if (err)
goto out;
+ if (HAS_ENGINE(gt, GSC0)) {
+ struct i915_vma *vma = intel_guc_allocate_vma(>->uc.guc,
SZ_8K);
+ if (IS_ERR(vma)) {
+ huc_info(huc, "Failed to allocate heci pkt\n");
+ goto out;
+ }
+
+ huc->heci_pkt = vma;
+ }
+
err = intel_uc_fw_init(&huc->fw);
if (err)
- goto out;
+ goto out_pkt;
intel_uc_fw_change_status(&huc->fw, INTEL_UC_FIRMWARE_LOADABLE);
return 0;
+out_pkt:
+ if (huc->heci_pkt)
+ i915_vma_unpin_and_release(&huc->heci_pkt, 0);
out:
intel_uc_fw_change_status(&huc->fw, INTEL_UC_FIRMWARE_INIT_FAIL);
huc_info(huc, "initialization failed %pe\n", ERR_PTR(err));
@@ -375,6 +389,9 @@ void intel_huc_fini(struct intel_huc *huc)
*/
delayed_huc_load_fini(huc);
Re: [Intel-gfx] [PATCH 06/11] drm/i915/dp: Add link training debug and error printing helpers
On Fri, Apr 28, 2023 at 05:21:53PM +0300, Ville Syrjälä wrote:
> On Wed, Apr 26, 2023 at 07:53:00PM +0300, Imre Deak wrote:
> > Add functions for printing link training debug and error messages, both
> > to prepare for the next patch, which downgrades an error to debug if the
> > sink is disconnected and to remove some code duplication.
> >
> > Signed-off-by: Imre Deak
> > ---
> > .../drm/i915/display/intel_dp_link_training.c | 376 +++---
> > 1 file changed, 139 insertions(+), 237 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > index 6aa4ae5e7ebe3..12f2880e474ed 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > @@ -26,6 +26,47 @@
> > #include "intel_dp.h"
> > #include "intel_dp_link_training.h"
> >
> > +__printf(5, 6)
> > +static void lt_msg(struct intel_connector *connector, struct intel_dp
> > *intel_dp, enum drm_dp_phy dp_phy,
> > + bool is_error, const char *format, ...)
>
> I pretty much hate custom debug/error print functions. Makes it
> hard togrep/etc. and just generally causes more "wtf is this?"
> moments when reading the code. Unfortunateely the macro hell in
> drm_print.h seems to make it really hard to do anything generic
> directly :(
I guess could use something like drm_printf(&intel_dp->printer, ...)
instead, but that would still need passing the PHY format prefix at each
callsite.
>
> > +{
> > + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > + struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
> > + char conn_str[128] = {};
> > + struct va_format vaf;
> > + va_list args;
> > +
> > + va_start(args, format);
> > + vaf.fmt = format;
> > + vaf.va = &args;
> > +
> > + if (connector)
> > + snprintf(conn_str, sizeof(conn_str), "[CONNECTOR:%d:%s]",
> > +connector->base.base.id, connector->base.name);
>
> Are there actually places where we don't have/can't get the
> connector?
I guess link training messages could always print
intel_dp->attached_connector (not sure if for MST it's worth / practical
to list all the connectors).
> > +
> > + if (is_error)
> > + drm_err(&i915->drm, "%s[ENCODER:%d:%s][%s] %pV\n",
> > + conn_str,
> > + encoder->base.base.id, encoder->base.name,
> > + drm_dp_phy_name(dp_phy),
> > + &vaf);
> > + else
> > + drm_dbg(&i915->drm, "%s[ENCODER:%d:%s][%s] %pV\n",
>
> That has lost the correct debug category.
Yes, should've been drm_dbg_kms().
>
> > + conn_str,
> > + encoder->base.base.id, encoder->base.name,
> > + drm_dp_phy_name(dp_phy),
> > + &vaf);
>
> Hmm. ___drm_dev_dbg() already uses this vaf stuff.
> Does chaining it like that work correctly?
Didn't think of it, but can't see why not, it's used at least in a few
places like that.
> > +}
> > +
> > +#define lt_err(intel_dp, dp_phy, format, ...) \
> > + lt_msg(NULL, intel_dp, dp_phy, true, format, ## __VA_ARGS__)
> > +
> > +#define lt_dbg(intel_dp, dp_phy, format, ...) \
> > + lt_msg(NULL, intel_dp, dp_phy, false, format, ## __VA_ARGS__)
> > +
> > +#define lt_conn_dbg(connector, intel_dp, dp_phy, format, ...) \
> > + lt_msg(connector, intel_dp, dp_phy, false, format, ## __VA_ARGS__)
> > +
> > static void intel_dp_reset_lttpr_common_caps(struct intel_dp *intel_dp)
> > {
> > memset(intel_dp->lttpr_common_caps, 0,
> > sizeof(intel_dp->lttpr_common_caps));
> > @@ -47,29 +88,21 @@ static void intel_dp_read_lttpr_phy_caps(struct
> > intel_dp *intel_dp,
> > const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> > enum drm_dp_phy dp_phy)
> > {
> > - struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
> > u8 *phy_caps = intel_dp_lttpr_phy_caps(intel_dp, dp_phy);
> >
> > if (drm_dp_read_lttpr_phy_caps(&intel_dp->aux, dpcd, dp_phy, phy_caps)
> > < 0) {
> > - drm_dbg_kms(&dp_to_i915(intel_dp)->drm,
> > - "[ENCODER:%d:%s][%s] failed to read the PHY caps\n",
> > - encoder->base.base.id, encoder->base.name,
> > - drm_dp_phy_name(dp_phy));
> > + lt_dbg(intel_dp, dp_phy, "failed to read the PHY caps\n");
> > return;
> > }
> >
> > - drm_dbg_kms(&dp_to_i915(intel_dp)->drm,
> > - "[ENCODER:%d:%s][%s] PHY capabilities: %*ph\n",
> > - encoder->base.base.id, encoder->base.name,
> > - drm_dp_phy_name(dp_phy),
> > - (int)sizeof(intel_dp->lttpr_phy_caps[0]),
> > - phy_caps);
> > + lt_dbg(intel_dp, dp_phy, "PHY capabilities: %*ph\n",
> > + (int)sizeof(intel_dp->lttpr_phy_caps[0]),
> > + ph
Re: [Intel-gfx] [PATCH v2 0/5] drm/i915: Allow user to set cache at BO creation
> On 27/04/2023 17:07, Yang, Fei wrote:
>>> On 26/04/2023 16:41, Yang, Fei wrote:
> On 26/04/2023 07:24, fei.y...@intel.com wrote:
>> From: Fei Yang
>>
>> The first three patches in this series are taken from
>> https://patchwork.freedesktop.org/series/116868/
>> These patches are included here because the last patch
>> has dependency on the pat_index refactor.
>>
>> This series is focusing on uAPI changes,
>> 1. end support for set caching ioctl [PATCH 4/5]
>> 2. add set_pat extension for gem_create [PATCH 5/5]
>>
>> v2: drop one patch that was merged separately
>> 341ad0e8e254 drm/i915/mtl: Add PTE encode function
>
> Are the re-sends for stabilizing the series, or focusing on merge?
v2 was sent just to drop one of patches that has already been merged.
> If the latter then opens are:
>
> 1) Link to Mesa MR reviewed and ready to merge.
>
> 2) IGT reviewed.
>
> 3) I raised an open that get/set_caching should not "lie" but return an
> error if set pat extension has been used. I don't see a good reason not
> to do that.
I don't think it's "lying" to the userspace. the comparison is only valid
for objects created by KMD because only such object uses the pat_index
from the cachelevel_to_pat table.
>>>
>>> Lets double check my understanding is correct. Userspace sequence of
>>> operations:
>>> 1)
>>> obj = gem_create()+set_pat(PAT_UC)
>>>
>>> 2a)
>>> get_caching(obj)
>>> What gets reported?
>>
>> I see your point here. nice catch.
>> That should be handled by,
>> if (obj->cachel_level == I915_CACHE_INVAL) /* indicated pat-index is set by
>> userspace */
>> return -EOPNOTSUPP;
>> Will update the patch.
>>
>>>
>>> 2b)
>>> set_caching(obj, I915_CACHE_LLC)
>>> What is the return code?
>>
>> This will either return -EOPNOTSUPP, or ignored because set_pat
>> extension was called.
>
> I see that you made it fail instead of fake success in the latest respin
> and I definitely agree with that.
Thanks for your picky eyes. :)
>>>
>>> If answer to 2a is I915_CACHING_CACHED and to 2b) success, then please
>>> state a good reason why both shouldn't return an error.
>>>
> + Joonas on this one.
>
> 4) Refactoring as done is not very pretty and I proposed an idea for a
> nicer approach. Feasible or not, open for discussion.
Still digesting your proposal. but not sure how would you define things
like PAT_UC as that is platform dependent, not a constant.
>>>
>>> "PAT_UC" in my outline was purely a driver specific value, similarly as
>>> I915_CACHE_... are.
>>
>> Okay. Then you were suggesting to add a translation table for
>> pat_index-to-(PAT-UC/WB/WT)?
>> It's going to be a N:1 mapping.
>
> PAT index to a value, probably a bitmask, built out of bits which define
> caching modes. Like "PAT_WB | PAT_1WAY_COHERENT", or just PAT_WB. Would
> that approach be enough to express everything?
I was thinking about dumping the PAT tables from Bspec into struct
intel_device_info {}.
But that would be only useful to unify all those *_setup_private_ppat()
functions in
intel_gtt.c. Kernel doesn't really care much about PAT index except making sure
the bits
are programmed correctly in PTE.
>>
>>> With the whole point that driver can ask if
>>> something is uncached, WT or whatever. Using the platform specific
>>> mapping table which converts platform specific obj->pat_index to driver
>>> representation of caching modes (PAT_UC etc).
>>
>> Are you suggesting completely remove i915_cache_level and use
>> (PAT-UC/WB/WT) instead?
>
> Not completely but throughout the most internal code paths, which would
> all just work on PAT index. Basically object always has PAT index set,
> with a separate boolean saying whether it came from gem_create_ext or
> set_cache_level.
What's in my mind as an improvement is to completely remove i915_cache_level.
KMD is supposed to abstract the hardware, but in this case, since the desgin
is that UMDs understand PAT index (and MOCS as well), having an abstraction
in between would only introduce ambiguity and complexity.
Also kernel doesn't need to play with all available PAT indices, so it should
be okay to add i915->pat_{uc|wb|wt} and initialize them with proper indices
respectively. That takes care of the PAT checking as well wherever it's needed,
like "if (pat_index == i915->pat_uc)"
>> Let's say a KMD object wants to be set as WB, how you get the exact
>> pat_index to use?
>> Note that there are multiple PAT indices having caching mod WB, but they are
>> different,
>> e.g. do you want just WB or WB with 1-way-coherency or WB with 2-way
>> coherency?
>
> Just use the cache_level to pat_index mapping you added in the series?
>
>> Also, in case a checking of pat_index is needed, do we say WB with
>> 1-way-coherency is equal to WB or not?
>
> You mean the call sites where i915 is checking the object caching mode?
> We have two
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Use gt_err inplace of pr_err
== Series Details == Series: drm/i915: Use gt_err inplace of pr_err URL : https://patchwork.freedesktop.org/series/117116/ State : success == Summary == CI Bug Log - changes from CI_DRM_13074 -> Patchwork_117116v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117116v1/index.html Participating hosts (39 -> 37) -- Missing(2): fi-kbl-soraka fi-snb-2520m Known issues Here are the changes found in Patchwork_117116v1 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s3@smem: - bat-rpls-1: [PASS][1] -> [ABORT][2] ([i915#6687] / [i915#7978] / [i915#8407]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13074/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117116v1/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html * igt@i915_selftest@live@migrate: - bat-dg2-11: [PASS][3] -> [DMESG-FAIL][4] ([i915#7699] / [i915#7913]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13074/bat-dg2-11/igt@i915_selftest@l...@migrate.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117116v1/bat-dg2-11/igt@i915_selftest@l...@migrate.html * igt@i915_selftest@live@mman: - bat-rpls-1: [PASS][5] -> [TIMEOUT][6] ([i915#6794] / [i915#7392]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13074/bat-rpls-1/igt@i915_selftest@l...@mman.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117116v1/bat-rpls-1/igt@i915_selftest@l...@mman.html * igt@i915_selftest@live@requests: - bat-rplp-1: [PASS][7] -> [ABORT][8] ([i915#7913] / [i915#7920]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13074/bat-rplp-1/igt@i915_selftest@l...@requests.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117116v1/bat-rplp-1/igt@i915_selftest@l...@requests.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - fi-bsw-n3050: NOTRUN -> [SKIP][9] ([fdo#109271]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117116v1/fi-bsw-n3050/igt@kms_chamelium_...@common-hpd-after-suspend.html Possible fixes * igt@i915_selftest@live@execlists: - fi-bsw-n3050: [ABORT][10] ([i915#7911] / [i915#7913]) -> [PASS][11] [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13074/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117116v1/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html * igt@kms_pipe_crc_basic@nonblocking-crc@pipe-d-dp-1: - bat-dg2-8: [FAIL][12] ([i915#7932]) -> [PASS][13] [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13074/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117116v1/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687 [i915#6794]: https://gitlab.freedesktop.org/drm/intel/issues/6794 [i915#7392]: https://gitlab.freedesktop.org/drm/intel/issues/7392 [i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699 [i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911 [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913 [i915#7920]: https://gitlab.freedesktop.org/drm/intel/issues/7920 [i915#7932]: https://gitlab.freedesktop.org/drm/intel/issues/7932 [i915#7978]: https://gitlab.freedesktop.org/drm/intel/issues/7978 [i915#8407]: https://gitlab.freedesktop.org/drm/intel/issues/8407 Build changes - * Linux: CI_DRM_13074 -> Patchwork_117116v1 CI-20190529: 20190529 CI_DRM_13074: 29e53d3ca48aa5fcb6bcf8d1624c829b7838e242 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7277: 1cb3507f3ff28d11bd5cfabcde576fe78ddab571 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_117116v1: 29e53d3ca48aa5fcb6bcf8d1624c829b7838e242 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 592d276cdf31 drm/i915/selftests: Use gt_err for GT info 4bccec275de3 drm/i915/gt: Use gt_err for GT info == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117116v1/index.html
