Re: [Intel-gfx] [PATCH v5 1/9] drm/i915/display: Add new member to configure PCON color conversion
On 11/11/2022 2:08 AM, Ville Syrjälä wrote: On Fri, Oct 28, 2022 at 03:14:03PM +0530, Ankit Nautiyal wrote: The decision to use DFP output format conversion capabilities should be during compute_config phase. This patch adds new member to crtc_state to represent the final output_format to the sink. In case of a DFP this can be different than the output_format, as per the format conversion done via the PCON. This will help to store only the format conversion capabilities of the DP device in intel_dp->dfp, and use crtc_state to compute and store the configuration for color/format conversion for a given mode. v2: modified the new member to crtc_state to represent the final output_format that eaches the sink, after possible conversion by PCON kind of devices. (Ville) v3: Addressed comments from Ville: -Added comments to clarify difference between sink_format and output_format. -Corrected the order of setting sink_format and output_format. -Added readout for sink_format in get_pipe_config hooks. Signed-off-by: Ankit Nautiyal --- drivers/gpu/drm/i915/display/icl_dsi.c| 1 + drivers/gpu/drm/i915/display/intel_crt.c | 1 + .../drm/i915/display/intel_crtc_state_dump.c | 5 +-- drivers/gpu/drm/i915/display/intel_display.c | 5 +++ .../drm/i915/display/intel_display_types.h| 11 +- drivers/gpu/drm/i915/display/intel_dp.c | 34 +-- drivers/gpu/drm/i915/display/intel_dp_mst.c | 1 + drivers/gpu/drm/i915/display/intel_dvo.c | 1 + drivers/gpu/drm/i915/display/intel_hdmi.c | 24 - drivers/gpu/drm/i915/display/intel_lvds.c | 1 + drivers/gpu/drm/i915/display/intel_tv.c | 1 + drivers/gpu/drm/i915/display/vlv_dsi.c| 1 + We seem to miss intel_sdvo.c here. Apart from that looks nice. With sdvo fixed Reviewed-by: Ville Syrjälä Thanks Ville. Will add sdvo in the next version of the patch. Regards, Ankit 12 files changed, 63 insertions(+), 23 deletions(-) diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c b/drivers/gpu/drm/i915/display/icl_dsi.c index e05e7cd6c412..533563e94f58 100644 --- a/drivers/gpu/drm/i915/display/icl_dsi.c +++ b/drivers/gpu/drm/i915/display/icl_dsi.c @@ -1666,6 +1666,7 @@ static int gen11_dsi_compute_config(struct intel_encoder *encoder, _config->hw.adjusted_mode; int ret; + pipe_config->sink_format = INTEL_OUTPUT_FORMAT_RGB; pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB; ret = intel_panel_compute_config(intel_connector, adjusted_mode); diff --git a/drivers/gpu/drm/i915/display/intel_crt.c b/drivers/gpu/drm/i915/display/intel_crt.c index 94d0a5e1dd03..1b46d10fc6f4 100644 --- a/drivers/gpu/drm/i915/display/intel_crt.c +++ b/drivers/gpu/drm/i915/display/intel_crt.c @@ -391,6 +391,7 @@ static int intel_crt_compute_config(struct intel_encoder *encoder, if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN) return -EINVAL; + pipe_config->sink_format = INTEL_OUTPUT_FORMAT_RGB; pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB; return 0; diff --git a/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c b/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c index e9212f69c360..ed427b9cbf09 100644 --- a/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c +++ b/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c @@ -163,10 +163,11 @@ void intel_crtc_state_dump(const struct intel_crtc_state *pipe_config, snprintf_output_types(buf, sizeof(buf), pipe_config->output_types); drm_dbg_kms(>drm, - "active: %s, output_types: %s (0x%x), output format: %s\n", + "active: %s, output_types: %s (0x%x), output format: %s, sink format: %s\n", str_yes_no(pipe_config->hw.active), buf, pipe_config->output_types, - output_formats(pipe_config->output_format)); + output_formats(pipe_config->output_format), + output_formats(pipe_config->sink_format)); drm_dbg_kms(>drm, "cpu_transcoder: %s, pipe bpp: %i, dithering: %i\n", diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index 9697179309c4..6edb3f2af376 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -3240,6 +3240,7 @@ static bool i9xx_get_pipe_config(struct intel_crtc *crtc, return false; pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB; + pipe_config->sink_format = pipe_config->output_format; pipe_config->cpu_transcoder = (enum transcoder) crtc->pipe; pipe_config->shared_dpll = NULL; @@ -3699,6 +3700,8 @@ static bool ilk_get_pipe_config(struct intel_crtc *crtc, break; } + pipe_config->sink_format = pipe_config->output_format; + pipe_config->gamma_mode =
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v2,1/4] i915: Move list_count() to list.h for broader use
== Series Details == Series: series starting with [v2,1/4] i915: Move list_count() to list.h for broader use URL : https://patchwork.freedesktop.org/series/110870/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12379_full -> Patchwork_110870v1_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_110870v1_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_110870v1_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (11 -> 11) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_110870v1_full: ### IGT changes ### Possible regressions * igt@gem_spin_batch@user-each: - shard-skl: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12379/shard-skl10/igt@gem_spin_ba...@user-each.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110870v1/shard-skl2/igt@gem_spin_ba...@user-each.html Known issues Here are the changes found in Patchwork_110870v1_full that come from known issues: ### IGT changes ### Issues hit * igt@feature_discovery@psr2: - shard-iclb: [PASS][3] -> [SKIP][4] ([i915#658]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12379/shard-iclb2/igt@feature_discov...@psr2.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110870v1/shard-iclb3/igt@feature_discov...@psr2.html * igt@gem_ctx_persistence@hang: - shard-skl: NOTRUN -> [SKIP][5] ([fdo#109271]) +249 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110870v1/shard-skl7/igt@gem_ctx_persiste...@hang.html * igt@gem_eio@in-flight-suspend: - shard-apl: [PASS][6] -> [DMESG-WARN][7] ([i915#180]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12379/shard-apl3/igt@gem_...@in-flight-suspend.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110870v1/shard-apl3/igt@gem_...@in-flight-suspend.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-glk: [PASS][8] -> [FAIL][9] ([i915#2842]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12379/shard-glk5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110870v1/shard-glk2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_suspend@basic-s3@smem: - shard-skl: [PASS][10] -> [FAIL][11] ([fdo#103375]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12379/shard-skl10/igt@gem_exec_suspend@basic...@smem.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110870v1/shard-skl2/igt@gem_exec_suspend@basic...@smem.html * igt@gem_lmem_swapping@random: - shard-apl: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#4613]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110870v1/shard-apl6/igt@gem_lmem_swapp...@random.html * igt@gem_lmem_swapping@random-engines: - shard-skl: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#4613]) +5 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110870v1/shard-skl7/igt@gem_lmem_swapp...@random-engines.html * igt@gem_tiled_wb: - shard-skl: NOTRUN -> [TIMEOUT][14] ([i915#6990]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110870v1/shard-skl7/igt@gem_tiled_wb.html * igt@gem_userptr_blits@dmabuf-sync: - shard-skl: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#3323]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110870v1/shard-skl7/igt@gem_userptr_bl...@dmabuf-sync.html * igt@i915_module_load@load: - shard-skl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#6227]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110870v1/shard-skl1/igt@i915_module_l...@load.html * igt@i915_selftest@live@hangcheck: - shard-tglb: [PASS][17] -> [DMESG-WARN][18] ([i915#5591]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12379/shard-tglb3/igt@i915_selftest@l...@hangcheck.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110870v1/shard-tglb3/igt@i915_selftest@l...@hangcheck.html * igt@kms_ccs@pipe-a-bad-pixel-format-y_tiled_gen12_rc_ccs_cc: - shard-skl: NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#3886]) +10 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110870v1/shard-skl1/igt@kms_ccs@pipe-a-bad-pixel-format-y_tiled_gen12_rc_ccs_cc.html * igt@kms_ccs@pipe-b-random-ccs-data-4_tiled_dg2_rc_ccs: - shard-apl: NOTRUN -> [SKIP][20] ([fdo#109271]) +19 similar issues [20]:
[Intel-gfx] [i-g-t] tests/kms_plane: skip memory demanding modes in test_plane_panning
test_plane_panning requires about 10 times bigger amount of memory than
memory required by framebuffer in default display mode. In case of some
configurations it can exceed available memory (4k modes on small-bar
systems), causing test aborts.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6824
Signed-off-by: Andrzej Hajda
---
tests/kms_plane.c | 28 +---
1 file changed, 25 insertions(+), 3 deletions(-)
diff --git a/tests/kms_plane.c b/tests/kms_plane.c
index 8a54ba6645c..fc530d2cfd3 100644
--- a/tests/kms_plane.c
+++ b/tests/kms_plane.c
@@ -342,14 +342,14 @@ test_plane_panning_with_output(data_t *data,
drmModeModeInfo *mode;
igt_crc_t crc;
- igt_info("Testing connector %s using pipe %s\n",
-igt_output_name(output), kmstest_pipe_name(pipe));
-
igt_output_set_pipe(output, pipe);
mode = igt_output_get_mode(output);
primary = igt_output_get_plane(output, 0);
+ igt_info("Testing connector %s using pipe %s, mode %s\n",
+igt_output_name(output), kmstest_pipe_name(pipe), mode->name);
+
create_fb_for_mode_panning(data, mode, _fb);
igt_plane_set_fb(primary, _fb);
@@ -381,6 +381,8 @@ test_plane_panning_with_output(data_t *data,
static void
test_plane_panning(data_t *data, enum pipe pipe)
{
+ bool mode_found = false;
+ uint64_t mem_size = 0;
igt_output_t *output;
igt_crc_t ref_crc;
@@ -389,6 +391,26 @@ test_plane_panning(data_t *data, enum pipe pipe)
test_init(data, pipe);
+ for_each_memory_region(r, data->drm_fd)
+ if (r->ci.memory_class == I915_MEMORY_CLASS_DEVICE)
+ mem_size = r->cpu_size;
+
+ for_each_connector_mode(output) {
+ drmModeModeInfo *m = >config.connector->modes[j__];
+ uint32_t fb_size = m->hdisplay * m->vdisplay * 4;
+
+ /* test allocates 2 double-dim fbs, add one more, to be safe */
+ if (mem_size && 3 * 4 * fb_size > mem_size) {
+ igt_debug("Skipping mode %s due to low memory\n",
m->name);
+ continue;
+ }
+
+ igt_output_override_mode(output, m);
+ mode_found = true;
+ break;
+ }
+ igt_require(mode_found);
+
if (data->flags & TEST_PANNING_TOP_LEFT)
test_grab_crc(data, output, pipe, , data->flags, _crc);
else
--
2.34.1
[Intel-gfx] [PATCH v2] drm/i915: remove circ_buf.h includes
The last user of macros from that include was removed in 2018 by the
commit below.
Fixes: 6cc42152b02b ("drm/i915: Remove support for legacy debugfs crc
interface")
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: David Airlie
Cc: Daniel Vetter
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Jiri Slaby (SUSE)
---
Notes:
[v2] fixed e-mail setup
drivers/gpu/drm/i915/display/intel_pipe_crc.c | 1 -
drivers/gpu/drm/i915/i915_irq.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_pipe_crc.c
b/drivers/gpu/drm/i915/display/intel_pipe_crc.c
index 673454fbf784..e9774670e3f6 100644
--- a/drivers/gpu/drm/i915/display/intel_pipe_crc.c
+++ b/drivers/gpu/drm/i915/display/intel_pipe_crc.c
@@ -24,7 +24,6 @@
*
*/
-#include
#include
#include
#include
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index b0180ea38de0..a815a45a6e6b 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -28,7 +28,6 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-#include
#include
#include
--
2.38.1
Re: [Intel-gfx] [PATCH 1/3] Documentation/gpu: Fix section in the wrong scope
On Tue, Nov 08, 2022 at 09:49:45AM +, Tvrtko Ursulin wrote: On 07/11/2022 17:32, Lucas De Marchi wrote: That section should still be inside "DRM client usage stats" rather than as a sibling. Signed-off-by: Lucas De Marchi --- Documentation/gpu/drm-usage-stats.rst | 1 - 1 file changed, 1 deletion(-) diff --git a/Documentation/gpu/drm-usage-stats.rst b/Documentation/gpu/drm-usage-stats.rst index 92c5117368d7..b46327356e80 100644 --- a/Documentation/gpu/drm-usage-stats.rst +++ b/Documentation/gpu/drm-usage-stats.rst @@ -126,7 +126,6 @@ percentage utilization of the engine, whereas drm-engine- only reflects time active without considering what frequency the engine is operating as a percentage of it's maximum frequency. -=== Driver specific implementations === Oops - yep. Reviewed-by: Tvrtko Ursulin thanks, applied this. Anyone could take a look in the other 2? thanks Lucas De Marchi
Re: [Intel-gfx] [PATCH v5 3/9] drm/i915/dp: Replace intel_dp.dfp members with the new crtc_state sink_format
On 11/11/2022 2:36 AM, Ville Syrjälä wrote:
On Fri, Oct 28, 2022 at 03:14:05PM +0530, Ankit Nautiyal wrote:
The decision to use DFP output format conversion capabilities should be
during compute_config phase.
This patch uses the members of intel_dp->dfp to only store the
format conversion capabilities of the DP device and uses the crtc_state
sink_format member, to program the protocol-converter for
colorspace/format conversion.
v2: Use sink_format to determine the color conversion config for the
pcon (Ville).
v3: Fix typo: missing 'break' in switch case (lkp kernel test robot).
v4: Add helper to check if DP supports YCBCR420.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp.c | 122
1 file changed, 84 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 0e4f7b467970..95d0c653db7f 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -790,6 +790,7 @@ intel_dp_output_format(struct intel_connector *connector,
enum intel_output_format sink_format)
{
struct intel_dp *intel_dp = intel_attached_dp(connector);
+ struct drm_i915_private *i915 = dp_to_i915(intel_dp);
if (!connector->base.ycbcr_420_allowed ||
sink_format != INTEL_OUTPUT_FORMAT_YCBCR420)
@@ -799,6 +800,10 @@ intel_dp_output_format(struct intel_connector *connector,
intel_dp->dfp.ycbcr_444_to_420)
return INTEL_OUTPUT_FORMAT_RGB;
+ /* Prefer 4:2:0 passthrough over 4:4:4->4:2:0 conversion */
+ if (DISPLAY_VER(i915) >= 11 && intel_dp->dfp.ycbcr420_passthrough)
+ return INTEL_OUTPUT_FORMAT_YCBCR420;
+
if (intel_dp->dfp.ycbcr_444_to_420)
return INTEL_OUTPUT_FORMAT_YCBCR444;
else
The else branch here is also 420, so the whole logic
here doesn't seem to flow entirely sensibly.
Thinking a bit more abstractly, could we restate
this whole problem as something more like this?
if (source_can_output(sink_format))
return sink_format;
if (source_can_output(RGB) &&
dfp_can_convert_from_rgb(sink_format))
return RGB;
if (source_can_output(YCBCR444) &&
dfp_can_convert_from_ycbcr444(sink_format))
return YCBCR444;
This make sense and will also help to add 422 support easier.
I am only seeing one problem: about how to have DSC considerations
during source_can_output( ).
Gen 11+ should support YCBCR420. So for any ycbcr420_only mode we should
have sink_format, and output_format : YCbCr420.
This works well for cases where DSC doesn't get in picture. When higher
modes like 8k60 ycbcr420_only are involved, we need to use DSC.
Currently, our DSC1.1 does not support YCbCr420. The problem is that we
go for, dsc_compute_config at a later time.
This issue might have been masked, due to the messy order of checks in
intel_dp_output_format.
Specifically With HDMI2.1 PCONs supporting color conv, for such a case
we can have output_format as RGB, and sink_format as YCbCr420.
The DSC compression with RGB and then configure PCON to Decompress,
conv. to YCbCr420.
So can we put a check in source_can_output for Gen11+ where DSC might be
required, so that with source_can_output(YCBCR420) returns false in such
case, where DSC is the only way?
Regards,
Ankit
@@ -2668,6 +2673,8 @@ void intel_dp_configure_protocol_converter(struct
intel_dp *intel_dp,
const struct intel_crtc_state
*crtc_state)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ bool ycbcr444_to_420 = false;
+ bool rgb_to_ycbcr = false;
u8 tmp;
if (intel_dp->dpcd[DP_DPCD_REV] < 0x13)
@@ -2684,8 +2691,35 @@ void intel_dp_configure_protocol_converter(struct
intel_dp *intel_dp,
drm_dbg_kms(>drm, "Failed to %s protocol converter HDMI
mode\n",
str_enable_disable(intel_dp->has_hdmi_sink));
- tmp = crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR444 &&
- intel_dp->dfp.ycbcr_444_to_420 ?
DP_CONVERSION_TO_YCBCR420_ENABLE : 0;
+ if (crtc_state->sink_format == INTEL_OUTPUT_FORMAT_YCBCR420) {
+ switch (crtc_state->output_format) {
+ case INTEL_OUTPUT_FORMAT_YCBCR420:
+ /*
+* sink_format is YCBCR420, output_format is also
YCBCR420:
+* Passthrough.
+*/
+ break;
+ case INTEL_OUTPUT_FORMAT_YCBCR444:
+ /*
+* sink_format is YCBCR420, output_format is YCBCR444:
+* Downsample.
+*/
+ ycbcr444_to_420 = true;
+ break;
+ case INTEL_OUTPUT_FORMAT_RGB:
+ /*
+
Re: [Intel-gfx] [PATCH v2 00/11] Connect VFIO to IOMMUFD
On 2022/11/14 22:37, Yang, Lixiao wrote: > On 2022/11/14 20:51, Yi Liu wrote: >> On 2022/11/10 00:57, Jason Gunthorpe wrote: >>> On Tue, Nov 08, 2022 at 11:18:03PM +0800, Yi Liu wrote: On 2022/11/8 17:19, Nicolin Chen wrote: > On Mon, Nov 07, 2022 at 08:52:44PM -0400, Jason Gunthorpe wrote: > >> This is on github: >> https://github.com/jgunthorpe/linux/commits/vfio_iommufd > [...] >> v2: >> - Rebase to v6.1-rc3, v4 iommufd series >> - Fixup comments and commit messages from list remarks >> - Fix leaking of the iommufd for mdevs >> - New patch to fix vfio modaliases when vfio container is disabled >> - Add a dmesg once when the iommufd provided /dev/vfio/vfio is opened >> to signal that iommufd is providing this > > I've redone my previous sanity tests. Except those reported bugs, > things look fine. Once we fix those issues, GVT and other modules > can run some more stressful tests, I think. our side is also starting test (gvt, nic passthrough) this version. need to wait a while for the result. >>> >>> I've updated the branches with the two functional fixes discussed on >>> the list plus all the doc updates. >>> >> >> I see, due to timzone, the kernel we grabbed is 37c9e6e44d77a, it has >> slight diff in the scripts/kernel-doc compared with the latest commit >> (6bb16a9c67769). I don't think it impacts the test. >> >> https://git.kernel.org/pub/scm/linux/kernel/git/jgg/iommufd.git/log/?h=for-next >>(37c9e6e44d77a) >> >> Our side, Yu He, Lixiao Yang has done below tests on Intel platform >> with the above kernel, results are: >> >> 1) GVT-g test suit passed, Intel iGFx passthrough passed. >> >> 2) NIC passthrough test with different guest memory (1G/4G), passed. >> >> 3) Booting two different QEMUs in the same time but one QEMU opens >> legacy /dev/vfio/vfio and another opens /dev/iommu. Tests passed. >> >> 4) Tried below Kconfig combinations, results are expected. >> >> VFIO_CONTAINER=y, IOMMUFD=y -- test pass >> VFIO_CONTAINER=y, IOMMUFD=n -- test pass >> VFIO_CONTAINER=n, IOMMUFD=y , IOMMUFD_VFIO_CONTAINER=y -- test pass >> VFIO_CONTAINER=n, IOMMUFD=y , IOMMUFD_VFIO_CONTAINER=n -- no >> /dev/vfio/vfio, so test fail, expected >> >> 5) Tested devices from multi-device group. Assign such devices to the >> same VM, pass; assign them to different VMs, fail; assign them to a VM >> with Intel virtual VT-d, fail; Results are expected. >> >> Meanwhile, I also tested the branch in development branch for nesting, >> the basic functionality looks good. >> >> Tested-by: Yi Liu >> > Tested-by: Lixiao Yang > Tested-by: Yu He -- Best regards, He,Yu
Re: [Intel-gfx] [PATCH v3 3/6] drm/i915/pxp: Make intel_pxp_is_active implicitly sort PXP-owning-GT
On Mon, 2022-11-14 at 20:17 -0800, Ceraolo Spurio, Daniele wrote:
>
> On 10/21/2022 10:39 AM, Alan Previn wrote:
> > Make intel_pxp_is_active a global check and implicitly find
> > the PXP-owning-GT.
> >
> > As per prior two patches, callers of this function shall now
> > pass in i915 since PXP is a global GPU feature. Make
> > intel_pxp_is_active implicitly find the right gt so it's transparent
> > for global view callers (like display or gem-exec).
> >
> > However we also need to expose the per-gt variation of this for internal
> > pxp files to use (like what intel_pxp_is_active was prior) so also expose
> > a new intel_gtpxp_is_active function for replacement.
> >
> > Signed-off-by: Alan Previn
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +-
> > drivers/gpu/drm/i915/pxp/intel_pxp.c | 14 --
> > drivers/gpu/drm/i915/pxp/intel_pxp.h | 3 ++-
> > drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c | 4 ++--
> > drivers/gpu/drm/i915/pxp/intel_pxp_irq.c | 2 +-
> > 5 files changed, 18 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > index 72f47ebda75f..798e77398acc 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > @@ -271,7 +271,7 @@ static int proto_context_set_protected(struct
> > drm_i915_private *i915,
> > */
> > pc->pxp_wakeref = intel_runtime_pm_get(>runtime_pm);
> >
> > - if (!intel_pxp_is_active(_gt(i915)->pxp))
> > + if (!intel_pxp_is_active(i915))
> > ret = intel_pxp_start(_gt(i915)->pxp);
> > }
> >
> > diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> > b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> > index f7c909fce97c..15f7983f6da8 100644
> > --- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> > +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> > @@ -97,11 +97,21 @@ bool intel_pxp_is_enabled(struct drm_i915_private *i915)
> > return intel_gtpxp_is_enabled(>pxp);
> > }
> >
> > -bool intel_pxp_is_active(const struct intel_pxp *pxp)
> > +bool intel_gtpxp_is_active(const struct intel_pxp *pxp)
> > {
> > return pxp->arb_is_valid;
> > }
> >
> > +bool intel_pxp_is_active(struct drm_i915_private *i915)
>
> again I'd suggest a different name to differentiate the 2 checkers.
> Considering the only calling of this is from outside the PXP code is to
> decide whether to start the arb session or not, maybe rename this to
> intel_pxp_has_started or intel_pxp_is_running and leave the old
> intel_pxp_is_active as-is?
>
Again, i humbly disagree - if one is a wrapper around the other, i rather keep
the action specific part of the function
name to be exactly consistent. Perhaps like earlier, we can make
intel_pxp_is_active as a wrapper round
intel_gt_has_active_pxp. But i want to maintain the "active" key word to
enforce that symmetry and not decouple them
(since its a wrapper relationship).
> Daniele
>
>
Re: [Intel-gfx] [PATCH v3 2/6] drm/i915/pxp: Make intel_pxp_is_enabled implicitly sort PXP-owning-GT
On Mon, 2022-11-14 at 20:11 -0800, Ceraolo Spurio, Daniele wrote:
>
> On 10/21/2022 10:39 AM, Alan Previn wrote:
> > @@ -68,11 +69,34 @@ bool intel_gtpxp_is_supported(struct intel_pxp *pxp)
> > return false;
> > }
> >
> > -bool intel_pxp_is_enabled(const struct intel_pxp *pxp)
> > +bool intel_gtpxp_is_enabled(const struct intel_pxp *pxp)
>
> I'd rename this to intel_pxp_is_initialized, that way we don't have 2
> almost identically named checkers that mean different things (and also
> avoid the gtpxp prefix).
>
I disagree - one is a wrapper around the other so i rather DO insist we have
the same function-action name in the middle
with a different part of the function name being the qualifier for whether its
a global level checker or a gt-level
checker. Perhaps as per last review reply, we can do "intel_pxp_is_enabled" as
wrapper around "intel_gt_has_pxp_enabled"
- i think the "enabled" part SHOULD be consistent since one is a wrapper around
the other else a new reader will even
more baffled about why "enabled" is different from "initialized" despite trying
to get to the same anchor point, "pxp-
>ce".
> > {
> > return pxp->ce;
> > }
> >
> > +static struct intel_gt *_i915_to_pxp_gt(struct drm_i915_private *i915)
>
> nit: why the "_" prefix? we usually don't use it for x_to_y functions.
> Not a blocker.
I was assuming internal static functions dont have to obey such rules - i like
to use _foo for all local static
functions (so that when reading from a caller's code, i know its a local
static). Again, just another naming convention
preference thing that i feel seems to be happening here and there in the driver
code base but not consistent across all
files / function types. Since its a nit, i won't change this.
>
> > +{
> > + struct intel_gt *gt = NULL;
> > + int i = 0;
> > +
> > + for_each_gt(gt, i915, i) {
> > + /* There can be only one GT that supports PXP */
>
>
>
> > + if (gt && intel_gtpxp_is_supported(>pxp))
>
> for_each_gt already checks for gt not being NULL, no need to check again.
Got it - will fix this.
>
> Daniele
>
>
Re: [Intel-gfx] [PATCH v3 1/6] drm/i915/pxp: Make gt and pxp init/fini aware of PXP-owning-GT
On Mon, 2022-11-14 at 20:00 -0800, Ceraolo Spurio, Daniele wrote:
>
> On 10/21/2022 10:39 AM, Alan Previn wrote:
> > In preparation for future MTL-PXP feature support, PXP control
> > @@ -142,22 +166,21 @@ void intel_pxp_init(struct intel_pxp *pxp)
> > {
> > struct intel_gt *gt = pxp_to_gt(pxp);
> >
> > - /* we rely on the mei PXP module */
> > - if (!IS_ENABLED(CONFIG_INTEL_MEI_PXP))
> > - return;
> > -
> > /*
> > * If HuC is loaded by GSC but PXP is disabled, we can skip the init of
> > * the full PXP session/object management and just init the tee channel.
> > */
> > - if (HAS_PXP(gt->i915))
> > + if (_gt_supports_pxp(gt))
> > pxp_init_full(pxp);
> > - else if (intel_huc_is_loaded_by_gsc(>uc.huc) &&
> > intel_uc_uses_huc(>uc))
> > + else if (_gt_needs_teelink(gt))
> > intel_pxp_tee_component_init(pxp);
> > }
> >
> > void intel_pxp_fini(struct intel_pxp *pxp)
> > {
> > + if (!intel_gtpxp_is_supported(pxp))
> > + return;
>
> Why do you need this? the fini below should already be smart enough to
> only cleanup when needed.
Eventually i plan to create a backend abstraction for tee based vs mtl's gscccs
based and rather keep as much of the
checking on the front end to keep it cleaner.
>
> > +
> > pxp->arb_is_valid = false;
> >
> > intel_pxp_tee_component_fini(pxp);
> > diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
> > b/drivers/gpu/drm/i915/pxp/intel_pxp.h
> > index 2da309088c6d..c12e4d419c78 100644
> > --- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
> > +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
> > @@ -13,6 +13,8 @@ struct intel_pxp;
> > struct drm_i915_gem_object;
> >
> > struct intel_gt *pxp_to_gt(const struct intel_pxp *pxp);
> > +bool intel_gtpxp_is_supported(struct intel_pxp *pxp);
> > +
> > bool intel_pxp_is_enabled(const struct intel_pxp *pxp);
> > bool intel_pxp_is_active(const struct intel_pxp *pxp);
> >
> > diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
> > b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
> > index 4359e8be4101..124663cf0047 100644
> > --- a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
> > +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
> > @@ -70,7 +70,7 @@ void intel_pxp_debugfs_register(struct intel_pxp *pxp,
> > struct dentry *gt_root)
> > if (!gt_root)
> > return;
> >
> > - if (!HAS_PXP((pxp_to_gt(pxp)->i915)))
> > + if (!intel_gtpxp_is_supported(pxp))
> > return;
> >
>
> This now returns true for DG2, but we don't want to register the PXP
> debugfs there as we don't support PXP aside from HuC loading.
>
yeah - ok.
> IMO a
> better approach would be to have intel_gtpxp_is_supported be what you
> currently have as _gt_supports_pxp().
>
Okay, let me take a look at that since i recall that future patches would rely
on intel_gtpxp_is_supported for the case
where PXP is not supported but we just want to know if GT has backend tee for
component binding or something - but i
guess that could get a separate function as opposed to reusing
intel_gtpxp_is_supported.
> Also, intel_gtpxp_is_supported is a bit confusing because of the new
> "gtpxp" prefix. Why not use just intel_pxp_is_supported? We already have
> per-gt checkers that refer only to the subcomponent, like
> intel_huc_is_supported(), which for MTL is false on the primary GT and
> true on the media one. I don't see why we can't do the same for PXP.
I think that existing method isn't a good way - i rather use this opportunity
to set a precendence for pxp we can have a
more standardized naming convention based on the global-vs-per-gt level
checking (i also wish i had time to look at
"intra-vs-inter function naming). So when something is called with _pxp_ its
meant to be called as a global check
(passing in i915 as its param) and if its using _gtpxp_, then its meant to be
called as gt-level checker. And the
similar function name should be okay if the check is similar (just at different
hierarchy level). I prefer my way
because it allows that understanding purely from the function name as opposed
to having to look at the full definition
before knowing if its a global check vs a gt level check. I think we really
ought to have a more concise naming
convention as opposed to "we do it like this, so why not just follow". An
alternative would be instead of
"intel_gtpxp_is_supported" then "intel_gt_supports_pxp".
>
> Daniele
>
> > root = debugfs_create_dir("pxp", gt_root);
>
Re: [Intel-gfx] [PATCH 0/8] Enable YCbCr420 for VDSC
> > This patch series aims to enable the YCbCr420 format for DSC. Changes > > are mostly compute params related for hdmi,dp and dsi along with the > > addition of new rc_tables for native_420 and corresponding changes to > > macros used to fetch them. > > Huh, what's the deal with all the series on this sent today? > Was trying to create a new version of the older series I sent but ended up Creating a new link was experimenting around to get it right Regards, Suraj Kandpal > BR, > Jani. > > > -- > Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] ✗ Fi.CI.IGT: failure for i915: CAGF and RC6 changes for MTL (rev12)
== Series Details == Series: i915: CAGF and RC6 changes for MTL (rev12) URL : https://patchwork.freedesktop.org/series/108156/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12378_full -> Patchwork_108156v12_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_108156v12_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_108156v12_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (11 -> 11) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_108156v12_full: ### IGT changes ### Possible regressions * igt@gem_eio@banned: - shard-tglb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12378/shard-tglb8/igt@gem_...@banned.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v12/shard-tglb3/igt@gem_...@banned.html Known issues Here are the changes found in Patchwork_108156v12_full that come from known issues: ### CI changes ### Issues hit * boot: - shard-skl: ([PASS][3], [PASS][4], [PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26]) -> ([PASS][27], [PASS][28], [PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [FAIL][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49]) ([i915#5032]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12378/shard-skl9/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12378/shard-skl9/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12378/shard-skl9/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12378/shard-skl9/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12378/shard-skl7/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12378/shard-skl7/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12378/shard-skl7/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12378/shard-skl6/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12378/shard-skl6/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12378/shard-skl6/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12378/shard-skl6/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12378/shard-skl4/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12378/shard-skl4/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12378/shard-skl4/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12378/shard-skl2/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12378/shard-skl2/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12378/shard-skl1/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12378/shard-skl1/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12378/shard-skl1/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12378/shard-skl10/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12378/shard-skl10/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12378/shard-skl10/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12378/shard-skl10/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12378/shard-skl10/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v12/shard-skl9/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v12/shard-skl9/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v12/shard-skl9/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v12/shard-skl9/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v12/shard-skl7/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v12/shard-skl7/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v12/shard-skl7/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v12/shard-skl7/boot.html [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v12/shard-skl6/boot.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v12/shard-skl6/boot.html [37]:
Re: [Intel-gfx] [PATCH i-g-t v2 1/3] lib/igt_pm: Refactor get firmware_node fd
> -Original Message-
> From: Vivi, Rodrigo
> Sent: Tuesday, November 15, 2022 1:27 AM
> To: Gupta, Anshuman
> Cc: intel-gfx@lists.freedesktop.org; kamil.koniec...@linux.intel.com;
> Tangudu, Tilak ; Nilawar, Badal
>
> Subject: Re: [PATCH i-g-t v2 1/3] lib/igt_pm: Refactor get firmware_node fd
>
> On Mon, Nov 14, 2022 at 06:08:41PM +0530, Anshuman Gupta wrote:
> > Created igt_pm_open_pci_firmware_node() to refactor the retrieving the
> > firmware_node fd code.
> >
> > igt_pm_open_pci_firmware_node() will be used by other firmware_node
> > consumers.
> >
> > While doing that fixed the leaked fd as well.
> >
> > v2:
> > - return false instead of igt_require on no firmware_node_fd. [Kamil]
> > - use igt_assert() when failed to open 'real_power_state' on error
> > other then ENONET.
> >
> > Signed-off-by: Anshuman Gupta
> > ---
> > lib/igt_pm.c | 36 +---
>
> I believe we need a massive refactor in this lib... we have 2 different ways
> of
> using stuff, plus that ugly global restore...
>
> but anyway, this one here looks a good change regardless of the current
> mess in the lib.
>
>
> Reviewed-by: Rodrigo Vivi
Thanks Rodrigo for RB,
my bad I sent these patches on kernel mailing list instead of igt-dev.
I will keep your RB and re-float the patches to igt-dev.
Thanks,
Anshuman Gupta.
>
>
> > 1 file changed, 25 insertions(+), 11 deletions(-)
> >
> > diff --git a/lib/igt_pm.c b/lib/igt_pm.c index 1e6e9ed3f..4f0cfbdd1
> > 100644
> > --- a/lib/igt_pm.c
> > +++ b/lib/igt_pm.c
> > @@ -863,6 +863,20 @@ bool i915_output_is_lpsp_capable(int drm_fd,
> igt_output_t *output)
> > return strstr(buf, "LPSP: capable"); }
> >
> > +static int igt_pm_open_pci_firmware_node(struct pci_device *pci_dev)
> > +{
> > + char name[PATH_MAX];
> > + int dir;
> > +
> > + snprintf(name, PATH_MAX,
> > +
> "/sys/bus/pci/devices/%04x:%02x:%02x.%01x/firmware_node",
> > +pci_dev->domain, pci_dev->bus, pci_dev->dev, pci_dev-
> >func);
> > +
> > + dir = open(name, O_RDONLY);
> > +
> > + return dir;
> > +}
> > +
> > /**
> > * igt_pm_acpi_d3cold_supported:
> > * @pci_dev: root port pci_dev.
> > @@ -873,23 +887,23 @@ bool i915_output_is_lpsp_capable(int drm_fd,
> igt_output_t *output)
> > */
> > bool igt_pm_acpi_d3cold_supported(struct pci_device *pci_dev) {
> > - char name[PATH_MAX];
> > - int dir, fd;
> > -
> > - snprintf(name, PATH_MAX,
> > -
> "/sys/bus/pci/devices/%04x:%02x:%02x.%01x/firmware_node",
> > -pci_dev->domain, pci_dev->bus, pci_dev->dev, pci_dev-
> >func);
> > + int firmware_node_fd, fd;
> >
> > - dir = open(name, O_RDONLY);
> > - igt_require(dir > 0);
> > + firmware_node_fd = igt_pm_open_pci_firmware_node(pci_dev);
> > + if (firmware_node_fd < 0)
> > + return false;
> >
> > /* BIOS need to enable ACPI D3Cold Support.*/
> > - fd = openat(dir, "real_power_state", O_RDONLY);
> > - if (fd < 0 && errno == ENOENT)
> > + fd = openat(firmware_node_fd, "real_power_state", O_RDONLY);
> > + if (fd < 0 && errno == ENOENT) {
> > + close(firmware_node_fd);
> > return false;
> > + }
> >
> > - igt_require(fd > 0);
> > + igt_assert(errno > 0);
> >
> > + close(firmware_node_fd);
> > + close(fd);
> > return true;
> > }
> >
> > --
> > 2.25.1
> >
Re: [Intel-gfx] [PATCH v3 6/6] drm/i915/pxp: Make intel_pxp_key_check implicitly sort PXP-owning-GT
On 10/21/2022 10:39 AM, Alan Previn wrote:
Make intel_pxp_key_check implicitly find the PXP-owning-GT.
Callers of this function shall now pass in i915 since PXP
is a global GPU feature. Make intel_pxp_key_check implicitly
find the right gt to verify pxp session key establishment count
so it's transparent to the callers.
Signed-off-by: Alan Previn
Reviewed-by: Daniele Ceraolo Spurio
Daniele
---
drivers/gpu/drm/i915/display/skl_universal_plane.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +-
drivers/gpu/drm/i915/pxp/intel_pxp.c | 10 +-
drivers/gpu/drm/i915/pxp/intel_pxp.h | 2 +-
4 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index 7cb713043408..04e78acbaf5f 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -1841,7 +1841,7 @@ static bool bo_has_valid_encryption(struct
drm_i915_gem_object *obj)
{
struct drm_i915_private *i915 = to_i915(obj->base.dev);
- return intel_pxp_key_check(_gt(i915)->pxp, obj, false) == 0;
+ return intel_pxp_key_check(i915, obj, false) == 0;
}
static bool pxp_is_borked(struct drm_i915_gem_object *obj)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 1160723c9d2d..23224977e003 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -868,7 +868,7 @@ static struct i915_vma *eb_lookup_vma(struct
i915_execbuffer *eb, u32 handle)
*/
if (i915_gem_context_uses_protected_content(eb->gem_context) &&
i915_gem_object_is_protected(obj)) {
- err = intel_pxp_key_check(>gt->pxp, obj, true);
+ err = intel_pxp_key_check(vm->gt->i915, obj, true);
if (err) {
i915_gem_object_put(obj);
return ERR_PTR(err);
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index c87f812ba13a..5c9a4b2c9a75 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -313,10 +313,18 @@ void intel_pxp_fini_hw(struct intel_pxp *pxp)
intel_pxp_irq_disable(pxp);
}
-int intel_pxp_key_check(struct intel_pxp *pxp,
+int intel_pxp_key_check(struct drm_i915_private *i915,
struct drm_i915_gem_object *obj,
bool assign)
{
+ struct intel_gt *gt = intel_pxp_get_owning_gt(i915);
+ struct intel_pxp *pxp;
+
+ if (!gt)
+ return -ENODEV;
+
+ pxp = >pxp;
+
if (!intel_gtpxp_is_active(pxp))
return -ENODEV;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h b/drivers/gpu/drm/i915/pxp/intel_pxp.h
index c45949bb1f7b..85c5499daba5 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
@@ -33,7 +33,7 @@ void intel_pxp_mark_termination_in_progress(struct intel_pxp
*pxp);
int intel_pxp_start(struct drm_i915_private *i915);
-int intel_pxp_key_check(struct intel_pxp *pxp,
+int intel_pxp_key_check(struct drm_i915_private *i915,
struct drm_i915_gem_object *obj,
bool assign);
Re: [Intel-gfx] [PATCH v3 5/6] drm/i915/pxp: Make intel_pxp_start implicitly sort PXP-owning-GT
On 10/21/2022 10:39 AM, Alan Previn wrote:
Make intel_pxp_is_start implicitly find the PXP-owning-GT.
Callers of this function shall now pass in i915 since PXP
is a global GPU feature. Make intel_pxp_start implicitly
find the right gt to start PXP arb session so
it's transparent to the callers.
Signed-off-by: Alan Previn
Reviewed-by: Daniele Ceraolo Spurio
Daniele
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +-
drivers/gpu/drm/i915/pxp/intel_pxp.c| 9 -
drivers/gpu/drm/i915/pxp/intel_pxp.h| 2 +-
3 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 798e77398acc..af60f6494947 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -272,7 +272,7 @@ static int proto_context_set_protected(struct
drm_i915_private *i915,
pc->pxp_wakeref = intel_runtime_pm_get(>runtime_pm);
if (!intel_pxp_is_active(i915))
- ret = intel_pxp_start(_gt(i915)->pxp);
+ ret = intel_pxp_start(i915);
}
return ret;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 2c835c38c527..c87f812ba13a 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -259,10 +259,17 @@ static bool pxp_component_bound(struct intel_pxp *pxp)
* the arb session is restarted from the irq work when we receive the
* termination completion interrupt
*/
-int intel_pxp_start(struct intel_pxp *pxp)
+int intel_pxp_start(struct drm_i915_private *i915)
{
+ struct intel_gt *gt = intel_pxp_get_owning_gt(i915);
+ struct intel_pxp *pxp;
int ret = 0;
+ if (!gt)
+ return -ENODEV;
+
+ pxp = >pxp;
+
if (!intel_gtpxp_is_enabled(pxp))
return -ENODEV;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h b/drivers/gpu/drm/i915/pxp/intel_pxp.h
index 7d93055cdd6b..c45949bb1f7b 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
@@ -31,7 +31,7 @@ void intel_pxp_fini_hw(struct intel_pxp *pxp);
void intel_pxp_mark_termination_in_progress(struct intel_pxp *pxp);
-int intel_pxp_start(struct intel_pxp *pxp);
+int intel_pxp_start(struct drm_i915_private *i915);
int intel_pxp_key_check(struct intel_pxp *pxp,
struct drm_i915_gem_object *obj,
Re: [Intel-gfx] [PATCH v3 4/6] drm/i915/pxp: Make PXP tee component bind/unbind aware of PXP-owning-GT
On 10/21/2022 10:39 AM, Alan Previn wrote:
Ensure i915_pxp_tee_component_bind / unbind implicitly sorts out
getting the correct per-GT PXP control-context from the PXP-owning-GT
when establishing or ending connection. Thus, replace _i915_to_pxp_gt
with intel_pxp_get_owning_gt (also takes in i915).
Signed-off-by: Alan Previn
Reviewed-by: Daniele Ceraolo Spurio
Daniele
---
drivers/gpu/drm/i915/pxp/intel_pxp.c | 6 +++---
drivers/gpu/drm/i915/pxp/intel_pxp.h | 2 ++
drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 14 --
3 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 15f7983f6da8..2c835c38c527 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -74,7 +74,7 @@ bool intel_gtpxp_is_enabled(const struct intel_pxp *pxp)
return pxp->ce;
}
-static struct intel_gt *_i915_to_pxp_gt(struct drm_i915_private *i915)
+struct intel_gt *intel_pxp_get_owning_gt(struct drm_i915_private *i915)
{
struct intel_gt *gt = NULL;
int i = 0;
@@ -89,7 +89,7 @@ static struct intel_gt *_i915_to_pxp_gt(struct
drm_i915_private *i915)
bool intel_pxp_is_enabled(struct drm_i915_private *i915)
{
- struct intel_gt *gt = _i915_to_pxp_gt(i915);
+ struct intel_gt *gt = intel_pxp_get_owning_gt(i915);
if (!gt)
return false;
@@ -104,7 +104,7 @@ bool intel_gtpxp_is_active(const struct intel_pxp *pxp)
bool intel_pxp_is_active(struct drm_i915_private *i915)
{
- struct intel_gt *gt = _i915_to_pxp_gt(i915);
+ struct intel_gt *gt = intel_pxp_get_owning_gt(i915);
if (!gt)
return false;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
b/drivers/gpu/drm/i915/pxp/intel_pxp.h
index 70383394adb4..7d93055cdd6b 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
@@ -13,6 +13,8 @@ struct intel_pxp;
struct drm_i915_gem_object;
struct drm_i915_private;
+struct intel_gt *intel_pxp_get_owning_gt(struct drm_i915_private *i915);
+
struct intel_gt *pxp_to_gt(const struct intel_pxp *pxp);
bool intel_gtpxp_is_supported(struct intel_pxp *pxp);
bool intel_gtpxp_is_enabled(const struct intel_pxp *pxp);
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
index 1c6bc56391b7..eb7adb972610 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
@@ -20,8 +20,12 @@
static inline struct intel_pxp *i915_dev_to_pxp(struct device *i915_kdev)
{
struct drm_i915_private *i915 = kdev_to_i915(i915_kdev);
+ struct intel_gt *gt = intel_pxp_get_owning_gt(i915);
- return _gt(i915)->pxp;
+ if (!gt)
+ return NULL;
+
+ return >pxp;
}
static int intel_pxp_tee_io_message(struct intel_pxp *pxp,
@@ -128,10 +132,16 @@ static int i915_pxp_tee_component_bind(struct device
*i915_kdev,
{
struct drm_i915_private *i915 = kdev_to_i915(i915_kdev);
struct intel_pxp *pxp = i915_dev_to_pxp(i915_kdev);
- struct intel_uc *uc = _to_gt(pxp)->uc;
+ struct intel_uc *uc;
intel_wakeref_t wakeref;
int ret = 0;
+ if (!pxp) {
+ drm_warn(>drm, "tee comp binding without a PXP-owner
GT\n");
+ return -ENODEV;
+ }
+ uc = _to_gt(pxp)->uc;
+
mutex_lock(>tee_mutex);
pxp->pxp_component = data;
pxp->pxp_component->tee_dev = tee_kdev;
Re: [Intel-gfx] [PATCH v3 3/6] drm/i915/pxp: Make intel_pxp_is_active implicitly sort PXP-owning-GT
On 10/21/2022 10:39 AM, Alan Previn wrote:
Make intel_pxp_is_active a global check and implicitly find
the PXP-owning-GT.
As per prior two patches, callers of this function shall now
pass in i915 since PXP is a global GPU feature. Make
intel_pxp_is_active implicitly find the right gt so it's transparent
for global view callers (like display or gem-exec).
However we also need to expose the per-gt variation of this for internal
pxp files to use (like what intel_pxp_is_active was prior) so also expose
a new intel_gtpxp_is_active function for replacement.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +-
drivers/gpu/drm/i915/pxp/intel_pxp.c | 14 --
drivers/gpu/drm/i915/pxp/intel_pxp.h | 3 ++-
drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c | 4 ++--
drivers/gpu/drm/i915/pxp/intel_pxp_irq.c | 2 +-
5 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 72f47ebda75f..798e77398acc 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -271,7 +271,7 @@ static int proto_context_set_protected(struct
drm_i915_private *i915,
*/
pc->pxp_wakeref = intel_runtime_pm_get(>runtime_pm);
- if (!intel_pxp_is_active(_gt(i915)->pxp))
+ if (!intel_pxp_is_active(i915))
ret = intel_pxp_start(_gt(i915)->pxp);
}
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index f7c909fce97c..15f7983f6da8 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -97,11 +97,21 @@ bool intel_pxp_is_enabled(struct drm_i915_private *i915)
return intel_gtpxp_is_enabled(>pxp);
}
-bool intel_pxp_is_active(const struct intel_pxp *pxp)
+bool intel_gtpxp_is_active(const struct intel_pxp *pxp)
{
return pxp->arb_is_valid;
}
+bool intel_pxp_is_active(struct drm_i915_private *i915)
again I'd suggest a different name to differentiate the 2 checkers.
Considering the only calling of this is from outside the PXP code is to
decide whether to start the arb session or not, maybe rename this to
intel_pxp_has_started or intel_pxp_is_running and leave the old
intel_pxp_is_active as-is?
Daniele
+{
+ struct intel_gt *gt = _i915_to_pxp_gt(i915);
+
+ if (!gt)
+ return false;
+
+ return intel_gtpxp_is_active(>pxp);
+}
+
/* KCR register definitions */
#define KCR_INIT _MMIO(0x320f0)
/* Setting KCR Init bit is required after system boot */
@@ -300,7 +310,7 @@ int intel_pxp_key_check(struct intel_pxp *pxp,
struct drm_i915_gem_object *obj,
bool assign)
{
- if (!intel_pxp_is_active(pxp))
+ if (!intel_gtpxp_is_active(pxp))
return -ENODEV;
if (!i915_gem_object_is_protected(obj))
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
b/drivers/gpu/drm/i915/pxp/intel_pxp.h
index 61472018bc45..70383394adb4 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
@@ -16,9 +16,10 @@ struct drm_i915_private;
struct intel_gt *pxp_to_gt(const struct intel_pxp *pxp);
bool intel_gtpxp_is_supported(struct intel_pxp *pxp);
bool intel_gtpxp_is_enabled(const struct intel_pxp *pxp);
+bool intel_gtpxp_is_active(const struct intel_pxp *pxp);
bool intel_pxp_is_enabled(struct drm_i915_private *i915);
-bool intel_pxp_is_active(const struct intel_pxp *pxp);
+bool intel_pxp_is_active(struct drm_i915_private *i915);
void intel_pxp_init(struct intel_pxp *pxp);
void intel_pxp_fini(struct intel_pxp *pxp);
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
index 13f517f94bae..7f304b421633 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
@@ -25,7 +25,7 @@ static int pxp_info_show(struct seq_file *m, void *data)
return 0;
}
- drm_printf(, "active: %s\n", str_yes_no(intel_pxp_is_active(pxp)));
+ drm_printf(, "active: %s\n", str_yes_no(intel_gtpxp_is_active(pxp)));
drm_printf(, "instance counter: %u\n", pxp->key_instance);
return 0;
@@ -43,7 +43,7 @@ static int pxp_terminate_set(void *data, u64 val)
struct intel_pxp *pxp = data;
struct intel_gt *gt = pxp_to_gt(pxp);
- if (!intel_pxp_is_active(pxp))
+ if (!intel_gtpxp_is_active(pxp))
return -ENODEV;
/* simulate a termination interrupt */
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
index 8e8e5645e4fc..cd97f8d8cc10 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
@@ -86,7 +86,7 @@ void intel_pxp_irq_disable(struct intel_pxp *pxp)
Re: [Intel-gfx] [PATCH v3 2/6] drm/i915/pxp: Make intel_pxp_is_enabled implicitly sort PXP-owning-GT
On 10/21/2022 10:39 AM, Alan Previn wrote:
Make intel_pxp_is_enabled a global check and implicitly find the
PXP-owning-GT.
PXP feature support is a device-config flag. In preparation for MTL
PXP control-context shall reside on of the two GT's. That said,
update intel_pxp_is_enabled to take in i915 as its input and internally
find the right gt to check if PXP is enabled so its transparent to
callers of this functions.
However we also need to expose the per-gt variation of this internal
pxp files to use (like what intel_pxp_enabled was prior) so also expose
a new intel_gtpxp_is_enabled function for replacement.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_create.c | 2 +-
drivers/gpu/drm/i915/pxp/intel_pxp.c | 28 ++--
drivers/gpu/drm/i915/pxp/intel_pxp.h | 4 ++-
drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c | 2 +-
drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c | 2 +-
drivers/gpu/drm/i915/pxp/intel_pxp_irq.c | 2 +-
drivers/gpu/drm/i915/pxp/intel_pxp_pm.c | 8 +++---
drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 4 +--
9 files changed, 40 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 1e29b1e6d186..72f47ebda75f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -257,7 +257,7 @@ static int proto_context_set_protected(struct
drm_i915_private *i915,
if (!protected) {
pc->uses_protected_content = false;
- } else if (!intel_pxp_is_enabled(_gt(i915)->pxp)) {
+ } else if (!intel_pxp_is_enabled(i915)) {
ret = -ENODEV;
} else if ((pc->user_flags & BIT(UCONTEXT_RECOVERABLE)) ||
!(pc->user_flags & BIT(UCONTEXT_BANNABLE))) {
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index 33673fe7ee0a..e44803f9bec4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -384,7 +384,7 @@ static int ext_set_protected(struct i915_user_extension
__user *base, void *data
if (ext.flags)
return -EINVAL;
- if (!intel_pxp_is_enabled(_gt(ext_data->i915)->pxp))
+ if (!intel_pxp_is_enabled(ext_data->i915))
return -ENODEV;
ext_data->flags |= I915_BO_PROTECTED;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 545c075bf1aa..f7c909fce97c 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -9,6 +9,7 @@
#include "intel_pxp_tee.h"
#include "gem/i915_gem_context.h"
#include "gt/intel_context.h"
+#include "gt/intel_gt.h"
#include "i915_drv.h"
/**
@@ -68,11 +69,34 @@ bool intel_gtpxp_is_supported(struct intel_pxp *pxp)
return false;
}
-bool intel_pxp_is_enabled(const struct intel_pxp *pxp)
+bool intel_gtpxp_is_enabled(const struct intel_pxp *pxp)
I'd rename this to intel_pxp_is_initialized, that way we don't have 2
almost identically named checkers that mean different things (and also
avoid the gtpxp prefix).
{
return pxp->ce;
}
+static struct intel_gt *_i915_to_pxp_gt(struct drm_i915_private *i915)
nit: why the "_" prefix? we usually don't use it for x_to_y functions.
Not a blocker.
+{
+ struct intel_gt *gt = NULL;
+ int i = 0;
+
+ for_each_gt(gt, i915, i) {
+ /* There can be only one GT that supports PXP */
+ if (gt && intel_gtpxp_is_supported(>pxp))
for_each_gt already checks for gt not being NULL, no need to check again.
Daniele
+ return gt;
+ }
+ return NULL;
+}
+
+bool intel_pxp_is_enabled(struct drm_i915_private *i915)
+{
+ struct intel_gt *gt = _i915_to_pxp_gt(i915);
+
+ if (!gt)
+ return false;
+
+ return intel_gtpxp_is_enabled(>pxp);
+}
+
bool intel_pxp_is_active(const struct intel_pxp *pxp)
{
return pxp->arb_is_valid;
@@ -229,7 +253,7 @@ int intel_pxp_start(struct intel_pxp *pxp)
{
int ret = 0;
- if (!intel_pxp_is_enabled(pxp))
+ if (!intel_gtpxp_is_enabled(pxp))
return -ENODEV;
if (wait_for(pxp_component_bound(pxp), 250))
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
b/drivers/gpu/drm/i915/pxp/intel_pxp.h
index c12e4d419c78..61472018bc45 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
@@ -11,11 +11,13 @@
struct intel_pxp;
struct drm_i915_gem_object;
+struct drm_i915_private;
struct intel_gt *pxp_to_gt(const struct intel_pxp *pxp);
bool intel_gtpxp_is_supported(struct intel_pxp *pxp);
+bool intel_gtpxp_is_enabled(const struct intel_pxp *pxp);
-bool intel_pxp_is_enabled(const struct intel_pxp *pxp);
+bool
Re: [Intel-gfx] [PATCH v3 1/6] drm/i915/pxp: Make gt and pxp init/fini aware of PXP-owning-GT
On 10/21/2022 10:39 AM, Alan Previn wrote:
In preparation for future MTL-PXP feature support, PXP control
context should only valid on the correct gt tile. Depending on the
device-info this depends on which tile owns the VEBOX and KCR.
PXP is still a global feature though (despite its control-context
located in the owning GT structure). Additionally, we find
that the HAS_PXP macro is only used within the pxp module,
That said, lets drop that HAS_PXP macro altogether and replace it
with a more fitting named intel_gtpxp_is_supported and helpers
so that PXP init/fini can use to verify if the referenced gt supports
PXP or teelink.
Add TODO for Meteorlake that will come in future series.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/i915_drv.h | 4 ---
drivers/gpu/drm/i915/pxp/intel_pxp.c | 35
drivers/gpu/drm/i915/pxp/intel_pxp.h | 2 ++
drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c | 2 +-
4 files changed, 32 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7c64f8a17493..0921d1107825 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -923,10 +923,6 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
#define HAS_GLOBAL_MOCS_REGISTERS(dev_priv) (INTEL_INFO(dev_priv)->has_global_mocs)
-#define HAS_PXP(dev_priv) ((IS_ENABLED(CONFIG_DRM_I915_PXP) && \
- INTEL_INFO(dev_priv)->has_pxp) && \
- VDBOX_MASK(to_gt(dev_priv)))
-
#define HAS_GMCH(dev_priv) (INTEL_INFO(dev_priv)->display.has_gmch)
#define HAS_GMD_ID(i915) (INTEL_INFO(i915)->has_gmd_id)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 5efe61f67546..545c075bf1aa 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -44,6 +44,30 @@ struct intel_gt *pxp_to_gt(const struct intel_pxp *pxp)
return container_of(pxp, struct intel_gt, pxp);
}
+static bool _gt_needs_teelink(struct intel_gt *gt)
+{
+ /* TODO: MTL won't rely on CONFIG_INTEL_MEI_PXP but on GSC engine */
+ return (IS_ENABLED(CONFIG_INTEL_MEI_PXP) &&
intel_huc_is_loaded_by_gsc(>uc.huc) &&
+ intel_uc_uses_huc(>uc));
+}
+
+static bool _gt_supports_pxp(struct intel_gt *gt)
+{
+ /* TODO: MTL won't rely on CONFIG_INTEL_MEI_PXP but on GSC engine */
+ return (IS_ENABLED(CONFIG_INTEL_MEI_PXP) && IS_ENABLED(CONFIG_DRM_I915_PXP)
&&
+ INTEL_INFO((gt)->i915)->has_pxp && VDBOX_MASK(gt));
+}
+
+bool intel_gtpxp_is_supported(struct intel_pxp *pxp)
+{
+ struct intel_gt *gt = pxp_to_gt(pxp);
+
+ if (_gt_needs_teelink(gt) || _gt_supports_pxp(gt))
+ return true;
+
+ return false;
+}
+
bool intel_pxp_is_enabled(const struct intel_pxp *pxp)
{
return pxp->ce;
@@ -142,22 +166,21 @@ void intel_pxp_init(struct intel_pxp *pxp)
{
struct intel_gt *gt = pxp_to_gt(pxp);
- /* we rely on the mei PXP module */
- if (!IS_ENABLED(CONFIG_INTEL_MEI_PXP))
- return;
-
/*
* If HuC is loaded by GSC but PXP is disabled, we can skip the init of
* the full PXP session/object management and just init the tee channel.
*/
- if (HAS_PXP(gt->i915))
+ if (_gt_supports_pxp(gt))
pxp_init_full(pxp);
- else if (intel_huc_is_loaded_by_gsc(>uc.huc) &&
intel_uc_uses_huc(>uc))
+ else if (_gt_needs_teelink(gt))
intel_pxp_tee_component_init(pxp);
}
void intel_pxp_fini(struct intel_pxp *pxp)
{
+ if (!intel_gtpxp_is_supported(pxp))
+ return;
Why do you need this? the fini below should already be smart enough to
only cleanup when needed.
+
pxp->arb_is_valid = false;
intel_pxp_tee_component_fini(pxp);
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
b/drivers/gpu/drm/i915/pxp/intel_pxp.h
index 2da309088c6d..c12e4d419c78 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
@@ -13,6 +13,8 @@ struct intel_pxp;
struct drm_i915_gem_object;
struct intel_gt *pxp_to_gt(const struct intel_pxp *pxp);
+bool intel_gtpxp_is_supported(struct intel_pxp *pxp);
+
bool intel_pxp_is_enabled(const struct intel_pxp *pxp);
bool intel_pxp_is_active(const struct intel_pxp *pxp);
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
index 4359e8be4101..124663cf0047 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
@@ -70,7 +70,7 @@ void intel_pxp_debugfs_register(struct intel_pxp *pxp, struct
dentry *gt_root)
if (!gt_root)
return;
- if (!HAS_PXP((pxp_to_gt(pxp)->i915)))
+ if (!intel_gtpxp_is_supported(pxp))
return;
This now returns true for DG2, but we
Re: [Intel-gfx] [PATCH v2 1/3] KVM: x86: add a new page track hook track_remove_slot
On Tue, Nov 15, 2022 at 12:55:42AM +, Sean Christopherson wrote:
> On Tue, Nov 15, 2022, Yan Zhao wrote:
> > On Mon, Nov 14, 2022 at 11:24:16PM +, Sean Christopherson wrote:
> > > On Tue, Nov 15, 2022, Yan Zhao wrote:
> > > > On Mon, Nov 14, 2022 at 04:32:34PM +, Sean Christopherson wrote:
> > > > > On Mon, Nov 14, 2022, Yan Zhao wrote:
> > > > > > On Sat, Nov 12, 2022 at 12:43:07AM +, Sean Christopherson wrote:
> > > > > > > On Sat, Nov 12, 2022, Yan Zhao wrote:
> > > > > > > > And I'm also not sure if a slots_arch_lock is required for
> > > > > > > > kvm_slot_page_track_add_page() and
> > > > > > > > kvm_slot_page_track_remove_page().
> > > > > > >
> > > > > > > It's not required. slots_arch_lock protects interaction between
> > > > > > > memslot updates
> > > > > > In kvm_slot_page_track_add_page() and
> > > > > > kvm_slot_page_track_remove_page(),
> > > > > > slot->arch.gfn_track[mode][index] is updated in update_gfn_track(),
> > > > > > do you know which lock is used to protect it?
> > > > >
> > > > > mmu_lock protects the count, kvm->srcu protects the slot, and
> > > > > shadow_root_allocated
> > > > > protects that validity of gfn_track, i.e. shadow_root_allocated
> > > > > ensures that KVM
> > > > > allocates gfn_track for all memslots when shadow paging is activated.
> > > > Hmm, thanks for the reply.
> > > > but in direct_page_fault(),
> > > > if (page_fault_handle_page_track(vcpu, fault))
> > > > return RET_PF_EMULATE;
> > > >
> > > > slot->arch.gfn_track is read without any mmu_lock is held.
> > >
> > > That's a fast path that deliberately reads out of mmu_lock. A false
> > > positive
> > > only results in unnecessary emulation, and any false positive is
> > > inherently prone
> > > to races anyways, e.g. fault racing with zap.
> > what about false negative?
> > If the fast path read 0 count, no page track write callback will be called
> > and write
> > protection will be removed in the slow path.
>
> No. For a false negative to occur, a different task would have to create a
> SPTE
> and write-protect the GFN _while holding mmu_lock_. And then after acquiring
> mmu_lock, the vCPU that got the false negative would call make_spte(), which
> would
> detect that making the SPTE writable is disallowed due to the GFN being
> write-protected.
>
> if (pte_access & ACC_WRITE_MASK) {
> spte |= PT_WRITABLE_MASK | shadow_mmu_writable_mask;
>
> /*
>* Optimization: for pte sync, if spte was writable the hash
>* lookup is unnecessary (and expensive). Write protection
>* is responsibility of kvm_mmu_get_page / kvm_mmu_sync_roots.
>* Same reasoning can be applied to dirty page accounting.
>*/
> if (is_writable_pte(old_spte))
> goto out;
>
> /*
>* Unsync shadow pages that are reachable by the new, writable
>* SPTE. Write-protect the SPTE if the page can't be unsync'd,
>* e.g. it's write-tracked (upper-level SPs) or has one or more
>* shadow pages and unsync'ing pages is not allowed.
>*/
> if (mmu_try_to_unsync_pages(vcpu->kvm, slot, gfn, can_unsync,
> prefetch)) {
> pgprintk("%s: found shadow page for %llx, marking ro\n",
>__func__, gfn);
> wrprot = true;
> pte_access &= ~ACC_WRITE_MASK;
> spte &= ~(PT_WRITABLE_MASK | shadow_mmu_writable_mask);
> }
> }
>
>
>
> int mmu_try_to_unsync_pages(struct kvm *kvm, const struct kvm_memory_slot
> *slot,
> gfn_t gfn, bool can_unsync, bool prefetch)
> {
> struct kvm_mmu_page *sp;
> bool locked = false;
>
> /*
>* Force write-protection if the page is being tracked. Note, the page
>* track machinery is used to write-protect upper-level shadow pages,
>* i.e. this guards the role.level == 4K assertion below!
>*/
> if (kvm_slot_page_track_is_active(kvm, slot, gfn, KVM_PAGE_TRACK_WRITE))
> return -EPERM;
>
> ...
> }
Oh, you are right! I thought mmu_try_to_unsync_pages() is only for the
shadow mmu, and overlooked that TDP MMU will also go into it.
Thanks for the detailed explanation.
Thanks
Yan
Re: [Intel-gfx] [PATCH v2 00/11] Connect VFIO to IOMMUFD
On 11/9/22 11:57 AM, Jason Gunthorpe wrote: > On Tue, Nov 08, 2022 at 11:18:03PM +0800, Yi Liu wrote: >> On 2022/11/8 17:19, Nicolin Chen wrote: >>> On Mon, Nov 07, 2022 at 08:52:44PM -0400, Jason Gunthorpe wrote: >>> This is on github: https://github.com/jgunthorpe/linux/commits/vfio_iommufd >>> [...] v2: - Rebase to v6.1-rc3, v4 iommufd series - Fixup comments and commit messages from list remarks - Fix leaking of the iommufd for mdevs - New patch to fix vfio modaliases when vfio container is disabled - Add a dmesg once when the iommufd provided /dev/vfio/vfio is opened to signal that iommufd is providing this >>> >>> I've redone my previous sanity tests. Except those reported bugs, >>> things look fine. Once we fix those issues, GVT and other modules >>> can run some more stressful tests, I think. >> >> our side is also starting test (gvt, nic passthrough) this version. need to >> wait a while for the result. > > I've updated the branches with the two functional fixes discussed on > the list plus all the doc updates. > For s390, tested vfio-pci against some data mover workloads using QEMU on s390x with CONFIG_VFIO_CONTAINER=y and =n using zPCI interpretation assists (over ism/SMC-D, mlx5 and NVMe) and without zPCI interpretation assists (over mlx5 and NVMe) - will continue testing with more aggressive workloads. (I did not run with CONFIG_IOMMUFD_TEST other than when building the selftest, but I see you mentioned this to Yi -- I'll incorporate that setting into future runs.) Ran the self-tests on s390 in LPAR and within a QEMU guest -- all tests pass (used 1M hugepages) Did light regression testing of vfio-ap and vfio-ccw on s390x with CONFIG_VFIO_CONTAINER=y and =n. Didn't see it in your branch yet, but also verified the proposed change to iommufd_fill_cap_dma_avail (.avail = U32_MAX) would work as expected. Tested-by: Matthew Rosato
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: drm/i915/tgl+: Enable DC power states on all eDP ports
== Series Details ==
Series: drm/i915: drm/i915/tgl+: Enable DC power states on all eDP ports
URL : https://patchwork.freedesktop.org/series/110862/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12377_full -> Patchwork_110862v1_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (11 -> 11)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_110862v1_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_prime@basic-crc-vgem:
- {shard-dg1}:[SKIP][1] ([i915#6524]) -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12377/shard-dg1-13/igt@kms_pr...@basic-crc-vgem.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110862v1/shard-dg1-17/igt@kms_pr...@basic-crc-vgem.html
Known issues
Here are the changes found in Patchwork_110862v1_full that come from known
issues:
### CI changes ###
Issues hit
* boot:
- shard-glk: ([PASS][3], [PASS][4], [PASS][5], [PASS][6],
[PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12],
[PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18],
[PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24],
[PASS][25], [PASS][26], [PASS][27]) -> ([PASS][28], [PASS][29], [PASS][30],
[PASS][31], [PASS][32], [PASS][33], [FAIL][34], [PASS][35], [PASS][36],
[PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42],
[PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48],
[PASS][49], [PASS][50], [PASS][51], [PASS][52]) ([i915#4392])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12377/shard-glk1/boot.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12377/shard-glk9/boot.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12377/shard-glk9/boot.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12377/shard-glk9/boot.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12377/shard-glk8/boot.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12377/shard-glk8/boot.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12377/shard-glk8/boot.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12377/shard-glk7/boot.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12377/shard-glk7/boot.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12377/shard-glk7/boot.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12377/shard-glk6/boot.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12377/shard-glk6/boot.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12377/shard-glk6/boot.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12377/shard-glk6/boot.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12377/shard-glk5/boot.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12377/shard-glk5/boot.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12377/shard-glk5/boot.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12377/shard-glk3/boot.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12377/shard-glk3/boot.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12377/shard-glk3/boot.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12377/shard-glk2/boot.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12377/shard-glk2/boot.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12377/shard-glk2/boot.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12377/shard-glk1/boot.html
[27]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12377/shard-glk1/boot.html
[28]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110862v1/shard-glk1/boot.html
[29]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110862v1/shard-glk1/boot.html
[30]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110862v1/shard-glk1/boot.html
[31]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110862v1/shard-glk2/boot.html
[32]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110862v1/shard-glk2/boot.html
[33]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110862v1/shard-glk2/boot.html
[34]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110862v1/shard-glk3/boot.html
[35]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110862v1/shard-glk3/boot.html
[36]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110862v1/shard-glk3/boot.html
[37]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110862v1/shard-glk3/boot.html
[38]:
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/display: Add missing checks for cdclk crawling
== Series Details ==
Series: series starting with [1/3] drm/i915/display: Add missing checks for
cdclk crawling
URL : https://patchwork.freedesktop.org/series/110882/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12379 -> Patchwork_110882v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110882v1/index.html
Participating hosts (40 -> 37)
--
Missing(3): bat-kbl-2 bat-atsm-1 fi-bdw-samus
Known issues
Here are the changes found in Patchwork_110882v1 that come from known issues:
### IGT changes ###
Possible fixes
* igt@fbdev@read:
- {bat-rpls-2}: [SKIP][1] ([i915#2582]) -> [PASS][2] +4 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12379/bat-rpls-2/igt@fb...@read.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110882v1/bat-rpls-2/igt@fb...@read.html
* igt@gem_huc_copy@huc-copy:
- {bat-dg2-8}:[FAIL][3] ([i915#7029]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12379/bat-dg2-8/igt@gem_huc_c...@huc-copy.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110882v1/bat-dg2-8/igt@gem_huc_c...@huc-copy.html
* igt@i915_selftest@live@hugepages:
- {bat-rpls-2}: [DMESG-WARN][5] ([i915#5278]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12379/bat-rpls-2/igt@i915_selftest@l...@hugepages.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110882v1/bat-rpls-2/igt@i915_selftest@l...@hugepages.html
* igt@i915_selftest@live@requests:
- {bat-rpls-1}: [INCOMPLETE][7] ([i915#6257]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12379/bat-rpls-1/igt@i915_selftest@l...@requests.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110882v1/bat-rpls-1/igt@i915_selftest@l...@requests.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka: [FAIL][9] ([i915#6298]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12379/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110882v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
[i915#5278]: https://gitlab.freedesktop.org/drm/intel/issues/5278
[i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257
[i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#6434]: https://gitlab.freedesktop.org/drm/intel/issues/6434
[i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687
[i915#7029]: https://gitlab.freedesktop.org/drm/intel/issues/7029
[i915#7346]: https://gitlab.freedesktop.org/drm/intel/issues/7346
Build changes
-
* Linux: CI_DRM_12379 -> Patchwork_110882v1
CI-20190529: 20190529
CI_DRM_12379: fbd41f5bba3fa2af510a37dadb4ef872e2c54701 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7056: 05096a6754048f4b5a2de798ab4bea32012b556a @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_110882v1: fbd41f5bba3fa2af510a37dadb4ef872e2c54701 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
eafd11930413 drm/i915/display: Add CDCLK Support for MTL
5366152b9e7c drm/i915/display: Do both crawl and squash when changing cdclk
707c5fb520ba drm/i915/display: Add missing checks for cdclk crawling
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110882v1/index.html
Re: [Intel-gfx] [PATCH 2/3] drm/i915/display: Do both crawl and squash when changing cdclk
On Mon, Nov 14, 2022 at 04:07:13PM -0800, Srivatsa, Anusha wrote:
>
>
> > -Original Message-
> > From: Roper, Matthew D
> > Sent: Monday, November 14, 2022 4:01 PM
> > To: Srivatsa, Anusha
> > Cc: intel-gfx@lists.freedesktop.org; Ville Syrjälä
> >
> > Subject: Re: [PATCH 2/3] drm/i915/display: Do both crawl and squash when
> > changing cdclk
> >
> > On Mon, Nov 14, 2022 at 03:14:33PM -0800, Srivatsa, Anusha wrote:
> > ...
> > > > > +static void bxt_set_cdclk(struct drm_i915_private *dev_priv,
> > > > > + const struct intel_cdclk_config *cdclk_config,
> > > > > + enum pipe pipe)
> > > > > +{
> > > > > + struct intel_cdclk_config mid_cdclk_config;
> > > > > + int cdclk = cdclk_config->cdclk;
> > > > > + int ret;
> > > >
> > > > You should initialize ret to 0 here since you don't set it in the
> > > > new branch of the if/else ladder below.
> > > >
> > > > > +
> > > > > + /* Inform power controller of upcoming frequency change. */
> > > > > + if (DISPLAY_VER(dev_priv) >= 14) {
> > > > > + /* DISPLAY14+ do not follow the PUnit mailbox
> > > > communication,
> > > >
> > > > "Display versions 14 and above" or "Xe_LPD+ and beyond"
> > > >
> > > > Also, this is another case where "/*" should be on its own line.
> > > >
> > > > > + * skip this step.
> > > > > + */
> > > > > + } else if (DISPLAY_VER(dev_priv) >= 11) {
> > > > > + ret = skl_pcode_request(_priv->uncore,
> > > > SKL_PCODE_CDCLK_CONTROL,
> > > > > + SKL_CDCLK_PREPARE_FOR_CHANGE,
> > > > > + SKL_CDCLK_READY_FOR_CHANGE,
> > > > > + SKL_CDCLK_READY_FOR_CHANGE, 3);
> > > > > } else {
> > > > > /*
> > > > > - * The timeout isn't specified, the 2ms used here is
> > > > > based on
> > > > > - * experiment.
> > > > > - * FIXME: Waiting for the request completion could be
> > > > delayed
> > > > > - * until the next PCODE request based on BSpec.
> > > > > + * BSpec requires us to wait up to 150usec, but that
> > > > > leads to
> > > > > + * timeouts; the 2ms used here is based on experiment.
> > > > >*/
> > > > > ret = snb_pcode_write_timeout(_priv->uncore,
> > > > >
> > > > HSW_PCODE_DE_WRITE_FREQ_REQ,
> > > > > -
> > > > > cdclk_config->voltage_level,
> > > > > - 150, 2);
> > > > > + 0x8000, 150, 2);
> > > >
> > > > The switch from cdclk_config->voltage_level to a magic number
> > > > (0x8000) on old platforms doesn't seem to be related to the rest
> > > > of this patch. Ditto for the comment update about 150usec not being
> > enough.
> > > > Were those intended for a different patch?
> > > Well, initially both squash and crawl support for MTl was the
> > > intention. The change came to be a part of this patch because MTL
> > > doesn't go through the Punit mailbox communication like previous
> > > platforms and hence the churn. Thinking out loud if changing the
> > > commit message makes more sense or a separate patch. A separate patch
> > > would just remove make sure MTL does not touch the bits of code Punit
> > > code. And the next patch would be the actual
> > > squash_crawl-mid_cdclk_config patch.
> >
> > Okay, it looks like part of my confusion is just that the code movement made
> > the diff deltas somewhat non-intuitive; due to code ordering changes, it's
> > actually giving a diff of two completely different code blocks that just
> > happen
> > to look similar; you're not actually changing the value here.
> >
> > However I still think there might be a problem here. For pre-MTL platforms
> > there are supposed to be two pcode transactions, one before the frequency
> > change and one after. Before your patch, the 'before'
> > transaction used a hardcoded 0x8000 and the 'after' transaction used
> > cdclk_config->voltage_level [1]. Your patch keeps the 'before' step at the
> > beginning of bxt_set_cdclk, but it seems to drop the 'after' step as far as
> > I can
> > see. I don't believe that was intentional was it?
>
> That was not the intention here. I think the Pcode thing needs to be a
> separate patch? Might make reviewing easy.
The pcode handling in the current code is what we consider correct-ish
(although as noted in [1] below, not 100% correct). So I'm not sure
what you mean by a separate patch for the pcode thing. Do you mean
refactoring out the _bxt_set_cdclk() function in an initial patch
without the two-step midpoint stuff (since I think that refactoring is
the point you accidentally deleted the pcode hunk of code)? You can do
that if you want, although it's also probably fine to just update this
patch to not delete that code
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/i915/display: Add missing checks for cdclk crawling
== Series Details == Series: series starting with [1/3] drm/i915/display: Add missing checks for cdclk crawling URL : https://patchwork.freedesktop.org/series/110882/ State : warning == Summary == Error: dim checkpatch failed 77c35543c996 drm/i915/display: Add missing checks for cdclk crawling 0ea41d2f3543 drm/i915/display: Do both crawl and squash when changing cdclk -:62: WARNING:LONG_LINE: line length of 102 exceeds 100 columns #62: FILE: drivers/gpu/drm/i915/display/intel_cdclk.c:1736: + const struct intel_cdclk_config *old_cdclk_config, -:63: WARNING:LONG_LINE: line length of 102 exceeds 100 columns #63: FILE: drivers/gpu/drm/i915/display/intel_cdclk.c:1737: + const struct intel_cdclk_config *new_cdclk_config, -:192: ERROR:TRAILING_WHITESPACE: trailing whitespace #192: FILE: drivers/gpu/drm/i915/display/intel_cdclk.c:1862: +^I$ total: 1 errors, 2 warnings, 0 checks, 206 lines checked 17dddff83aa5 drm/i915/display: Add CDCLK Support for MTL
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/4] i915: Move list_count() to list.h for broader use
== Series Details ==
Series: series starting with [v2,1/4] i915: Move list_count() to list.h for
broader use
URL : https://patchwork.freedesktop.org/series/110870/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12379 -> Patchwork_110870v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110870v1/index.html
Participating hosts (40 -> 37)
--
Additional (1): fi-rkl-11600
Missing(4): fi-hsw-4770 bat-kbl-2 bat-atsm-1 fi-bdw-samus
Known issues
Here are the changes found in Patchwork_110870v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-rkl-11600: NOTRUN -> [SKIP][1] ([i915#2190])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110870v1/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@parallel-random-engines:
- fi-rkl-11600: NOTRUN -> [SKIP][2] ([i915#4613]) +3 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110870v1/fi-rkl-11600/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@gem_tiled_pread_basic:
- fi-rkl-11600: NOTRUN -> [SKIP][3] ([i915#3282])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110870v1/fi-rkl-11600/igt@gem_tiled_pread_basic.html
* igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600: NOTRUN -> [SKIP][4] ([i915#3012])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110870v1/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-7567u: [PASS][5] -> [DMESG-FAIL][6] ([i915#5334])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12379/fi-kbl-7567u/igt@i915_selftest@live@gt_heartbeat.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110870v1/fi-kbl-7567u/igt@i915_selftest@live@gt_heartbeat.html
- fi-bxt-dsi: [PASS][7] -> [DMESG-FAIL][8] ([i915#5334])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12379/fi-bxt-dsi/igt@i915_selftest@live@gt_heartbeat.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110870v1/fi-bxt-dsi/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600: NOTRUN -> [INCOMPLETE][9] ([i915#4817])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110870v1/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-rkl-11600: NOTRUN -> [SKIP][10] ([fdo#111827]) +7 similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110870v1/fi-rkl-11600/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-rkl-11600: NOTRUN -> [SKIP][11] ([i915#4103])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110870v1/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html
* igt@kms_force_connector_basic@force-load-detect:
- fi-rkl-11600: NOTRUN -> [SKIP][12] ([fdo#109285] / [i915#4098])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110870v1/fi-rkl-11600/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_psr@sprite_plane_onoff:
- fi-rkl-11600: NOTRUN -> [SKIP][13] ([i915#1072]) +3 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110870v1/fi-rkl-11600/igt@kms_psr@sprite_plane_onoff.html
* igt@kms_setmode@basic-clone-single-crtc:
- fi-rkl-11600: NOTRUN -> [SKIP][14] ([i915#3555] / [i915#4098])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110870v1/fi-rkl-11600/igt@kms_setm...@basic-clone-single-crtc.html
* igt@prime_vgem@basic-read:
- fi-rkl-11600: NOTRUN -> [SKIP][15] ([fdo#109295] / [i915#3291] /
[i915#3708]) +2 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110870v1/fi-rkl-11600/igt@prime_v...@basic-read.html
* igt@prime_vgem@basic-userptr:
- fi-rkl-11600: NOTRUN -> [SKIP][16] ([fdo#109295] / [i915#3301] /
[i915#3708])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110870v1/fi-rkl-11600/igt@prime_v...@basic-userptr.html
Possible fixes
* igt@gem_huc_copy@huc-copy:
- {bat-dg2-8}:[FAIL][17] ([i915#7029]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12379/bat-dg2-8/igt@gem_huc_c...@huc-copy.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110870v1/bat-dg2-8/igt@gem_huc_c...@huc-copy.html
* igt@i915_selftest@live@migrate:
- {bat-adlp-6}: [INCOMPLETE][19] ([i915#7348]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12379/bat-adlp-6/igt@i915_selftest@l...@migrate.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110870v1/bat-adlp-6/igt@i915_selftest@l...@migrate.html
*
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Finish (de)gamma readout (rev8)
== Series Details ==
Series: drm/i915: Finish (de)gamma readout (rev8)
URL : https://patchwork.freedesktop.org/series/79614/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12379 -> Patchwork_79614v8
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_79614v8 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_79614v8, 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_79614v8/index.html
Participating hosts (40 -> 40)
--
Additional (2): fi-kbl-soraka fi-tgl-dsi
Missing(2): bat-atsm-1 fi-bdw-samus
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_79614v8:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@client:
- fi-kbl-soraka: NOTRUN -> [INCOMPLETE][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_79614v8/fi-kbl-soraka/igt@i915_selftest@l...@client.html
Known issues
Here are the changes found in Patchwork_79614v8 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_gttfill@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][2] ([fdo#109271]) +8 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_79614v8/fi-kbl-soraka/igt@gem_exec_gttf...@basic.html
* igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_79614v8/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613]) +3
similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_79614v8/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][5] ([i915#1886])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_79614v8/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[PASS][6] -> [INCOMPLETE][7] ([i915#4785])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12379/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_79614v8/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@hugepages:
- fi-bsw-nick:[PASS][8] -> [DMESG-FAIL][9] ([i915#6217])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12379/fi-bsw-nick/igt@i915_selftest@l...@hugepages.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_79614v8/fi-bsw-nick/igt@i915_selftest@l...@hugepages.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-soraka: NOTRUN -> [SKIP][10] ([fdo#109271] / [fdo#111827]) +7
similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_79614v8/fi-kbl-soraka/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@runner@aborted:
- fi-hsw-4770:NOTRUN -> [FAIL][11] ([fdo#109271] / [i915#4312] /
[i915#5594])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_79614v8/fi-hsw-4770/igt@run...@aborted.html
- fi-bsw-nick:NOTRUN -> [FAIL][12] ([fdo#109271] / [i915#4312])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_79614v8/fi-bsw-nick/igt@run...@aborted.html
Possible fixes
* igt@gem_huc_copy@huc-copy:
- {bat-dg2-8}:[FAIL][13] ([i915#7029]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12379/bat-dg2-8/igt@gem_huc_c...@huc-copy.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_79614v8/bat-dg2-8/igt@gem_huc_c...@huc-copy.html
* igt@i915_pm_rpm@module-reload:
- {bat-rpls-2}: [DMESG-WARN][15] ([i915#6434]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12379/bat-rpls-2/igt@i915_pm_...@module-reload.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_79614v8/bat-rpls-2/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@hugepages:
- {bat-rpls-2}: [DMESG-WARN][17] ([i915#5278]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12379/bat-rpls-2/igt@i915_selftest@l...@hugepages.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_79614v8/bat-rpls-2/igt@i915_selftest@l...@hugepages.html
* igt@i915_selftest@live@migrate:
- {bat-adlp-6}: [INCOMPLETE][19] ([i915#7348]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12379/bat-adlp-6/igt@i915_selftest@l...@migrate.html
[20]:
Re: [Intel-gfx] [PATCH 2/3] drm/i915/display: Do both crawl and squash when changing cdclk
> -Original Message-
> From: Roper, Matthew D
> Sent: Monday, November 14, 2022 4:01 PM
> To: Srivatsa, Anusha
> Cc: intel-gfx@lists.freedesktop.org; Ville Syrjälä
>
> Subject: Re: [PATCH 2/3] drm/i915/display: Do both crawl and squash when
> changing cdclk
>
> On Mon, Nov 14, 2022 at 03:14:33PM -0800, Srivatsa, Anusha wrote:
> ...
> > > > +static void bxt_set_cdclk(struct drm_i915_private *dev_priv,
> > > > + const struct intel_cdclk_config *cdclk_config,
> > > > + enum pipe pipe)
> > > > +{
> > > > + struct intel_cdclk_config mid_cdclk_config;
> > > > + int cdclk = cdclk_config->cdclk;
> > > > + int ret;
> > >
> > > You should initialize ret to 0 here since you don't set it in the
> > > new branch of the if/else ladder below.
> > >
> > > > +
> > > > + /* Inform power controller of upcoming frequency change. */
> > > > + if (DISPLAY_VER(dev_priv) >= 14) {
> > > > + /* DISPLAY14+ do not follow the PUnit mailbox
> > > communication,
> > >
> > > "Display versions 14 and above" or "Xe_LPD+ and beyond"
> > >
> > > Also, this is another case where "/*" should be on its own line.
> > >
> > > > +* skip this step.
> > > > +*/
> > > > + } else if (DISPLAY_VER(dev_priv) >= 11) {
> > > > + ret = skl_pcode_request(_priv->uncore,
> > > SKL_PCODE_CDCLK_CONTROL,
> > > > + SKL_CDCLK_PREPARE_FOR_CHANGE,
> > > > + SKL_CDCLK_READY_FOR_CHANGE,
> > > > + SKL_CDCLK_READY_FOR_CHANGE, 3);
> > > > } else {
> > > > /*
> > > > -* The timeout isn't specified, the 2ms used here is
> > > > based on
> > > > -* experiment.
> > > > -* FIXME: Waiting for the request completion could be
> > > delayed
> > > > -* until the next PCODE request based on BSpec.
> > > > +* BSpec requires us to wait up to 150usec, but that
> > > > leads to
> > > > +* timeouts; the 2ms used here is based on experiment.
> > > > */
> > > > ret = snb_pcode_write_timeout(_priv->uncore,
> > > >
> > > HSW_PCODE_DE_WRITE_FREQ_REQ,
> > > > -
> > > > cdclk_config->voltage_level,
> > > > - 150, 2);
> > > > + 0x8000, 150, 2);
> > >
> > > The switch from cdclk_config->voltage_level to a magic number
> > > (0x8000) on old platforms doesn't seem to be related to the rest
> > > of this patch. Ditto for the comment update about 150usec not being
> enough.
> > > Were those intended for a different patch?
> > Well, initially both squash and crawl support for MTl was the
> > intention. The change came to be a part of this patch because MTL
> > doesn't go through the Punit mailbox communication like previous
> > platforms and hence the churn. Thinking out loud if changing the
> > commit message makes more sense or a separate patch. A separate patch
> > would just remove make sure MTL does not touch the bits of code Punit
> > code. And the next patch would be the actual
> > squash_crawl-mid_cdclk_config patch.
>
> Okay, it looks like part of my confusion is just that the code movement made
> the diff deltas somewhat non-intuitive; due to code ordering changes, it's
> actually giving a diff of two completely different code blocks that just
> happen
> to look similar; you're not actually changing the value here.
>
> However I still think there might be a problem here. For pre-MTL platforms
> there are supposed to be two pcode transactions, one before the frequency
> change and one after. Before your patch, the 'before'
> transaction used a hardcoded 0x8000 and the 'after' transaction used
> cdclk_config->voltage_level [1]. Your patch keeps the 'before' step at the
> beginning of bxt_set_cdclk, but it seems to drop the 'after' step as far as I
> can
> see. I don't believe that was intentional was it?
That was not the intention here. I think the Pcode thing needs to be a separate
patch? Might make reviewing easy.
Anusha
>
> Matt
>
>
> [1] It looks like we might need some other updates to that pcode stuff in
> general for some pre-MTL platforms. What we have today doesn't match
> what I see on the bspec for TGL at least (bspec 49208). That would be work
> for a different series though; just figured I should mention it...
>
> --
> Matt Roper
> Graphics Software Engineer
> VTT-OSGC Platform Enablement
> Intel Corporation
Re: [Intel-gfx] [PATCH 2/3] drm/i915/display: Do both crawl and squash when changing cdclk
On Mon, Nov 14, 2022 at 03:14:33PM -0800, Srivatsa, Anusha wrote:
...
> > > +static void bxt_set_cdclk(struct drm_i915_private *dev_priv,
> > > + const struct intel_cdclk_config *cdclk_config,
> > > + enum pipe pipe)
> > > +{
> > > + struct intel_cdclk_config mid_cdclk_config;
> > > + int cdclk = cdclk_config->cdclk;
> > > + int ret;
> >
> > You should initialize ret to 0 here since you don't set it in the new
> > branch of
> > the if/else ladder below.
> >
> > > +
> > > + /* Inform power controller of upcoming frequency change. */
> > > + if (DISPLAY_VER(dev_priv) >= 14) {
> > > + /* DISPLAY14+ do not follow the PUnit mailbox
> > communication,
> >
> > "Display versions 14 and above" or "Xe_LPD+ and beyond"
> >
> > Also, this is another case where "/*" should be on its own line.
> >
> > > + * skip this step.
> > > + */
> > > + } else if (DISPLAY_VER(dev_priv) >= 11) {
> > > + ret = skl_pcode_request(_priv->uncore,
> > SKL_PCODE_CDCLK_CONTROL,
> > > + SKL_CDCLK_PREPARE_FOR_CHANGE,
> > > + SKL_CDCLK_READY_FOR_CHANGE,
> > > + SKL_CDCLK_READY_FOR_CHANGE, 3);
> > > } else {
> > > /*
> > > - * The timeout isn't specified, the 2ms used here is based on
> > > - * experiment.
> > > - * FIXME: Waiting for the request completion could be
> > delayed
> > > - * until the next PCODE request based on BSpec.
> > > + * BSpec requires us to wait up to 150usec, but that leads to
> > > + * timeouts; the 2ms used here is based on experiment.
> > >*/
> > > ret = snb_pcode_write_timeout(_priv->uncore,
> > >
> > HSW_PCODE_DE_WRITE_FREQ_REQ,
> > > - cdclk_config->voltage_level,
> > > - 150, 2);
> > > + 0x8000, 150, 2);
> >
> > The switch from cdclk_config->voltage_level to a magic number
> > (0x8000) on old platforms doesn't seem to be related to the rest of this
> > patch. Ditto for the comment update about 150usec not being enough.
> > Were those intended for a different patch?
> Well, initially both squash and crawl support for MTl was the
> intention. The change came to be a part of this patch because MTL
> doesn't go through the Punit mailbox communication like previous
> platforms and hence the churn. Thinking out loud if changing the
> commit message makes more sense or a separate patch. A separate patch
> would just remove make sure MTL does not touch the bits of code Punit
> code. And the next patch would be the actual
> squash_crawl-mid_cdclk_config patch.
Okay, it looks like part of my confusion is just that the code movement
made the diff deltas somewhat non-intuitive; due to code ordering
changes, it's actually giving a diff of two completely different code
blocks that just happen to look similar; you're not actually changing
the value here.
However I still think there might be a problem here. For pre-MTL
platforms there are supposed to be two pcode transactions, one before
the frequency change and one after. Before your patch, the 'before'
transaction used a hardcoded 0x8000 and the 'after' transaction used
cdclk_config->voltage_level [1]. Your patch keeps the 'before' step at the
beginning of bxt_set_cdclk, but it seems to drop the 'after' step as far
as I can see. I don't believe that was intentional was it?
Matt
[1] It looks like we might need some other updates to that pcode stuff
in general for some pre-MTL platforms. What we have today doesn't match
what I see on the bspec for TGL at least (bspec 49208). That would be
work for a different series though; just figured I should mention it...
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/4] i915: Move list_count() to list.h for broader use
== Series Details == Series: series starting with [v2,1/4] i915: Move list_count() to list.h for broader use URL : https://patchwork.freedesktop.org/series/110870/ 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] [PATCH v2 1/3] KVM: x86: add a new page track hook track_remove_slot
On Mon, Nov 14, 2022 at 11:24:16PM +, Sean Christopherson wrote:
> On Tue, Nov 15, 2022, Yan Zhao wrote:
> > On Mon, Nov 14, 2022 at 04:32:34PM +, Sean Christopherson wrote:
> > > On Mon, Nov 14, 2022, Yan Zhao wrote:
> > > > On Sat, Nov 12, 2022 at 12:43:07AM +, Sean Christopherson wrote:
> > > > > On Sat, Nov 12, 2022, Yan Zhao wrote:
> > > > > > And I'm also not sure if a slots_arch_lock is required for
> > > > > > kvm_slot_page_track_add_page() and
> > > > > > kvm_slot_page_track_remove_page().
> > > > >
> > > > > It's not required. slots_arch_lock protects interaction between
> > > > > memslot updates
> > > > In kvm_slot_page_track_add_page() and kvm_slot_page_track_remove_page(),
> > > > slot->arch.gfn_track[mode][index] is updated in update_gfn_track(),
> > > > do you know which lock is used to protect it?
> > >
> > > mmu_lock protects the count, kvm->srcu protects the slot, and
> > > shadow_root_allocated
> > > protects that validity of gfn_track, i.e. shadow_root_allocated ensures
> > > that KVM
> > > allocates gfn_track for all memslots when shadow paging is activated.
> > Hmm, thanks for the reply.
> > but in direct_page_fault(),
> > if (page_fault_handle_page_track(vcpu, fault))
> > return RET_PF_EMULATE;
> >
> > slot->arch.gfn_track is read without any mmu_lock is held.
>
> That's a fast path that deliberately reads out of mmu_lock. A false positive
> only results in unnecessary emulation, and any false positive is inherently
> prone
> to races anyways, e.g. fault racing with zap.
what about false negative?
If the fast path read 0 count, no page track write callback will be called and
write
protection will be removed in the slow path.
Thanks
Yan
>
> > > arch/x86/kvm/mmu/page_track.c-void __kvm_write_track_remove_gfn(struct
> > > kvm *kvm,
> > > arch/x86/kvm/mmu/page_track.c-struct
> > > kvm_memory_slot *slot, gfn_t gfn)
> > > arch/x86/kvm/mmu/page_track.c-{
> > > arch/x86/kvm/mmu/page_track.c- lockdep_assert_held_write(>mmu_lock);
> > > arch/x86/kvm/mmu/page_track.c-
> > > arch/x86/kvm/mmu/page_track.c- if
> > > (KVM_BUG_ON(!kvm_page_track_write_tracking_enabled(kvm), kvm))
> > > arch/x86/kvm/mmu/page_track.c- return;
> > > arch/x86/kvm/mmu/page_track.c-
> > > arch/x86/kvm/mmu/page_track.c: update_gfn_write_track(slot, gfn, -1);
> > yes, it will be helpful.
> >
> > Besides, will WRITE_ONCE or atomic_add in update_gfn_write_track() to
> > update slot->arch.gfn_track be better?
>
> WRITE_ONCE() won't suffice, it needs to be atomic. Switching to
> atomic_inc/dec
> isn't worth it so long as KVM's shadow MMU takes mmu_lock for write, i.e.
> while
> the accounting is mutually exclusive for other reasons in both KVM and KVMGT.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Finish (de)gamma readout (rev8)
== Series Details ==
Series: drm/i915: Finish (de)gamma readout (rev8)
URL : https://patchwork.freedesktop.org/series/79614/
State : warning
== Summary ==
Error: dim checkpatch failed
88c0420d5b67 drm/i915: Clean up legacy palette defines
d4d9f8eed90c drm/i915: Clean up 10bit precision palette defines
-:31: WARNING:LONG_LINE: line length of 101 exceeds 100 columns
#31: FILE: drivers/gpu/drm/i915/display/intel_color.c:475:
+ REG_FIELD_PREP(PREC_PALETTE_10_GREEN_MASK,
drm_color_lut_extract(color->green, 10)) |
total: 0 errors, 1 warnings, 0 checks, 48 lines checked
c81bbc797f45 drm/i915: Clean up 12.4bit precision palette defines
a2eeb8680d4e drm/i915: Clean up chv CGM (de)gamma defines
-:29: WARNING:LONG_LINE: line length of 105 exceeds 100 columns
#29: FILE: drivers/gpu/drm/i915/display/intel_color.c:1081:
+ return REG_FIELD_PREP(CGM_PIPE_DEGAMMA_GREEN_LDW_MASK,
drm_color_lut_extract(color->green, 14)) |
-:30: WARNING:LONG_LINE: line length of 103 exceeds 100 columns
#30: FILE: drivers/gpu/drm/i915/display/intel_color.c:1082:
+ REG_FIELD_PREP(CGM_PIPE_DEGAMMA_BLUE_LDW_MASK,
drm_color_lut_extract(color->blue, 14));
-:46: WARNING:LONG_LINE: line length of 103 exceeds 100 columns
#46: FILE: drivers/gpu/drm/i915/display/intel_color.c:1108:
+ return REG_FIELD_PREP(CGM_PIPE_GAMMA_GREEN_LDW_MASK,
drm_color_lut_extract(color->green, 10)) |
-:47: WARNING:LONG_LINE: line length of 101 exceeds 100 columns
#47: FILE: drivers/gpu/drm/i915/display/intel_color.c:1109:
+ REG_FIELD_PREP(CGM_PIPE_GAMMA_BLUE_LDW_MASK,
drm_color_lut_extract(color->blue, 10));
total: 0 errors, 4 warnings, 0 checks, 65 lines checked
87fa44e9f527 drm/i915: Reorder 12.4 lut udw vs. ldw functions
a0584e681184 drm/i915: Fix adl+ degamma LUT size
27efc2b3de52 drm/i915: s/gamma/post_csc_lut/
a526cae69eab drm/i915: Add glk+ degamma readout
5bd63c9b8039 drm/i915: Read out CHV CGM degamma
-:27: WARNING:LONG_LINE: line length of 101 exceeds 100 columns
#27: FILE: drivers/gpu/drm/i915/display/intel_color.c:1092:
+ entry->green =
intel_color_lut_pack(REG_FIELD_GET(CGM_PIPE_DEGAMMA_GREEN_LDW_MASK, ldw), 14);
total: 0 errors, 1 warnings, 0 checks, 54 lines checked
9db95062c99a drm/i915: Add gamma/degamma readout for bdw+
5282c8be2812 drm/i915: Add gamma/degamma readout for ivb/hsw
33e4c52bdc35 drm/i915: Make ilk_read_luts() capable of degamma readout
e7c6ad10c86a drm/i915: Prep for C8 palette readout
72871ad9017d drm/i915: Make .read_luts() mandatory
121a91c16f3b drm/i915: Finish the LUT state checker
-:517: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'lut' - possible
side-effects?
#517: FILE: drivers/gpu/drm/i915/display/intel_display.c:5679:
+#define PIPE_CONF_CHECK_COLOR_LUT(lut, is_pre_csc_lut) do { \
+ if (current_config->gamma_mode == pipe_config->gamma_mode && \
+ !intel_color_lut_equal(current_config, \
+ current_config->lut, pipe_config->lut, \
+ is_pre_csc_lut)) { \
+ pipe_config_mismatch(fastset, crtc, __stringify(lut), \
+"hw_state doesn't match sw_state"); \
+ ret = false; \
} \
} while (0)
-:517: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'lut' may be better as
'(lut)' to avoid precedence issues
#517: FILE: drivers/gpu/drm/i915/display/intel_display.c:5679:
+#define PIPE_CONF_CHECK_COLOR_LUT(lut, is_pre_csc_lut) do { \
+ if (current_config->gamma_mode == pipe_config->gamma_mode && \
+ !intel_color_lut_equal(current_config, \
+ current_config->lut, pipe_config->lut, \
+ is_pre_csc_lut)) { \
+ pipe_config_mismatch(fastset, crtc, __stringify(lut), \
+"hw_state doesn't match sw_state"); \
+ ret = false; \
} \
} while (0)
total: 0 errors, 0 warnings, 2 checks, 476 lines checked
d270a10da218 drm/i915: Rework legacy LUT handling
f79130dcde2d drm/i915: Use hw degamma LUT for sw gamma on glk with YCbCr output
-:93: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written
"crtc_state->post_csc_lut"
#93: FILE: drivers/gpu/drm/i915/display/intel_color.c:1426:
+ crtc_state->post_csc_lut != NULL &&
total: 0 errors, 0 warnings, 1 checks, 131 lines checked
2ae5cea55c5e drm/i915: Use gamma LUT for RGB limited range compression
5e2c41d7c28a drm/i915: Add 10bit gamma mode for gen2/3
07d966797122 drm/i915: Do state check for color management changes
Re: [Intel-gfx] [PATCH 2/3] drm/i915/display: Do both crawl and squash when changing cdclk
> -Original Message-
> From: Roper, Matthew D
> Sent: Monday, November 14, 2022 2:16 PM
> To: Srivatsa, Anusha
> Cc: intel-gfx@lists.freedesktop.org; Ville Syrjälä
>
> Subject: Re: [PATCH 2/3] drm/i915/display: Do both crawl and squash when
> changing cdclk
>
> On Mon, Nov 14, 2022 at 12:57:16PM -0800, Anusha Srivatsa wrote:
> > From: Ville Syrjälä
> >
> > For MTL, changing cdclk from between certain frequencies has both
> > squash and crawl. Use the current cdclk config and the new(desired)
> > cdclk config to construtc a mid cdclk config.
> > Set the cdclk twice:
> > - Current cdclk -> mid cdclk
> > - mid cdclk -> desired cdclk
> >
> > v2: Add check in intel_modeset_calc_cdclk() to avoid cdclk change via
> > modeset for platforms that support squash_crawl sequences(Ville)
> >
> > v3: Add checks for:
> > - scenario where only slow clock is used and cdclk is actually 0
> > (bringing up display).
> > - PLLs are on before looking up the waveform.
> > - Squash and crawl capability checks.(Ville)
> >
> > v4: Rebase
> > - Move checks to be more consistent (Ville)
> > - Add comments (Bala)
> > v5:
> > - Further small changes. Move checks around.
> > - Make if-else better looking (Ville)
> >
> > v6: MTl should not follow PUnit mailbox communication as the rest of
> > gen11+ platforms.(Anusha)
> >
> > v7: (MattR)
> > - s/cdclk_crawl_and_squash/cdclk_compute_crawl_squash_midpoint
> > - Cleanup Pcode checks in bxt_set_cdclk()
> > - Correct unsigned/signed checks
> >
> > Cc: Matt Roper
> > Signed-off-by: Anusha Srivatsa
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/display/intel_cdclk.c | 163
> > -
> > 1 file changed, 124 insertions(+), 39 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > index 25d01271dc09..4db7103fe5d6 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > @@ -1727,37 +1727,74 @@ static bool cdclk_pll_is_unknown(unsigned int
> vco)
> > return vco == ~0;
> > }
> >
> > -static void bxt_set_cdclk(struct drm_i915_private *dev_priv,
> > - const struct intel_cdclk_config *cdclk_config,
> > - enum pipe pipe)
> > +static int cdclk_squash_divider(u16 waveform) {
> > + return hweight16(waveform ?: 0x); }
> > +
> > +static bool cdclk_compute_crawl_and_squash_midpoint(struct
> drm_i915_private *i915,
> > + const struct
> intel_cdclk_config *old_cdclk_config,
> > + const struct
> intel_cdclk_config *new_cdclk_config,
> > + struct intel_cdclk_config
> *mid_cdclk_config) {
> > + u16 old_waveform, new_waveform, mid_waveform;
> > + int size = 16;
> > + int div = 2;
> > +
> > + /* Return if both Squash and Crawl are not present */
> > + if (!HAS_CDCLK_CRAWL(i915) || !HAS_CDCLK_SQUASH(i915))
> > + return false;
> > +
> > + old_waveform = cdclk_squash_waveform(i915, old_cdclk_config-
> >cdclk);
> > + new_waveform = cdclk_squash_waveform(i915, new_cdclk_config-
> >cdclk);
> > +
> > + /* Return if Squash only or Crawl only is the desired action */
> > + if (old_cdclk_config->vco == 0 || new_cdclk_config->vco == 0 ||
> > + old_cdclk_config->vco == new_cdclk_config->vco ||
> > + old_waveform == new_waveform)
> > + return false;
> > +
> > + *mid_cdclk_config = *new_cdclk_config;
> > +
> > + /* Populate the mid_cdclk_config accordingly.
>
> Nit: kernel coding style says the "/*" needs to be on its own line.
>
> > +* - If moving to a higher cdclk, the desired action is squashing.
> > +* The mid cdclk config should have the new (squash) waveform.
> > +* - If moving to a lower cdclk, the desired action is crawling.
> > +* The mid cdclk config should have the new vco.
> > +*/
> > +
> > + if (cdclk_squash_divider(new_waveform) >
> cdclk_squash_divider(old_waveform)) {
> > + mid_cdclk_config->vco = old_cdclk_config->vco;
> > + mid_waveform = new_waveform;
> > + } else {
> > + mid_cdclk_config->vco = new_cdclk_config->vco;
> > + mid_waveform = old_waveform;
> > + }
> > +
> > + mid_cdclk_config->cdclk =
> DIV_ROUND_CLOSEST(cdclk_squash_divider(mid_waveform) *
> > + mid_cdclk_config->vco, size
> * div);
> > +
> > + /* make sure the mid clock came out sane */
> > +
> > + drm_WARN_ON(>drm, mid_cdclk_config->cdclk <
> > + min(old_cdclk_config->cdclk, new_cdclk_config->cdclk));
> > + drm_WARN_ON(>drm, mid_cdclk_config->cdclk >
> > + i915->display.cdclk.max_cdclk_freq);
> > + drm_WARN_ON(>drm, cdclk_squash_waveform(i915,
> mid_cdclk_config->cdclk) !=
> > + mid_waveform);
> > +
> > + return true;
> > +}
> > +
> > +static void
Re: [Intel-gfx] [PATCH v3 1/1] drm/i915/pxp: Separate PXP FW interface structures for both v42 and 43
On 11/7/2022 8:56 PM, Alan Previn wrote:
Previously, we only used PXP FW interface version-42 structures for
PXP arbitration session on ADL/TGL products and version-43 for HuC
authentication on DG2. That worked fine despite not differentiating such
versioning of the PXP firmware interaction structures. This was okay
back then because the only commands used via version 42 was not
used via version 43 and vice versa.
With MTL, we'll need both these versions side by side for the same
commands (PXP-session) with the older platform feature support. That
said, let's create separate files to define the structures and definitions
for both version-42 and 43 of PXP FW interfaces.
Signed-off-by: Alan Previn
Reviewed-by: Daniele Ceraolo Spurio
Daniele
---
.../drm/i915/pxp/intel_pxp_cmd_interface_42.h | 28 +
.../drm/i915/pxp/intel_pxp_cmd_interface_43.h | 26 +
.../i915/pxp/intel_pxp_cmd_interface_cmn.h| 35
drivers/gpu/drm/i915/pxp/intel_pxp_huc.c | 10 ++--
drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 12 ++--
.../drm/i915/pxp/intel_pxp_tee_interface.h| 57 ---
6 files changed, 100 insertions(+), 68 deletions(-)
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_42.h
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
delete mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_tee_interface.h
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_42.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_42.h
new file mode 100644
index ..739f9072fa5f
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_42.h
@@ -0,0 +1,28 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright(c) 2020, Intel Corporation. All rights reserved.
+ */
+
+#ifndef __INTEL_PXP_FW_INTERFACE_42_H__
+#define __INTEL_PXP_FW_INTERFACE_42_H__
+
+#include
+#include "intel_pxp_cmd_interface_cmn.h"
+
+/* PXP-Opcode for Init Session */
+#define PXP42_CMDID_INIT_SESSION 0x1e
+
+/* PXP-Input-Packet: Init Session (Arb-Session) */
+struct pxp42_create_arb_in {
+ struct pxp_cmd_header header;
+ u32 protection_mode;
+#define PXP42_ARB_SESSION_MODE_HEAVY 0x2
+ u32 session_id;
+} __packed;
+
+/* PXP-Output-Packet: Init Session */
+struct pxp42_create_arb_out {
+ struct pxp_cmd_header header;
+} __packed;
+
+#endif /* __INTEL_PXP_FW_INTERFACE_42_H__ */
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
new file mode 100644
index ..ad67e3f49c20
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright(c) 2022, Intel Corporation. All rights reserved.
+ */
+
+#ifndef __INTEL_PXP_FW_INTERFACE_43_H__
+#define __INTEL_PXP_FW_INTERFACE_43_H__
+
+#include
+#include "intel_pxp_cmd_interface_cmn.h"
+
+/* PXP-Cmd-Op definitions */
+#define PXP43_CMDID_START_HUC_AUTH 0x003A
+
+/* PXP-Input-Packet: HUC-Authentication */
+struct pxp43_start_huc_auth_in {
+ struct pxp_cmd_header header;
+ __le64 huc_base_address;
+} __packed;
+
+/* PXP-Output-Packet: HUC-Authentication */
+struct pxp43_start_huc_auth_out {
+ struct pxp_cmd_header header;
+} __packed;
+
+#endif /* __INTEL_PXP_FW_INTERFACE_43_H__ */
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
new file mode 100644
index ..c2f23394f9b8
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
@@ -0,0 +1,35 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright(c) 2022, Intel Corporation. All rights reserved.
+ */
+
+#ifndef __INTEL_PXP_FW_INTERFACE_CMN_H__
+#define __INTEL_PXP_FW_INTERFACE_CMN_H__
+
+#include
+
+#define PXP_APIVER(x, y) (((x) & 0x) << 16 | ((y) & 0x))
+
+/*
+ * there are a lot of status codes for PXP, but we only define the cross-API
+ * common ones that we actually can handle in the kernel driver. Other failure
+ * codes should be printed to error msg for debug.
+ */
+enum pxp_status {
+ PXP_STATUS_SUCCESS = 0x0,
+ PXP_STATUS_OP_NOT_PERMITTED = 0x4013
+};
+
+/* Common PXP FW message header */
+struct pxp_cmd_header {
+ u32 api_version;
+ u32 command_id;
+ union {
+ u32 status; /* out */
+ u32 stream_id; /* in */
+ };
+ /* Length of the message (excluding the header) */
+ u32 buffer_len;
+} __packed;
+
+#endif /* __INTEL_PXP_FW_INTERFACE_CMN_H__ */
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_huc.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_huc.c
index 7ec36d94e758..ed27e3524afc 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_huc.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_huc.c
@@ -13,14 +13,14 @@
#include "intel_pxp_huc.h"
#include "intel_pxp_tee.h"
#include
Re: [Intel-gfx] [PATCH v2 1/3] KVM: x86: add a new page track hook track_remove_slot
On Mon, Nov 14, 2022 at 04:32:34PM +, Sean Christopherson wrote:
> On Mon, Nov 14, 2022, Yan Zhao wrote:
> > On Sat, Nov 12, 2022 at 12:43:07AM +, Sean Christopherson wrote:
> > > On Sat, Nov 12, 2022, Yan Zhao wrote:
> > > > And I'm also not sure if a slots_arch_lock is required for
> > > > kvm_slot_page_track_add_page() and kvm_slot_page_track_remove_page().
> > >
> > > It's not required. slots_arch_lock protects interaction between memslot
> > > updates
> > In kvm_slot_page_track_add_page() and kvm_slot_page_track_remove_page(),
> > slot->arch.gfn_track[mode][index] is updated in update_gfn_track(),
> > do you know which lock is used to protect it?
>
> mmu_lock protects the count, kvm->srcu protects the slot, and
> shadow_root_allocated
> protects that validity of gfn_track, i.e. shadow_root_allocated ensures that
> KVM
> allocates gfn_track for all memslots when shadow paging is activated.
Hmm, thanks for the reply.
but in direct_page_fault(),
if (page_fault_handle_page_track(vcpu, fault))
return RET_PF_EMULATE;
slot->arch.gfn_track is read without any mmu_lock is held.
>
> The cleanup series I'm prepping adds lockdep assertions for the relevant
> paths, e.g.
>
> $ git grep -B 8 -E "update_gfn_write_track.*;"
> arch/x86/kvm/mmu/page_track.c-void __kvm_write_track_add_gfn(struct kvm *kvm,
> struct kvm_memory_slot *slot,
> arch/x86/kvm/mmu/page_track.c- gfn_t gfn)
> arch/x86/kvm/mmu/page_track.c-{
> arch/x86/kvm/mmu/page_track.c- lockdep_assert_held_write(>mmu_lock);
> arch/x86/kvm/mmu/page_track.c-
> arch/x86/kvm/mmu/page_track.c- if
> (KVM_BUG_ON(!kvm_page_track_write_tracking_enabled(kvm), kvm))
> arch/x86/kvm/mmu/page_track.c- return;
> arch/x86/kvm/mmu/page_track.c-
> arch/x86/kvm/mmu/page_track.c: update_gfn_write_track(slot, gfn, 1);
> --
> arch/x86/kvm/mmu/page_track.c-void __kvm_write_track_remove_gfn(struct kvm
> *kvm,
> arch/x86/kvm/mmu/page_track.c-struct
> kvm_memory_slot *slot, gfn_t gfn)
> arch/x86/kvm/mmu/page_track.c-{
> arch/x86/kvm/mmu/page_track.c- lockdep_assert_held_write(>mmu_lock);
> arch/x86/kvm/mmu/page_track.c-
> arch/x86/kvm/mmu/page_track.c- if
> (KVM_BUG_ON(!kvm_page_track_write_tracking_enabled(kvm), kvm))
> arch/x86/kvm/mmu/page_track.c- return;
> arch/x86/kvm/mmu/page_track.c-
> arch/x86/kvm/mmu/page_track.c: update_gfn_write_track(slot, gfn, -1);
yes, it will be helpful.
Besides, will WRITE_ONCE or atomic_add in update_gfn_write_track() to
update slot->arch.gfn_track be better?
Thanks
Yan
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm: Analog TV Improvements (rev10)
== Series Details ==
Series: drm: Analog TV Improvements (rev10)
URL : https://patchwork.freedesktop.org/series/107892/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12378 -> Patchwork_107892v10
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_107892v10 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_107892v10, 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_107892v10/index.html
Participating hosts (39 -> 39)
--
Additional (1): bat-rpls-2
Missing(1): fi-bdw-samus
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_107892v10:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@workarounds:
- fi-rkl-guc: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12378/fi-rkl-guc/igt@i915_selftest@l...@workarounds.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107892v10/fi-rkl-guc/igt@i915_selftest@l...@workarounds.html
Known issues
Here are the changes found in Patchwork_107892v10 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3@smem:
- fi-rkl-11600: NOTRUN -> [INCOMPLETE][3] ([i915#6179])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107892v10/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@gt_engines:
- bat-dg1-6: [PASS][4] -> [INCOMPLETE][5] ([i915#4418])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12378/bat-dg1-6/igt@i915_selftest@live@gt_engines.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107892v10/bat-dg1-6/igt@i915_selftest@live@gt_engines.html
* igt@runner@aborted:
- fi-apl-guc: NOTRUN -> [FAIL][6] ([i915#4312])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107892v10/fi-apl-guc/igt@run...@aborted.html
- bat-dg1-6: NOTRUN -> [FAIL][7] ([i915#4312])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107892v10/bat-dg1-6/igt@run...@aborted.html
Possible fixes
* igt@gem_huc_copy@huc-copy:
- {bat-dg2-8}:[FAIL][8] ([i915#7029]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12378/bat-dg2-8/igt@gem_huc_c...@huc-copy.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107892v10/bat-dg2-8/igt@gem_huc_c...@huc-copy.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-bxt-dsi: [DMESG-FAIL][10] ([i915#5334]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12378/fi-bxt-dsi/igt@i915_selftest@live@gt_heartbeat.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107892v10/fi-bxt-dsi/igt@i915_selftest@live@gt_heartbeat.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka: [FAIL][12] ([i915#6298]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12378/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107892v10/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
Warnings
* igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600: [INCOMPLETE][14] ([i915#4817]) -> [FAIL][15]
([fdo#103375])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12378/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107892v10/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155
[i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
[i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
[i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
[i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
[i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
[i915#4258]: https://gitlab.freedesktop.org/drm/intel/issues/4258
[i915#4312]:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm: Analog TV Improvements (rev10)
== Series Details == Series: drm: Analog TV Improvements (rev10) URL : https://patchwork.freedesktop.org/series/107892/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm: Analog TV Improvements (rev10)
== Series Details ==
Series: drm: Analog TV Improvements (rev10)
URL : https://patchwork.freedesktop.org/series/107892/
State : warning
== Summary ==
Error: dim checkpatch failed
33225d7686a2 docs/fb: Document current named modes
8c65b8e4719a drm/tests: Add Kunit Helpers
-:33: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#33:
new file mode 100644
-:38: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier
tag in line 1
#38: FILE: drivers/gpu/drm/tests/drm_kunit_helpers.c:1:
+#include
-:108: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier
tag in line 1
#108: FILE: drivers/gpu/drm/tests/drm_kunit_helpers.h:1:
+#ifndef DRM_KUNIT_HELPERS_H_
total: 0 errors, 3 warnings, 0 checks, 80 lines checked
a3be5ddeda07 drm/connector: Rename legacy TV property
-:111: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#111: FILE: drivers/gpu/drm/i2c/ch7006_drv.c:268:
+ drm_object_attach_property(>base,
conf->legacy_tv_mode_property,
priv->norm);
total: 0 errors, 0 warnings, 1 checks, 164 lines checked
f6e78b240441 drm/connector: Only register TV mode property if present
d25e87b44429 drm/connector: Rename drm_mode_create_tv_properties
2d384f3cc11f drm/connector: Add TV standard property
-:79: CHECK:LINE_SPACING: Please use a blank line after
function/struct/union/enum declarations
#79: FILE: drivers/gpu/drm/drm_connector.c:996:
+};
+DRM_ENUM_NAME_FN(drm_get_tv_mode_name, drm_tv_mode_enum_list)
-:335: WARNING:TYPO_SPELLING: 'Superseeded' may be misspelled - perhaps
'Superseded'?
#335: FILE: include/drm/drm_mode_config.h:720:
+* Superseeded by @tv_mode_property
^^^
total: 0 errors, 1 warnings, 1 checks, 291 lines checked
854c15ba16a0 drm/modes: Add a function to generate analog display modes
Traceback (most recent call last):
File "scripts/spdxcheck.py", line 11, in
import git
ModuleNotFoundError: No module named 'git'
-:122: WARNING:LONG_LINE: line length of 119 exceeds 100 columns
#122: FILE: drivers/gpu/drm/drm_modes.c:212:
+#define TV_MODE_PARAMETER(_mode, _lines, _line_dur, _hact, _hfp, _hslen, _hbp,
_hblk, _bt601_hfp, _vfp, _vslen, _vbp) \
-:137: WARNING:STATIC_CONST: Move const after static - use 'static const struct
analog_parameters '
#137: FILE: drivers/gpu/drm/drm_modes.c:227:
+const static struct analog_parameters tv_modes_parameters[] = {
-:330: WARNING:TABSTOP: Statements should start on a tabstop
#330: FILE: drivers/gpu/drm/drm_modes.c:420:
+int porches_rem = porches - hfp_min - hbp_min;
-:377: WARNING:TYPO_SPELLING: 'asymetric' may be misspelled - perhaps
'asymmetric'?
#377: FILE: drivers/gpu/drm/drm_modes.c:467:
+* PAL systems also have asymetric timings between the
^
-:378: WARNING:TYPO_SPELLING: 'symetric' may be misspelled - perhaps
'symmetric'?
#378: FILE: drivers/gpu/drm/drm_modes.c:468:
+* even and odd field, while NTSC is symetric.
-:518: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#518:
new file mode 100644
total: 0 errors, 6 warnings, 0 checks, 651 lines checked
fc9a4d8ce45b drm/client: Add some tests for drm_connector_pick_cmdline_mode()
Traceback (most recent call last):
File "scripts/spdxcheck.py", line 11, in
import git
ModuleNotFoundError: No module named 'git'
-:34: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#34:
new file mode 100644
-:95: CHECK:BRACES: Blank lines aren't necessary before a close brace '}'
#95: FILE: drivers/gpu/drm/tests/drm_client_modeset_test.c:57:
+
+}
-:126: CHECK:LINE_SPACING: Please don't use multiple blank lines
#126: FILE: drivers/gpu/drm/tests/drm_client_modeset_test.c:88:
+
+
total: 0 errors, 1 warnings, 2 checks, 107 lines checked
aba284fb3fe8 drm/modes: Move named modes parsing to a separate function
d0f98f4732dc drm/modes: Switch to named mode descriptors
201515db7ab8 drm/modes: Fill drm_cmdline mode from named modes
cd37dfced952 drm/connector: Add pixel clock to cmdline mode
214ea6d758e3 drm/connector: Add a function to lookup a TV mode by its name
Traceback (most recent call last):
File "scripts/spdxcheck.py", line 11, in
import git
ModuleNotFoundError: No module named 'git'
-:68: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#68:
new file mode 100644
total: 0 errors, 1 warnings, 0 checks, 118 lines checked
75d731d5d5c0 drm/modes: Introduce the tv_mode property as a command-line option
-:190: CHECK:LINE_SPACING: Please use a blank line after
function/struct/union/enum declarations
#190: FILE: drivers/gpu/drm/tests/drm_cmdline_parser_test.c:1002:
+}
+KUNIT_ARRAY_PARAM(drm_cmdline_tv_option,
total: 0 errors, 0 warnings, 1 checks, 183
Re: [Intel-gfx] [PATCH 2/3] drm/i915/display: Do both crawl and squash when changing cdclk
On Mon, Nov 14, 2022 at 12:57:16PM -0800, Anusha Srivatsa wrote:
> From: Ville Syrjälä
>
> For MTL, changing cdclk from between certain frequencies has
> both squash and crawl. Use the current cdclk config and
> the new(desired) cdclk config to construtc a mid cdclk config.
> Set the cdclk twice:
> - Current cdclk -> mid cdclk
> - mid cdclk -> desired cdclk
>
> v2: Add check in intel_modeset_calc_cdclk() to avoid cdclk
> change via modeset for platforms that support squash_crawl sequences(Ville)
>
> v3: Add checks for:
> - scenario where only slow clock is used and
> cdclk is actually 0 (bringing up display).
> - PLLs are on before looking up the waveform.
> - Squash and crawl capability checks.(Ville)
>
> v4: Rebase
> - Move checks to be more consistent (Ville)
> - Add comments (Bala)
> v5:
> - Further small changes. Move checks around.
> - Make if-else better looking (Ville)
>
> v6: MTl should not follow PUnit mailbox communication as the rest of
> gen11+ platforms.(Anusha)
>
> v7: (MattR)
> - s/cdclk_crawl_and_squash/cdclk_compute_crawl_squash_midpoint
> - Cleanup Pcode checks in bxt_set_cdclk()
> - Correct unsigned/signed checks
>
> Cc: Matt Roper
> Signed-off-by: Anusha Srivatsa
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 163 -
> 1 file changed, 124 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 25d01271dc09..4db7103fe5d6 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -1727,37 +1727,74 @@ static bool cdclk_pll_is_unknown(unsigned int vco)
> return vco == ~0;
> }
>
> -static void bxt_set_cdclk(struct drm_i915_private *dev_priv,
> - const struct intel_cdclk_config *cdclk_config,
> - enum pipe pipe)
> +static int cdclk_squash_divider(u16 waveform)
> +{
> + return hweight16(waveform ?: 0x);
> +}
> +
> +static bool cdclk_compute_crawl_and_squash_midpoint(struct drm_i915_private
> *i915,
> + const struct
> intel_cdclk_config *old_cdclk_config,
> + const struct
> intel_cdclk_config *new_cdclk_config,
> + struct intel_cdclk_config
> *mid_cdclk_config)
> +{
> + u16 old_waveform, new_waveform, mid_waveform;
> + int size = 16;
> + int div = 2;
> +
> + /* Return if both Squash and Crawl are not present */
> + if (!HAS_CDCLK_CRAWL(i915) || !HAS_CDCLK_SQUASH(i915))
> + return false;
> +
> + old_waveform = cdclk_squash_waveform(i915, old_cdclk_config->cdclk);
> + new_waveform = cdclk_squash_waveform(i915, new_cdclk_config->cdclk);
> +
> + /* Return if Squash only or Crawl only is the desired action */
> + if (old_cdclk_config->vco == 0 || new_cdclk_config->vco == 0 ||
> + old_cdclk_config->vco == new_cdclk_config->vco ||
> + old_waveform == new_waveform)
> + return false;
> +
> + *mid_cdclk_config = *new_cdclk_config;
> +
> + /* Populate the mid_cdclk_config accordingly.
Nit: kernel coding style says the "/*" needs to be on its own line.
> + * - If moving to a higher cdclk, the desired action is squashing.
> + * The mid cdclk config should have the new (squash) waveform.
> + * - If moving to a lower cdclk, the desired action is crawling.
> + * The mid cdclk config should have the new vco.
> + */
> +
> + if (cdclk_squash_divider(new_waveform) >
> cdclk_squash_divider(old_waveform)) {
> + mid_cdclk_config->vco = old_cdclk_config->vco;
> + mid_waveform = new_waveform;
> + } else {
> + mid_cdclk_config->vco = new_cdclk_config->vco;
> + mid_waveform = old_waveform;
> + }
> +
> + mid_cdclk_config->cdclk =
> DIV_ROUND_CLOSEST(cdclk_squash_divider(mid_waveform) *
> + mid_cdclk_config->vco, size
> * div);
> +
> + /* make sure the mid clock came out sane */
> +
> + drm_WARN_ON(>drm, mid_cdclk_config->cdclk <
> + min(old_cdclk_config->cdclk, new_cdclk_config->cdclk));
> + drm_WARN_ON(>drm, mid_cdclk_config->cdclk >
> + i915->display.cdclk.max_cdclk_freq);
> + drm_WARN_ON(>drm, cdclk_squash_waveform(i915,
> mid_cdclk_config->cdclk) !=
> + mid_waveform);
> +
> + return true;
> +}
> +
> +static void _bxt_set_cdclk(struct drm_i915_private *dev_priv,
> +const struct intel_cdclk_config *cdclk_config,
> +enum pipe pipe)
> {
> int cdclk = cdclk_config->cdclk;
> int vco = cdclk_config->vco;
> u32 val;
> u16 waveform;
> int clock;
> - int ret;
> -
> - /* Inform power controller of upcoming frequency change. */
> -
Re: [Intel-gfx] [PATCH 1/2] drm/i915/gt: Add GT oriented dmesg output
On 11/10/2022 01:43, Tvrtko Ursulin wrote:
On 09/11/2022 17:46, John Harrison wrote:
On 11/9/2022 03:05, Tvrtko Ursulin wrote:
On 08/11/2022 20:15, John Harrison wrote:
On 11/8/2022 01:01, Tvrtko Ursulin wrote:
On 07/11/2022 19:14, John Harrison wrote:
On 11/7/2022 08:17, Tvrtko Ursulin wrote:
On 07/11/2022 09:33, Tvrtko Ursulin wrote:
On 05/11/2022 01:03, Ceraolo Spurio, Daniele wrote:
On 11/4/2022 10:25 AM, john.c.harri...@intel.com wrote:
From: John Harrison
When trying to analyse bug reports from CI, customers, etc.
it can be
difficult to work out exactly what is happening on which GT in a
multi-GT system. So add GT oriented debug/error message
wrappers. If
used instead of the drm_ equivalents, you get the same output
but with
a GT# prefix on it.
Signed-off-by: John Harrison
The only downside to this is that we'll print "GT0: " even on
single-GT devices. We could introduce a gt->info.name and
print that, so we could have it different per-platform, but
IMO it's not worth the effort.
Reviewed-by: Daniele Ceraolo Spurio
I think it might be worth getting an ack from one of the
maintainers to make sure we're all aligned on transitioning to
these new logging macro for gt code.
Idea is I think a very good one. First I would suggest
standardising to lowercase GT in logs because:
$ grep "GT%" i915/ -r
$ grep "gt%" i915/ -r
i915/gt/intel_gt_sysfs.c: gt->i915->sysfs_gt, "gt%d",
gt->info.id))
i915/gt/intel_gt_sysfs.c: "failed to initialize
gt%d sysfs root\n", gt->info.id);
i915/gt/intel_gt_sysfs_pm.c: "failed to create gt%u RC6 sysfs
files (%pe)\n",
i915/gt/intel_gt_sysfs_pm.c: "failed to create gt%u RC6p sysfs
files (%pe)\n",
i915/gt/intel_gt_sysfs_pm.c: "failed to create gt%u RPS sysfs
files (%pe)",
i915/gt/intel_gt_sysfs_pm.c: "failed to create gt%u
punit_req_freq_mhz sysfs (%pe)",
i915/gt/intel_gt_sysfs_pm.c: "failed to create gt%u throttle
sysfs files (%pe)",
i915/gt/intel_gt_sysfs_pm.c: "failed to create gt%u
media_perf_power_attrs sysfs (%pe)\n",
i915/gt/intel_gt_sysfs_pm.c: "failed to add gt%u rps defaults
(%pe)\n",
i915/i915_driver.c: drm_err(>i915->drm, "gt%d:
intel_pcode_init failed %d\n", id, ret);
i915/i915_hwmon.c: snprintf(ddat_gt->name,
sizeof(ddat_gt->name), "i915_gt%u", i);
Just because there are 11 existing instances of one form doesn't
mean that the 275 instances that are waiting to be converted
should be done incorrectly. GT is an acronym and should be
capitalised.
Okay just make it consistent then.
Besides:
grep -r "GT " i915 | grep '"'
i915/vlv_suspend.c: drm_err(>drm, "timeout disabling GT
waking\n");
i915/vlv_suspend.c: "timeout waiting for GT
wells to go %s\n",
i915/vlv_suspend.c: drm_dbg(>drm, "GT register access
while GT waking disabled\n");
i915/i915_gpu_error.c: err_printf(m, "GT awake: %s\n",
str_yes_no(gt->awake));
i915/i915_debugfs.c: seq_printf(m, "GT awake? %s [%d], %llums\n",
i915/selftests/i915_gem_evict.c: pr_err("Failed to idle GT (on
%s)", engine->name);
i915/intel_uncore.c: "GT thread status wait
timed out\n");
i915/gt/uc/selftest_guc_multi_lrc.c: drm_err(>i915->drm, "GT
failed to idle: %d\n", ret);
i915/gt/uc/selftest_guc.c: drm_err(>i915->drm, "GT failed to
idle: %d\n", ret);
i915/gt/uc/selftest_guc.c: drm_err(>i915->drm, "GT failed to
idle: %d\n", ret);
i915/gt/intel_gt_mcr.c: * Some GT registers are designed as
"multicast" or "replicated" registers:
i915/gt/selftest_rps.c: pr_info("%s: rps counted
%d C0 cycles [%lldns] in %lldns [%d cycles], using GT clock
frequency of %uKHz\n",
i915/gt/selftest_hangcheck.c: pr_err("[%s] GT is wedged!\n",
engine->name);
i915/gt/selftest_hangcheck.c: pr_err("GT is wedged!\n");
i915/gt/intel_gt_clock_utils.c: "GT clock
frequency changed, was %uHz, now %uHz!\n",
i915/gt/selftest_engine_pm.c: pr_err("Unable to flush
GT pm before test\n");
i915/gt/selftest_engine_pm.c: pr_err("GT failed to idle\n");
i915/i915_sysfs.c: "failed to register GT
sysfs directory\n");
i915/intel_uncore.h: * of the basic non-engine GT registers
(referred to as "GSI" on
i915/intel_uncore.h: * newer platforms, or "GT block" on
older platforms)? If so, we'll
Then there is a question of naming. Are we okay with GT_XXX or,
do we want intel_gt_, or something completely different. I
don't have a strong opinion at the moment so I'll add some more
folks to Cc.
You mean GT_ERR("msg") vs intel_gt_err("msg")? Personally, I
would prefer just gt_err("msg") to keep it as close to the
official drm_* versions as possible. Print lines tend to be
excessively long already. Taking a 'gt' parameter instead of a
'>i915->drm' parameter does help with that but it seems like
calling the wrapper intel_gt_* is shooting ourselves in the foot
on that one. And GT_ERR vs gt_err just comes down to the fact
that it is a macro wrapper and therefore is required to
Re: [Intel-gfx] [PATCH 1/2] drm/i915/gt: Add GT oriented dmesg output
On 11/10/2022 02:33, Jani Nikula wrote:
On Wed, 09 Nov 2022, Michal Wajdeczko wrote:
Instead of merging this patch now, oriented on GT only, I would rather
wait until we discuss and plan solution for the all sub-components.
Once that's done (with agreement on naming and output) we can start
converting exiting messages.
My proposal would be:
- use wrappers per component
- use lower case names
- don't add colon
#define i915_xxx(_i915, _fmt, ...) \
drm_xxx(&(_i915)->drm, _fmt, ##__VA_ARGS__)
#define gt_xxx(_gt, _fmt, ...) \
i915_xxx((_gt)->i915, "GT%u " _fmt, (_gt)->info.id, ..
#define guc_xxx(_guc, _fmt, ...) \
gt_xxx(guc_to_gt(_guc), "GuC " _fmt, ..
#define ct_xxx(_ct, _fmt, ...) \
guc_xxx(ct_to_guc(_ct), "CTB " _fmt, ..
where
xxx = { err, warn, notice, info, dbg }
and then for calls like:
i915_err(i915, "Foo failed (%pe)\n", ERR_PTR(err));
gt_err(gt, "Foo failed (%pe)\n", ERR_PTR(err));
guc_err(guc, "Foo failed (%pe)\n", ERR_PTR(err));
ct_err(ct, "Foo failed (%pe)\n", ERR_PTR(err));
the output would look like:
[ ] i915 :00:02.0: [drm] *ERROR* Foo failed (-EIO)
[ ] i915 :00:02.0: [drm] *ERROR* GT0 Foo failed (-EIO)
[ ] i915 :00:02.0: [drm] *ERROR* GT0 GuC Foo failed (-EIO)
[ ] i915 :00:02.0: [drm] *ERROR* GT0 GuC CTB Foo failed (-EIO)
Would that work for all of you?
I think we borderline have too many wrappers already. I've basically
blocked the i915_* variants early on in favour of just using the drm_*
calls directly - which, themselves, are also wrappers on dev_*.
In general, there's aversion in the kernel to adding wrappers that hide
what's actually going on. WYSIWYG.
That is blatantly not the case. There is a very strong push in kernel
code reviews to abstract common code into helper functions. How is this
any different? If you removed all helper functions with the desire to
have truly WYSIWYG code then each line of code would be a paragraph long.
So I wasn't thrilled to see the GT_* wrappers either.
And indeed part of it is that anything you do sets an example for the
next developer coming along. You add wrappers for this, and sure enough
someone's going to cargo cult and add wrappers for some other
component. We didn't even have to merge this to see that idea pop up.
The thing with logging is that it's not just one wrapper. It's info,
notice, warn, err, multiplied by the "once" variants, with some
duplicated by the "ratelimited" variants. (And yeah, C sucks at this.)
Arguably the display code could use logging wrappers for connectors,
encoders and crtcs, too. Not just i915, but across drm. See:
git grep "\[\(CONNECTOR\|ENCODER\|CRTC\)"
But we've opted not to.
This is just my educated guess, but what I think is more likely to
happen is adding a "debug name" member to the relevant structs that you
could use like:
drm_dbg_kms(connector->dev, "%s foo\n", connector->dbg_id);
Huh? You want the wrapper to be called drm_dbg_gt instead of gt_dbg but
otherwise it is identical to what is currently in the patch? Other than
being a longer name, how is that any different? It is still very much a
wrapper of exactly the type that you don't seem to like? And as noted
already, in that case shouldn't we be pushing a patch to rename drm_dbg
to dev_dbg_drm first? In which case the above should be dev_dbg_drm_kms?
---
I'm not going to block this patchset, but I also really *really* don't
want to see a cargo culted copy of this for other components. Which kind
of makes me anxious.
I really don't understand the problem with adding such wrappers. Sure,
there are a bunch of varients - dbg, err, warn, etc. But the variant
list is contained and unlikely to grow at any point. It is trivially
easy to look up gt_dbg to find out what it is doing. It makes the code
much easier to read. I mean, who cares that gt_dbg is implemented via
drm_dbg which is implemented via dev_dbg? Only someone that is actively
wanting to further change the implementation. Anyone who is using it
just wants to know that they are calling the correct debug printer for
their module and are giving it the correct parameters. Having a nice
simple name makes that totally clear.
So what if you looked again what you could do to make using the drm_*
logging variants easier?
Not a lot. All other proposals so far have been adding complicated and
unwieldy constructs to every single print.
Fundamentally, the drm_dbg wrappers as they stand do not allow for
further customisation. So your choice is to replace, rewrite or wrap.
Replacing it with an entirely parallel implementation is fundamentally
the wrong direction. Re-writing the DRM layer to take a pointer to a
custom printer object instead of a 'struct drm_device' (where each
sub-module defines it's own private printer that adds it's preferred
string and chains on to the next printer) seems like a huge change to
the entire DRM code base for
[Intel-gfx] ✓ Fi.CI.BAT: success for i915: CAGF and RC6 changes for MTL (rev12)
== Series Details ==
Series: i915: CAGF and RC6 changes for MTL (rev12)
URL : https://patchwork.freedesktop.org/series/108156/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12378 -> Patchwork_108156v12
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v12/index.html
Participating hosts (39 -> 38)
--
Additional (1): bat-rpls-2
Missing(2): fi-bdw-samus fi-pnv-d510
Known issues
Here are the changes found in Patchwork_108156v12 that come from known issues:
### IGT changes ###
Possible fixes
* igt@gem_huc_copy@huc-copy:
- {bat-dg2-8}:[FAIL][1] ([i915#7029]) -> [PASS][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12378/bat-dg2-8/igt@gem_huc_c...@huc-copy.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v12/bat-dg2-8/igt@gem_huc_c...@huc-copy.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-bxt-dsi: [DMESG-FAIL][3] ([i915#5334]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12378/fi-bxt-dsi/igt@i915_selftest@live@gt_heartbeat.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v12/fi-bxt-dsi/igt@i915_selftest@live@gt_heartbeat.html
- fi-apl-guc: [DMESG-FAIL][5] ([i915#5334]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12378/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v12/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka: [FAIL][7] ([i915#6298]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12378/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v12/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155
[i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
[i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
[i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
[i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
[i915#4258]: https://gitlab.freedesktop.org/drm/intel/issues/4258
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
[i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#6434]: https://gitlab.freedesktop.org/drm/intel/issues/6434
[i915#6559]: https://gitlab.freedesktop.org/drm/intel/issues/6559
[i915#6621]: https://gitlab.freedesktop.org/drm/intel/issues/6621
[i915#7029]: https://gitlab.freedesktop.org/drm/intel/issues/7029
[i915#7456]: https://gitlab.freedesktop.org/drm/intel/issues/7456
Build changes
-
* Linux: CI_DRM_12378 -> Patchwork_108156v12
CI-20190529: 20190529
CI_DRM_12378: adf57aa9c15f55b7c544ff211e9e9f6a6f37ac10 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7056: 05096a6754048f4b5a2de798ab4bea32012b556a @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_108156v12: adf57aa9c15f55b7c544ff211e9e9f6a6f37ac10 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
70c286fb7f6f drm/i915/mtl: C6 residency and C state type for MTL SAMedia
382d47183b0d drm/i915/gt: Use RC6 residency types as arguments to residency
functions
1b56b7e64ad3 drm/i915/mtl: Modify CAGF functions for MTL
fd65468dc101 drm/i915: Use GEN12_RPSTAT register for GT freq
b9dfdfaecba0 drm/i915/rps: Prefer REG_FIELD_GET in intel_rps_get_cagf
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v12/index.html
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/edid/firmware: stop using a throwaway platform device
== Series Details ==
Series: drm/edid/firmware: stop using a throwaway platform device
URL : https://patchwork.freedesktop.org/series/110859/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12376_full -> Patchwork_110859v1_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_110859v1_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_110859v1_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (11 -> 11)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_110859v1_full:
### IGT changes ###
Possible regressions
* igt@kms_cursor_crc@cursor-sliding-64x64@pipe-b-edp-1:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/shard-tglb1/igt@kms_cursor_crc@cursor-sliding-64...@pipe-b-edp-1.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/shard-tglb8/igt@kms_cursor_crc@cursor-sliding-64...@pipe-b-edp-1.html
* igt@kms_flip@busy-flip@a-edp1:
- shard-skl: NOTRUN -> [FAIL][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/shard-skl2/igt@kms_flip@busy-f...@a-edp1.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_ctx_isolation@preservation-s3@vcs1:
- {shard-dg1}:NOTRUN -> [INCOMPLETE][4] +1 similar issue
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/shard-dg1-13/igt@gem_ctx_isolation@preservation...@vcs1.html
Known issues
Here are the changes found in Patchwork_110859v1_full that come from known
issues:
### CI changes ###
Issues hit
* boot:
- shard-glk: ([PASS][5], [PASS][6], [PASS][7], [PASS][8],
[PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14],
[PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20],
[PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26],
[PASS][27], [PASS][28], [PASS][29]) -> ([PASS][30], [PASS][31], [PASS][32],
[FAIL][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38],
[PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44],
[PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50],
[PASS][51], [PASS][52], [PASS][53], [PASS][54]) ([i915#4392])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/shard-glk1/boot.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/shard-glk9/boot.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/shard-glk9/boot.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/shard-glk9/boot.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/shard-glk8/boot.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/shard-glk8/boot.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/shard-glk8/boot.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/shard-glk7/boot.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/shard-glk7/boot.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/shard-glk7/boot.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/shard-glk6/boot.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/shard-glk6/boot.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/shard-glk6/boot.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/shard-glk5/boot.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/shard-glk5/boot.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/shard-glk5/boot.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/shard-glk1/boot.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/shard-glk3/boot.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/shard-glk3/boot.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/shard-glk1/boot.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/shard-glk3/boot.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/shard-glk2/boot.html
[27]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/shard-glk2/boot.html
[28]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/shard-glk2/boot.html
[29]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/shard-glk2/boot.html
[30]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/shard-glk5/boot.html
[31]:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for i915: CAGF and RC6 changes for MTL (rev12)
== Series Details == Series: i915: CAGF and RC6 changes for MTL (rev12) URL : https://patchwork.freedesktop.org/series/108156/ 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] [PATCH] drm/i915: Update workaround documentation
On Mon, Nov 07, 2022 at 04:30:28PM -0800, Lucas De Marchi wrote: > There were several updates in the driver on how the workarounds are > handled since its documentation was written. Update the documentation to > reflect the current reality. > > Signed-off-by: Lucas De Marchi > --- > drivers/gpu/drm/i915/gt/intel_workarounds.c | 87 + > 1 file changed, 56 insertions(+), 31 deletions(-) > > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c > b/drivers/gpu/drm/i915/gt/intel_workarounds.c > index 3cdf5c24dbc5..0db3713c1beb 100644 > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c > @@ -17,43 +17,68 @@ > /** > * DOC: Hardware workarounds > * > - * This file is intended as a central place to implement most [1]_ of the > - * required workarounds for hardware to work as originally intended. They > fall > - * in five basic categories depending on how/when they are applied: > + * This is intended as a central place to implement most [1]_ of the Your footnotes don't hook up properly anymore. The original code had [1] and [2], but the new code hooks [1] to what used to be [2]. Since we moved this file under gt/ a while back, I wonder if we should note somehow that sgunit/soc workarounds and display workarounds aren't expected to be part of this file? > + * required workarounds for hardware to work as originally intended. Hardware > + * workarounds are register programming documented to be executed in the > driver > + * that fall outside of the normal programming sequences for a platform. > There > + * are some basic categories of workarounds, depending on how/when they are > + * applied: > * > - * - Workarounds that touch registers that are saved/restored to/from the HW > - * context image. The list is emitted (via Load Register Immediate > commands) > - * everytime a new context is created. > - * - GT workarounds. The list of these WAs is applied whenever these > registers > - * revert to default values (on GPU reset, suspend/resume [2]_, etc..). > - * - Display workarounds. The list is applied during display clock-gating > - * initialization. > - * - Workarounds that whitelist a privileged register, so that UMDs can > manage > - * them directly. This is just a special case of a MMMIO workaround (as we > - * write the list of these to/be-whitelisted registers to some special HW > - * registers). > - * - Workaround batchbuffers, that get executed automatically by the hardware > - * on every HW context restore. > + * - Context workarounds: workarounds that touch registers that are > + * saved/restored to/from the HW context image. The list is emitted (via > Load > + * Register Immediate commands) once when initializing the device and > saved in > + * the default context. That default context is then used on every context > + * creation to have a "primed golden context", i.e. a context image that > + * already contains the changes needed to all the registers. > * > - * .. [1] Please notice that there are other WAs that, due to their nature, > - *cannot be applied from a central place. Those are peppered around the > rest > - *of the code, as needed. > + * - Engine workarounds: the list of these WAs is applied whenever the > specific > + * engine is reset. It's also possible that a set of engine classes share a > + * common power domain and they are reset together. This happens on some > + * platforms with render and compute engines. In this case (at least) one > of > + * them need to keeep the workaround programming: the approach taken in the > + * driver is to tie those workarounds to the first compute/render engine > that > + * is registered. When executing with GuC submission, engine resets are > + * outside of kernel driver control, hence the list of registers involved > in > + * written once, on engine initialization, and then passed to GuC, that > + * saves/restores their values before/after the reset takes place. See > + * ``drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c`` for reference. > * > - * .. [2] Technically, some registers are powercontext saved & restored, so > they > - *survive a suspend/resume. In practice, writing them again is not too > - *costly and simplifies things. We can revisit this in the future. > + * - GT workarounds: the list of these WAs is applied whenever these > registers > + * revert to their default values: on GPU reset, suspend/resume, etc. This is where the new [1] used to be referenced from. > * > - * Layout > - * ~~ > + * - Register whitelist: some workarounds need to be implemented in > userspace, > + * but need to touch privileged registers. The whitelist in the kernel > + * instructs the hardware to allow the access to happen. From the kernel > side, > + * this is just a special case of a MMIO workaround (as we write the list > of > + * these to/be-whitelisted registers to some
[Intel-gfx] [PATCH 2/3] drm/i915/display: Do both crawl and squash when changing cdclk
From: Ville Syrjälä
For MTL, changing cdclk from between certain frequencies has
both squash and crawl. Use the current cdclk config and
the new(desired) cdclk config to construtc a mid cdclk config.
Set the cdclk twice:
- Current cdclk -> mid cdclk
- mid cdclk -> desired cdclk
v2: Add check in intel_modeset_calc_cdclk() to avoid cdclk
change via modeset for platforms that support squash_crawl sequences(Ville)
v3: Add checks for:
- scenario where only slow clock is used and
cdclk is actually 0 (bringing up display).
- PLLs are on before looking up the waveform.
- Squash and crawl capability checks.(Ville)
v4: Rebase
- Move checks to be more consistent (Ville)
- Add comments (Bala)
v5:
- Further small changes. Move checks around.
- Make if-else better looking (Ville)
v6: MTl should not follow PUnit mailbox communication as the rest of
gen11+ platforms.(Anusha)
v7: (MattR)
- s/cdclk_crawl_and_squash/cdclk_compute_crawl_squash_midpoint
- Cleanup Pcode checks in bxt_set_cdclk()
- Correct unsigned/signed checks
Cc: Matt Roper
Signed-off-by: Anusha Srivatsa
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 163 -
1 file changed, 124 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 25d01271dc09..4db7103fe5d6 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -1727,37 +1727,74 @@ static bool cdclk_pll_is_unknown(unsigned int vco)
return vco == ~0;
}
-static void bxt_set_cdclk(struct drm_i915_private *dev_priv,
- const struct intel_cdclk_config *cdclk_config,
- enum pipe pipe)
+static int cdclk_squash_divider(u16 waveform)
+{
+ return hweight16(waveform ?: 0x);
+}
+
+static bool cdclk_compute_crawl_and_squash_midpoint(struct drm_i915_private
*i915,
+ const struct
intel_cdclk_config *old_cdclk_config,
+ const struct
intel_cdclk_config *new_cdclk_config,
+ struct intel_cdclk_config
*mid_cdclk_config)
+{
+ u16 old_waveform, new_waveform, mid_waveform;
+ int size = 16;
+ int div = 2;
+
+ /* Return if both Squash and Crawl are not present */
+ if (!HAS_CDCLK_CRAWL(i915) || !HAS_CDCLK_SQUASH(i915))
+ return false;
+
+ old_waveform = cdclk_squash_waveform(i915, old_cdclk_config->cdclk);
+ new_waveform = cdclk_squash_waveform(i915, new_cdclk_config->cdclk);
+
+ /* Return if Squash only or Crawl only is the desired action */
+ if (old_cdclk_config->vco == 0 || new_cdclk_config->vco == 0 ||
+ old_cdclk_config->vco == new_cdclk_config->vco ||
+ old_waveform == new_waveform)
+ return false;
+
+ *mid_cdclk_config = *new_cdclk_config;
+
+ /* Populate the mid_cdclk_config accordingly.
+* - If moving to a higher cdclk, the desired action is squashing.
+* The mid cdclk config should have the new (squash) waveform.
+* - If moving to a lower cdclk, the desired action is crawling.
+* The mid cdclk config should have the new vco.
+*/
+
+ if (cdclk_squash_divider(new_waveform) >
cdclk_squash_divider(old_waveform)) {
+ mid_cdclk_config->vco = old_cdclk_config->vco;
+ mid_waveform = new_waveform;
+ } else {
+ mid_cdclk_config->vco = new_cdclk_config->vco;
+ mid_waveform = old_waveform;
+ }
+
+ mid_cdclk_config->cdclk =
DIV_ROUND_CLOSEST(cdclk_squash_divider(mid_waveform) *
+ mid_cdclk_config->vco, size
* div);
+
+ /* make sure the mid clock came out sane */
+
+ drm_WARN_ON(>drm, mid_cdclk_config->cdclk <
+ min(old_cdclk_config->cdclk, new_cdclk_config->cdclk));
+ drm_WARN_ON(>drm, mid_cdclk_config->cdclk >
+ i915->display.cdclk.max_cdclk_freq);
+ drm_WARN_ON(>drm, cdclk_squash_waveform(i915,
mid_cdclk_config->cdclk) !=
+ mid_waveform);
+
+ return true;
+}
+
+static void _bxt_set_cdclk(struct drm_i915_private *dev_priv,
+ const struct intel_cdclk_config *cdclk_config,
+ enum pipe pipe)
{
int cdclk = cdclk_config->cdclk;
int vco = cdclk_config->vco;
u32 val;
u16 waveform;
int clock;
- int ret;
-
- /* Inform power controller of upcoming frequency change. */
- if (DISPLAY_VER(dev_priv) >= 11)
- ret = skl_pcode_request(_priv->uncore,
SKL_PCODE_CDCLK_CONTROL,
- SKL_CDCLK_PREPARE_FOR_CHANGE,
- SKL_CDCLK_READY_FOR_CHANGE,
-
[Intel-gfx] [PATCH 3/3] drm/i915/display: Add CDCLK Support for MTL
As per bSpec MTL has 38.4 MHz Reference clock.
Adding the cdclk tables and cdclk_funcs that MTL
will use.
v2: Revert to using bxt_get_cdclk()
BSpec: 65243
Cc: Clint Taylor
Signed-off-by: Anusha Srivatsa
Reviewed-by: Clint Taylor
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 4db7103fe5d6..a672ce927f04 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -1346,6 +1346,16 @@ static const struct intel_cdclk_vals dg2_cdclk_table[] =
{
{}
};
+static const struct intel_cdclk_vals mtl_cdclk_table[] = {
+ { .refclk = 38400, .cdclk = 172800, .divider = 2, .ratio = 16,
.waveform = 0xad5a },
+ { .refclk = 38400, .cdclk = 192000, .divider = 2, .ratio = 16,
.waveform = 0xb6b6 },
+ { .refclk = 38400, .cdclk = 307200, .divider = 2, .ratio = 16,
.waveform = 0x },
+ { .refclk = 38400, .cdclk = 48, .divider = 2, .ratio = 25,
.waveform = 0x },
+ { .refclk = 38400, .cdclk = 556800, .divider = 2, .ratio = 29,
.waveform = 0x },
+ { .refclk = 38400, .cdclk = 652800, .divider = 2, .ratio = 34,
.waveform = 0x },
+ {}
+};
+
static int bxt_calc_cdclk(struct drm_i915_private *dev_priv, int min_cdclk)
{
const struct intel_cdclk_vals *table = dev_priv->display.cdclk.table;
@@ -3156,6 +3166,13 @@ u32 intel_read_rawclk(struct drm_i915_private *dev_priv)
return freq;
}
+static const struct intel_cdclk_funcs mtl_cdclk_funcs = {
+ .get_cdclk = bxt_get_cdclk,
+ .set_cdclk = bxt_set_cdclk,
+ .modeset_calc_cdclk = bxt_modeset_calc_cdclk,
+ .calc_voltage_level = tgl_calc_voltage_level,
+};
+
static const struct intel_cdclk_funcs tgl_cdclk_funcs = {
.get_cdclk = bxt_get_cdclk,
.set_cdclk = bxt_set_cdclk,
@@ -3291,7 +3308,10 @@ static const struct intel_cdclk_funcs i830_cdclk_funcs =
{
*/
void intel_init_cdclk_hooks(struct drm_i915_private *dev_priv)
{
- if (IS_DG2(dev_priv)) {
+ if (IS_METEORLAKE(dev_priv)) {
+ dev_priv->display.funcs.cdclk = _cdclk_funcs;
+ dev_priv->display.cdclk.table = mtl_cdclk_table;
+ } else if (IS_DG2(dev_priv)) {
dev_priv->display.funcs.cdclk = _cdclk_funcs;
dev_priv->display.cdclk.table = dg2_cdclk_table;
} else if (IS_ALDERLAKE_P(dev_priv)) {
--
2.25.1
[Intel-gfx] [PATCH 1/3] drm/i915/display: Add missing checks for cdclk crawling
cdclk_sanitize() function was written assuming vco was a signed integer.
vco gets assigned to -1 (essentially ~0) for the case where PLL
might be enabled and vco is not a frequency that will ever
get used. In such a scenario the right thing to do is disable the
PLL and re-enable it again with a valid frequency.
However the vco is declared as a unsigned variable.
With the above assumption, driver takes crawl path when not needed.
Add explicit check to not crawl in the case of an invalid PLL.
v2: Move the check from .h to .c (MattR)
- Move check to bxt_set_cdclk() instead of
intel_modeset_calc_cdclk() which is directly in
the path of the sanitize() function (Ville)
v3: remove unwanted parenthesis(Ville)
Cc: Ville Syrjälä
Cc: Matt Roper
Suggested-by: Ville Syrjälä
Signed-off-by: Anusha Srivatsa
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index b74e36d76013..25d01271dc09 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -1717,6 +1717,16 @@ static void dg2_cdclk_squash_program(struct
drm_i915_private *i915,
intel_de_write(i915, CDCLK_SQUASH_CTL, squash_ctl);
}
+static bool cdclk_pll_is_unknown(unsigned int vco)
+{
+ /*
+* Ensure driver does not take the crawl path for the
+* case when the vco is set to ~0 in the
+* sanitize path.
+*/
+ return vco == ~0;
+}
+
static void bxt_set_cdclk(struct drm_i915_private *dev_priv,
const struct intel_cdclk_config *cdclk_config,
enum pipe pipe)
@@ -1749,7 +1759,8 @@ static void bxt_set_cdclk(struct drm_i915_private
*dev_priv,
return;
}
- if (HAS_CDCLK_CRAWL(dev_priv) && dev_priv->display.cdclk.hw.vco > 0 &&
vco > 0) {
+ if (HAS_CDCLK_CRAWL(dev_priv) && dev_priv->display.cdclk.hw.vco > 0 &&
vco > 0 &&
+ !cdclk_pll_is_unknown(dev_priv->display.cdclk.hw.vco)) {
if (dev_priv->display.cdclk.hw.vco != vco)
adlp_cdclk_pll_crawl(dev_priv, vco);
} else if (DISPLAY_VER(dev_priv) >= 11)
--
2.25.1
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: drm/i915/tgl+: Enable DC power states on all eDP ports
== Series Details ==
Series: drm/i915: drm/i915/tgl+: Enable DC power states on all eDP ports
URL : https://patchwork.freedesktop.org/series/110862/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12377 -> Patchwork_110862v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110862v1/index.html
Participating hosts (39 -> 39)
--
Additional (1): fi-tgl-dsi
Missing(1): fi-bdw-samus
Known issues
Here are the changes found in Patchwork_110862v1 that come from known issues:
### IGT changes ###
Possible fixes
* igt@gem_exec_suspend@basic-s0@smem:
- {bat-rplp-1}: [DMESG-WARN][1] ([i915#2867]) -> [PASS][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12377/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110862v1/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@hangcheck:
- {fi-ehl-2}: [INCOMPLETE][3] ([i915#6106]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12377/fi-ehl-2/igt@i915_selftest@l...@hangcheck.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110862v1/fi-ehl-2/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@requests:
- {bat-rpls-1}: [INCOMPLETE][5] ([i915#4983]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12377/bat-rpls-1/igt@i915_selftest@l...@requests.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110862v1/bat-rpls-1/igt@i915_selftest@l...@requests.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
[fdo#110189]: https://bugs.freedesktop.org/show_bug.cgi?id=110189
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#2411]: https://gitlab.freedesktop.org/drm/intel/issues/2411
[i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
[i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
[i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
[i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354
[i915#6106]: https://gitlab.freedesktop.org/drm/intel/issues/6106
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#6434]: https://gitlab.freedesktop.org/drm/intel/issues/6434
[i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687
[i915#7125]: https://gitlab.freedesktop.org/drm/intel/issues/7125
[i915#7346]: https://gitlab.freedesktop.org/drm/intel/issues/7346
[i915#7456]: https://gitlab.freedesktop.org/drm/intel/issues/7456
Build changes
-
* Linux: CI_DRM_12377 -> Patchwork_110862v1
CI-20190529: 20190529
CI_DRM_12377: 0c63617617b6d93cb2472774ee34ee3fc1ff52d7 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7055: f37ce4d34c3220a2bd5492a2e9c2a7390288 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_110862v1: 0c63617617b6d93cb2472774ee34ee3fc1ff52d7 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
bea6f498193d drm/i915/mtl+: Don't enable the AUX_IO power for non-eDP port main
links
9b8ca3958200 drm/i915: Factor out function to get/put AUX_IO power for main link
a99ddab7 drm/i915: Add missing DC_OFF power domain->well mappings
a294c341236c drm/i915: Add missing AUX_IO_A power domain->well mappings
2db339c50b11 drm/i915/tgl+: Enable display DC power states on all eDP ports
50fff7d9ab0e drm/i915: Use the AUX_IO power domain only for eDP/PSR port
1f37fa2a0417 drm/i915: Move the POWER_DOMAIN_AUX_IO_A definition to its logical
place
e06d0fde860e drm/i915: Preallocate the debug power domain wakerefs array
1c4fe4e2f4a5 drm/i915: Fix warn in intel_display_power_*_domain() functions
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110862v1/index.html
Re: [Intel-gfx] [PATCH i-g-t v2 1/3] lib/igt_pm: Refactor get firmware_node fd
On Mon, Nov 14, 2022 at 06:08:41PM +0530, Anshuman Gupta wrote:
> Created igt_pm_open_pci_firmware_node() to refactor
> the retrieving the firmware_node fd code.
>
> igt_pm_open_pci_firmware_node() will be used by other
> firmware_node consumers.
>
> While doing that fixed the leaked fd as well.
>
> v2:
> - return false instead of igt_require on no firmware_node_fd. [Kamil]
> - use igt_assert() when failed to open 'real_power_state' on error
> other then ENONET.
>
> Signed-off-by: Anshuman Gupta
> ---
> lib/igt_pm.c | 36 +---
I believe we need a massive refactor in this lib... we have 2 different ways
of using stuff, plus that ugly global restore...
but anyway, this one here looks a good change regardless of the current mess
in the lib.
Reviewed-by: Rodrigo Vivi
> 1 file changed, 25 insertions(+), 11 deletions(-)
>
> diff --git a/lib/igt_pm.c b/lib/igt_pm.c
> index 1e6e9ed3f..4f0cfbdd1 100644
> --- a/lib/igt_pm.c
> +++ b/lib/igt_pm.c
> @@ -863,6 +863,20 @@ bool i915_output_is_lpsp_capable(int drm_fd,
> igt_output_t *output)
> return strstr(buf, "LPSP: capable");
> }
>
> +static int igt_pm_open_pci_firmware_node(struct pci_device *pci_dev)
> +{
> + char name[PATH_MAX];
> + int dir;
> +
> + snprintf(name, PATH_MAX,
> + "/sys/bus/pci/devices/%04x:%02x:%02x.%01x/firmware_node",
> + pci_dev->domain, pci_dev->bus, pci_dev->dev, pci_dev->func);
> +
> + dir = open(name, O_RDONLY);
> +
> + return dir;
> +}
> +
> /**
> * igt_pm_acpi_d3cold_supported:
> * @pci_dev: root port pci_dev.
> @@ -873,23 +887,23 @@ bool i915_output_is_lpsp_capable(int drm_fd,
> igt_output_t *output)
> */
> bool igt_pm_acpi_d3cold_supported(struct pci_device *pci_dev)
> {
> - char name[PATH_MAX];
> - int dir, fd;
> -
> - snprintf(name, PATH_MAX,
> - "/sys/bus/pci/devices/%04x:%02x:%02x.%01x/firmware_node",
> - pci_dev->domain, pci_dev->bus, pci_dev->dev, pci_dev->func);
> + int firmware_node_fd, fd;
>
> - dir = open(name, O_RDONLY);
> - igt_require(dir > 0);
> + firmware_node_fd = igt_pm_open_pci_firmware_node(pci_dev);
> + if (firmware_node_fd < 0)
> + return false;
>
> /* BIOS need to enable ACPI D3Cold Support.*/
> - fd = openat(dir, "real_power_state", O_RDONLY);
> - if (fd < 0 && errno == ENOENT)
> + fd = openat(firmware_node_fd, "real_power_state", O_RDONLY);
> + if (fd < 0 && errno == ENOENT) {
> + close(firmware_node_fd);
> return false;
> + }
>
> - igt_require(fd > 0);
> + igt_assert(errno > 0);
>
> + close(firmware_node_fd);
> + close(fd);
> return true;
> }
>
> --
> 2.25.1
>
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: drm/i915/tgl+: Enable DC power states on all eDP ports
== Series Details == Series: drm/i915: drm/i915/tgl+: Enable DC power states on all eDP ports URL : https://patchwork.freedesktop.org/series/110862/ 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] linux-next: manual merge of the drm-intel tree with Linus' tree
On Mon, Nov 14, 2022 at 01:02:46PM +0200, Jani Nikula wrote:
> On Mon, 14 Nov 2022, Hans de Goede wrote:
> > Hi,
> >
> > On 11/14/22 11:10, Jani Nikula wrote:
> >> On Mon, 14 Nov 2022, Hans de Goede wrote:
> >>> Hi,
> >>>
> >>> On 11/14/22 00:23, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the drm-intel tree got a conflict in:
>
> drivers/gpu/drm/i915/display/intel_backlight.c
>
> between commit:
>
> b1d36e73cc1c ("drm/i915: Don't register backlight when another
> backlight should be used (v2)")
>
> from Linus' tree and commit:
>
> 801543b2593b ("drm/i915: stop including i915_irq.h from i915_trace.h")
>
> from the drm-intel tree.
> >>>
> >>> This is weird, because the:
> >>>
> >>>b1d36e73cc1c ("drm/i915: Don't register backlight when another
> >>> backlight should be used (v2)")
> >>>
> >>> commit is in 6.1-rc1, so there can only be a conflict it 6.1-rc1 has not
> >>> been back-merged into drm-intel yet ?
> >>
> >> That's the reason it *is* a conflict, right?
> >
> > Right what I was trying to say is that I am surprised that 6.1-rc1 has not
> > been back-merged into drm-intel yet even though it has been released
> > 4 weeks ago.
>
> Right, -ENOCOFFEE at my end.
>
> > I thought it was more or less standard process to backmerge rc1 soon after
> > it is released ?
>
> The delay may be because v6.1-rc1 brought in more regressions for us
> than any other -rc1 in recent memory. Our CI's been suffering, and our
> folks have been spending a lot of time debugging, bisecting and
> reporting. (And before you ask, yes, we're going to be more proactive in
> reporting issues we find in linux-next.)
>
> That said, Rodrigo's been in charge of drm-intel-next this cycle, maybe
> it's time to backmerge drm-next?
yeap, I'm on it...
>
>
> BR,
> Jani.
>
> --
> Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v2 00/11] Connect VFIO to IOMMUFD
On Mon, Nov 14, 2022 at 10:21:50AM -0500, Matthew Rosato wrote: > On 11/14/22 9:59 AM, Jason Gunthorpe wrote: > > On Mon, Nov 14, 2022 at 09:55:21AM -0500, Matthew Rosato wrote: > AFAICT there is no equivalent means to specify > vfio_iommu_type1.dma_entry_limit when using iommufd; looks like > we'll just always get the default 65535. > >>> > >>> No, there is no arbitary limit on iommufd > >> > >> Yeah, that's what I suspected. But FWIW, userspace checks the > >> advertised limit via VFIO_IOMMU_GET_INFO / > >> VFIO_IOMMU_TYPE1_INFO_DMA_AVAIL, and this is still being advertised > >> as 65535 when using iommufd. I don't think there is a defined way > >> to return 'ignore this value'. > > > > Is something using this? Should we make it much bigger? > > Yes, s390 when doing lazy unmapping likes to use larger amounts of > concurrent DMA, so there can be cases where we want to raise this > limit. > > The initial value of 65535 is already pretty arbitrary (U16_MAX) -- It was choosen to match VFIO's default > If iommufd is doing its own management and this value becomes > deprecated in this scenario, and we can't set it to a magic value > that says 'ignore me' then maybe it just makes sense for now to set > it arbitrarily larger when using iommufd e.g. U32_MAX? Sure /* * iommufd's limit is based on the cgroup's memory limit. * Normally vfio would return U16_MAX here, and provide a module * parameter to adjust it. Since S390 qemu userspace actually * pays attention and needs a value bigger than U16_MAX return * U32_MAX. */ .avail = U32_MAX, Thanks, Jason
Re: [Intel-gfx] [PATCH] drm/i915: disable DMC idle states for Intel UHD Graphics 620
On Mon, Nov 14, 2022 at 01:11:23PM +0200, Jani Nikula wrote:
> On Fri, 11 Nov 2022, "Steven 'Steve' Kendall" wrote:
> > Some machines with Intel UHD Graphics 620 (8086:5917) such as Dell
> > Latitude 7490 are unable to wake from sleep. Disable DMC for
> > Intel UHD Graphics 620.
>
> Cc: some more folks
>
> The patch at hand seems like too heavy a hammer. But this needs
> attention.
yeap, it probably deserver a traditional quirk, including vendor ir,
instead of this change in the platform list.
>
> BR,
> Jani.
>
>
>
> >
> > Link: https://gitlab.freedesktop.org/drm/intel/-/issues/7339
> > Signed-off-by: Steven 'Steve' Kendall
> > ---
> > drivers/gpu/drm/i915/i915_pci.c | 14 ++
> > include/drm/i915_pciids.h | 6 +-
> > 2 files changed, 19 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_pci.c
> > b/drivers/gpu/drm/i915/i915_pci.c
> > index cd4487a1d3be..ea148be46b14 100644
> > --- a/drivers/gpu/drm/i915/i915_pci.c
> > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > @@ -697,6 +697,10 @@ static const struct intel_device_info skl_gt4_info = {
> > .gt = 4,
> > };
> >
> > +#define GEN9_DMCLESS_FEATURES \
> > + GEN9_FEATURES, \
> > + .__runtime.has_dmc = 0
> > +
> > #define GEN9_LP_FEATURES \
> > GEN(9), \
> > .is_lp = 1, \
> > @@ -753,6 +757,10 @@ static const struct intel_device_info glk_info = {
> > GEN9_FEATURES, \
> > PLATFORM(INTEL_KABYLAKE)
> >
> > +#define KBL_DMCLESS_PLATFORM \
> > + GEN9_DMCLESS_FEATURES, \
> > + PLATFORM(INTEL_KABYLAKE)
> > +
> > static const struct intel_device_info kbl_gt1_info = {
> > KBL_PLATFORM,
> > .gt = 1,
> > @@ -763,6 +771,11 @@ static const struct intel_device_info kbl_gt2_info = {
> > .gt = 2,
> > };
> >
> > +static const struct intel_device_info dmcless_kbl_gt2_info = {
> > + KBL_DMCLESS_PLATFORM,
> > + .gt = 2,
> > +};
> > +
> > static const struct intel_device_info kbl_gt3_info = {
> > KBL_PLATFORM,
> > .gt = 3,
> > @@ -1202,6 +1215,7 @@ static const struct pci_device_id pciidlist[] = {
> > INTEL_GLK_IDS(_info),
> > INTEL_KBL_GT1_IDS(_gt1_info),
> > INTEL_KBL_GT2_IDS(_gt2_info),
> > + DMCLESS_INTEL_KBL_GT2_IDS(_kbl_gt2_info),
> > INTEL_KBL_GT3_IDS(_gt3_info),
> > INTEL_KBL_GT4_IDS(_gt3_info),
> > INTEL_AML_KBL_GT2_IDS(_gt2_info),
> > diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
> > index 4a4c190f7698..93bea60772ff 100644
> > --- a/include/drm/i915_pciids.h
> > +++ b/include/drm/i915_pciids.h
> > @@ -420,11 +420,15 @@
> > INTEL_KBL_ULT_GT2_IDS(info), \
> > INTEL_KBL_ULX_GT2_IDS(info), \
> > INTEL_VGA_DEVICE(0x5912, info), /* DT GT2 */ \
> > - INTEL_VGA_DEVICE(0x5917, info), /* Mobile GT2 */ \
> > INTEL_VGA_DEVICE(0x591A, info), /* SRV GT2 */ \
> > INTEL_VGA_DEVICE(0x591B, info), /* Halo GT2 */ \
> > INTEL_VGA_DEVICE(0x591D, info) /* WKS GT2 */
> >
> > +#define DMCLESS_INTEL_KBL_GT2_IDS(info) \
> > + INTEL_KBL_ULT_GT2_IDS(info), \
> > + INTEL_KBL_ULX_GT2_IDS(info), \
> > + INTEL_VGA_DEVICE(0x5917, info) /* Mobile GT2 */
> > +
> > #define INTEL_KBL_ULT_GT3_IDS(info) \
> > INTEL_VGA_DEVICE(0x5926, info) /* ULT GT3 */
>
> --
> Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v2 2/4] usb: gadget: hid: Convert to use list_count()
On Mon, Nov 14, 2022 at 1:22 PM Andy Shevchenko wrote: > > The list API now provides the list_count() to help with counting > existing nodes in the list. Uilise it. s/Uilise/Utilise
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/edid/firmware: stop using a throwaway platform device
== Series Details ==
Series: drm/edid/firmware: stop using a throwaway platform device
URL : https://patchwork.freedesktop.org/series/110859/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12376 -> Patchwork_110859v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/index.html
Participating hosts (37 -> 38)
--
Additional (3): fi-kbl-soraka bat-kbl-2 fi-bsw-nick
Missing(2): fi-bdw-samus bat-dg1-5
Known issues
Here are the changes found in Patchwork_110859v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_gttfill@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][1] ([fdo#109271]) +8 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-kbl-soraka/igt@gem_exec_gttf...@basic.html
* 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_110859v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-apl-guc: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#4613]) +3
similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-apl-guc/igt@gem_lmem_swapp...@basic.html
- fi-kbl-soraka: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613]) +3
similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
* igt@gem_lmem_swapping@parallel-random-engines:
- fi-bsw-nick:NOTRUN -> [SKIP][5] ([fdo#109271]) +38 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-bsw-nick/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- bat-adlp-4: [PASS][6] -> [DMESG-WARN][7] ([i915#7077])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/bat-adlp-4/igt@i915_pm_...@basic-pci-d3-state.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/bat-adlp-4/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][8] ([i915#1886])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@mman:
- fi-rkl-guc: [PASS][9] -> [TIMEOUT][10] ([i915#6794])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/fi-rkl-guc/igt@i915_selftest@l...@mman.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-rkl-guc/igt@i915_selftest@l...@mman.html
- fi-kbl-soraka: NOTRUN -> [INCOMPLETE][11] ([i915#7320])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-kbl-soraka/igt@i915_selftest@l...@mman.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-rkl-11600: NOTRUN -> [SKIP][12] ([fdo#111827])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-rkl-11600/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_chamelium@hdmi-crc-fast:
- fi-apl-guc: NOTRUN -> [SKIP][13] ([fdo#109271] / [fdo#111827]) +8
similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-apl-guc/igt@kms_chamel...@hdmi-crc-fast.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-bsw-nick:NOTRUN -> [SKIP][14] ([fdo#109271] / [fdo#111827]) +8
similar issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-bsw-nick/igt@kms_chamel...@hdmi-hpd-fast.html
- fi-kbl-soraka: NOTRUN -> [SKIP][15] ([fdo#109271] / [fdo#111827]) +7
similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-kbl-soraka/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_force_connector_basic@force-connector-state:
- fi-apl-guc: NOTRUN -> [SKIP][16] ([fdo#109271]) +11 similar issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-apl-guc/igt@kms_force_connector_ba...@force-connector-state.html
Possible fixes
* igt@gem_render_tiled_blits@basic:
- fi-apl-guc: [INCOMPLETE][17] ([i915#7056]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/fi-apl-guc/igt@gem_render_tiled_bl...@basic.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-apl-guc/igt@gem_render_tiled_bl...@basic.html
* igt@i915_selftest@live@migrate:
- {bat-adlp-6}: [INCOMPLETE][19] ([i915#7348]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/bat-adlp-6/igt@i915_selftest@l...@migrate.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/bat-adlp-6/igt@i915_selftest@l...@migrate.html
* igt@i915_selftest@live@slpc:
- {bat-adln-1}:
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/edid/firmware: stop using a throwaway platform device
== Series Details == Series: drm/edid/firmware: stop using a throwaway platform device URL : https://patchwork.freedesktop.org/series/110859/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12376 -> Patchwork_110859v1 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_110859v1 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_110859v1, 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_110859v1/index.html Participating hosts (37 -> 38) -- Additional (3): fi-kbl-soraka bat-kbl-2 fi-bsw-nick Missing(2): fi-bdw-samus bat-dg1-5 Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_110859v1: ### IGT changes ### Possible regressions * igt@i915_selftest@live@mman: - fi-kbl-soraka: NOTRUN -> [INCOMPLETE][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-kbl-soraka/igt@i915_selftest@l...@mman.html Known issues Here are the changes found in Patchwork_110859v1 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_gttfill@basic: - fi-kbl-soraka: NOTRUN -> [SKIP][2] ([fdo#109271]) +8 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-kbl-soraka/igt@gem_exec_gttf...@basic.html * igt@gem_huc_copy@huc-copy: - fi-kbl-soraka: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - fi-apl-guc: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613]) +3 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-apl-guc/igt@gem_lmem_swapp...@basic.html - fi-kbl-soraka: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#4613]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html * igt@gem_lmem_swapping@parallel-random-engines: - fi-bsw-nick:NOTRUN -> [SKIP][6] ([fdo#109271]) +38 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-bsw-nick/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@i915_pm_rpm@basic-pci-d3-state: - bat-adlp-4: [PASS][7] -> [DMESG-WARN][8] ([i915#7077]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/bat-adlp-4/igt@i915_pm_...@basic-pci-d3-state.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/bat-adlp-4/igt@i915_pm_...@basic-pci-d3-state.html * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][9] ([i915#1886]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@i915_selftest@live@mman: - fi-rkl-guc: [PASS][10] -> [TIMEOUT][11] ([i915#6794]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/fi-rkl-guc/igt@i915_selftest@l...@mman.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-rkl-guc/igt@i915_selftest@l...@mman.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-rkl-11600: NOTRUN -> [SKIP][12] ([fdo#111827]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-rkl-11600/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_chamelium@hdmi-crc-fast: - fi-apl-guc: NOTRUN -> [SKIP][13] ([fdo#109271] / [fdo#111827]) +8 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-apl-guc/igt@kms_chamel...@hdmi-crc-fast.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-bsw-nick:NOTRUN -> [SKIP][14] ([fdo#109271] / [fdo#111827]) +8 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-bsw-nick/igt@kms_chamel...@hdmi-hpd-fast.html - fi-kbl-soraka: NOTRUN -> [SKIP][15] ([fdo#109271] / [fdo#111827]) +7 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-kbl-soraka/igt@kms_chamel...@hdmi-hpd-fast.html * igt@kms_force_connector_basic@force-connector-state: - fi-apl-guc: NOTRUN -> [SKIP][16] ([fdo#109271]) +11 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-apl-guc/igt@kms_force_connector_ba...@force-connector-state.html Possible fixes * igt@gem_render_tiled_blits@basic: - fi-apl-guc: [INCOMPLETE][17] ([i915#7056]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/fi-apl-guc/igt@gem_render_tiled_bl...@basic.html [18]:
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/edid/firmware: stop using a throwaway platform device
Issue si related to https://gitlab.freedesktop.org/drm/intel/-/issues/6794.
Re-reported.
Lakshmi.
-Original Message-
From: Nikula, Jani
Sent: Monday, November 14, 2022 5:33 PM
To: Patchwork ; Vudum, Lakshminarayana
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: ✗ Fi.CI.BAT: failure for drm/edid/firmware: stop using a throwaway
platform device
On Mon, 14 Nov 2022, Patchwork wrote:
> == Series Details ==
>
> Series: drm/edid/firmware: stop using a throwaway platform device
> URL : https://patchwork.freedesktop.org/series/110859/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_12376 -> Patchwork_110859v1
>
>
> Summary
> ---
>
> **FAILURE**
>
> Serious unknown changes coming with Patchwork_110859v1 absolutely need to be
> verified manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_110859v1, 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_110859v1/index.html
>
> Participating hosts (37 -> 37)
> --
>
> Additional (2): bat-kbl-2 fi-bsw-nick
> Missing(2): fi-bdw-samus bat-dg1-5
>
> Possible new issues
> ---
>
> Here are the unknown changes that may have been introduced in
> Patchwork_110859v1:
>
> ### IGT changes ###
>
> Possible regressions
>
> * igt@i915_selftest@live@mman:
> - fi-rkl-guc: [PASS][1] -> [TIMEOUT][2]
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/fi-rkl-guc/igt@i915_selftest@l...@mman.html
>[2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-rkl-guc
> /igt@i915_selftest@l...@mman.html
Completely unrelated.
BR,
Jani.
>
>
> Known issues
>
>
> Here are the changes found in Patchwork_110859v1 that come from known
> issues:
>
> ### IGT changes ###
>
> Issues hit
>
> * igt@gem_lmem_swapping@basic:
> - fi-apl-guc: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#4613]) +3
> similar issues
>[3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-apl-guc
> /igt@gem_lmem_swapp...@basic.html
>
> * igt@gem_lmem_swapping@parallel-random-engines:
> - fi-bsw-nick:NOTRUN -> [SKIP][4] ([fdo#109271]) +38 similar
> issues
>[4]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-bsw-nic
> k/igt@gem_lmem_swapp...@parallel-random-engines.html
>
> * igt@i915_pm_rpm@basic-pci-d3-state:
> - bat-adlp-4: [PASS][5] -> [DMESG-WARN][6] ([i915#7077])
>[5]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/bat-adlp-4/igt@i915_pm_...@basic-pci-d3-state.html
>[6]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/bat-adlp-4
> /igt@i915_pm_...@basic-pci-d3-state.html
>
> * igt@kms_chamelium@common-hpd-after-suspend:
> - fi-rkl-11600: NOTRUN -> [SKIP][7] ([fdo#111827])
>[7]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-rkl-116
> 00/igt@kms_chamel...@common-hpd-after-suspend.html
>
> * igt@kms_chamelium@hdmi-crc-fast:
> - fi-apl-guc: NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827])
> +8 similar issues
>[8]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-apl-guc
> /igt@kms_chamel...@hdmi-crc-fast.html
>
> * igt@kms_chamelium@hdmi-hpd-fast:
> - fi-bsw-nick:NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827])
> +8 similar issues
>[9]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-bsw-nic
> k/igt@kms_chamel...@hdmi-hpd-fast.html
>
> * igt@kms_force_connector_basic@force-connector-state:
> - fi-apl-guc: NOTRUN -> [SKIP][10] ([fdo#109271]) +11 similar
> issues
>[10]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-apl-guc
> /igt@kms_force_connector_ba...@force-connector-state.html
>
>
> Possible fixes
>
> * igt@gem_render_tiled_blits@basic:
> - fi-apl-guc: [INCOMPLETE][11] ([i915#7056]) -> [PASS][12]
>[11]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/fi-apl-guc/igt@gem_render_tiled_bl...@basic.html
>[12]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-apl-guc
> /igt@gem_render_tiled_bl...@basic.html
>
> * igt@i915_selftest@live@migrate:
> - {bat-adlp-6}: [INCOMPLETE][13] ([i915#7348]) -> [PASS][14]
>[13]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/bat-adlp-6/igt@i915_selftest@l...@migrate.html
>[14]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/bat-adlp-6
> /igt@i915_selftest@l...@migrate.html
>
> * igt@i915_selftest@live@slpc:
> - {bat-adln-1}: [DMESG-FAIL][15] ([i915#6997]) -> [PASS][16]
>[15]:
>
Re: [Intel-gfx] [PATCH v2 1/4] i915: Move list_count() to list.h for broader use
On Mon, Nov 14, 2022 at 06:11:51PM +, Ruhl, Michael J wrote: ... > So all of the non-list_for_each code appears to be an inline. This is not true. > This which, resembles the non-list_for_each pattern is a macro? > > Just curious as to why the macro rather than inline? See above. However, I'm fine with the inline. -- With Best Regards, Andy Shevchenko
Re: [Intel-gfx] [PATCH v2 1/4] i915: Move list_count() to list.h for broader use
>-Original Message-
>From: dri-devel On Behalf Of
>Andy Shevchenko
>Sent: Monday, November 14, 2022 11:22 AM
>To: Jakob Koschel ; Andy Shevchenko
>; Greg Kroah-Hartman
>; Mathias Nyman
>; intel-gfx@lists.freedesktop.org; dri-
>de...@lists.freedesktop.org; linux-ker...@vger.kernel.org; linux-
>u...@vger.kernel.org
>Cc: Tvrtko Ursulin ; Kevin Cernekee
>; Nyman, Mathias ; Vivi,
>Rodrigo ; Andrew Morton foundation.org>
>Subject: [PATCH v2 1/4] i915: Move list_count() to list.h for broader use
>
>Some of the existing users, and definitely will be new ones, want to
>count existing nodes in the list. Provide a generic API for that by
>moving code from i915 to list.h.
>
>Signed-off-by: Andy Shevchenko
>---
>v2: dropped the duplicate code in i915 (LKP)
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 13 +
> include/linux/list.h | 13 +
> 2 files changed, 14 insertions(+), 12 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
>b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
>index 6ae8b07cfaa1..b5d474be564d 100644
>--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
>+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
>@@ -2085,17 +2085,6 @@ static void print_request_ring(struct drm_printer
>*m, struct i915_request *rq)
> }
> }
>
>-static unsigned long list_count(struct list_head *list)
>-{
>- struct list_head *pos;
>- unsigned long count = 0;
>-
>- list_for_each(pos, list)
>- count++;
>-
>- return count;
>-}
>-
> static unsigned long read_ul(void *p, size_t x)
> {
> return *(unsigned long *)(p + x);
>@@ -2270,7 +2259,7 @@ void intel_engine_dump(struct intel_engine_cs
>*engine,
> spin_lock_irqsave(>sched_engine->lock, flags);
> engine_dump_active_requests(engine, m);
>
>- drm_printf(m, "\tOn hold?: %lu\n",
>+ drm_printf(m, "\tOn hold?: %zu\n",
> list_count(>sched_engine->hold));
> spin_unlock_irqrestore(>sched_engine->lock, flags);
>
>diff --git a/include/linux/list.h b/include/linux/list.h
>index 61762054b4be..098eccf8c1b6 100644
>--- a/include/linux/list.h
>+++ b/include/linux/list.h
>@@ -655,6 +655,19 @@ static inline void list_splice_tail_init(struct list_head
>*list,
>!list_is_head(pos, (head)); \
>pos = n, n = pos->prev)
>
>+/**
>+ * list_count - count nodes in the list
>+ * @head: the head for your list.
>+ */
>+#define list_count(head) \
>+({\
>+ struct list_head *__tmp;\
>+ size_t __i = 0; \
>+ list_for_each(__tmp, head) \
>+ __i++; \
>+ __i;\
>+})
So all of the non-list_for_each code appears to be an inline.
This which, resembles the non-list_for_each pattern is a macro?
Just curious as to why the macro rather than inline?
Mike
+
> /**
> * list_entry_is_head - test if the entry points to the head of the list
> * @pos: the type * to cursor
>--
>2.35.1
Re: [Intel-gfx] [PATCH v9 01/25] docs/fb: Document current named modes
Den 14.11.2022 14.00, skrev Maxime Ripard: > KMS supports a number of named modes already, but it's never been > documented anywhere, let's fix that. > > Signed-off-by: Maxime Ripard > > --- Reviewed-by: Noralf Trønnes
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/pps: improve eDP power on flow. (rev4)
== Series Details ==
Series: drm/i915/pps: improve eDP power on flow. (rev4)
URL : https://patchwork.freedesktop.org/series/110038/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12375_full -> Patchwork_110038v4_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_110038v4_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_110038v4_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (10 -> 11)
--
Additional (1): pig-skl-6260u
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_110038v4_full:
### IGT changes ###
Possible regressions
* igt@device_reset@unbind-reset-rebind:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-tglb3/igt@device_re...@unbind-reset-rebind.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110038v4/shard-tglb6/igt@device_re...@unbind-reset-rebind.html
* igt@kms_fbcon_fbt@psr-suspend:
- shard-skl: [PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-skl6/igt@kms_fbcon_...@psr-suspend.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110038v4/shard-skl7/igt@kms_fbcon_...@psr-suspend.html
Warnings
* igt@kms_color@ctm-0-75@pipe-b-edp-1:
- shard-tglb: [FAIL][5] ([i915#315] / [i915#6946]) ->
[INCOMPLETE][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-tglb5/igt@kms_color@ctm-0...@pipe-b-edp-1.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110038v4/shard-tglb8/igt@kms_color@ctm-0...@pipe-b-edp-1.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_eio@in-flight-contexts-1us:
- {shard-rkl}:[PASS][7] -> [INCOMPLETE][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-rkl-2/igt@gem_...@in-flight-contexts-1us.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110038v4/shard-rkl-3/igt@gem_...@in-flight-contexts-1us.html
* igt@gem_exec_whisper@basic-fds-priority:
- {shard-rkl}:NOTRUN -> [INCOMPLETE][9]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110038v4/shard-rkl-5/igt@gem_exec_whis...@basic-fds-priority.html
Known issues
Here are the changes found in Patchwork_110038v4_full that come from known
issues:
### CI changes ###
Issues hit
* boot:
- shard-glk: ([PASS][10], [PASS][11], [PASS][12], [PASS][13],
[PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19],
[PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25],
[PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30], [PASS][31],
[PASS][32], [PASS][33], [PASS][34]) -> ([PASS][35], [PASS][36], [PASS][37],
[PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43],
[FAIL][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49],
[PASS][50], [PASS][51], [PASS][52], [PASS][53], [PASS][54], [PASS][55],
[PASS][56], [PASS][57], [PASS][58], [PASS][59]) ([i915#4392])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-glk5/boot.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-glk6/boot.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-glk6/boot.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-glk6/boot.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-glk7/boot.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-glk7/boot.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-glk7/boot.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-glk8/boot.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-glk8/boot.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-glk8/boot.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-glk9/boot.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-glk9/boot.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-glk9/boot.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-glk9/boot.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-glk5/boot.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-glk5/boot.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-glk3/boot.html
[27]:
[Intel-gfx] [PATCH v2 3/4] usb: gadget: udc: bcm63xx: Convert to use list_count()
The list API now provides the list_count() to help with counting
existing nodes in the list. Uilise it.
Signed-off-by: Andy Shevchenko
---
v2: no change
drivers/usb/gadget/udc/bcm63xx_udc.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/gadget/udc/bcm63xx_udc.c
b/drivers/usb/gadget/udc/bcm63xx_udc.c
index 2cdb07905bde..0762e49e85f8 100644
--- a/drivers/usb/gadget/udc/bcm63xx_udc.c
+++ b/drivers/usb/gadget/udc/bcm63xx_udc.c
@@ -2172,7 +2172,6 @@ static int bcm63xx_iudma_dbg_show(struct seq_file *s,
void *p)
for (ch_idx = 0; ch_idx < BCM63XX_NUM_IUDMA; ch_idx++) {
struct iudma_ch *iudma = >iudma[ch_idx];
- struct list_head *pos;
seq_printf(s, "IUDMA channel %d -- ", ch_idx);
switch (iudma_defaults[ch_idx].ep_type) {
@@ -2205,14 +2204,10 @@ static int bcm63xx_iudma_dbg_show(struct seq_file *s,
void *p)
seq_printf(s, " desc: %d/%d used", iudma->n_bds_used,
iudma->n_bds);
- if (iudma->bep) {
- i = 0;
- list_for_each(pos, >bep->queue)
- i++;
- seq_printf(s, "; %d queued\n", i);
- } else {
+ if (iudma->bep)
+ seq_printf(s, "; %zu queued\n",
list_count(>bep->queue));
+ else
seq_printf(s, "\n");
- }
for (i = 0; i < iudma->n_bds; i++) {
struct bcm_enet_desc *d = >bd_ring[i];
--
2.35.1
[Intel-gfx] [PATCH v2 4/4] xhci: Convert to use list_count()
The list API now provides the list_count() to help with counting
existing nodes in the list. Uilise it.
Signed-off-by: Andy Shevchenko
---
v2: no change
drivers/usb/host/xhci-ring.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index ad81e9a508b1..817c31e3b0c8 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -2532,7 +2532,6 @@ static int handle_tx_event(struct xhci_hcd *xhci,
union xhci_trb *ep_trb;
int status = -EINPROGRESS;
struct xhci_ep_ctx *ep_ctx;
- struct list_head *tmp;
u32 trb_comp_code;
int td_num = 0;
bool handling_skipped_tds = false;
@@ -2580,10 +2579,8 @@ static int handle_tx_event(struct xhci_hcd *xhci,
}
/* Count current td numbers if ep->skip is set */
- if (ep->skip) {
- list_for_each(tmp, _ring->td_list)
- td_num++;
- }
+ if (ep->skip)
+ td_num += list_count(_ring->td_list);
/* Look for common error cases */
switch (trb_comp_code) {
--
2.35.1
[Intel-gfx] [PATCH v2 1/4] i915: Move list_count() to list.h for broader use
Some of the existing users, and definitely will be new ones, want to
count existing nodes in the list. Provide a generic API for that by
moving code from i915 to list.h.
Signed-off-by: Andy Shevchenko
---
v2: dropped the duplicate code in i915 (LKP)
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 13 +
include/linux/list.h | 13 +
2 files changed, 14 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 6ae8b07cfaa1..b5d474be564d 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -2085,17 +2085,6 @@ static void print_request_ring(struct drm_printer *m,
struct i915_request *rq)
}
}
-static unsigned long list_count(struct list_head *list)
-{
- struct list_head *pos;
- unsigned long count = 0;
-
- list_for_each(pos, list)
- count++;
-
- return count;
-}
-
static unsigned long read_ul(void *p, size_t x)
{
return *(unsigned long *)(p + x);
@@ -2270,7 +2259,7 @@ void intel_engine_dump(struct intel_engine_cs *engine,
spin_lock_irqsave(>sched_engine->lock, flags);
engine_dump_active_requests(engine, m);
- drm_printf(m, "\tOn hold?: %lu\n",
+ drm_printf(m, "\tOn hold?: %zu\n",
list_count(>sched_engine->hold));
spin_unlock_irqrestore(>sched_engine->lock, flags);
diff --git a/include/linux/list.h b/include/linux/list.h
index 61762054b4be..098eccf8c1b6 100644
--- a/include/linux/list.h
+++ b/include/linux/list.h
@@ -655,6 +655,19 @@ static inline void list_splice_tail_init(struct list_head
*list,
!list_is_head(pos, (head)); \
pos = n, n = pos->prev)
+/**
+ * list_count - count nodes in the list
+ * @head: the head for your list.
+ */
+#define list_count(head) \
+({ \
+ struct list_head *__tmp;\
+ size_t __i = 0; \
+ list_for_each(__tmp, head) \
+ __i++; \
+ __i;\
+})
+
/**
* list_entry_is_head - test if the entry points to the head of the list
* @pos: the type * to cursor
--
2.35.1
[Intel-gfx] [PATCH v2 2/4] usb: gadget: hid: Convert to use list_count()
The list API now provides the list_count() to help with counting
existing nodes in the list. Uilise it.
Signed-off-by: Andy Shevchenko
---
v2: no change
drivers/usb/gadget/legacy/hid.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/gadget/legacy/hid.c b/drivers/usb/gadget/legacy/hid.c
index 1187ee4f316a..6196c3456e0b 100644
--- a/drivers/usb/gadget/legacy/hid.c
+++ b/drivers/usb/gadget/legacy/hid.c
@@ -133,14 +133,11 @@ static struct usb_configuration config_driver = {
static int hid_bind(struct usb_composite_dev *cdev)
{
struct usb_gadget *gadget = cdev->gadget;
- struct list_head *tmp;
struct hidg_func_node *n = NULL, *m, *iter_n;
struct f_hid_opts *hid_opts;
- int status, funcs = 0;
-
- list_for_each(tmp, _func_list)
- funcs++;
+ int status, funcs;
+ funcs = list_count(_func_list);
if (!funcs)
return -ENODEV;
--
2.35.1
Re: [Intel-gfx] [PATCH] drm/i915/display: Add missing checks for cdclk crawling
> -Original Message-
> From: Ville Syrjälä
> Sent: Friday, November 11, 2022 11:40 AM
> To: Srivatsa, Anusha
> Cc: intel-gfx@lists.freedesktop.org; Roper, Matthew D
>
> Subject: Re: [PATCH] drm/i915/display: Add missing checks for cdclk crawling
>
> On Fri, Nov 11, 2022 at 11:26:02AM -0800, Anusha Srivatsa wrote:
> > cdclk_sanitize() function was written assuming vco was a signed integer.
> > vco gets assigned to -1 (essentially ~0) for the case where PLL might
> > be enabled and vco is not a frequency that will ever get used. In such
> > a scenario the right thing to do is disable the PLL and re-enable it
> > again with a valid frequency.
> > However the vco is declared as a unsigned variable.
> > With the above assumption, driver takes crawl path when not needed.
> > Add explicit check to not crawl in the case of an invalid PLL.
> >
> > v2: Move the check from .h to .c (MattR)
> > - Move check to bxt_set_cdclk() instead of
> > intel_modeset_calc_cdclk() which is directly in the path of the
> > sanitize() function (Ville)
> >
> > Cc: Ville Syrjälä
> > Cc: Matt Roper
> > Suggested-by: Ville Syrjälä
> > Signed-off-by: Anusha Srivatsa
> > ---
> > drivers/gpu/drm/i915/display/intel_cdclk.c | 13 -
> > 1 file changed, 12 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > index 8a9031012d74..2d9b7ba58358 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > @@ -1716,6 +1716,16 @@ static void dg2_cdclk_squash_program(struct
> drm_i915_private *i915,
> > intel_de_write(i915, CDCLK_SQUASH_CTL, squash_ctl); }
> >
> > +static bool cdclk_pll_is_unknown(unsigned int vco) {
> > + /*
> > +* Ensure driver does not take the crawl path for the
> > +* case when the vco is set to ~0 in the
> > +* sanitize path.
> > +*/
> > + return (vco == ~0);
>
> Pointless parens.
>
> > +}
> > +
> > static void bxt_set_cdclk(struct drm_i915_private *dev_priv,
> > const struct intel_cdclk_config *cdclk_config,
> > enum pipe pipe)
> > @@ -1748,7 +1758,8 @@ static void bxt_set_cdclk(struct drm_i915_private
> *dev_priv,
> > return;
> > }
> >
> > - if (HAS_CDCLK_CRAWL(dev_priv) && dev_priv->display.cdclk.hw.vco
> > 0 && vco > 0) {
> > + if (HAS_CDCLK_CRAWL(dev_priv) && dev_priv->display.cdclk.hw.vco
> > 0 && vco > 0 &&
> > + (!cdclk_pll_is_unknown(dev_priv->display.cdclk.hw.vco))) {
>
> More pointless parens
>
> With those removed
> Reviewed-by: Ville Syrjälä
Thanks Ville.
> Though I think we should probably add the pll_is_enabled() helper too, just
> make the code a bit more self explanatory.
At this point the current code should atleast not block the MTL cdclk churn
series. But the suggested helper will make the code more explanatory and I can
take it up.
Thanks for the feedback!
Anusha
> > if (dev_priv->display.cdclk.hw.vco != vco)
> > adlp_cdclk_pll_crawl(dev_priv, vco);
> > } else if (DISPLAY_VER(dev_priv) >= 11)
> > --
> > 2.25.1
>
> --
> Ville Syrjälä
> Intel
[Intel-gfx] [PATCH v3 19/20] drm/i915: Add 10bit gamma mode for gen2/3
From: Ville Syrjälä
Some gen2/gen3 parts have a 10bit gamma mode, on some pipes.
Expose it.
The format is different to the later i965+ style in that we
store a 10bit value and a 6 bit floating point slope for each
entry. Ie. the hardware extrapolates the intermediate steps
from the current LUT entry, instead of interpolating between
the current and next LUT entries. This also means we don't store
the last LUT entry in any register as it is defined by the previous
LUT entry's value+slope.
The slope has limited precision though (2 bit exponent + 4 bit
mantissa), so we'd have to allow for more error in the state checker
for the last entry and we have to make sure userspace doesn't
pass in something where the slope is simply to steep. In theory
we should perhaps check the slope for every interval, but we don't
do that for any other interpolated gamma mode and I suspect they
may also have some internal limit on the slope. I haven't confirmed
that theory though. Anyways, for ease of implementation we shall
just ignore the last entry in the state checker. If all the other
entries match anyway then that seems like a good indication that
the hardware was programmed as expected.
v2: Redo the state checker logic a bit
Rebase due to other changes
v3: Fix C8 readout
Acked-by: Uma Shankar
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 268 +++--
drivers/gpu/drm/i915/i915_pci.c| 10 +-
drivers/gpu/drm/i915/i915_reg.h| 14 ++
3 files changed, 271 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index dee0382015a5..52f3d548da02 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -467,6 +467,79 @@ static void i9xx_lut_8_pack(struct drm_color_lut *entry,
u32 val)
entry->blue = intel_color_lut_pack(REG_FIELD_GET(PALETTE_BLUE_MASK,
val), 8);
}
+/* i8xx/i9xx+ 10bit slope format "even DW" (low 8 bits) */
+static u32 _i9xx_lut_10_ldw(u16 a)
+{
+ return drm_color_lut_extract(a, 10) & 0xff;
+}
+
+static u32 i9xx_lut_10_ldw(const struct drm_color_lut *color)
+{
+ return _i9xx_lut_10_ldw(color[0].red) << 16 |
+ _i9xx_lut_10_ldw(color[0].green) << 8 |
+ _i9xx_lut_10_ldw(color[0].blue);
+}
+
+/* i8xx/i9xx+ 10bit slope format "odd DW" (high 2 bits + slope) */
+static u32 _i9xx_lut_10_udw(u16 a, u16 b)
+{
+ unsigned int mantissa, exponent;
+
+ a = drm_color_lut_extract(a, 10);
+ b = drm_color_lut_extract(b, 10);
+
+ /* b = a + 8 * m * 2 ^ -e */
+ mantissa = clamp(b - a, 0, 0x7f);
+ exponent = 3;
+ while (mantissa > 0xf) {
+ mantissa >>= 1;
+ exponent--;
+ }
+
+ return (exponent << 6) |
+ (mantissa << 2) |
+ (a >> 8);
+}
+
+static u32 i9xx_lut_10_udw(const struct drm_color_lut *color)
+{
+ return _i9xx_lut_10_udw(color[0].red, color[1].red) << 16 |
+ _i9xx_lut_10_udw(color[0].green, color[1].green) << 8 |
+ _i9xx_lut_10_udw(color[0].blue, color[1].blue);
+}
+
+static void i9xx_lut_10_pack(struct drm_color_lut *color,
+u32 ldw, u32 udw)
+{
+ u16 red = REG_FIELD_GET(PALETTE_10BIT_RED_LDW_MASK, ldw) |
+ REG_FIELD_GET(PALETTE_10BIT_RED_UDW_MASK, udw) << 8;
+ u16 green = REG_FIELD_GET(PALETTE_10BIT_GREEN_LDW_MASK, ldw) |
+ REG_FIELD_GET(PALETTE_10BIT_GREEN_UDW_MASK, udw) << 8;
+ u16 blue = REG_FIELD_GET(PALETTE_10BIT_BLUE_LDW_MASK, ldw) |
+ REG_FIELD_GET(PALETTE_10BIT_BLUE_UDW_MASK, udw) << 8;
+
+ color->red = intel_color_lut_pack(red, 10);
+ color->green = intel_color_lut_pack(green, 10);
+ color->blue = intel_color_lut_pack(blue, 10);
+}
+
+static void i9xx_lut_10_pack_slope(struct drm_color_lut *color,
+ u32 ldw, u32 udw)
+{
+ int r_exp = REG_FIELD_GET(PALETTE_10BIT_RED_EXP_MASK, udw);
+ int r_mant = REG_FIELD_GET(PALETTE_10BIT_RED_MANT_MASK, udw);
+ int g_exp = REG_FIELD_GET(PALETTE_10BIT_GREEN_EXP_MASK, udw);
+ int g_mant = REG_FIELD_GET(PALETTE_10BIT_GREEN_MANT_MASK, udw);
+ int b_exp = REG_FIELD_GET(PALETTE_10BIT_BLUE_EXP_MASK, udw);
+ int b_mant = REG_FIELD_GET(PALETTE_10BIT_BLUE_MANT_MASK, udw);
+
+ i9xx_lut_10_pack(color, ldw, udw);
+
+ color->red += r_mant << (3 - r_exp);
+ color->green += g_mant << (3 - g_exp);
+ color->blue += b_mant << (3 - b_exp);
+}
+
/* i965+ "10.6" bit interpolated format "even DW" (low 8 bits) */
static u32 i965_lut_10p6_ldw(const struct drm_color_lut *color)
{
@@ -691,12 +764,38 @@ static void i9xx_load_lut_8(struct intel_crtc *crtc,
i9xx_lut_8([i]));
}
+static void i9xx_load_lut_10(struct intel_crtc *crtc,
+const struct
[Intel-gfx] [PATCH v3 18/20] drm/i915: Use gamma LUT for RGB limited range compression
From: Ville Syrjälä
On ilk+ and glk class hardware we current make a mess of
things when we have to both generate limited range output
and use the hw gamma LUT. Since we do the range compression
using the pipe CSC unit (which is situated before the gamma
LUT in the pipe) we are in fact applying the gamma to the
limited range data instead of the full range data as the
user intended.
We can work around this by applying the range compression
via the gamma LUT instead of using the pipe CSC for it.
Fairly easy to do now that we have the internal post_csc_lut
attachment point where we can stick our new cooked LUT.
On ilk+ this only needs to be dome when using the split
gamma mode or when the ctm is enabled since otherwise we can
simply reorder the LUT vs. CSC. On glk we need to do this any
time a gamma LUT is used since no reordering is possible.
We do lose a bit of coverage in intel_color_assert_luts(),
but so be it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 133 +
1 file changed, 111 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index c336524d9225..dee0382015a5 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -249,17 +249,44 @@ static void icl_update_output_csc(struct intel_crtc *crtc,
intel_de_write_fw(i915, PIPE_CSC_OUTPUT_POSTOFF_LO(pipe), postoff[2]);
}
+static bool ilk_limited_range(const struct intel_crtc_state *crtc_state)
+{
+ struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
+
+ /* icl+ have dedicated output CSC */
+ if (DISPLAY_VER(i915) >= 11)
+ return false;
+
+ /* pre-hsw have PIPECONF_COLOR_RANGE_SELECT */
+ if (DISPLAY_VER(i915) < 7 || IS_IVYBRIDGE(i915))
+ return false;
+
+ return crtc_state->limited_color_range;
+}
+
+static bool ilk_lut_limited_range(const struct intel_crtc_state *crtc_state)
+{
+ struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
+
+ if (!ilk_limited_range(crtc_state))
+ return false;
+
+ if (crtc_state->c8_planes)
+ return false;
+
+ if (DISPLAY_VER(i915) == 10)
+ return crtc_state->hw.gamma_lut;
+ else
+ return crtc_state->hw.gamma_lut &&
+ (crtc_state->hw.degamma_lut || crtc_state->hw.ctm);
+}
+
static bool ilk_csc_limited_range(const struct intel_crtc_state *crtc_state)
{
- struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
+ if (!ilk_limited_range(crtc_state))
+ return false;
- /*
-* FIXME if there's a gamma LUT after the CSC, we should
-* do the range compression using the gamma LUT instead.
-*/
- return crtc_state->limited_color_range &&
- (IS_HASWELL(i915) || IS_BROADWELL(i915) ||
-IS_DISPLAY_VER(i915, 9, 10));
+ return !ilk_lut_limited_range(crtc_state);
}
static void ilk_csc_convert_ctm(const struct intel_crtc_state *crtc_state,
@@ -603,9 +630,18 @@ create_linear_lut(struct drm_i915_private *i915, int
lut_size)
return blob;
}
+static u16 lut_limited_range(unsigned int value)
+{
+ unsigned int min = 16 << 8;
+ unsigned int max = 235 << 8;
+
+ return value * (max - min) / 0x + min;
+}
+
static struct drm_property_blob *
create_resized_lut(struct drm_i915_private *i915,
- const struct drm_property_blob *blob_in, int lut_out_size)
+ const struct drm_property_blob *blob_in, int lut_out_size,
+ bool limited_color_range)
{
int i, lut_in_size = drm_color_lut_size(blob_in);
struct drm_property_blob *blob_out;
@@ -621,8 +657,18 @@ create_resized_lut(struct drm_i915_private *i915,
lut_in = blob_in->data;
lut_out = blob_out->data;
- for (i = 0; i < lut_out_size; i++)
- lut_out[i] = lut_in[i * (lut_in_size - 1) / (lut_out_size - 1)];
+ for (i = 0; i < lut_out_size; i++) {
+ const struct drm_color_lut *entry =
+ _in[i * (lut_in_size - 1) / (lut_out_size - 1)];
+
+ if (limited_color_range) {
+ lut_out[i].red = lut_limited_range(entry->red);
+ lut_out[i].green = lut_limited_range(entry->green);
+ lut_out[i].blue = lut_limited_range(entry->blue);
+ } else {
+ lut_out[i] = *entry;
+ }
+ }
return blob_out;
}
@@ -1423,6 +1469,7 @@ void intel_color_assert_luts(const struct
intel_crtc_state *crtc_state)
crtc_state->pre_csc_lut !=
crtc_state->hw.degamma_lut &&
crtc_state->pre_csc_lut !=
i915->display.color.glk_linear_degamma_lut);
[Intel-gfx] [PATCH v3 16/20] drm/i915: Rework legacy LUT handling
From: Ville Syrjälä
Currently crtc_state_is_legacy_gamma() has a very specific set
of conditions, not all of which are actually necessary. Also
Also when we detect those conditions check_luts() just skips
all the checks. That will no longer work for glk soon when we'll
start to use the hw degamma LUT in place of the hw gamma LUT
for YCbCr output. So let's rework the logic to only really consider
whether the user provided gamma_lut is one that matches the hw
legacy LUT capabilities or not.
We'll need to reject C8+degamma on ivb+ since the presence of
degamma_lut would either mean we have to really use the LUT
for degamma as opposed to C8 palette, or we have to enable
split gamma mode which also can't work as the C8 palette.
Otherwise this will now cause the legacy LUT to go through the
regular lut checks as well. As a side effect we also start to
allow the use of the legacy LUT with CTM, but that is perfectly
fine as far a the hardware is concerned.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 82 +++---
1 file changed, 55 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index e2bcfbffb298..8bb8983b490c 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -154,15 +154,7 @@ static const u16 ilk_csc_postoff_rgb_to_ycbcr[3] = {
static bool lut_is_legacy(const struct drm_property_blob *lut)
{
- return drm_color_lut_size(lut) == LEGACY_LUT_LENGTH;
-}
-
-static bool crtc_state_is_legacy_gamma(const struct intel_crtc_state
*crtc_state)
-{
- return !crtc_state->hw.degamma_lut &&
- !crtc_state->hw.ctm &&
- crtc_state->hw.gamma_lut &&
- lut_is_legacy(crtc_state->hw.gamma_lut);
+ return lut && drm_color_lut_size(lut) == LEGACY_LUT_LENGTH;
}
/*
@@ -1317,6 +1309,42 @@ intel_color_add_affected_planes(struct intel_crtc_state
*new_crtc_state)
return 0;
}
+static u32 intel_gamma_lut_tests(const struct intel_crtc_state *crtc_state)
+{
+ struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
+ const struct drm_property_blob *gamma_lut = crtc_state->hw.gamma_lut;
+
+ if (lut_is_legacy(gamma_lut))
+ return 0;
+
+ return INTEL_INFO(i915)->display.color.gamma_lut_tests;
+}
+
+static u32 intel_degamma_lut_tests(const struct intel_crtc_state *crtc_state)
+{
+ struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
+
+ return INTEL_INFO(i915)->display.color.degamma_lut_tests;
+}
+
+static int intel_gamma_lut_size(const struct intel_crtc_state *crtc_state)
+{
+ struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
+ const struct drm_property_blob *gamma_lut = crtc_state->hw.gamma_lut;
+
+ if (lut_is_legacy(gamma_lut))
+ return LEGACY_LUT_LENGTH;
+
+ return INTEL_INFO(i915)->display.color.gamma_lut_size;
+}
+
+static u32 intel_degamma_lut_size(const struct intel_crtc_state *crtc_state)
+{
+ struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
+
+ return INTEL_INFO(i915)->display.color.degamma_lut_size;
+}
+
static int check_lut_size(const struct drm_property_blob *lut, int expected)
{
int len;
@@ -1342,21 +1370,17 @@ static int check_luts(const struct intel_crtc_state
*crtc_state)
int gamma_length, degamma_length;
u32 gamma_tests, degamma_tests;
- /* Always allow legacy gamma LUT with no further checking. */
- if (crtc_state_is_legacy_gamma(crtc_state))
- return 0;
-
/* C8 relies on its palette being stored in the legacy LUT */
- if (crtc_state->c8_planes) {
+ if (crtc_state->c8_planes && !lut_is_legacy(crtc_state->hw.gamma_lut)) {
drm_dbg_kms(>drm,
"C8 pixelformat requires the legacy LUT\n");
return -EINVAL;
}
- degamma_length = INTEL_INFO(i915)->display.color.degamma_lut_size;
- gamma_length = INTEL_INFO(i915)->display.color.gamma_lut_size;
- degamma_tests = INTEL_INFO(i915)->display.color.degamma_lut_tests;
- gamma_tests = INTEL_INFO(i915)->display.color.gamma_lut_tests;
+ degamma_length = intel_degamma_lut_size(crtc_state);
+ gamma_length = intel_gamma_lut_size(crtc_state);
+ degamma_tests = intel_degamma_lut_tests(crtc_state);
+ gamma_tests = intel_gamma_lut_tests(crtc_state);
if (check_lut_size(degamma_lut, degamma_length) ||
check_lut_size(gamma_lut, gamma_length))
@@ -1372,7 +1396,7 @@ static int check_luts(const struct intel_crtc_state
*crtc_state)
static u32 i9xx_gamma_mode(struct intel_crtc_state *crtc_state)
{
if (!crtc_state->gamma_enable ||
- crtc_state_is_legacy_gamma(crtc_state))
+ lut_is_legacy(crtc_state->hw.gamma_lut))
return
[Intel-gfx] [PATCH v3 02/20] drm/i915: Clean up 10bit precision palette defines
From: Ville Syrjälä
Use consistent bit definitions for the 10bit precision palette bits.
We just define these alongside the ilk/snb register definitions and
point to those from the ivb+ defines.
Also use the these appropriately in the LUT entry pack/unpack
functions.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 12 ++--
drivers/gpu/drm/i915/i915_reg.h| 11 +--
2 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index 2cf92bc55e8d..05257d92408b 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -471,16 +471,16 @@ static u16 i965_lut_11p6_max_pack(u32 val)
static u32 ilk_lut_10(const struct drm_color_lut *color)
{
- return drm_color_lut_extract(color->red, 10) << 20 |
- drm_color_lut_extract(color->green, 10) << 10 |
- drm_color_lut_extract(color->blue, 10);
+ return REG_FIELD_PREP(PREC_PALETTE_10_RED_MASK,
drm_color_lut_extract(color->red, 10)) |
+ REG_FIELD_PREP(PREC_PALETTE_10_GREEN_MASK,
drm_color_lut_extract(color->green, 10)) |
+ REG_FIELD_PREP(PREC_PALETTE_10_BLUE_MASK,
drm_color_lut_extract(color->blue, 10));
}
static void ilk_lut_10_pack(struct drm_color_lut *entry, u32 val)
{
- entry->red = intel_color_lut_pack(REG_FIELD_GET(PREC_PALETTE_RED_MASK,
val), 10);
- entry->green =
intel_color_lut_pack(REG_FIELD_GET(PREC_PALETTE_GREEN_MASK, val), 10);
- entry->blue =
intel_color_lut_pack(REG_FIELD_GET(PREC_PALETTE_BLUE_MASK, val), 10);
+ entry->red =
intel_color_lut_pack(REG_FIELD_GET(PREC_PALETTE_10_RED_MASK, val), 10);
+ entry->green =
intel_color_lut_pack(REG_FIELD_GET(PREC_PALETTE_10_GREEN_MASK, val), 10);
+ entry->blue =
intel_color_lut_pack(REG_FIELD_GET(PREC_PALETTE_10_BLUE_MASK, val), 10);
}
/* ilk+ "12.4" interpolated format (high 10 bits) */
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 1a210a4cbd0f..a4c0912a2f4f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5319,9 +5319,10 @@
/* ilk/snb precision palette */
#define _PREC_PALETTE_A 0x4b000
#define _PREC_PALETTE_B 0x4c000
-#define PREC_PALETTE_RED_MASK REG_GENMASK(29, 20)
-#define PREC_PALETTE_GREEN_MASK REG_GENMASK(19, 10)
-#define PREC_PALETTE_BLUE_MASK REG_GENMASK(9, 0)
+/* 10bit mode */
+#define PREC_PALETTE_10_RED_MASK REG_GENMASK(29, 20)
+#define PREC_PALETTE_10_GREEN_MASK REG_GENMASK(19, 10)
+#define PREC_PALETTE_10_BLUE_MASKREG_GENMASK(9, 0)
#define PREC_PALETTE(pipe, i) _MMIO(_PIPE(pipe, _PREC_PALETTE_A,
_PREC_PALETTE_B) + (i) * 4)
#define _PREC_PIPEAGCMAX 0x4d000
@@ -7560,12 +7561,10 @@ enum skl_power_gate {
#define _PAL_PREC_DATA_A 0x4A404
#define _PAL_PREC_DATA_B 0x4AC04
#define _PAL_PREC_DATA_C 0x4B404
+/* see PREC_PALETTE_* for the bits */
#define _PAL_PREC_GC_MAX_A 0x4A410
#define _PAL_PREC_GC_MAX_B 0x4AC10
#define _PAL_PREC_GC_MAX_C 0x4B410
-#define PREC_PAL_DATA_RED_MASK REG_GENMASK(29, 20)
-#define PREC_PAL_DATA_GREEN_MASK REG_GENMASK(19, 10)
-#define PREC_PAL_DATA_BLUE_MASK REG_GENMASK(9, 0)
#define _PAL_PREC_EXT_GC_MAX_A 0x4A420
#define _PAL_PREC_EXT_GC_MAX_B 0x4AC20
#define _PAL_PREC_EXT_GC_MAX_C 0x4B420
--
2.37.4
[Intel-gfx] [PATCH v3 13/20] drm/i915: Prep for C8 palette readout
From: Ville Syrjälä
Add the approproate c8_planes checks to make the LUT
code ready for C8 palette readout. Note we currently
lack the actual c8_planes readout, so this won't work
yet. But no harm in making the code somewhat more ready
for the day when we do get c8_planes readout.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index ef171837ef45..ca01b3e6b585 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -1801,7 +1801,7 @@ static int icl_color_check(struct intel_crtc_state
*crtc_state)
static int i9xx_post_csc_lut_precision(const struct intel_crtc_state
*crtc_state)
{
- if (!crtc_state->gamma_enable)
+ if (!crtc_state->gamma_enable && !crtc_state->c8_planes)
return 0;
switch (crtc_state->gamma_mode) {
@@ -1817,6 +1817,9 @@ static int i9xx_post_csc_lut_precision(const struct
intel_crtc_state *crtc_state
static bool ilk_has_post_csc_lut(const struct intel_crtc_state *crtc_state)
{
+ if (crtc_state->c8_planes)
+ return true;
+
return crtc_state->gamma_enable &&
(crtc_state->csc_mode & CSC_POSITION_BEFORE_GAMMA) != 0;
}
@@ -1847,7 +1850,7 @@ static int chv_post_csc_lut_precision(const struct
intel_crtc_state *crtc_state)
static int glk_post_csc_lut_precision(const struct intel_crtc_state
*crtc_state)
{
- if (!crtc_state->gamma_enable)
+ if (!crtc_state->gamma_enable && !crtc_state->c8_planes)
return 0;
switch (crtc_state->gamma_mode) {
@@ -1863,6 +1866,9 @@ static int glk_post_csc_lut_precision(const struct
intel_crtc_state *crtc_state)
static bool icl_has_post_csc_lut(const struct intel_crtc_state *crtc_state)
{
+ if (crtc_state->c8_planes)
+ return true;
+
return crtc_state->gamma_mode & POST_CSC_GAMMA_ENABLE;
}
@@ -2009,7 +2015,7 @@ static void i9xx_read_luts(struct intel_crtc_state
*crtc_state)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
- if (!crtc_state->gamma_enable)
+ if (!crtc_state->gamma_enable && !crtc_state->c8_planes)
return;
crtc_state->post_csc_lut = i9xx_read_lut_8(crtc);
@@ -2049,7 +2055,7 @@ static void i965_read_luts(struct intel_crtc_state
*crtc_state)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
- if (!crtc_state->gamma_enable)
+ if (!crtc_state->gamma_enable && !crtc_state->c8_planes)
return;
if (crtc_state->gamma_mode == GAMMA_MODE_MODE_8BIT)
@@ -2180,7 +2186,7 @@ static void ilk_read_luts(struct intel_crtc_state
*crtc_state)
ilk_has_post_csc_lut(crtc_state) ?
_state->post_csc_lut : _state->pre_csc_lut;
- if (!crtc_state->gamma_enable)
+ if (!crtc_state->gamma_enable && !crtc_state->c8_planes)
return;
switch (crtc_state->gamma_mode) {
@@ -2240,7 +2246,7 @@ static void ivb_read_luts(struct intel_crtc_state
*crtc_state)
ilk_has_post_csc_lut(crtc_state) ?
_state->post_csc_lut : _state->pre_csc_lut;
- if (!crtc_state->gamma_enable)
+ if (!crtc_state->gamma_enable && !crtc_state->c8_planes)
return;
switch (crtc_state->gamma_mode) {
@@ -2303,7 +2309,7 @@ static void bdw_read_luts(struct intel_crtc_state
*crtc_state)
ilk_has_post_csc_lut(crtc_state) ?
_state->post_csc_lut : _state->pre_csc_lut;
- if (!crtc_state->gamma_enable)
+ if (!crtc_state->gamma_enable && !crtc_state->c8_planes)
return;
switch (crtc_state->gamma_mode) {
@@ -2372,7 +2378,7 @@ static void glk_read_luts(struct intel_crtc_state
*crtc_state)
if (crtc_state->csc_enable)
crtc_state->pre_csc_lut = glk_read_degamma_lut(crtc);
- if (!crtc_state->gamma_enable)
+ if (!crtc_state->gamma_enable && !crtc_state->c8_planes)
return;
switch (crtc_state->gamma_mode) {
--
2.37.4
[Intel-gfx] [PATCH v3 11/20] drm/i915: Add gamma/degamma readout for ivb/hsw
From: Ville Syrjälä
We now have all the code necessary for gamma/degamma readout on
ivb/hsw. Plug it all in. As with bdw+ the cooked {pre,post}_csc_lut
make this trivial even in split gamma mode.
Note that on HSW if IPS is enabled the hardware will hang if
you try to access the LUT in split gamma mode. Thus we need to
reorder the LUT readout vs. IPS enable steps.
v2: deal with {pre,post}_csc_lut
split gamma is no longer a problem
handle HSW IPS w/a
v3: use ilk_has_post_csc_lut() helper
Reviewed-by: Uma Shankar #v1
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 72 +++-
drivers/gpu/drm/i915/display/intel_display.c | 4 +-
2 files changed, 73 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index bdc218dbc623..583a93351c97 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -2196,6 +2196,74 @@ static void ilk_read_luts(struct intel_crtc_state
*crtc_state)
}
}
+/*
+ * IVB/HSW Bspec / PAL_PREC_INDEX:
+ * "Restriction : Index auto increment mode is not
+ * supported and must not be enabled."
+ */
+static struct drm_property_blob *ivb_read_lut_10(struct intel_crtc *crtc,
+u32 prec_index)
+{
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ int i, lut_size = ivb_lut_10_size(prec_index);
+ enum pipe pipe = crtc->pipe;
+ struct drm_property_blob *blob;
+ struct drm_color_lut *lut;
+
+ blob = drm_property_create_blob(_priv->drm,
+ sizeof(lut[0]) * lut_size,
+ NULL);
+ if (IS_ERR(blob))
+ return NULL;
+
+ lut = blob->data;
+
+ for (i = 0; i < lut_size; i++) {
+ u32 val;
+
+ intel_de_write_fw(dev_priv, PREC_PAL_INDEX(pipe),
+ prec_index + i);
+ val = intel_de_read_fw(dev_priv, PREC_PAL_DATA(pipe));
+
+ ilk_lut_10_pack([i], val);
+ }
+
+ intel_de_write_fw(dev_priv, PREC_PAL_INDEX(pipe), 0);
+
+ return blob;
+}
+
+static void ivb_read_luts(struct intel_crtc_state *crtc_state)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+ struct drm_property_blob **blob =
+ ilk_has_post_csc_lut(crtc_state) ?
+ _state->post_csc_lut : _state->pre_csc_lut;
+
+ if (!crtc_state->gamma_enable)
+ return;
+
+ switch (crtc_state->gamma_mode) {
+ case GAMMA_MODE_MODE_8BIT:
+ *blob = ilk_read_lut_8(crtc);
+ break;
+ case GAMMA_MODE_MODE_SPLIT:
+ crtc_state->pre_csc_lut =
+ ivb_read_lut_10(crtc, PAL_PREC_SPLIT_MODE |
+ PAL_PREC_INDEX_VALUE(0));
+ crtc_state->post_csc_lut =
+ ivb_read_lut_10(crtc, PAL_PREC_SPLIT_MODE |
+ PAL_PREC_INDEX_VALUE(512));
+ break;
+ case GAMMA_MODE_MODE_10BIT:
+ *blob = ivb_read_lut_10(crtc, PAL_PREC_INDEX_VALUE(0));
+ break;
+ default:
+ MISSING_CASE(crtc_state->gamma_mode);
+ break;
+ }
+}
+
/* On BDW+ the index auto increment mode actually works */
static struct drm_property_blob *bdw_read_lut_10(struct intel_crtc *crtc,
u32 prec_index)
@@ -2442,7 +2510,7 @@ static const struct intel_color_funcs hsw_color_funcs = {
.color_commit_noarm = ilk_color_commit_noarm,
.color_commit_arm = hsw_color_commit_arm,
.load_luts = ivb_load_luts,
- .read_luts = NULL,
+ .read_luts = ivb_read_luts,
};
static const struct intel_color_funcs ivb_color_funcs = {
@@ -2450,7 +2518,7 @@ static const struct intel_color_funcs ivb_color_funcs = {
.color_commit_noarm = ilk_color_commit_noarm,
.color_commit_arm = ilk_color_commit_arm,
.load_luts = ivb_load_luts,
- .read_luts = NULL,
+ .read_luts = ivb_read_luts,
};
static const struct intel_color_funcs ilk_color_funcs = {
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 7cceaa6b1166..c8422fef992a 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1245,7 +1245,6 @@ static void intel_post_plane_update(struct
intel_atomic_state *state,
if (new_crtc_state->update_wm_post && new_crtc_state->hw.active)
intel_update_watermarks(dev_priv);
- hsw_ips_post_update(state, crtc);
intel_fbc_post_update(state, crtc);
if (needs_async_flip_vtd_wa(old_crtc_state) &&
@@ -7583,6 +7582,9 @@ static void intel_atomic_commit_tail(struct
[Intel-gfx] [PATCH v3 14/20] drm/i915: Make .read_luts() mandatory
From: Ville Syrjälä
Every platform now implemnts .read_luts(). Make it mandatory.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index ca01b3e6b585..f0bb4227338c 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -1231,8 +1231,7 @@ void intel_color_get_config(struct intel_crtc_state
*crtc_state)
{
struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
- if (i915->display.funcs.color->read_luts)
- i915->display.funcs.color->read_luts(crtc_state);
+ i915->display.funcs.color->read_luts(crtc_state);
}
static bool need_plane_update(struct intel_plane *plane,
--
2.37.4
[Intel-gfx] [PATCH v3 20/20] drm/i915: Do state check for color management changes
From: Ville Syrjälä
In order to validate LUT programming more thoroughly let's
do a state check for all color management updates as well.
Not sure we really want this outside CI. It is rather heavy
and color management updates could become rather common
with all the HDR/etc. stuff happening. Maybe we should have
an extra knob for this that we could enable in CI?
v2: Skip for initial_commit to avoid FDI dotclock
sanity checks/etc. tripping up
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_modeset_verify.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_modeset_verify.c
b/drivers/gpu/drm/i915/display/intel_modeset_verify.c
index 842d70f0dfd2..9e4767e1b900 100644
--- a/drivers/gpu/drm/i915/display/intel_modeset_verify.c
+++ b/drivers/gpu/drm/i915/display/intel_modeset_verify.c
@@ -228,6 +228,8 @@ void intel_modeset_verify_crtc(struct intel_crtc *crtc,
struct intel_crtc_state *new_crtc_state)
{
if (!intel_crtc_needs_modeset(new_crtc_state) &&
+ (!intel_crtc_needs_color_update(new_crtc_state) ||
+new_crtc_state->inherited) &&
!intel_crtc_needs_fastset(new_crtc_state))
return;
--
2.37.4
[Intel-gfx] [PATCH v3 07/20] drm/i915: s/gamma/post_csc_lut/
From: Ville Syrjälä
Rename a the LUT state check foo_gamma_precision() functions
to foo_post_csc_lut_precision() to make it more clear what
they really do.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index 250e83f1f5ac..e1958a1b4dcc 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -1792,7 +1792,7 @@ static int icl_color_check(struct intel_crtc_state
*crtc_state)
return 0;
}
-static int i9xx_gamma_precision(const struct intel_crtc_state *crtc_state)
+static int i9xx_post_csc_lut_precision(const struct intel_crtc_state
*crtc_state)
{
if (!crtc_state->gamma_enable)
return 0;
@@ -1808,7 +1808,7 @@ static int i9xx_gamma_precision(const struct
intel_crtc_state *crtc_state)
}
}
-static int ilk_gamma_precision(const struct intel_crtc_state *crtc_state)
+static int ilk_post_csc_lut_precision(const struct intel_crtc_state
*crtc_state)
{
if (!crtc_state->gamma_enable)
return 0;
@@ -1827,15 +1827,15 @@ static int ilk_gamma_precision(const struct
intel_crtc_state *crtc_state)
}
}
-static int chv_gamma_precision(const struct intel_crtc_state *crtc_state)
+static int chv_post_csc_lut_precision(const struct intel_crtc_state
*crtc_state)
{
if (crtc_state->cgm_mode & CGM_PIPE_MODE_GAMMA)
return 10;
else
- return i9xx_gamma_precision(crtc_state);
+ return i9xx_post_csc_lut_precision(crtc_state);
}
-static int glk_gamma_precision(const struct intel_crtc_state *crtc_state)
+static int glk_post_csc_lut_precision(const struct intel_crtc_state
*crtc_state)
{
if (!crtc_state->gamma_enable)
return 0;
@@ -1851,7 +1851,7 @@ static int glk_gamma_precision(const struct
intel_crtc_state *crtc_state)
}
}
-static int icl_gamma_precision(const struct intel_crtc_state *crtc_state)
+static int icl_post_csc_lut_precision(const struct intel_crtc_state
*crtc_state)
{
if ((crtc_state->gamma_mode & POST_CSC_GAMMA_ENABLE) == 0)
return 0;
@@ -1876,16 +1876,16 @@ int intel_color_get_gamma_bit_precision(const struct
intel_crtc_state *crtc_stat
if (HAS_GMCH(i915)) {
if (IS_CHERRYVIEW(i915))
- return chv_gamma_precision(crtc_state);
+ return chv_post_csc_lut_precision(crtc_state);
else
- return i9xx_gamma_precision(crtc_state);
+ return i9xx_post_csc_lut_precision(crtc_state);
} else {
if (DISPLAY_VER(i915) >= 11)
- return icl_gamma_precision(crtc_state);
+ return icl_post_csc_lut_precision(crtc_state);
else if (DISPLAY_VER(i915) == 10)
- return glk_gamma_precision(crtc_state);
+ return glk_post_csc_lut_precision(crtc_state);
else if (IS_IRONLAKE(i915))
- return ilk_gamma_precision(crtc_state);
+ return ilk_post_csc_lut_precision(crtc_state);
}
return 0;
--
2.37.4
[Intel-gfx] [PATCH v3 17/20] drm/i915: Use hw degamma LUT for sw gamma on glk with YCbCr output
From: Ville Syrjälä
On glk we can no longer reorder the hw LUTS vs. pipe CSC like
we could on eaerlier platforms, and neither do we have a
separate output CSC like on icl+. That means if we use the
pipe CSC for YCbCr output we are currently applying the gamma
LUT after the RGB->YCbCr conversion, which is just wrong.
The further we go from a linear curve the more distorted the
resulting colors become.
To work around this terrible limitation the best we can do is
repurpose the hw degamma LUT as a poor man's gamma LUT. Now
that we have the internal pre_csc_lut attachment point that
is not particularly hard to do.
What makes this less than ideal however is the fact that the
hw degamma LUT and gamma LUTs have very different capabilities.
The gamma LUT can operatie in direct color type modes, whereas
the degamma LUT can't and just always operaters in interpolated
mode. Additionally the degamma LUT is just a single 1D LUT, whereas
the gamma LUT is made of three separate 1D LUts (one for each channel).
So in order to make this semi-sensible we must also verify the
user supplied LUT more less matches the hw degamma LUT capabilities.
We still end up losing most of the LUT entries though, so the results
might be a bit crap.
The other option of flat out rejecting the YCbCr+gamma LUT combo
seems extremely likely to just cause a black screen for the user.
Eg. pretty sure Xorg always applies some kind of gamma LUT, and
if the user then plugs in a display that needs YCbCr output we're
toast.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 61 +++---
1 file changed, 54 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index 8bb8983b490c..c336524d9225 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -1362,13 +1362,13 @@ static int check_lut_size(const struct
drm_property_blob *lut, int expected)
return 0;
}
-static int check_luts(const struct intel_crtc_state *crtc_state)
+static int _check_luts(const struct intel_crtc_state *crtc_state,
+ u32 degamma_tests, u32 gamma_tests)
{
struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
const struct drm_property_blob *gamma_lut = crtc_state->hw.gamma_lut;
const struct drm_property_blob *degamma_lut =
crtc_state->hw.degamma_lut;
int gamma_length, degamma_length;
- u32 gamma_tests, degamma_tests;
/* C8 relies on its palette being stored in the legacy LUT */
if (crtc_state->c8_planes && !lut_is_legacy(crtc_state->hw.gamma_lut)) {
@@ -1379,8 +1379,6 @@ static int check_luts(const struct intel_crtc_state
*crtc_state)
degamma_length = intel_degamma_lut_size(crtc_state);
gamma_length = intel_gamma_lut_size(crtc_state);
- degamma_tests = intel_degamma_lut_tests(crtc_state);
- gamma_tests = intel_gamma_lut_tests(crtc_state);
if (check_lut_size(degamma_lut, degamma_length) ||
check_lut_size(gamma_lut, gamma_length))
@@ -1393,6 +1391,13 @@ static int check_luts(const struct intel_crtc_state
*crtc_state)
return 0;
}
+static int check_luts(const struct intel_crtc_state *crtc_state)
+{
+ return _check_luts(crtc_state,
+ intel_degamma_lut_tests(crtc_state),
+ intel_gamma_lut_tests(crtc_state));
+}
+
static u32 i9xx_gamma_mode(struct intel_crtc_state *crtc_state)
{
if (!crtc_state->gamma_enable ||
@@ -1414,9 +1419,11 @@ void intel_color_assert_luts(const struct
intel_crtc_state *crtc_state)
crtc_state->post_csc_lut !=
crtc_state->hw.gamma_lut);
} else if (DISPLAY_VER(i915) == 10) {
drm_WARN_ON(>drm,
+ crtc_state->post_csc_lut ==
crtc_state->hw.gamma_lut &&
crtc_state->pre_csc_lut !=
crtc_state->hw.degamma_lut &&
crtc_state->pre_csc_lut !=
i915->display.color.glk_linear_degamma_lut);
drm_WARN_ON(>drm,
+ crtc_state->post_csc_lut != NULL &&
crtc_state->post_csc_lut !=
crtc_state->hw.gamma_lut);
} else if (crtc_state->gamma_mode != GAMMA_MODE_MODE_SPLIT) {
drm_WARN_ON(>drm,
@@ -1728,10 +1735,33 @@ static u32 glk_gamma_mode(const struct intel_crtc_state
*crtc_state)
return GAMMA_MODE_MODE_10BIT;
}
-static void glk_assign_luts(struct intel_crtc_state *crtc_state)
+static bool glk_use_pre_csc_lut_for_gamma(const struct intel_crtc_state
*crtc_state)
+{
+ return crtc_state->hw.gamma_lut &&
+ !crtc_state->c8_planes &&
+ crtc_state->output_format != INTEL_OUTPUT_FORMAT_RGB;
+}
+
+static int glk_assign_luts(struct intel_crtc_state *crtc_state)
{
struct drm_i915_private *i915 =
[Intel-gfx] [PATCH v3 15/20] drm/i915: Finish the LUT state checker
From: Ville Syrjälä
We have full readout now for all platforms (sans the icl+
multi-segment readout hw fail), so hook up the LUT state
checker for everyone.
We add a new vfunc for this since different platforms need
to handle the details a bit differently.
The implementation is rather repetitive in places. Probably
we want to think of a more declarative approach for the
LUT precision/etc. stuff in the future...
Note that we're currently missing readout for c8_planes, so
we'll have to skip the state check in that case.
v2: Fix readout for C8 use cases
v3: Skip C8 entirely due to lack of c8_planes readout
Add ilk_has_pre_csc_lut() helper and use other such helpers
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 275 ++-
drivers/gpu/drm/i915/display/intel_color.h | 8 +-
drivers/gpu/drm/i915/display/intel_display.c | 29 +-
3 files changed, 225 insertions(+), 87 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index f0bb4227338c..e2bcfbffb298 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -53,7 +53,18 @@ struct intel_color_funcs {
* involved with the same commit.
*/
void (*load_luts)(const struct intel_crtc_state *crtc_state);
+ /*
+* Read out the LUTs from the hardware into the software state.
+* Used by eg. the hardware state checker.
+*/
void (*read_luts)(struct intel_crtc_state *crtc_state);
+ /*
+* Compare the LUTs
+*/
+ bool (*lut_equal)(const struct intel_crtc_state *crtc_state,
+ const struct drm_property_blob *blob1,
+ const struct drm_property_blob *blob2,
+ bool is_pre_csc_lut);
};
#define CTM_COEFF_SIGN (1ULL << 63)
@@ -1234,6 +1245,24 @@ void intel_color_get_config(struct intel_crtc_state
*crtc_state)
i915->display.funcs.color->read_luts(crtc_state);
}
+bool intel_color_lut_equal(const struct intel_crtc_state *crtc_state,
+ const struct drm_property_blob *blob1,
+ const struct drm_property_blob *blob2,
+ bool is_pre_csc_lut)
+{
+ struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
+
+ /*
+* FIXME c8_planes readout missing thus
+* .read_luts() doesn't read out post_csc_lut.
+*/
+ if (!is_pre_csc_lut && crtc_state->c8_planes)
+ return true;
+
+ return i915->display.funcs.color->lut_equal(crtc_state, blob1, blob2,
+ is_pre_csc_lut);
+}
+
static bool need_plane_update(struct intel_plane *plane,
const struct intel_crtc_state *crtc_state)
{
@@ -1814,6 +1843,24 @@ static int i9xx_post_csc_lut_precision(const struct
intel_crtc_state *crtc_state
}
}
+static int i9xx_pre_csc_lut_precision(const struct intel_crtc_state
*crtc_state)
+{
+ return 0;
+}
+
+static int ilk_gamma_mode_precision(u32 gamma_mode)
+{
+ switch (gamma_mode) {
+ case GAMMA_MODE_MODE_8BIT:
+ return 8;
+ case GAMMA_MODE_MODE_10BIT:
+ return 10;
+ default:
+ MISSING_CASE(gamma_mode);
+ return 0;
+ }
+}
+
static bool ilk_has_post_csc_lut(const struct intel_crtc_state *crtc_state)
{
if (crtc_state->c8_planes)
@@ -1823,28 +1870,60 @@ static bool ilk_has_post_csc_lut(const struct
intel_crtc_state *crtc_state)
(crtc_state->csc_mode & CSC_POSITION_BEFORE_GAMMA) != 0;
}
+static bool ilk_has_pre_csc_lut(const struct intel_crtc_state *crtc_state)
+{
+ return crtc_state->gamma_enable &&
+ (crtc_state->csc_mode & CSC_POSITION_BEFORE_GAMMA) == 0;
+}
+
static int ilk_post_csc_lut_precision(const struct intel_crtc_state
*crtc_state)
{
if (!ilk_has_post_csc_lut(crtc_state))
return 0;
- switch (crtc_state->gamma_mode) {
- case GAMMA_MODE_MODE_8BIT:
- return 8;
- case GAMMA_MODE_MODE_10BIT:
- return 10;
- default:
- MISSING_CASE(crtc_state->gamma_mode);
+ return ilk_gamma_mode_precision(crtc_state->gamma_mode);
+}
+
+static int ilk_pre_csc_lut_precision(const struct intel_crtc_state *crtc_state)
+{
+ if (!ilk_has_pre_csc_lut(crtc_state))
return 0;
- }
+
+ return ilk_gamma_mode_precision(crtc_state->gamma_mode);
+}
+
+static int ivb_post_csc_lut_precision(const struct intel_crtc_state
*crtc_state)
+{
+ if (crtc_state->gamma_enable &&
+ crtc_state->gamma_mode == GAMMA_MODE_MODE_SPLIT)
+ return 10;
+
+ return ilk_post_csc_lut_precision(crtc_state);
+}
+
+static int ivb_pre_csc_lut_precision(const struct intel_crtc_state *crtc_state)
+{
+
[Intel-gfx] [PATCH v3 05/20] drm/i915: Reorder 12.4 lut udw vs. ldw functions
From: Ville Syrjälä
Satisfy my ocd and define ilk_lut_12p4_ldw() before ilk_lut_12p4_udw().
That is the order all the other similar functions use.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index a71e4a40ccf7..250e83f1f5ac 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -483,14 +483,6 @@ static void ilk_lut_10_pack(struct drm_color_lut *entry,
u32 val)
entry->blue =
intel_color_lut_pack(REG_FIELD_GET(PREC_PALETTE_10_BLUE_MASK, val), 10);
}
-/* ilk+ "12.4" interpolated format (high 10 bits) */
-static u32 ilk_lut_12p4_udw(const struct drm_color_lut *color)
-{
- return REG_FIELD_PREP(PREC_PALETTE_12P4_RED_UDW_MASK, color->red >> 6) |
- REG_FIELD_PREP(PREC_PALETTE_12P4_GREEN_UDW_MASK, color->green
>> 6) |
- REG_FIELD_PREP(PREC_PALETTE_12P4_BLUE_UDW_MASK, color->blue >>
6);
-}
-
/* ilk+ "12.4" interpolated format (low 6 bits) */
static u32 ilk_lut_12p4_ldw(const struct drm_color_lut *color)
{
@@ -499,6 +491,14 @@ static u32 ilk_lut_12p4_ldw(const struct drm_color_lut
*color)
REG_FIELD_PREP(PREC_PALETTE_12P4_BLUE_LDW_MASK, color->blue &
0x3f);
}
+/* ilk+ "12.4" interpolated format (high 10 bits) */
+static u32 ilk_lut_12p4_udw(const struct drm_color_lut *color)
+{
+ return REG_FIELD_PREP(PREC_PALETTE_12P4_RED_UDW_MASK, color->red >> 6) |
+ REG_FIELD_PREP(PREC_PALETTE_12P4_GREEN_UDW_MASK, color->green
>> 6) |
+ REG_FIELD_PREP(PREC_PALETTE_12P4_BLUE_UDW_MASK, color->blue >>
6);
+}
+
static void ilk_lut_12p4_pack(struct drm_color_lut *entry, u32 ldw, u32 udw)
{
entry->red = REG_FIELD_GET(PREC_PALETTE_12P4_RED_UDW_MASK, udw) << 6 |
--
2.37.4
[Intel-gfx] [PATCH v3 09/20] drm/i915: Read out CHV CGM degamma
From: Ville Syrjälä
Since CHV has the dedicate CGM degamma unit readout is trivial.
Just do it.
v2: deal with post_csc_lut
Reviewed-by: Uma Shankar
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 36 ++
1 file changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index 3dd8a4ff0eca..430fa23c102f 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -1087,6 +1087,13 @@ static u32 chv_cgm_degamma_udw(const struct
drm_color_lut *color)
return REG_FIELD_PREP(CGM_PIPE_DEGAMMA_RED_UDW_MASK,
drm_color_lut_extract(color->red, 14));
}
+static void chv_cgm_degamma_pack(struct drm_color_lut *entry, u32 ldw, u32 udw)
+{
+ entry->green =
intel_color_lut_pack(REG_FIELD_GET(CGM_PIPE_DEGAMMA_GREEN_LDW_MASK, ldw), 14);
+ entry->blue =
intel_color_lut_pack(REG_FIELD_GET(CGM_PIPE_DEGAMMA_BLUE_LDW_MASK, ldw), 14);
+ entry->red =
intel_color_lut_pack(REG_FIELD_GET(CGM_PIPE_DEGAMMA_RED_UDW_MASK, udw), 14);
+}
+
static void chv_load_cgm_degamma(struct intel_crtc *crtc,
const struct drm_property_blob *blob)
{
@@ -2048,6 +2055,32 @@ static void i965_read_luts(struct intel_crtc_state
*crtc_state)
crtc_state->post_csc_lut = i965_read_lut_10p6(crtc);
}
+static struct drm_property_blob *chv_read_cgm_degamma(struct intel_crtc *crtc)
+{
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ int i, lut_size = INTEL_INFO(dev_priv)->display.color.degamma_lut_size;
+ enum pipe pipe = crtc->pipe;
+ struct drm_property_blob *blob;
+ struct drm_color_lut *lut;
+
+ blob = drm_property_create_blob(_priv->drm,
+ sizeof(lut[0]) * lut_size,
+ NULL);
+ if (IS_ERR(blob))
+ return NULL;
+
+ lut = blob->data;
+
+ for (i = 0; i < lut_size; i++) {
+ u32 ldw = intel_de_read_fw(dev_priv, CGM_PIPE_DEGAMMA(pipe, i,
0));
+ u32 udw = intel_de_read_fw(dev_priv, CGM_PIPE_DEGAMMA(pipe, i,
1));
+
+ chv_cgm_degamma_pack([i], ldw, udw);
+ }
+
+ return blob;
+}
+
static struct drm_property_blob *chv_read_cgm_gamma(struct intel_crtc *crtc)
{
struct drm_i915_private *i915 = to_i915(crtc->base.dev);
@@ -2078,6 +2111,9 @@ static void chv_read_luts(struct intel_crtc_state
*crtc_state)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+ if (crtc_state->cgm_mode & CGM_PIPE_MODE_DEGAMMA)
+ crtc_state->pre_csc_lut = chv_read_cgm_degamma(crtc);
+
if (crtc_state->cgm_mode & CGM_PIPE_MODE_GAMMA)
crtc_state->post_csc_lut = chv_read_cgm_gamma(crtc);
else
--
2.37.4
[Intel-gfx] [PATCH v3 06/20] drm/i915: Fix adl+ degamma LUT size
From: Ville Syrjälä
The degamma LUT is interpolated so we need the 128th (==1.0)
entry to represent the full < 1.0 input range. Only the 129th
and 130th entries are strictly for the >=1.0 extended range
inputs.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 211913be40ce..c50841e36c61 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -948,7 +948,7 @@ static const struct intel_device_info adl_s_info = {
#define XE_LPD_FEATURES \
.display.abox_mask = GENMASK(1, 0),
\
.display.color = {
\
- .degamma_lut_size = 128, .gamma_lut_size = 1024,
\
+ .degamma_lut_size = 129, .gamma_lut_size = 1024,
\
.degamma_lut_tests = DRM_COLOR_LUT_NON_DECREASING |
\
DRM_COLOR_LUT_EQUAL_CHANNELS,
\
},
\
--
2.37.4
[Intel-gfx] [PATCH v3 12/20] drm/i915: Make ilk_read_luts() capable of degamma readout
From: Ville Syrjälä
Just like ivb+, ilk/snb can select whether the hw lut acts as
gamma or degamma. Make the readout cognizant of that fact.
v2: deal with pre_csc_lut
v3: use ilk_has_post_csc_lut() helper
Reviewed-by: Uma Shankar
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index 583a93351c97..ef171837ef45 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -2176,19 +2176,19 @@ static struct drm_property_blob *ilk_read_lut_10(struct
intel_crtc *crtc)
static void ilk_read_luts(struct intel_crtc_state *crtc_state)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+ struct drm_property_blob **blob =
+ ilk_has_post_csc_lut(crtc_state) ?
+ _state->post_csc_lut : _state->pre_csc_lut;
if (!crtc_state->gamma_enable)
return;
- if ((crtc_state->csc_mode & CSC_POSITION_BEFORE_GAMMA) == 0)
- return;
-
switch (crtc_state->gamma_mode) {
case GAMMA_MODE_MODE_8BIT:
- crtc_state->post_csc_lut = ilk_read_lut_8(crtc);
+ *blob = ilk_read_lut_8(crtc);
break;
case GAMMA_MODE_MODE_10BIT:
- crtc_state->post_csc_lut = ilk_read_lut_10(crtc);
+ *blob = ilk_read_lut_10(crtc);
break;
default:
MISSING_CASE(crtc_state->gamma_mode);
--
2.37.4
[Intel-gfx] [PATCH v3 10/20] drm/i915: Add gamma/degamma readout for bdw+
From: Ville Syrjälä
Read out the gamma/degamma LUT on bdw+. Now that the
{pre,post}_csc_lut match the hardware LUT size even
in split gamma mode this is trivial.
v2: deal with {pre,post}_csc_lut
split gamma is no longer a problem
v3: add ilk_has_post_csc_lut() helper
Reviewed-by: Uma Shankar #v1
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 51 +-
1 file changed, 41 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index 430fa23c102f..bdc218dbc623 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -1815,12 +1815,15 @@ static int i9xx_post_csc_lut_precision(const struct
intel_crtc_state *crtc_state
}
}
+static bool ilk_has_post_csc_lut(const struct intel_crtc_state *crtc_state)
+{
+ return crtc_state->gamma_enable &&
+ (crtc_state->csc_mode & CSC_POSITION_BEFORE_GAMMA) != 0;
+}
+
static int ilk_post_csc_lut_precision(const struct intel_crtc_state
*crtc_state)
{
- if (!crtc_state->gamma_enable)
- return 0;
-
- if ((crtc_state->csc_mode & CSC_POSITION_BEFORE_GAMMA) == 0)
+ if (!ilk_has_post_csc_lut(crtc_state))
return 0;
switch (crtc_state->gamma_mode) {
@@ -2198,14 +2201,11 @@ static struct drm_property_blob *bdw_read_lut_10(struct
intel_crtc *crtc,
u32 prec_index)
{
struct drm_i915_private *i915 = to_i915(crtc->base.dev);
- int i, hw_lut_size = ivb_lut_10_size(prec_index);
- int lut_size = INTEL_INFO(i915)->display.color.gamma_lut_size;
+ int i, lut_size = ivb_lut_10_size(prec_index);
enum pipe pipe = crtc->pipe;
struct drm_property_blob *blob;
struct drm_color_lut *lut;
- drm_WARN_ON(>drm, lut_size != hw_lut_size);
-
blob = drm_property_create_blob(>drm,
sizeof(lut[0]) * lut_size,
NULL);
@@ -2228,6 +2228,37 @@ static struct drm_property_blob *bdw_read_lut_10(struct
intel_crtc *crtc,
return blob;
}
+static void bdw_read_luts(struct intel_crtc_state *crtc_state)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+ struct drm_property_blob **blob =
+ ilk_has_post_csc_lut(crtc_state) ?
+ _state->post_csc_lut : _state->pre_csc_lut;
+
+ if (!crtc_state->gamma_enable)
+ return;
+
+ switch (crtc_state->gamma_mode) {
+ case GAMMA_MODE_MODE_8BIT:
+ *blob = ilk_read_lut_8(crtc);
+ break;
+ case GAMMA_MODE_MODE_SPLIT:
+ crtc_state->pre_csc_lut =
+ bdw_read_lut_10(crtc, PAL_PREC_SPLIT_MODE |
+ PAL_PREC_INDEX_VALUE(0));
+ crtc_state->post_csc_lut =
+ bdw_read_lut_10(crtc, PAL_PREC_SPLIT_MODE |
+ PAL_PREC_INDEX_VALUE(512));
+ break;
+ case GAMMA_MODE_MODE_10BIT:
+ *blob = bdw_read_lut_10(crtc, PAL_PREC_INDEX_VALUE(0));
+ break;
+ default:
+ MISSING_CASE(crtc_state->gamma_mode);
+ break;
+ }
+}
+
static struct drm_property_blob *glk_read_degamma_lut(struct intel_crtc *crtc)
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
@@ -2395,7 +2426,7 @@ static const struct intel_color_funcs skl_color_funcs = {
.color_commit_noarm = ilk_color_commit_noarm,
.color_commit_arm = skl_color_commit_arm,
.load_luts = bdw_load_luts,
- .read_luts = NULL,
+ .read_luts = bdw_read_luts,
};
static const struct intel_color_funcs bdw_color_funcs = {
@@ -2403,7 +2434,7 @@ static const struct intel_color_funcs bdw_color_funcs = {
.color_commit_noarm = ilk_color_commit_noarm,
.color_commit_arm = hsw_color_commit_arm,
.load_luts = bdw_load_luts,
- .read_luts = NULL,
+ .read_luts = bdw_read_luts,
};
static const struct intel_color_funcs hsw_color_funcs = {
--
2.37.4
[Intel-gfx] [PATCH v3 08/20] drm/i915: Add glk+ degamma readout
From: Ville Syrjälä
Read out the degamma LUT on glk+. No state cheker as of yet since
it requires dealing with the glk csc vs. degamma mess.
v2: deal with post_csc_lut
v3: add icl_has_{pre,post}_csc_lut(*) helpers
Reviewed-by: Uma Shankar
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 58 +-
1 file changed, 56 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index e1958a1b4dcc..3dd8a4ff0eca 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -1851,9 +1851,19 @@ static int glk_post_csc_lut_precision(const struct
intel_crtc_state *crtc_state)
}
}
+static bool icl_has_post_csc_lut(const struct intel_crtc_state *crtc_state)
+{
+ return crtc_state->gamma_mode & POST_CSC_GAMMA_ENABLE;
+}
+
+static bool icl_has_pre_csc_lut(const struct intel_crtc_state *crtc_state)
+{
+ return crtc_state->gamma_mode & PRE_CSC_GAMMA_ENABLE;
+}
+
static int icl_post_csc_lut_precision(const struct intel_crtc_state
*crtc_state)
{
- if ((crtc_state->gamma_mode & POST_CSC_GAMMA_ENABLE) == 0)
+ if (!icl_has_post_csc_lut(crtc_state))
return 0;
switch (crtc_state->gamma_mode & GAMMA_MODE_MODE_MASK) {
@@ -2182,10 +2192,51 @@ static struct drm_property_blob *bdw_read_lut_10(struct
intel_crtc *crtc,
return blob;
}
+static struct drm_property_blob *glk_read_degamma_lut(struct intel_crtc *crtc)
+{
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ int i, lut_size = INTEL_INFO(dev_priv)->display.color.degamma_lut_size;
+ enum pipe pipe = crtc->pipe;
+ struct drm_property_blob *blob;
+ struct drm_color_lut *lut;
+
+ blob = drm_property_create_blob(_priv->drm,
+ sizeof(lut[0]) * lut_size,
+ NULL);
+ if (IS_ERR(blob))
+ return NULL;
+
+ lut = blob->data;
+
+ /*
+* When setting the auto-increment bit, the hardware seems to
+* ignore the index bits, so we need to reset it to index 0
+* separately.
+*/
+ intel_de_write_fw(dev_priv, PRE_CSC_GAMC_INDEX(pipe), 0);
+ intel_de_write_fw(dev_priv, PRE_CSC_GAMC_INDEX(pipe),
+ PRE_CSC_GAMC_AUTO_INCREMENT);
+
+ for (i = 0; i < lut_size; i++) {
+ u32 val = intel_de_read_fw(dev_priv, PRE_CSC_GAMC_DATA(pipe));
+
+ lut[i].red = val;
+ lut[i].green = val;
+ lut[i].blue = val;
+ }
+
+ intel_de_write_fw(dev_priv, PRE_CSC_GAMC_INDEX(pipe), 0);
+
+ return blob;
+}
+
static void glk_read_luts(struct intel_crtc_state *crtc_state)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+ if (crtc_state->csc_enable)
+ crtc_state->pre_csc_lut = glk_read_degamma_lut(crtc);
+
if (!crtc_state->gamma_enable)
return;
@@ -2244,7 +2295,10 @@ static void icl_read_luts(struct intel_crtc_state
*crtc_state)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
- if ((crtc_state->gamma_mode & POST_CSC_GAMMA_ENABLE) == 0)
+ if (icl_has_pre_csc_lut(crtc_state))
+ crtc_state->pre_csc_lut = glk_read_degamma_lut(crtc);
+
+ if (!icl_has_post_csc_lut(crtc_state))
return;
switch (crtc_state->gamma_mode & GAMMA_MODE_MODE_MASK) {
--
2.37.4
[Intel-gfx] [PATCH v3 04/20] drm/i915: Clean up chv CGM (de)gamma defines
From: Ville Syrjälä
Add the missing ldw vs. udw information to the CGM (de)gamma
bit definitions to make it a bit easier to see which should
be used where.
Also use the these appropriately in the LUT entry pack/unpack
functions.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 18 +-
drivers/gpu/drm/i915/i915_reg.h| 16 ++--
2 files changed, 19 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index 8dfccf50dc7d..a71e4a40ccf7 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -1078,13 +1078,13 @@ static void icl_load_luts(const struct intel_crtc_state
*crtc_state)
static u32 chv_cgm_degamma_ldw(const struct drm_color_lut *color)
{
- return drm_color_lut_extract(color->green, 14) << 16 |
- drm_color_lut_extract(color->blue, 14);
+ return REG_FIELD_PREP(CGM_PIPE_DEGAMMA_GREEN_LDW_MASK,
drm_color_lut_extract(color->green, 14)) |
+ REG_FIELD_PREP(CGM_PIPE_DEGAMMA_BLUE_LDW_MASK,
drm_color_lut_extract(color->blue, 14));
}
static u32 chv_cgm_degamma_udw(const struct drm_color_lut *color)
{
- return drm_color_lut_extract(color->red, 14);
+ return REG_FIELD_PREP(CGM_PIPE_DEGAMMA_RED_UDW_MASK,
drm_color_lut_extract(color->red, 14));
}
static void chv_load_cgm_degamma(struct intel_crtc *crtc,
@@ -1105,20 +1105,20 @@ static void chv_load_cgm_degamma(struct intel_crtc
*crtc,
static u32 chv_cgm_gamma_ldw(const struct drm_color_lut *color)
{
- return drm_color_lut_extract(color->green, 10) << 16 |
- drm_color_lut_extract(color->blue, 10);
+ return REG_FIELD_PREP(CGM_PIPE_GAMMA_GREEN_LDW_MASK,
drm_color_lut_extract(color->green, 10)) |
+ REG_FIELD_PREP(CGM_PIPE_GAMMA_BLUE_LDW_MASK,
drm_color_lut_extract(color->blue, 10));
}
static u32 chv_cgm_gamma_udw(const struct drm_color_lut *color)
{
- return drm_color_lut_extract(color->red, 10);
+ return REG_FIELD_PREP(CGM_PIPE_GAMMA_RED_UDW_MASK,
drm_color_lut_extract(color->red, 10));
}
static void chv_cgm_gamma_pack(struct drm_color_lut *entry, u32 ldw, u32 udw)
{
- entry->green =
intel_color_lut_pack(REG_FIELD_GET(CGM_PIPE_GAMMA_GREEN_MASK, ldw), 10);
- entry->blue =
intel_color_lut_pack(REG_FIELD_GET(CGM_PIPE_GAMMA_BLUE_MASK, ldw), 10);
- entry->red =
intel_color_lut_pack(REG_FIELD_GET(CGM_PIPE_GAMMA_RED_MASK, udw), 10);
+ entry->green =
intel_color_lut_pack(REG_FIELD_GET(CGM_PIPE_GAMMA_GREEN_LDW_MASK, ldw), 10);
+ entry->blue =
intel_color_lut_pack(REG_FIELD_GET(CGM_PIPE_GAMMA_BLUE_LDW_MASK, ldw), 10);
+ entry->red =
intel_color_lut_pack(REG_FIELD_GET(CGM_PIPE_GAMMA_RED_UDW_MASK, udw), 10);
}
static void chv_load_cgm_gamma(struct intel_crtc *crtc,
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 4341f69c7c9c..c0dc9425a37c 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7666,13 +7666,17 @@ enum skl_power_gate {
#define _CGM_PIPE_A_CSC_COEFF67(VLV_DISPLAY_BASE + 0x6790C)
#define _CGM_PIPE_A_CSC_COEFF8 (VLV_DISPLAY_BASE + 0x67910)
#define _CGM_PIPE_A_DEGAMMA(VLV_DISPLAY_BASE + 0x66000)
-#define CGM_PIPE_DEGAMMA_RED_MASKREG_GENMASK(13, 0)
-#define CGM_PIPE_DEGAMMA_GREEN_MASK REG_GENMASK(29, 16)
-#define CGM_PIPE_DEGAMMA_BLUE_MASK REG_GENMASK(13, 0)
+/* cgm degamma ldw */
+#define CGM_PIPE_DEGAMMA_GREEN_LDW_MASK REG_GENMASK(29, 16)
+#define CGM_PIPE_DEGAMMA_BLUE_LDW_MASK REG_GENMASK(13, 0)
+/* cgm degamma udw */
+#define CGM_PIPE_DEGAMMA_RED_UDW_MASKREG_GENMASK(13, 0)
#define _CGM_PIPE_A_GAMMA (VLV_DISPLAY_BASE + 0x67000)
-#define CGM_PIPE_GAMMA_RED_MASK REG_GENMASK(9, 0)
-#define CGM_PIPE_GAMMA_GREEN_MASKREG_GENMASK(25, 16)
-#define CGM_PIPE_GAMMA_BLUE_MASK REG_GENMASK(9, 0)
+/* cgm gamma ldw */
+#define CGM_PIPE_GAMMA_GREEN_LDW_MASKREG_GENMASK(25, 16)
+#define CGM_PIPE_GAMMA_BLUE_LDW_MASK REG_GENMASK(9, 0)
+/* cgm gamma udw */
+#define CGM_PIPE_GAMMA_RED_UDW_MASK REG_GENMASK(9, 0)
#define _CGM_PIPE_A_MODE (VLV_DISPLAY_BASE + 0x67A00)
#define CGM_PIPE_MODE_GAMMA (1 << 2)
#define CGM_PIPE_MODE_CSC(1 << 1)
--
2.37.4
[Intel-gfx] [PATCH v3 01/20] drm/i915: Clean up legacy palette defines
From: Ville Syrjälä
Use consistent bit definitions for the legacy gamma LUT. We just
define these alongside the pre-ilk register definitions and point
to those from the ilk+ defines.
Also use the these appropriately in the LUT entry pack/unpack
functions.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 24 +++---
drivers/gpu/drm/i915/i915_reg.h| 11 +-
2 files changed, 17 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index 12f5b976c795..2cf92bc55e8d 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -425,32 +425,32 @@ static u32 intel_color_lut_pack(u32 val, int
bit_precision)
static u32 i9xx_lut_8(const struct drm_color_lut *color)
{
- return drm_color_lut_extract(color->red, 8) << 16 |
- drm_color_lut_extract(color->green, 8) << 8 |
- drm_color_lut_extract(color->blue, 8);
+ return REG_FIELD_PREP(PALETTE_RED_MASK,
drm_color_lut_extract(color->red, 8)) |
+ REG_FIELD_PREP(PALETTE_GREEN_MASK,
drm_color_lut_extract(color->green, 8)) |
+ REG_FIELD_PREP(PALETTE_BLUE_MASK,
drm_color_lut_extract(color->blue, 8));
}
static void i9xx_lut_8_pack(struct drm_color_lut *entry, u32 val)
{
- entry->red = intel_color_lut_pack(REG_FIELD_GET(LGC_PALETTE_RED_MASK,
val), 8);
- entry->green =
intel_color_lut_pack(REG_FIELD_GET(LGC_PALETTE_GREEN_MASK, val), 8);
- entry->blue = intel_color_lut_pack(REG_FIELD_GET(LGC_PALETTE_BLUE_MASK,
val), 8);
+ entry->red = intel_color_lut_pack(REG_FIELD_GET(PALETTE_RED_MASK, val),
8);
+ entry->green = intel_color_lut_pack(REG_FIELD_GET(PALETTE_GREEN_MASK,
val), 8);
+ entry->blue = intel_color_lut_pack(REG_FIELD_GET(PALETTE_BLUE_MASK,
val), 8);
}
/* i965+ "10.6" bit interpolated format "even DW" (low 8 bits) */
static u32 i965_lut_10p6_ldw(const struct drm_color_lut *color)
{
- return (color->red & 0xff) << 16 |
- (color->green & 0xff) << 8 |
- (color->blue & 0xff);
+ return REG_FIELD_PREP(PALETTE_RED_MASK, color->red & 0xff) |
+ REG_FIELD_PREP(PALETTE_GREEN_MASK, color->green & 0xff) |
+ REG_FIELD_PREP(PALETTE_BLUE_MASK, color->blue & 0xff);
}
/* i965+ "10.6" interpolated format "odd DW" (high 8 bits) */
static u32 i965_lut_10p6_udw(const struct drm_color_lut *color)
{
- return (color->red >> 8) << 16 |
- (color->green >> 8) << 8 |
- (color->blue >> 8);
+ return REG_FIELD_PREP(PALETTE_RED_MASK, color->red >> 8) |
+ REG_FIELD_PREP(PALETTE_GREEN_MASK, color->green >> 8) |
+ REG_FIELD_PREP(PALETTE_BLUE_MASK, color->blue >> 8);
}
static void i965_lut_10p6_pack(struct drm_color_lut *entry, u32 ldw, u32 udw)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c4921c9a6077..1a210a4cbd0f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1714,9 +1714,10 @@
#define _PALETTE_A 0xa000
#define _PALETTE_B 0xa800
#define _CHV_PALETTE_C 0xc000
-#define PALETTE_RED_MASKREG_GENMASK(23, 16)
-#define PALETTE_GREEN_MASK REG_GENMASK(15, 8)
-#define PALETTE_BLUE_MASK REG_GENMASK(7, 0)
+/* 8bit mode / i965+ 10.6 interpolated mode ldw/udw */
+#define PALETTE_RED_MASK REG_GENMASK(23, 16)
+#define PALETTE_GREEN_MASK REG_GENMASK(15, 8)
+#define PALETTE_BLUE_MASKREG_GENMASK(7, 0)
#define PALETTE(pipe, i) _MMIO(DISPLAY_MMIO_BASE(dev_priv) + \
_PICK((pipe), _PALETTE_A, \
_PALETTE_B, _CHV_PALETTE_C) + \
@@ -5312,9 +5313,7 @@
/* legacy palette */
#define _LGC_PALETTE_A 0x4a000
#define _LGC_PALETTE_B 0x4a800
-#define LGC_PALETTE_RED_MASK REG_GENMASK(23, 16)
-#define LGC_PALETTE_GREEN_MASK REG_GENMASK(15, 8)
-#define LGC_PALETTE_BLUE_MASKREG_GENMASK(7, 0)
+/* see PALETTE_* for the bits */
#define LGC_PALETTE(pipe, i) _MMIO(_PIPE(pipe, _LGC_PALETTE_A, _LGC_PALETTE_B)
+ (i) * 4)
/* ilk/snb precision palette */
--
2.37.4
[Intel-gfx] [PATCH v3 03/20] drm/i915: Clean up 12.4bit precision palette defines
From: Ville Syrjälä
Use consistent bit definitions for the 12.4bit precision palette bits.
We just define these alongside the ilk/snb register definitions and
point to those from the icl+ superfine segment defines (and we also
already pointed to them from the ivb+ precision palette defines).
Also use the these appropriately in the LUT entry pack/unpack
functions.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 22 --
drivers/gpu/drm/i915/i915_reg.h| 15 +--
2 files changed, 21 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index 05257d92408b..8dfccf50dc7d 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -486,25 +486,27 @@ static void ilk_lut_10_pack(struct drm_color_lut *entry,
u32 val)
/* ilk+ "12.4" interpolated format (high 10 bits) */
static u32 ilk_lut_12p4_udw(const struct drm_color_lut *color)
{
- return (color->red >> 6) << 20 | (color->green >> 6) << 10 |
- (color->blue >> 6);
+ return REG_FIELD_PREP(PREC_PALETTE_12P4_RED_UDW_MASK, color->red >> 6) |
+ REG_FIELD_PREP(PREC_PALETTE_12P4_GREEN_UDW_MASK, color->green
>> 6) |
+ REG_FIELD_PREP(PREC_PALETTE_12P4_BLUE_UDW_MASK, color->blue >>
6);
}
/* ilk+ "12.4" interpolated format (low 6 bits) */
static u32 ilk_lut_12p4_ldw(const struct drm_color_lut *color)
{
- return (color->red & 0x3f) << 24 | (color->green & 0x3f) << 14 |
- (color->blue & 0x3f) << 4;
+ return REG_FIELD_PREP(PREC_PALETTE_12P4_RED_LDW_MASK, color->red &
0x3f) |
+ REG_FIELD_PREP(PREC_PALETTE_12P4_GREEN_LDW_MASK, color->green &
0x3f) |
+ REG_FIELD_PREP(PREC_PALETTE_12P4_BLUE_LDW_MASK, color->blue &
0x3f);
}
static void ilk_lut_12p4_pack(struct drm_color_lut *entry, u32 ldw, u32 udw)
{
- entry->red = REG_FIELD_GET(PAL_PREC_MULTI_SEG_RED_UDW_MASK, udw) << 6 |
- REG_FIELD_GET(PAL_PREC_MULTI_SEG_RED_LDW_MASK, ldw);
- entry->green = REG_FIELD_GET(PAL_PREC_MULTI_SEG_GREEN_UDW_MASK, udw) <<
6 |
- REG_FIELD_GET(PAL_PREC_MULTI_SEG_GREEN_LDW_MASK, ldw);
- entry->blue = REG_FIELD_GET(PAL_PREC_MULTI_SEG_BLUE_UDW_MASK, udw) << 6
|
- REG_FIELD_GET(PAL_PREC_MULTI_SEG_BLUE_LDW_MASK, ldw);
+ entry->red = REG_FIELD_GET(PREC_PALETTE_12P4_RED_UDW_MASK, udw) << 6 |
+ REG_FIELD_GET(PREC_PALETTE_12P4_RED_LDW_MASK, ldw);
+ entry->green = REG_FIELD_GET(PREC_PALETTE_12P4_GREEN_UDW_MASK, udw) <<
6 |
+ REG_FIELD_GET(PREC_PALETTE_12P4_GREEN_LDW_MASK, ldw);
+ entry->blue = REG_FIELD_GET(PREC_PALETTE_12P4_BLUE_UDW_MASK, udw) << 6 |
+ REG_FIELD_GET(PREC_PALETTE_12P4_BLUE_LDW_MASK, ldw);
}
static void icl_color_commit_noarm(const struct intel_crtc_state *crtc_state)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index a4c0912a2f4f..4341f69c7c9c 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5323,6 +5323,14 @@
#define PREC_PALETTE_10_RED_MASK REG_GENMASK(29, 20)
#define PREC_PALETTE_10_GREEN_MASK REG_GENMASK(19, 10)
#define PREC_PALETTE_10_BLUE_MASKREG_GENMASK(9, 0)
+/* 12.4 interpolated mode ldw */
+#define PREC_PALETTE_12P4_RED_LDW_MASK REG_GENMASK(29, 24)
+#define PREC_PALETTE_12P4_GREEN_LDW_MASK REG_GENMASK(19, 14)
+#define PREC_PALETTE_12P4_BLUE_LDW_MASK REG_GENMASK(9, 4)
+/* 12.4 interpolated mode udw */
+#define PREC_PALETTE_12P4_RED_UDW_MASK REG_GENMASK(29, 20)
+#define PREC_PALETTE_12P4_GREEN_UDW_MASK REG_GENMASK(19, 10)
+#define PREC_PALETTE_12P4_BLUE_UDW_MASK REG_GENMASK(9, 0)
#define PREC_PALETTE(pipe, i) _MMIO(_PIPE(pipe, _PREC_PALETTE_A,
_PREC_PALETTE_B) + (i) * 4)
#define _PREC_PIPEAGCMAX 0x4d000
@@ -7597,12 +7605,7 @@ enum skl_power_gate {
#define _PAL_PREC_MULTI_SEG_DATA_A 0x4A40C
#define _PAL_PREC_MULTI_SEG_DATA_B 0x4AC0C
-#define PAL_PREC_MULTI_SEG_RED_LDW_MASK REG_GENMASK(29, 24)
-#define PAL_PREC_MULTI_SEG_RED_UDW_MASK REG_GENMASK(29, 20)
-#define PAL_PREC_MULTI_SEG_GREEN_LDW_MASK REG_GENMASK(19, 14)
-#define PAL_PREC_MULTI_SEG_GREEN_UDW_MASK REG_GENMASK(19, 10)
-#define PAL_PREC_MULTI_SEG_BLUE_LDW_MASK REG_GENMASK(9, 4)
-#define PAL_PREC_MULTI_SEG_BLUE_UDW_MASK REG_GENMASK(9, 0)
+/* see PREC_PALETTE_12P4_* for the bits */
#define PREC_PAL_MULTI_SEG_INDEX(pipe) _MMIO_PIPE(pipe, \
_PAL_PREC_MULTI_SEG_INDEX_A, \
--
2.37.4
[Intel-gfx] [PATCH v3 00/20] drm/i915: Finish (de)gamma readout
From: Ville Syrjälä
The gamma readout stuff was left half finished. No degamma
readout, and no readout whatsoever on ivb/bdw/skl/bxt.
Let's finish it.
Since we have the {pre,post}_csc_lut stuff this is fairly
easy to do now. The implementation of the LUT checker is
a bit more repetitive than I'd like but we an work on
shrinking it later.
There are some fixes/cleanups at the start, and while we're
in there let's also throw in the 10bit gamma mode for gen2/3.
At the end I also added a few patches to fix existing issues
with gamma vs. YCbCr/RGB limited range output.
v2: Mostly redone, only some of the readout implementations
remain more or less unchange
v3: More work towards C8 palette readout, but disable the
state checker for it now since we lack c8_planes readout
Ville Syrjälä (20):
drm/i915: Clean up legacy palette defines
drm/i915: Clean up 10bit precision palette defines
drm/i915: Clean up 12.4bit precision palette defines
drm/i915: Clean up chv CGM (de)gamma defines
drm/i915: Reorder 12.4 lut udw vs. ldw functions
drm/i915: Fix adl+ degamma LUT size
drm/i915: s/gamma/post_csc_lut/
drm/i915: Add glk+ degamma readout
drm/i915: Read out CHV CGM degamma
drm/i915: Add gamma/degamma readout for bdw+
drm/i915: Add gamma/degamma readout for ivb/hsw
drm/i915: Make ilk_read_luts() capable of degamma readout
drm/i915: Prep for C8 palette readout
drm/i915: Make .read_luts() mandatory
drm/i915: Finish the LUT state checker
drm/i915: Rework legacy LUT handling
drm/i915: Use hw degamma LUT for sw gamma on glk with YCbCr output
drm/i915: Use gamma LUT for RGB limited range compression
drm/i915: Add 10bit gamma mode for gen2/3
drm/i915: Do state check for color management changes
drivers/gpu/drm/i915/display/intel_color.c| 1137 ++---
drivers/gpu/drm/i915/display/intel_color.h|8 +-
drivers/gpu/drm/i915/display/intel_display.c | 33 +-
.../drm/i915/display/intel_modeset_verify.c |2 +
drivers/gpu/drm/i915/i915_pci.c | 12 +-
drivers/gpu/drm/i915/i915_reg.h | 67 +-
6 files changed, 1008 insertions(+), 251 deletions(-)
--
2.37.4
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/edid/firmware: stop using a throwaway platform device
On Mon, 14 Nov 2022, Patchwork wrote:
> == Series Details ==
>
> Series: drm/edid/firmware: stop using a throwaway platform device
> URL : https://patchwork.freedesktop.org/series/110859/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_12376 -> Patchwork_110859v1
>
>
> Summary
> ---
>
> **FAILURE**
>
> Serious unknown changes coming with Patchwork_110859v1 absolutely need to be
> verified manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_110859v1, 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_110859v1/index.html
>
> Participating hosts (37 -> 37)
> --
>
> Additional (2): bat-kbl-2 fi-bsw-nick
> Missing(2): fi-bdw-samus bat-dg1-5
>
> Possible new issues
> ---
>
> Here are the unknown changes that may have been introduced in
> Patchwork_110859v1:
>
> ### IGT changes ###
>
> Possible regressions
>
> * igt@i915_selftest@live@mman:
> - fi-rkl-guc: [PASS][1] -> [TIMEOUT][2]
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/fi-rkl-guc/igt@i915_selftest@l...@mman.html
>[2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-rkl-guc/igt@i915_selftest@l...@mman.html
Completely unrelated.
BR,
Jani.
>
>
> Known issues
>
>
> Here are the changes found in Patchwork_110859v1 that come from known
> issues:
>
> ### IGT changes ###
>
> Issues hit
>
> * igt@gem_lmem_swapping@basic:
> - fi-apl-guc: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#4613]) +3
> similar issues
>[3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-apl-guc/igt@gem_lmem_swapp...@basic.html
>
> * igt@gem_lmem_swapping@parallel-random-engines:
> - fi-bsw-nick:NOTRUN -> [SKIP][4] ([fdo#109271]) +38 similar
> issues
>[4]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-bsw-nick/igt@gem_lmem_swapp...@parallel-random-engines.html
>
> * igt@i915_pm_rpm@basic-pci-d3-state:
> - bat-adlp-4: [PASS][5] -> [DMESG-WARN][6] ([i915#7077])
>[5]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/bat-adlp-4/igt@i915_pm_...@basic-pci-d3-state.html
>[6]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/bat-adlp-4/igt@i915_pm_...@basic-pci-d3-state.html
>
> * igt@kms_chamelium@common-hpd-after-suspend:
> - fi-rkl-11600: NOTRUN -> [SKIP][7] ([fdo#111827])
>[7]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-rkl-11600/igt@kms_chamel...@common-hpd-after-suspend.html
>
> * igt@kms_chamelium@hdmi-crc-fast:
> - fi-apl-guc: NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827])
> +8 similar issues
>[8]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-apl-guc/igt@kms_chamel...@hdmi-crc-fast.html
>
> * igt@kms_chamelium@hdmi-hpd-fast:
> - fi-bsw-nick:NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827])
> +8 similar issues
>[9]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-bsw-nick/igt@kms_chamel...@hdmi-hpd-fast.html
>
> * igt@kms_force_connector_basic@force-connector-state:
> - fi-apl-guc: NOTRUN -> [SKIP][10] ([fdo#109271]) +11 similar
> issues
>[10]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-apl-guc/igt@kms_force_connector_ba...@force-connector-state.html
>
>
> Possible fixes
>
> * igt@gem_render_tiled_blits@basic:
> - fi-apl-guc: [INCOMPLETE][11] ([i915#7056]) -> [PASS][12]
>[11]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/fi-apl-guc/igt@gem_render_tiled_bl...@basic.html
>[12]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-apl-guc/igt@gem_render_tiled_bl...@basic.html
>
> * igt@i915_selftest@live@migrate:
> - {bat-adlp-6}: [INCOMPLETE][13] ([i915#7348]) -> [PASS][14]
>[13]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/bat-adlp-6/igt@i915_selftest@l...@migrate.html
>[14]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/bat-adlp-6/igt@i915_selftest@l...@migrate.html
>
> * igt@i915_selftest@live@slpc:
> - {bat-adln-1}: [DMESG-FAIL][15] ([i915#6997]) -> [PASS][16]
>[15]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/bat-adln-1/igt@i915_selftest@l...@slpc.html
>[16]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/bat-adln-1/igt@i915_selftest@l...@slpc.html
>
> * igt@i915_suspend@basic-s3-without-i915:
> - fi-rkl-11600: [INCOMPLETE][17] ([i915#4817]) -> [PASS][18]
>[17]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
>[18]:
>
Re: [Intel-gfx] [PATCH v2 00/11] Connect VFIO to IOMMUFD
On 11/14/22 9:59 AM, Jason Gunthorpe wrote: > On Mon, Nov 14, 2022 at 09:55:21AM -0500, Matthew Rosato wrote: AFAICT there is no equivalent means to specify vfio_iommu_type1.dma_entry_limit when using iommufd; looks like we'll just always get the default 65535. >>> >>> No, there is no arbitary limit on iommufd >> >> Yeah, that's what I suspected. But FWIW, userspace checks the >> advertised limit via VFIO_IOMMU_GET_INFO / >> VFIO_IOMMU_TYPE1_INFO_DMA_AVAIL, and this is still being advertised >> as 65535 when using iommufd. I don't think there is a defined way >> to return 'ignore this value'. > > Is something using this? Should we make it much bigger? Yes, s390 when doing lazy unmapping likes to use larger amounts of concurrent DMA, so there can be cases where we want to raise this limit. The initial value of 65535 is already pretty arbitrary (U16_MAX) -- If iommufd is doing its own management and this value becomes deprecated in this scenario, and we can't set it to a magic value that says 'ignore me' then maybe it just makes sense for now to set it arbitrarily larger when using iommufd e.g. U32_MAX?
[Intel-gfx] ✗ Fi.CI.IGT: failure for Enable Pipewriteback (rev10)
== Series Details == Series: Enable Pipewriteback (rev10) URL : https://patchwork.freedesktop.org/series/107440/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12375_full -> Patchwork_107440v10_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_107440v10_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_107440v10_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (10 -> 11) -- Additional (1): pig-skl-6260u Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_107440v10_full: ### IGT changes ### Possible regressions * igt@gem_exec_endless@dispatch@rcs0: - shard-tglb: [PASS][1] -> [TIMEOUT][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-tglb7/igt@gem_exec_endless@dispa...@rcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107440v10/shard-tglb1/igt@gem_exec_endless@dispa...@rcs0.html * igt@i915_pm_rc6_residency@rc6-accuracy: - shard-tglb: [PASS][3] -> [SKIP][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-tglb7/igt@i915_pm_rc6_reside...@rc6-accuracy.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107440v10/shard-tglb1/igt@i915_pm_rc6_reside...@rc6-accuracy.html Warnings * igt@kms_writeback@writeback-check-output: - shard-tglb: [SKIP][5] ([i915#2437]) -> [INCOMPLETE][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-tglb6/igt@kms_writeb...@writeback-check-output.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107440v10/shard-tglb2/igt@kms_writeb...@writeback-check-output.html Known issues Here are the changes found in Patchwork_107440v10_full that come from known issues: ### CI changes ### Issues hit * boot: - shard-glk: ([PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30], [PASS][31]) -> ([PASS][32], [PASS][33], [FAIL][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50], [PASS][51], [PASS][52], [PASS][53], [PASS][54], [PASS][55]) ([i915#4392]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-glk8/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-glk7/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-glk7/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-glk7/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-glk6/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-glk6/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-glk6/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-glk5/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-glk5/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-glk5/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-glk3/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-glk3/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-glk3/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-glk2/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-glk2/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-glk2/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-glk1/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-glk1/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-glk1/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-glk9/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-glk9/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-glk9/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-glk9/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-glk8/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12375/shard-glk8/boot.html [32]:
Re: [Intel-gfx] [PATCH v2 00/11] Connect VFIO to IOMMUFD
On Mon, Nov 14, 2022 at 09:55:21AM -0500, Matthew Rosato wrote: > >> AFAICT there is no equivalent means to specify > >> vfio_iommu_type1.dma_entry_limit when using iommufd; looks like > >> we'll just always get the default 65535. > > > > No, there is no arbitary limit on iommufd > > Yeah, that's what I suspected. But FWIW, userspace checks the > advertised limit via VFIO_IOMMU_GET_INFO / > VFIO_IOMMU_TYPE1_INFO_DMA_AVAIL, and this is still being advertised > as 65535 when using iommufd. I don't think there is a defined way > to return 'ignore this value'. Is something using this? Should we make it much bigger? Jason
Re: [Intel-gfx] [PATCH v2 00/11] Connect VFIO to IOMMUFD
On 11/14/22 9:23 AM, Jason Gunthorpe wrote: > On Thu, Nov 10, 2022 at 10:01:13PM -0500, Matthew Rosato wrote: >> On 11/7/22 7:52 PM, Jason Gunthorpe wrote: >>> This series provides an alternative container layer for VFIO implemented >>> using iommufd. This is optional, if CONFIG_IOMMUFD is not set then it will >>> not be compiled in. >>> >>> At this point iommufd can be injected by passing in a iommfd FD to >>> VFIO_GROUP_SET_CONTAINER which will use the VFIO compat layer in iommufd >>> to obtain the compat IOAS and then connect up all the VFIO drivers as >>> appropriate. >>> >>> This is temporary stopping point, a following series will provide a way to >>> directly open a VFIO device FD and directly connect it to IOMMUFD using >>> native ioctls that can expose the IOMMUFD features like hwpt, future >>> vPASID and dynamic attachment. >>> >>> This series, in compat mode, has passed all the qemu tests we have >>> available, including the test suites for the Intel GVT mdev. Aside from >>> the temporary limitation with P2P memory this is belived to be fully >>> compatible with VFIO. >> >> AFAICT there is no equivalent means to specify >> vfio_iommu_type1.dma_entry_limit when using iommufd; looks like >> we'll just always get the default 65535. > > No, there is no arbitary limit on iommufd Yeah, that's what I suspected. But FWIW, userspace checks the advertised limit via VFIO_IOMMU_GET_INFO / VFIO_IOMMU_TYPE1_INFO_DMA_AVAIL, and this is still being advertised as 65535 when using iommufd. I don't think there is a defined way to return 'ignore this value'. This should go away later when we bind to iommufd directly since QEMU would not be sharing the type1 codepath in userspace. > >> Was this because you envision the limit being not applicable for >> iommufd (limits will be enforced via either means and eventually we >> won't want to ) or was it an oversight? > > The limit here is primarily about limiting userspace abuse of the > interface. > > iommufd is using GFP_KERNEL_ACCOUNT which shifts the responsiblity to > cgroups, which is similar to how KVM works. > > So, for a VM sandbox you'd set a cgroup limit and if a hostile > userspace in the sanbox decides to try to OOM the system it will hit > that limit, regardless of which kernel APIs it tries to abuse. > > This work is not entirely complete as we also need the iommu driver to > use GFP_KERNEL_ACCOUNT for allocations connected to the iommu_domain, > particularly for allocations of the IO page tables themselves - which > can be quite big. > > Jason
Re: [Intel-gfx] [PATCH v2 11/11] iommufd: Allow iommufd to supply /dev/vfio/vfio
On Fri, Nov 11, 2022 at 12:16:02PM +0800, Yi Liu wrote:
> > +#if IS_ENABLED(CONFIG_IOMMUFD_VFIO_CONTAINER)
> > +MODULE_ALIAS_MISCDEV(VFIO_MINOR);
> > +MODULE_ALIAS("devname:vfio/vfio");
>
> will this line also result in systemd to create this devnodes at boot
> based on the module info even if the IOMMUFD_VFIO_CONTAINER is not
> configured?
No, it is contained by an ifdef.
The MODULE_ALIAS mechanism works by inspecting the compiled object
files for special ELF sections, if the code is discarded by the
preprocessor then the sections will not be created by the compiler.
Jason
Re: [Intel-gfx] [PATCH v2 07/11] vfio-iommufd: Support iommufd for physical VFIO devices
On Fri, Nov 11, 2022 at 12:12:36PM +0800, Yi Liu wrote:
> > +int vfio_iommufd_bind(struct vfio_device *vdev, struct iommufd_ctx *ictx)
> > +{
> > + u32 ioas_id;
> > + u32 device_id;
> > + int ret;
> > +
> > + lockdep_assert_held(>dev_set->lock);
> > +
> > + /*
> > +* If the driver doesn't provide this op then it means the device does
> > +* not do DMA at all. So nothing to do.
> > +*/
> > + if (!vdev->ops->bind_iommufd)
> > + return 0;
> > +
> > + ret = vdev->ops->bind_iommufd(vdev, ictx, _id);
> > + if (ret)
> > + return ret;
> > +
> > + ret = iommufd_vfio_compat_ioas_id(ictx, _id);
> > + if (ret)
> > + goto err_unbind;
> > + ret = vdev->ops->attach_ioas(vdev, _id);
> > + if (ret)
> > + goto err_unbind;
> > + vdev->iommufd_attached = true;
>
> it's better to set this bool in vfio_iommufd_physical_attach_ioas() as
> the emulated devices uses iommufd_access instead. is it? or you mean this
> flag to cover both cases?
Yes, that is probably clearer:
@@ -50,7 +50,6 @@ int vfio_iommufd_bind(struct vfio_device *vdev, struct
iommufd_ctx *ictx)
ret = vdev->ops->attach_ioas(vdev, _id);
if (ret)
goto err_unbind;
- vdev->iommufd_attached = true;
/*
* The legacy path has no way to return the device id or the selected
@@ -110,10 +109,15 @@ EXPORT_SYMBOL_GPL(vfio_iommufd_physical_unbind);
int vfio_iommufd_physical_attach_ioas(struct vfio_device *vdev, u32 *pt_id)
{
unsigned int flags = 0;
+ int rc;
if (vfio_allow_unsafe_interrupts)
flags |= IOMMUFD_ATTACH_FLAGS_ALLOW_UNSAFE_INTERRUPT;
- return iommufd_device_attach(vdev->iommufd_device, pt_id, flags);
+ rc = iommufd_device_attach(vdev->iommufd_device, pt_id, flags);
+ if (rc)
+ return rc;
+ vdev->iommufd_attached = true;
+ return 0;
}
EXPORT_SYMBOL_GPL(vfio_iommufd_physical_attach_ioas);
Thanks,
Jason
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/edid/firmware: stop using a throwaway platform device
== Series Details ==
Series: drm/edid/firmware: stop using a throwaway platform device
URL : https://patchwork.freedesktop.org/series/110859/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12376 -> Patchwork_110859v1
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_110859v1 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_110859v1, 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_110859v1/index.html
Participating hosts (37 -> 37)
--
Additional (2): bat-kbl-2 fi-bsw-nick
Missing(2): fi-bdw-samus bat-dg1-5
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_110859v1:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@mman:
- fi-rkl-guc: [PASS][1] -> [TIMEOUT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/fi-rkl-guc/igt@i915_selftest@l...@mman.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-rkl-guc/igt@i915_selftest@l...@mman.html
Known issues
Here are the changes found in Patchwork_110859v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_lmem_swapping@basic:
- fi-apl-guc: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#4613]) +3
similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-apl-guc/igt@gem_lmem_swapp...@basic.html
* igt@gem_lmem_swapping@parallel-random-engines:
- fi-bsw-nick:NOTRUN -> [SKIP][4] ([fdo#109271]) +38 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-bsw-nick/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- bat-adlp-4: [PASS][5] -> [DMESG-WARN][6] ([i915#7077])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/bat-adlp-4/igt@i915_pm_...@basic-pci-d3-state.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/bat-adlp-4/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-rkl-11600: NOTRUN -> [SKIP][7] ([fdo#111827])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-rkl-11600/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_chamelium@hdmi-crc-fast:
- fi-apl-guc: NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827]) +8
similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-apl-guc/igt@kms_chamel...@hdmi-crc-fast.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-bsw-nick:NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827]) +8
similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-bsw-nick/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_force_connector_basic@force-connector-state:
- fi-apl-guc: NOTRUN -> [SKIP][10] ([fdo#109271]) +11 similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-apl-guc/igt@kms_force_connector_ba...@force-connector-state.html
Possible fixes
* igt@gem_render_tiled_blits@basic:
- fi-apl-guc: [INCOMPLETE][11] ([i915#7056]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/fi-apl-guc/igt@gem_render_tiled_bl...@basic.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-apl-guc/igt@gem_render_tiled_bl...@basic.html
* igt@i915_selftest@live@migrate:
- {bat-adlp-6}: [INCOMPLETE][13] ([i915#7348]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/bat-adlp-6/igt@i915_selftest@l...@migrate.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/bat-adlp-6/igt@i915_selftest@l...@migrate.html
* igt@i915_selftest@live@slpc:
- {bat-adln-1}: [DMESG-FAIL][15] ([i915#6997]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/bat-adln-1/igt@i915_selftest@l...@slpc.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/bat-adln-1/igt@i915_selftest@l...@slpc.html
* igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600: [INCOMPLETE][17] ([i915#4817]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12376/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110859v1/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]:
Re: [Intel-gfx] [PATCH v2 00/11] Connect VFIO to IOMMUFD
On 2022/11/14 22:38, Jason Gunthorpe wrote: On Mon, Nov 14, 2022 at 08:51:58PM +0800, Yi Liu wrote: Our side, Yu He, Lixiao Yang has done below tests on Intel platform with the above kernel, results are: 1) GVT-g test suit passed, Intel iGFx passthrough passed. 2) NIC passthrough test with different guest memory (1G/4G), passed. 3) Booting two different QEMUs in the same time but one QEMU opens legacy /dev/vfio/vfio and another opens /dev/iommu. Tests passed. 4) Tried below Kconfig combinations, results are expected. VFIO_CONTAINER=y, IOMMUFD=y -- test pass VFIO_CONTAINER=y, IOMMUFD=n -- test pass VFIO_CONTAINER=n, IOMMUFD=y , IOMMUFD_VFIO_CONTAINER=y -- test pass VFIO_CONTAINER=n, IOMMUFD=y , IOMMUFD_VFIO_CONTAINER=n -- no /dev/vfio/vfio, so test fail, expected 5) Tested devices from multi-device group. Assign such devices to the same VM, pass; assign them to different VMs, fail; assign them to a VM with Intel virtual VT-d, fail; Results are expected. Meanwhile, I also tested the branch in development branch for nesting, the basic functionality looks good. Tested-by: Yi Liu Great thanks! you are welcome. this is a team work. :) In future I also recommend running tests with the CONFIG_IOMMUFD_TEST turned on, it enables a bunch more fast path assertions that might catch something interesting oh, sure. will try. -- Regards, Yi Liu
Re: [Intel-gfx] [PATCH v2 00/11] Connect VFIO to IOMMUFD
On Mon, Nov 14, 2022 at 08:51:58PM +0800, Yi Liu wrote: > Our side, Yu He, Lixiao Yang has done below tests on Intel platform with > the above kernel, results are: > > 1) GVT-g test suit passed, Intel iGFx passthrough passed. > > 2) NIC passthrough test with different guest memory (1G/4G), passed. > > 3) Booting two different QEMUs in the same time but one QEMU opens > legacy /dev/vfio/vfio and another opens /dev/iommu. Tests passed. > > 4) Tried below Kconfig combinations, results are expected. > > VFIO_CONTAINER=y, IOMMUFD=y -- test pass > VFIO_CONTAINER=y, IOMMUFD=n -- test pass > VFIO_CONTAINER=n, IOMMUFD=y , IOMMUFD_VFIO_CONTAINER=y -- test pass > VFIO_CONTAINER=n, IOMMUFD=y , IOMMUFD_VFIO_CONTAINER=n -- no > /dev/vfio/vfio, so test fail, expected > > 5) Tested devices from multi-device group. Assign such devices to the same > VM, pass; assign them to different VMs, fail; assign them to a VM with Intel > virtual VT-d, fail; Results are expected. > > Meanwhile, I also tested the branch in development branch for nesting, > the basic functionality looks good. > > Tested-by: Yi Liu Great thanks! In future I also recommend running tests with the CONFIG_IOMMUFD_TEST turned on, it enables a bunch more fast path assertions that might catch something interesting Jason
Re: [Intel-gfx] [PATCH v2 00/11] Connect VFIO to IOMMUFD
On 2022/11/14 20:51, Yi Liu wrote: > On 2022/11/10 00:57, Jason Gunthorpe wrote: >> On Tue, Nov 08, 2022 at 11:18:03PM +0800, Yi Liu wrote: >>> On 2022/11/8 17:19, Nicolin Chen wrote: On Mon, Nov 07, 2022 at 08:52:44PM -0400, Jason Gunthorpe wrote: > This is on github: > https://github.com/jgunthorpe/linux/commits/vfio_iommufd [...] > v2: >- Rebase to v6.1-rc3, v4 iommufd series >- Fixup comments and commit messages from list remarks >- Fix leaking of the iommufd for mdevs >- New patch to fix vfio modaliases when vfio container is disabled >- Add a dmesg once when the iommufd provided /dev/vfio/vfio is opened > to signal that iommufd is providing this I've redone my previous sanity tests. Except those reported bugs, things look fine. Once we fix those issues, GVT and other modules can run some more stressful tests, I think. >>> >>> our side is also starting test (gvt, nic passthrough) this version. >>> need to wait a while for the result. >> >> I've updated the branches with the two functional fixes discussed on >> the list plus all the doc updates. >> > > I see, due to timzone, the kernel we grabbed is 37c9e6e44d77a, it has > slight diff in the scripts/kernel-doc compared with the latest commit > (6bb16a9c67769). I don't think it impacts the test. > > https://git.kernel.org/pub/scm/linux/kernel/git/jgg/iommufd.git/log/?h=for-next > (37c9e6e44d77a) > > Our side, Yu He, Lixiao Yang has done below tests on Intel platform > with the above kernel, results are: > > 1) GVT-g test suit passed, Intel iGFx passthrough passed. > > 2) NIC passthrough test with different guest memory (1G/4G), passed. > > 3) Booting two different QEMUs in the same time but one QEMU opens > legacy /dev/vfio/vfio and another opens /dev/iommu. Tests passed. > > 4) Tried below Kconfig combinations, results are expected. > > VFIO_CONTAINER=y, IOMMUFD=y -- test pass > VFIO_CONTAINER=y, IOMMUFD=n -- test pass > VFIO_CONTAINER=n, IOMMUFD=y , IOMMUFD_VFIO_CONTAINER=y -- test pass > VFIO_CONTAINER=n, IOMMUFD=y , IOMMUFD_VFIO_CONTAINER=n -- no > /dev/vfio/vfio, so test fail, expected > > 5) Tested devices from multi-device group. Assign such devices to the > same VM, pass; assign them to different VMs, fail; assign them to a VM > with Intel virtual VT-d, fail; Results are expected. > > Meanwhile, I also tested the branch in development branch for nesting, > the basic functionality looks good. > > Tested-by: Yi Liu > Tested-by: Lixiao Yang -- Regards, Lixiao Yang
Re: [Intel-gfx] [PATCH v2 00/11] Connect VFIO to IOMMUFD
On Thu, Nov 10, 2022 at 10:01:13PM -0500, Matthew Rosato wrote: > On 11/7/22 7:52 PM, Jason Gunthorpe wrote: > > This series provides an alternative container layer for VFIO implemented > > using iommufd. This is optional, if CONFIG_IOMMUFD is not set then it will > > not be compiled in. > > > > At this point iommufd can be injected by passing in a iommfd FD to > > VFIO_GROUP_SET_CONTAINER which will use the VFIO compat layer in iommufd > > to obtain the compat IOAS and then connect up all the VFIO drivers as > > appropriate. > > > > This is temporary stopping point, a following series will provide a way to > > directly open a VFIO device FD and directly connect it to IOMMUFD using > > native ioctls that can expose the IOMMUFD features like hwpt, future > > vPASID and dynamic attachment. > > > > This series, in compat mode, has passed all the qemu tests we have > > available, including the test suites for the Intel GVT mdev. Aside from > > the temporary limitation with P2P memory this is belived to be fully > > compatible with VFIO. > > AFAICT there is no equivalent means to specify > vfio_iommu_type1.dma_entry_limit when using iommufd; looks like > we'll just always get the default 65535. No, there is no arbitary limit on iommufd > Was this because you envision the limit being not applicable for > iommufd (limits will be enforced via either means and eventually we > won't want to ) or was it an oversight? The limit here is primarily about limiting userspace abuse of the interface. iommufd is using GFP_KERNEL_ACCOUNT which shifts the responsiblity to cgroups, which is similar to how KVM works. So, for a VM sandbox you'd set a cgroup limit and if a hostile userspace in the sanbox decides to try to OOM the system it will hit that limit, regardless of which kernel APIs it tries to abuse. This work is not entirely complete as we also need the iommu driver to use GFP_KERNEL_ACCOUNT for allocations connected to the iommu_domain, particularly for allocations of the IO page tables themselves - which can be quite big. Jason
