[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gem: Remove stolen node before releasing the region
== Series Details ==
Series: drm/i915/gem: Remove stolen node before releasing the region
URL : https://patchwork.freedesktop.org/series/85727/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9585_full -> Patchwork_19320_full
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_19320_full need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_19320_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_19320_full:
### IGT changes ###
Warnings
* igt@i915_pm_dc@dc3co-vpb-simulation:
- shard-iclb: [SKIP][1] ([i915#588]) -> [SKIP][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9585/shard-iclb2/igt@i915_pm...@dc3co-vpb-simulation.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19320/shard-iclb3/igt@i915_pm...@dc3co-vpb-simulation.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@gem_exec_schedule@u-fairslice@vcs0}:
- shard-skl: [PASS][3] -> [FAIL][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9585/shard-skl9/igt@gem_exec_schedule@u-fairsl...@vcs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19320/shard-skl5/igt@gem_exec_schedule@u-fairsl...@vcs0.html
* {igt@gem_exec_schedule@u-fairslice@vecs0}:
- shard-skl: [DMESG-WARN][5] ([i915#1610] / [i915#2803]) ->
[FAIL][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9585/shard-skl9/igt@gem_exec_schedule@u-fairsl...@vecs0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19320/shard-skl5/igt@gem_exec_schedule@u-fairsl...@vecs0.html
* {igt@gem_softpin@32b-excludes-last-page}:
- shard-glk: [PASS][7] -> [FAIL][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9585/shard-glk7/igt@gem_soft...@32b-excludes-last-page.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19320/shard-glk2/igt@gem_soft...@32b-excludes-last-page.html
Known issues
Here are the changes found in Patchwork_19320_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@api_intel_bb@render-ccs:
- shard-apl: [PASS][9] -> [INCOMPLETE][10] ([i915#2405] /
[i915#2499])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9585/shard-apl3/igt@api_intel...@render-ccs.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19320/shard-apl2/igt@api_intel...@render-ccs.html
* igt@gem_ctx_persistence@legacy-engines-mixed-process:
- shard-hsw: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#1099]) +2
similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19320/shard-hsw8/igt@gem_ctx_persiste...@legacy-engines-mixed-process.html
* igt@gem_exec_reloc@basic-many-active@vcs0:
- shard-hsw: NOTRUN -> [FAIL][12] ([i915#2389]) +3 similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19320/shard-hsw8/igt@gem_exec_reloc@basic-many-act...@vcs0.html
* igt@gem_exec_reloc@basic-many-active@vcs1:
- shard-iclb: NOTRUN -> [FAIL][13] ([i915#2389])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19320/shard-iclb4/igt@gem_exec_reloc@basic-many-act...@vcs1.html
* igt@gem_mmap_gtt@pf-nonblock:
- shard-skl: [PASS][14] -> [DMESG-WARN][15] ([i915#1982])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9585/shard-skl8/igt@gem_mmap_...@pf-nonblock.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19320/shard-skl9/igt@gem_mmap_...@pf-nonblock.html
* igt@gem_pwrite@basic-exhaustion:
- shard-skl: NOTRUN -> [WARN][16] ([i915#2658])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19320/shard-skl10/igt@gem_pwr...@basic-exhaustion.html
* igt@gem_workarounds@suspend-resume-fd:
- shard-skl: [PASS][17] -> [INCOMPLETE][18] ([i915#146] /
[i915#198] / [i915#2405])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9585/shard-skl1/igt@gem_workarou...@suspend-resume-fd.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19320/shard-skl1/igt@gem_workarou...@suspend-resume-fd.html
* igt@i915_pm_dc@dc6-psr:
- shard-iclb: [PASS][19] -> [FAIL][20] ([i915#454])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9585/shard-iclb1/igt@i915_pm...@dc6-psr.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19320/shard-iclb6/igt@i915_pm...@dc6-psr.html
* igt@kms_big_joiner@basic:
- shard-skl: NOTRUN -> [SKIP][21] ([fdo#109271] / [i915#2705])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Allow huge_gem_object to kick the shrinker
== Series Details == Series: drm/i915/selftests: Allow huge_gem_object to kick the shrinker URL : https://patchwork.freedesktop.org/series/85729/ State : success == Summary == CI Bug Log - changes from CI_DRM_9586 -> Patchwork_19321 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19321/index.html Known issues Here are the changes found in Patchwork_19321 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@semaphore: - fi-bsw-nick:NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19321/fi-bsw-nick/igt@amdgpu/amd_ba...@semaphore.html * igt@amdgpu/amd_cs_nop@fork-gfx0: - fi-tgl-y: NOTRUN -> [SKIP][2] ([fdo#109315] / [i915#2575]) +16 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19321/fi-tgl-y/igt@amdgpu/amd_cs_...@fork-gfx0.html * igt@amdgpu/amd_cs_nop@sync-gfx0: - fi-bsw-n3050: NOTRUN -> [SKIP][3] ([fdo#109271]) +17 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19321/fi-bsw-n3050/igt@amdgpu/amd_cs_...@sync-gfx0.html * igt@gem_exec_suspend@basic-s3: - fi-tgl-u2: [PASS][4] -> [FAIL][5] ([i915#1888]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9586/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19321/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html * igt@i915_selftest@live@gem: - fi-kbl-soraka: [PASS][6] -> [DMESG-FAIL][7] ([i915#2927]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9586/fi-kbl-soraka/igt@i915_selftest@l...@gem.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19321/fi-kbl-soraka/igt@i915_selftest@l...@gem.html * igt@i915_selftest@live@gt_lrc: - fi-tgl-y: NOTRUN -> [DMESG-FAIL][8] ([i915#2373]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19321/fi-tgl-y/igt@i915_selftest@live@gt_lrc.html * igt@i915_selftest@live@gt_pm: - fi-tgl-y: NOTRUN -> [DMESG-FAIL][9] ([i915#1759]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19321/fi-tgl-y/igt@i915_selftest@live@gt_pm.html * igt@i915_selftest@live@reset: - fi-kbl-soraka: [PASS][10] -> [SKIP][11] ([fdo#109271]) +12 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9586/fi-kbl-soraka/igt@i915_selftest@l...@reset.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19321/fi-kbl-soraka/igt@i915_selftest@l...@reset.html * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy: - fi-snb-2600:NOTRUN -> [SKIP][12] ([fdo#109271]) +30 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19321/fi-snb-2600/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html * igt@kms_chamelium@hdmi-crc-fast: - fi-snb-2600:NOTRUN -> [SKIP][13] ([fdo#109271] / [fdo#111827]) +8 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19321/fi-snb-2600/igt@kms_chamel...@hdmi-crc-fast.html * igt@kms_chamelium@vga-edid-read: - fi-tgl-y: NOTRUN -> [SKIP][14] ([fdo#111827]) +8 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19321/fi-tgl-y/igt@kms_chamel...@vga-edid-read.html * igt@kms_force_connector_basic@force-load-detect: - fi-tgl-y: NOTRUN -> [SKIP][15] ([fdo#109285]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19321/fi-tgl-y/igt@kms_force_connector_ba...@force-load-detect.html * igt@prime_self_import@basic-with_one_bo_two_files: - fi-tgl-y: NOTRUN -> [DMESG-WARN][16] ([i915#402]) +2 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19321/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html * igt@runner@aborted: - fi-kbl-soraka: NOTRUN -> [FAIL][17] ([i915#1436] / [i915#2295]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19321/fi-kbl-soraka/igt@run...@aborted.html Possible fixes * igt@gem_exec_suspend@basic-s3: - fi-snb-2600:[DMESG-WARN][18] ([i915#2772]) -> [PASS][19] [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9586/fi-snb-2600/igt@gem_exec_susp...@basic-s3.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19321/fi-snb-2600/igt@gem_exec_susp...@basic-s3.html * igt@i915_selftest@live@gem: - fi-bsw-nick:[DMESG-FAIL][20] -> [PASS][21] [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9586/fi-bsw-nick/igt@i915_selftest@l...@gem.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19321/fi-bsw-nick/igt@i915_selftest@l...@gem.html * igt@i915_selftest@live@gt_lrc: - fi-bsw-n3050: [DMESG-FAIL][22] ([i915#2675]) -> [PASS][23] [22]: https://intel-gfx-ci.01.org/tree/drm-tip/C
Re: [Intel-gfx] [PATCH v9 14/19] drm/i915/hdcp: MST streams support in hdcp port_data
On Mon, 2021-01-11 at 13:41 +0530, Anshuman Gupta wrote:
> Add support for multiple mst stream in hdcp port data
> which will be used by RepeaterAuthStreamManage msg and
> HDCP 2.2 security f/w for m' validation.
>
> Security f/w doesn't have any provision to mark the stream_type
> for each stream separately, it just take single input of
> stream_type while authenticating the port and applies the
> same stream_type to all streams. So driver mark each stream_type
> with common highest supported content type for all streams
> in DP MST Topology.
>
> Security f/w supports RepeaterAuthStreamManage msg and m'
> validation only once during port authentication and encryption.
> Though it is not compulsory, security fw should support dynamic
> update of content_type and should support RepeaterAuthStreamManage
> msg and m' validation whenever required.
>
> v2:
> - Init the hdcp port data k for HDMI/DP SST stream.
> v3:
> - Cosmetic changes. [Uma]
> v4:
> - 's/port_auth/hdcp_port_auth'. [Ram]
> - Commit log improvement.
> v5:
> - Comment and commit log improvement. [Ram]
> v6:
> - Check first connector connected status before intel_encoder_is_mst
> to avoid any NULL pointer dereference.
>
> Cc: Ramalingam C
> Reviewed-by: Uma Shankar
> Reviewed-by: Ramalingam C
> Tested-by: Karthik B S
> Signed-off-by: Anshuman Gupta
> ---
> .../drm/i915/display/intel_display_types.h | 4 +-
> drivers/gpu/drm/i915/display/intel_hdcp.c | 113 +++-
> --
> 2 files changed, 102 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index b74c10c8b01c..b37a02a73de6 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1502,10 +1502,12 @@ struct intel_digital_port {
> enum phy_fia tc_phy_fia;
> u8 tc_phy_fia_idx;
>
> - /* protects num_hdcp_streams reference count, hdcp_port_data
> */
> + /* protects num_hdcp_streams reference count, hdcp_port_data
> and hdcp_auth_status */
> struct mutex hdcp_mutex;
> /* the number of pipes using HDCP signalling out of this port
> */
> unsigned int num_hdcp_streams;
> + /* port HDCP auth status */
> + bool hdcp_auth_status;
> /* HDCP port data need to pass to security f/w */
> struct hdcp_port_data hdcp_port_data;
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_hdcp.c
> index 2bec26123a05..bd87694def74 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> @@ -26,6 +26,74 @@
> #define KEY_LOAD_TRIES 5
> #define HDCP2_LC_RETRY_CNT 3
>
> +static int intel_conn_to_vcpi(struct intel_connector *connector)
> +{
> + /* For HDMI this is forced to be 0x0. For DP SST also this is
> 0x0. */
> + return connector->port ? connector->port->vcpi.vcpi : 0;
> +}
> +
> +/*
> + * intel_hdcp_required_content_stream selects the most highest
> common possible HDCP
> + * content_type for all streams in DP MST topology because security
> f/w doesn't
> + * have any provision to mark content_type for each stream
> separately, it marks
> + * all available streams with the content_type proivided at the time
> of port
> + * authentication. This may prohibit the userspace to use type1
> content on
> + * HDCP 2.2 capable sink because of other sink are not capable of
> HDCP 2.2 in
> + * DP MST topology. Though it is not compulsory, security fw should
> change its
> + * policy to mark different content_types for different streams.
> + */
> +static int
> +intel_hdcp_required_content_stream(struct intel_digital_port
> *dig_port)
> +{
> + struct drm_connector_list_iter conn_iter;
> + struct intel_digital_port *conn_dig_port;
> + struct intel_connector *connector;
> + struct drm_i915_private *i915 = to_i915(dig_port-
> >base.base.dev);
> + struct hdcp_port_data *data = &dig_port->hdcp_port_data;
> + bool enforce_type0 = false;
> + int k;
> +
> + if (dig_port->hdcp_auth_status)
> + return 0;
> +
> + drm_connector_list_iter_begin(&i915->drm, &conn_iter);
> + for_each_intel_connector_iter(connector, &conn_iter) {
> + if (connector->base.status ==
> connector_status_disconnected)
> + continue;
> +
> + if
> (!intel_encoder_is_mst(intel_attached_encoder(connector)))
> + continue;
> +
> + conn_dig_port = intel_attached_dig_port(connector);
> + if (conn_dig_port != dig_port)
> + continue;
> +
> + if (!enforce_type0 &&
> !intel_hdcp2_capable(connector))
> + enforce_type0 = true;
> +
> + data->streams[data->k].stream_id =
> intel_conn_to_vcpi(connector);
> + data->k++;
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Only enable DFP 4:4:4->4:2:0 conversion when outputting YCbCr 4:4:4 (rev2)
== Series Details ==
Series: drm/i915: Only enable DFP 4:4:4->4:2:0 conversion when outputting YCbCr
4:4:4 (rev2)
URL : https://patchwork.freedesktop.org/series/85715/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9585_full -> Patchwork_19319_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_19319_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_19319_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_19319_full:
### IGT changes ###
Possible regressions
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-draw-render:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9585/shard-tglb3/igt@kms_frontbuffer_track...@psr-1p-primscrn-cur-indfb-draw-render.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19319/shard-tglb6/igt@kms_frontbuffer_track...@psr-1p-primscrn-cur-indfb-draw-render.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@gem_exec_schedule@u-fairslice@vecs0}:
- shard-skl: [DMESG-WARN][3] ([i915#1610] / [i915#2803]) ->
[FAIL][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9585/shard-skl9/igt@gem_exec_schedule@u-fairsl...@vecs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19319/shard-skl2/igt@gem_exec_schedule@u-fairsl...@vecs0.html
* {igt@gem_softpin@32b-excludes-last-page}:
- shard-glk: [PASS][5] -> [FAIL][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9585/shard-glk7/igt@gem_soft...@32b-excludes-last-page.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19319/shard-glk8/igt@gem_soft...@32b-excludes-last-page.html
Known issues
Here are the changes found in Patchwork_19319_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@drm_mm@all@replace:
- shard-skl: [PASS][7] -> [INCOMPLETE][8] ([i915#2485] /
[i915#2813])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9585/shard-skl7/igt@drm_mm@a...@replace.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19319/shard-skl3/igt@drm_mm@a...@replace.html
* igt@gem_exec_reloc@basic-many-active@vcs1:
- shard-iclb: NOTRUN -> [FAIL][9] ([i915#2389])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19319/shard-iclb1/igt@gem_exec_reloc@basic-many-act...@vcs1.html
* igt@gem_pwrite@basic-exhaustion:
- shard-skl: NOTRUN -> [WARN][10] ([i915#2658])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19319/shard-skl8/igt@gem_pwr...@basic-exhaustion.html
* igt@kms_async_flips@alternate-sync-async-flip:
- shard-skl: [PASS][11] -> [FAIL][12] ([i915#2521])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9585/shard-skl4/igt@kms_async_fl...@alternate-sync-async-flip.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19319/shard-skl6/igt@kms_async_fl...@alternate-sync-async-flip.html
* igt@kms_big_joiner@basic:
- shard-skl: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#2705])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19319/shard-skl8/igt@kms_big_joi...@basic.html
* igt@kms_color@pipe-b-ctm-0-75:
- shard-skl: [PASS][14] -> [DMESG-WARN][15] ([i915#1982])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9585/shard-skl1/igt@kms_co...@pipe-b-ctm-0-75.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19319/shard-skl5/igt@kms_co...@pipe-b-ctm-0-75.html
* igt@kms_color@pipe-d-ctm-0-5:
- shard-skl: NOTRUN -> [SKIP][16] ([fdo#109271]) +87 similar issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19319/shard-skl8/igt@kms_co...@pipe-d-ctm-0-5.html
* igt@kms_color_chamelium@pipe-b-ctm-limited-range:
- shard-skl: NOTRUN -> [SKIP][17] ([fdo#109271] / [fdo#111827]) +6
similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19319/shard-skl3/igt@kms_color_chamel...@pipe-b-ctm-limited-range.html
* igt@kms_color_chamelium@pipe-c-gamma:
- shard-apl: NOTRUN -> [SKIP][18] ([fdo#109271] / [fdo#111827]) +1
similar issue
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19319/shard-apl6/igt@kms_color_chamel...@pipe-c-gamma.html
* igt@kms_content_protection@atomic-dpms:
- shard-apl: NOTRUN -> [TIMEOUT][19] ([i915#1319])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19319/shard-apl6/igt@kms_content_protect...@atomic-dpms.html
* igt@k
Re: [Intel-gfx] [PATCH 11/22] drm/i915/adl_s: Add adl-s ddc pin mapping
On Fri, Dec 04, 2020 at 05:08:33PM -0800, Aditya Swarup wrote:
> ADL-S requires TC pins to set up ddc for Combo PHY B, C, D and E.
> Combo PHY A still uses the old ddc pin mapping.
>
> From VBT, ddc pin info suggests the following mapping:
> VBT DRIVER
> DDI B->ddc_pin=2 should translate to PORT_D->0x9
> DDI C->ddc_pin=3 should translate to PORT_E->0xa
> DDI D->ddc_pin=4 should translate to PORT_F->0xb
> DDI E->ddc_pin=5 should translate to PORT_G->0xc
>
> Adding pin map to facilitate this translation as we cannot use existing
> icl ddc pin map due to conflict with DDI B and DDI C info.
>
> Bspec:20124
>
> v2: Replace IS_ALDERLAKE_S() with HAS_PCH_ADP() as the pin map pairing
> depends on the PCH being used rather than the platform.(mdroper)
>
> Cc: Jani Nikula
> Cc: Ville Syrjälä
> Cc: Imre Deak
> Cc: Matt Roper
> Cc: Lucas De Marchi
> Signed-off-by: Aditya Swarup
> ---
> drivers/gpu/drm/i915/display/intel_bios.c | 13 +++-
> drivers/gpu/drm/i915/display/intel_hdmi.c | 20 ++-
> drivers/gpu/drm/i915/display/intel_vbt_defs.h | 4
> 3 files changed, 35 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index 4cc949b228f2..9dc67c03ffc0 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -1623,12 +1623,23 @@ static const u8 icp_ddc_pin_map[] = {
> [TGL_DDC_BUS_PORT_6] = GMBUS_PIN_14_TC6_TGP,
> };
>
> +static const u8 adls_ddc_pin_map[] = {
> + [ICL_DDC_BUS_DDI_A] = GMBUS_PIN_1_BXT,
> + [ADLS_DDC_BUS_PORT_TC1] = GMBUS_PIN_9_TC1_ICP,
> + [ADLS_DDC_BUS_PORT_TC2] = GMBUS_PIN_10_TC2_ICP,
> + [ADLS_DDC_BUS_PORT_TC3] = GMBUS_PIN_11_TC3_ICP,
> + [ADLS_DDC_BUS_PORT_TC4] = GMBUS_PIN_12_TC4_ICP,
> +};
Can't we use icp_ddc_pin_map[] since it's a superset of this? The ICP
table has some extra entries that we'll never map through, but that's
true for other platforms as well. E.g., ICP itself can never have a
DDI_C or TC5/TC6, but it doesn't hurt anything to have those outputs as
extra entries in the table that never get looked up.
> +
> static u8 map_ddc_pin(struct drm_i915_private *dev_priv, u8 vbt_pin)
> {
> const u8 *ddc_pin_map;
> int n_entries;
>
> - if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG1) {
> + if (HAS_PCH_ADP(dev_priv)) {
> + ddc_pin_map = adls_ddc_pin_map;
> + n_entries = ARRAY_SIZE(adls_ddc_pin_map);
> + } else if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG1) {
> return vbt_pin;
> } else if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP) {
> ddc_pin_map = icp_ddc_pin_map;
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
> b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index e10fdb369daa..060a13b63aa9 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -3135,6 +3135,22 @@ static u8 dg1_port_to_ddc_pin(struct drm_i915_private
> *dev_priv, enum port port)
> return intel_port_to_phy(dev_priv, port) + 1;
> }
>
> +static u8 adls_port_to_ddc_pin(struct drm_i915_private *dev_priv, enum port
> port)
> +{
> + enum phy phy = intel_port_to_phy(dev_priv, port);
> +
> + WARN_ON(port == PORT_B || port == PORT_C);
> +
> + /*
> + * Pin mapping for ADL-S requires TC pins for all combo phy outputs
> + * except first combo output.
> + */
> + if (IS_ALDERLAKE_S(dev_priv) && phy >= PHY_B)
The IS_ADLS test here is redundant since we only call this function on
ADL-S, right?
> + return GMBUS_PIN_9_TC1_ICP + phy - PHY_B;
> +
> + return GMBUS_PIN_1_BXT + phy;
There's only one possible output that can get to this return
(PORT_A/PHY_A), so the generic "+ phy" seems unnecessary.
Actually it might more more sensible to make PHY_A the special case we
test for in the 'if' condition and then make the PHY_B+ case the
function's regular return.
> +}
> +
> static u8 g4x_port_to_ddc_pin(struct drm_i915_private *dev_priv,
> enum port port)
> {
> @@ -3172,7 +3188,9 @@ static u8 intel_hdmi_ddc_pin(struct intel_encoder
> *encoder)
> return ddc_pin;
> }
>
> - if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG1)
> + if (IS_ALDERLAKE_S(dev_priv))
This should probably be a PCH check instead of a platform check too.
Matt
> + ddc_pin = adls_port_to_ddc_pin(dev_priv, port);
> + else if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG1)
> ddc_pin = dg1_port_to_ddc_pin(dev_priv, port);
> else if (IS_ROCKETLAKE(dev_priv))
> ddc_pin = rkl_port_to_ddc_pin(dev_priv, port);
> diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> index 49b4b5fca941..32d1b4f05760 100644
> --- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> +++ b/drivers/gpu/drm/i915/display/intel_vbt_
Re: [Intel-gfx] [PATCH 12/22] drm/i915/adl_s: Add vbt port and aux channel settings for adls
On Fri, Dec 04, 2020 at 05:08:34PM -0800, Aditya Swarup wrote:
> - ADL-S driver internal mapping uses PORT D, E, F, G for Combo phy B, C, D
> and E.
> - Add ADLS specific port mappings for vbt port dvo settings.
> - Select appropriate AUX CH specific to ADLS based on port mapping.
The aux stuff is getting really messy; we're definitely going to have to
move to a table-based approach for some of this stuff soon to keep it
from getting too out of hand.
The changes here look correct for the current style though.
Reviewed-by: Matt Roper
>
> Cc: Jani Nikula
> Cc: Ville Syrjälä
> Cc: Imre Deak
> Cc: Matt Roper
> Cc: Lucas De Marchi
> Signed-off-by: Aditya Swarup
> ---
> drivers/gpu/drm/i915/display/intel_bios.c | 57 ++-
> 1 file changed, 46 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index 9dc67c03ffc0..8f166f49b6cc 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -1709,8 +1709,26 @@ static enum port dvo_port_to_port(struct
> drm_i915_private *dev_priv,
> [PORT_TC1] = { DVO_PORT_HDMIC, DVO_PORT_DPC, -1 },
> [PORT_TC2] = { DVO_PORT_HDMID, DVO_PORT_DPD, -1 },
> };
> + /*
> + * Alderlake S ports used in the driver are PORT_A, PORT_D, PORT_E,
> + * PORT_F and PORT_G, we need to map that to correct VBT sections.
> + */
> + static const int adls_port_mapping[][3] = {
> + [PORT_A] = { DVO_PORT_HDMIA, DVO_PORT_DPA, -1 },
> + [PORT_B] = { -1 },
> + [PORT_C] = { -1 },
> + [PORT_TC1] = { DVO_PORT_HDMIB, DVO_PORT_DPB, -1 },
> + [PORT_TC2] = { DVO_PORT_HDMIC, DVO_PORT_DPC, -1 },
> + [PORT_TC3] = { DVO_PORT_HDMID, DVO_PORT_DPD, -1 },
> + [PORT_TC4] = { DVO_PORT_HDMIE, DVO_PORT_DPE, -1 },
> + };
>
> - if (IS_DG1(dev_priv) || IS_ROCKETLAKE(dev_priv))
> + if (IS_ALDERLAKE_S(dev_priv))
> + return __dvo_port_to_port(ARRAY_SIZE(adls_port_mapping),
> + ARRAY_SIZE(adls_port_mapping[0]),
> + adls_port_mapping,
> + dvo_port);
> + else if (IS_DG1(dev_priv) || IS_ROCKETLAKE(dev_priv))
> return __dvo_port_to_port(ARRAY_SIZE(rkl_port_mapping),
> ARRAY_SIZE(rkl_port_mapping[0]),
> rkl_port_mapping,
> @@ -2667,27 +2685,44 @@ enum aux_ch intel_bios_port_aux_ch(struct
> drm_i915_private *dev_priv,
> return aux_ch;
> }
>
> + /*
> + * RKL/DG1 VBT uses PHY based mapping. Combo PHYs A,B,C,D
> + * map to DDI A,B,TC1,TC2 respectively.
> + *
> + * ADL-S VBT uses PHY based mapping. Combo PHYs A,B,C,D,E
> + * map to DDI A,TC1,TC2,TC3,TC4 respectively.
> + */
> switch (info->alternate_aux_channel) {
> case DP_AUX_A:
> aux_ch = AUX_CH_A;
> break;
> case DP_AUX_B:
> - aux_ch = AUX_CH_B;
> + if (IS_ALDERLAKE_S(dev_priv))
> + aux_ch = AUX_CH_USBC1;
> + else
> + aux_ch = AUX_CH_B;
> break;
> case DP_AUX_C:
> - /*
> - * RKL/DG1 VBT uses PHY based mapping. Combo PHYs A,B,C,D
> - * map to DDI A,B,TC1,TC2 respectively.
> - */
> - aux_ch = (IS_DG1(dev_priv) || IS_ROCKETLAKE(dev_priv)) ?
> - AUX_CH_USBC1 : AUX_CH_C;
> + if (IS_ALDERLAKE_S(dev_priv))
> + aux_ch = AUX_CH_USBC2;
> + else if (IS_DG1(dev_priv) || IS_ROCKETLAKE(dev_priv))
> + aux_ch = AUX_CH_USBC1;
> + else
> + aux_ch = AUX_CH_C;
> break;
> case DP_AUX_D:
> - aux_ch = (IS_DG1(dev_priv) || IS_ROCKETLAKE(dev_priv)) ?
> - AUX_CH_USBC2 : AUX_CH_D;
> + if (IS_ALDERLAKE_S(dev_priv))
> + aux_ch = AUX_CH_USBC3;
> + else if (IS_DG1(dev_priv) || IS_ROCKETLAKE(dev_priv))
> + aux_ch = AUX_CH_USBC2;
> + else
> + aux_ch = AUX_CH_D;
> break;
> case DP_AUX_E:
> - aux_ch = AUX_CH_E;
> + if (IS_ALDERLAKE_S(dev_priv))
> + aux_ch = AUX_CH_USBC4;
> + else
> + aux_ch = AUX_CH_E;
> break;
> case DP_AUX_F:
> aux_ch = AUX_CH_F;
> --
> 2.27.0
>
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/22] drm/i915/adl_s: Initialize display for ADL-S
On Fri, Dec 04, 2020 at 05:08:32PM -0800, Aditya Swarup wrote:
> Initialize display outputs for ADL-S. ADL-S has 5 display
> outputs -> 1 eDP, 2 HDMI and 2 DP++ outputs.
>
> Cc: Jani Nikula
> Cc: Ville Syrjälä
> Cc: Imre Deak
> Cc: Matt Roper
> Cc: Lucas De Marchi
> Signed-off-by: Aditya Swarup
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 0ff0eeabab8c..19ed51e6c647 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -17627,7 +17627,13 @@ static void intel_setup_outputs(struct
> drm_i915_private *dev_priv)
> if (!HAS_DISPLAY(dev_priv))
> return;
>
> - if (IS_DG1(dev_priv) || IS_ROCKETLAKE(dev_priv)) {
> + if (IS_ALDERLAKE_S(dev_priv)) {
> + intel_ddi_init(dev_priv, PORT_A);
> + intel_ddi_init(dev_priv, PORT_D); /* DDI TC1 */
It all comes out the same in the end, but we should just pass PORT_TC1
and such for these outputs since that's the formal name in the bspec
(and matches how we handle RKL/DG1 that also have "TC" DDIs that are
actually combo PHYs).
Matt
> + intel_ddi_init(dev_priv, PORT_E); /* DDI TC2 */
> + intel_ddi_init(dev_priv, PORT_F); /* DDI TC3 */
> + intel_ddi_init(dev_priv, PORT_G); /* DDI TC4 */
> + } else if (IS_DG1(dev_priv) || IS_ROCKETLAKE(dev_priv)) {
> intel_ddi_init(dev_priv, PORT_A);
> intel_ddi_init(dev_priv, PORT_B);
> intel_ddi_init(dev_priv, PORT_TC1);
> --
> 2.27.0
>
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/22] drm/i915/adl_s: Configure DPLL for ADL-S
On Fri, Dec 04, 2020 at 05:08:30PM -0800, Aditya Swarup wrote: > Add changes for configuring DPLL for ADL-S > - Reusing DG1 DPLL 2 & DPLL 3 for ADL-S > - Extend CNL macro to choose DPLL_ENABLE > for ADL-S. > - Select CFGCR0 and CFGCR1 for ADL-S plls. > > On BSpec: 53720 PLL arrangement dig for adls: > DPLL2 cfgcr is programmed using _ADLS_DPLL3_CFGCR(0/1) > DPLL3 cfgcr is programmed using _ADLS_DPLL4_CFGCR(0/1) 53720 shows DPLL's 0/1/2/3 in the diagram but the registers are named as DPLL 0/1/3/4 (no #2). I don't see anywhere on 53720 that it explicitly gives the mapping you mention here, but on page 53723 I see a note: Due to current BSpec filtering limitations, the DPLL4_CRCFG0/1 (164294h/164298h) are used to control the DPLL2. Assuming that's correct, the patch below has the registers for the last two DPLL's swapped. ... > + > +#define _ADLS_DPLL3_CFGCR1 0x1642C4 > +#define _ADLS_DPLL4_CFGCR1 0x164298 > +#define ADLS_DPLL_CFGCR1(pll)_MMIO_PLL3(pll, > _TGL_DPLL0_CFGCR1, \ > +_TGL_DPLL1_CFGCR1, \ > +_ADLS_DPLL3_CFGCR1, \ > +_ADLS_DPLL4_CFGCR1) I.e., this should be #define ADLS_DPLL_CFGCR1(pll) _MMIO_PLL3(pll, _TGL_DPLL0_CFGCR1, \ _TGL_DPLL1_CFGCR1, \ _ADLS_DPLL4_CFGCR1, \ _ADLS_DPLL3_CFGCR1) Given the strange spec naming, I think this calls for a comment in the code as well to clarify that yes, we really do want 4 before 3 and that there's no 2. Matt > + > #define _DKL_PHY1_BASE 0x168000 > #define _DKL_PHY2_BASE 0x169000 > #define _DKL_PHY3_BASE 0x16A000 > -- > 2.27.0 > -- Matt Roper Graphics Software Engineer VTT-OSGC Platform Enablement Intel Corporation (916) 356-2795 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH V4] drm/i915/gen9_bc : Add TGP PCH support
On Mon, Jan 11, 2021 at 05:30:00PM -0800, Matt Roper wrote:
On Mon, Jan 11, 2021 at 07:21:55PM -0500, Rodrigo Vivi wrote:
On Fri, Jan 08, 2021 at 05:39:22PM +0530, Tejas Upadhyay wrote:
> We have TGP PCH support for Tigerlake and Rocketlake. Similarly
> now TGP PCH can be used with Cometlake CPU.
>
> Changes since V3 :
>- Rebased to top drm-tip commit
>- dev_priv replaced with i915 for new API
>- Enable default Port B,C,D detection for TGP && GEN9_BC
> Changes since V2 :
> - IS_COMETLAKE replaced with IS_GEN9_BC
> - VBT ddc pin remapping added
> - Added dedicated HPD pin and DDC pin handling API
> Changes since V1 :
> - Matched HPD Pin mapping for PORT C and PORT D of CML CPU.
>
> Cc: Matt Roper
> Cc: Jani Nikula
> Signed-off-by: Tejas Upadhyay
> ---
> drivers/gpu/drm/i915/display/intel_bios.c| 9 +
> drivers/gpu/drm/i915/display/intel_ddi.c | 7 +--
> drivers/gpu/drm/i915/display/intel_display.c | 9 -
> drivers/gpu/drm/i915/display/intel_hdmi.c| 20
> drivers/gpu/drm/i915/intel_pch.c | 3 ++-
> 5 files changed, 44 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
> index 987cf509337f..730b7f45e5d4 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -1630,6 +1630,12 @@ static const u8 rkl_pch_tgp_ddc_pin_map[] = {
>[RKL_DDC_BUS_DDI_E] = GMBUS_PIN_10_TC2_ICP,
> };
>
> +static const u8 gen9bc_tgp_ddc_pin_map[] = {
> + [DDC_BUS_DDI_B] = GMBUS_PIN_2_BXT,
> + [DDC_BUS_DDI_C] = GMBUS_PIN_9_TC1_ICP,
> + [DDC_BUS_DDI_D] = GMBUS_PIN_10_TC2_ICP,
> +};
Could you please point out the spec you are using here?
VBT's spec at BSpec - at Block 2
I can see the TGP table is same as ICP.
So I'm kind of confused now.
It's a weird place to document it, but bspec 49181 has a compatibility
section that describes how to map the TGP pins when paired with a gen9bc
CPU.
> +
> static u8 map_ddc_pin(struct drm_i915_private *dev_priv, u8 vbt_pin)
> {
>const u8 *ddc_pin_map;
> @@ -1640,6 +1646,9 @@ static u8 map_ddc_pin(struct drm_i915_private
*dev_priv, u8 vbt_pin)
>} else if (IS_ROCKETLAKE(dev_priv) && INTEL_PCH_TYPE(dev_priv) == PCH_TGP)
{
>ddc_pin_map = rkl_pch_tgp_ddc_pin_map;
>n_entries = ARRAY_SIZE(rkl_pch_tgp_ddc_pin_map);
> + } else if (HAS_PCH_TGP(dev_priv) && IS_GEN9_BC(dev_priv)) {
> + ddc_pin_map = gen9bc_tgp_ddc_pin_map;
> + n_entries = ARRAY_SIZE(gen9bc_tgp_ddc_pin_map);
>} else if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP) {
>ddc_pin_map = icp_ddc_pin_map;
>n_entries = ARRAY_SIZE(icp_ddc_pin_map);
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 3df6913369bc..13f1268e2cff 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -5337,7 +5337,9 @@ static enum hpd_pin dg1_hpd_pin(struct drm_i915_private
*dev_priv,
> static enum hpd_pin tgl_hpd_pin(struct drm_i915_private *dev_priv,
>enum port port)
> {
> - if (port >= PORT_TC1)
> + if (IS_GEN9_BC(dev_priv) && port >= PORT_C)
gen9 in tgl function?!
please, no!
We should probably rename this function to tgp since it ultimately gets
called on every possible TGP platform (TGL+TGP, RKL+TGP, gen9+TGP). If
it weren't for RKL+CMP, I'd say that all these functions should just be
named after the PCH, but I guess the TC ports on RKL+CMP break the
pattern.
I think the real plan once we get some free time is to kill off a bunch
of these output-based functions and define DDI/port/phy/VBT/HPD/DDC
mapping for outputs declaratively in a table since all the special cases
we're running into on recent platforms are turning the logic-based
approach into a mess.
sounds like the direction I wanted to go with
https://patchwork.freedesktop.org/patch/346524/?series=71330&rev=1
there was ddi/por/phy/vbt in a single table, and we could add the
remaining ones.
Lucas De Marchi
> + return HPD_PORT_TC1 + port - PORT_C;
> + else if (port >= PORT_TC1)
>return HPD_PORT_TC1 + port - PORT_TC1;
>else
>return HPD_PORT_A + port - PORT_A;
> @@ -5493,7 +5495,8 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
enum port port)
>encoder->hpd_pin = dg1_hpd_pin(dev_priv, port);
>else if (IS_ROCKETLAKE(dev_priv))
>encoder->hpd_pin = rkl_hpd_pin(dev_priv, port);
> - else if (INTEL_GEN(dev_priv) >= 12)
> + else if (INTEL_GEN(dev_priv) >= 12 || (IS_GEN9_BC(dev_priv) &&
> + HAS_PCH_TGP(dev_priv)))
Here's another aspect that I don't like in this code.
It mixes the gfx gen with the PCH in many places.
Something is not right...
>encoder->hpd_pin = tgl_hpd_pin(dev_priv, port);
>else if
Re: [Intel-gfx] [PATCH 07/22] drm/i915/adl_s: Add PHYs for Alderlake S
On Fri, Dec 04, 2020 at 05:08:29PM -0800, Aditya Swarup wrote:
> From: Anusha Srivatsa
>
> Alderlake-S has 5 combo phys, add reg definitions for
> combo phys and update the port to phy helper for ADL-S.
>
> v2:
> - Change IS_GEN() >= 12 to IS_TIGERLAKE() in intel_phy_is_tc()
> and return false for platforms RKL,DG1 and ADLS.(mdroper)
>
> Cc: Lucas De Marchi
> Cc: Jani Nikula
> Cc: Ville Syrjälä
> Cc: Imre Deak
> Cc: Matt Roper
> Signed-off-by: Anusha Srivatsa
> Signed-off-by: Aditya Swarup
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 10 ++
> drivers/gpu/drm/i915/i915_reg.h | 5 -
> 2 files changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 9187a20a8aca..2d1c5bfe4032 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -7397,6 +7397,8 @@ bool intel_phy_is_combo(struct drm_i915_private
> *dev_priv, enum phy phy)
> {
> if (phy == PHY_NONE)
> return false;
> + else if (IS_ALDERLAKE_S(dev_priv))
> + return phy <= PHY_E;
> else if (IS_DG1(dev_priv) || IS_ROCKETLAKE(dev_priv))
> return phy <= PHY_D;
> else if (IS_JSL_EHL(dev_priv))
> @@ -7409,9 +7411,7 @@ bool intel_phy_is_combo(struct drm_i915_private
> *dev_priv, enum phy phy)
>
> bool intel_phy_is_tc(struct drm_i915_private *dev_priv, enum phy phy)
> {
> - if (IS_DG1(dev_priv) || IS_ROCKETLAKE(dev_priv))
> - return false;
> - else if (INTEL_GEN(dev_priv) >= 12)
> + if (IS_TIGERLAKE(dev_priv))
> return phy >= PHY_D && phy <= PHY_I;
> else if (INTEL_GEN(dev_priv) >= 11 && !IS_JSL_EHL(dev_priv))
> return phy >= PHY_C && phy <= PHY_F;
> @@ -7421,7 +7421,9 @@ bool intel_phy_is_tc(struct drm_i915_private *dev_priv,
> enum phy phy)
>
> enum phy intel_port_to_phy(struct drm_i915_private *i915, enum port port)
> {
> - if ((IS_DG1(i915) || IS_ROCKETLAKE(i915)) && port >= PORT_TC1)
> + if (IS_ALDERLAKE_S(i915) && port >= PORT_TC1)
> + return PHY_B + port - PORT_TC1;
> + else if ((IS_DG1(i915) || IS_ROCKETLAKE(i915)) && port >= PORT_TC1)
> return PHY_C + port - PORT_TC1;
> else if (IS_JSL_EHL(i915) && port == PORT_D)
> return PHY_A;
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index cdc67f583a9c..60a0d4c35cae 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1874,10 +1874,13 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
> #define _ICL_COMBOPHY_B 0x6C000
> #define _EHL_COMBOPHY_C 0x16
> #define _RKL_COMBOPHY_D 0x161000
> +#define _ADL_COMBOPHY_E 0x16B000
> +
> #define _ICL_COMBOPHY(phy) _PICK(phy, _ICL_COMBOPHY_A, \
> _ICL_COMBOPHY_B, \
> _EHL_COMBOPHY_C, \
> - _RKL_COMBOPHY_D)
> + _RKL_COMBOPHY_D, \
> + _ADL_COMBOPHY_E)
>
> /* CNL/ICL Port CL_DW registers */
> #define _ICL_PORT_CL_DW(dw, phy) (_ICL_COMBOPHY(phy) + \
> --
> 2.27.0
>
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gem: Remove stolen node before releasing the region
== Series Details == Series: drm/i915/gem: Remove stolen node before releasing the region URL : https://patchwork.freedesktop.org/series/85727/ State : success == Summary == CI Bug Log - changes from CI_DRM_9585 -> Patchwork_19320 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19320/index.html Known issues Here are the changes found in Patchwork_19320 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s3: - fi-snb-2600:[PASS][1] -> [DMESG-WARN][2] ([i915#2772]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9585/fi-snb-2600/igt@gem_exec_susp...@basic-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19320/fi-snb-2600/igt@gem_exec_susp...@basic-s3.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-kbl-7500u: [PASS][3] -> [DMESG-FAIL][4] ([i915#165]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9585/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19320/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html * igt@prime_vgem@basic-fence-flip: - fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([i915#402]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9585/fi-tgl-y/igt@prime_v...@basic-fence-flip.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19320/fi-tgl-y/igt@prime_v...@basic-fence-flip.html * igt@runner@aborted: - fi-snb-2600:NOTRUN -> [FAIL][7] ([i915#698]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19320/fi-snb-2600/igt@run...@aborted.html Possible fixes * igt@gem_exec_suspend@basic-s0: - fi-tgl-u2: [FAIL][8] ([i915#1888]) -> [PASS][9] [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9585/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19320/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html * igt@i915_selftest@live@active: - fi-kbl-soraka: [DMESG-FAIL][10] ([i915#2291] / [i915#666]) -> [PASS][11] [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9585/fi-kbl-soraka/igt@i915_selftest@l...@active.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19320/fi-kbl-soraka/igt@i915_selftest@l...@active.html * igt@i915_selftest@live@gt_heartbeat: - fi-kbl-soraka: [DMESG-FAIL][12] ([i915#2291] / [i915#541]) -> [PASS][13] [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9585/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19320/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html * igt@prime_self_import@basic-with_one_bo_two_files: - fi-tgl-y: [DMESG-WARN][14] ([i915#402]) -> [PASS][15] [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9585/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19320/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html [i915#165]: https://gitlab.freedesktop.org/drm/intel/issues/165 [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888 [i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291 [i915#2772]: https://gitlab.freedesktop.org/drm/intel/issues/2772 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 [i915#541]: https://gitlab.freedesktop.org/drm/intel/issues/541 [i915#666]: https://gitlab.freedesktop.org/drm/intel/issues/666 [i915#698]: https://gitlab.freedesktop.org/drm/intel/issues/698 Participating hosts (44 -> 38) -- Missing(6): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-cml-drallion fi-bdw-samus Build changes - * Linux: CI_DRM_9585 -> Patchwork_19320 CI-20190529: 20190529 CI_DRM_9585: ce8ee6513f0f9d00ea44e1c4b7aff8b4883cda13 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5954: 2763c0977004bed596ee876c755b0768187ea9ab @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19320: 23d74dcb08250cfbf057c9c11023a9a33152d597 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 23d74dcb0825 drm/i915/gem: Remove stolen node before releasing the region == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19320/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gem: Remove stolen node before releasing the region
== Series Details == Series: drm/i915/gem: Remove stolen node before releasing the region URL : https://patchwork.freedesktop.org/series/85727/ State : warning == Summary == $ dim checkpatch origin/drm-tip 23d74dcb0825 drm/i915/gem: Remove stolen node before releasing the region -:10: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #10: <4> [431.679633] WARNING: CPU: 0 PID: 110 at drivers/gpu/drm/drm_mm.c:999 drm_mm_takedown+0x51/0x100 total: 0 errors, 1 warnings, 0 checks, 13 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,1/3] drm/i915/gt: Limit VFE threads based on GT
== Series Details ==
Series: series starting with [CI,1/3] drm/i915/gt: Limit VFE threads based on GT
URL : https://patchwork.freedesktop.org/series/85726/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9584_full -> Patchwork_19318_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_19318_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_19318_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_19318_full:
### IGT changes ###
Possible regressions
* igt@kms_flip@flip-vs-suspend@c-dp1:
- shard-kbl: NOTRUN -> [DMESG-WARN][1] +2 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19318/shard-kbl4/igt@kms_flip@flip-vs-susp...@c-dp1.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@gem_exec_fair@basic-pace@rcs0}:
- shard-kbl: [PASS][2] -> [FAIL][3] +1 similar issue
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9584/shard-kbl3/igt@gem_exec_fair@basic-p...@rcs0.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19318/shard-kbl4/igt@gem_exec_fair@basic-p...@rcs0.html
* {igt@gem_softpin@32b-excludes-last-page}:
- shard-apl: [PASS][4] -> [FAIL][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9584/shard-apl4/igt@gem_soft...@32b-excludes-last-page.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19318/shard-apl1/igt@gem_soft...@32b-excludes-last-page.html
Known issues
Here are the changes found in Patchwork_19318_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_persistence@legacy-engines-cleanup:
- shard-hsw: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#1099]) +2
similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19318/shard-hsw2/igt@gem_ctx_persiste...@legacy-engines-cleanup.html
* igt@gem_exec_reloc@basic-many-active@vcs1:
- shard-iclb: NOTRUN -> [FAIL][7] ([i915#2389])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19318/shard-iclb2/igt@gem_exec_reloc@basic-many-act...@vcs1.html
* igt@gem_exec_whisper@basic-contexts-priority-all:
- shard-hsw: NOTRUN -> [SKIP][8] ([fdo#109271]) +99 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19318/shard-hsw4/igt@gem_exec_whis...@basic-contexts-priority-all.html
- shard-glk: [PASS][9] -> [DMESG-WARN][10] ([i915#118] / [i915#95])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9584/shard-glk1/igt@gem_exec_whis...@basic-contexts-priority-all.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19318/shard-glk8/igt@gem_exec_whis...@basic-contexts-priority-all.html
* igt@i915_pm_lpsp@kms-lpsp@kms-lpsp-dp:
- shard-kbl: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#1937])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19318/shard-kbl4/igt@i915_pm_lpsp@kms-l...@kms-lpsp-dp.html
* igt@i915_pm_rpm@gem-idle:
- shard-kbl: NOTRUN -> [SKIP][12] ([fdo#109271]) +24 similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19318/shard-kbl4/igt@i915_pm_...@gem-idle.html
* igt@kms_async_flips@test-time-stamp:
- shard-tglb: [PASS][13] -> [FAIL][14] ([i915#2574])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9584/shard-tglb1/igt@kms_async_fl...@test-time-stamp.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19318/shard-tglb7/igt@kms_async_fl...@test-time-stamp.html
* igt@kms_chamelium@vga-hpd-enable-disable-mode:
- shard-kbl: NOTRUN -> [SKIP][15] ([fdo#109271] / [fdo#111827]) +2
similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19318/shard-kbl4/igt@kms_chamel...@vga-hpd-enable-disable-mode.html
* igt@kms_chamelium@vga-hpd-fast:
- shard-skl: NOTRUN -> [SKIP][16] ([fdo#109271] / [fdo#111827]) +2
similar issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19318/shard-skl1/igt@kms_chamel...@vga-hpd-fast.html
* igt@kms_color_chamelium@pipe-d-ctm-0-75:
- shard-hsw: NOTRUN -> [SKIP][17] ([fdo#109271] / [fdo#111827]) +8
similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19318/shard-hsw4/igt@kms_color_chamel...@pipe-d-ctm-0-75.html
* igt@kms_cursor_crc@pipe-c-cursor-128x128-random:
- shard-skl: [PASS][18] -> [FAIL][19] ([i915#54]) +5 similar issues
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9584/shard-skl10/igt@kms_cursor_...@p
Re: [Intel-gfx] [PATCH 1/2] drm/i915/tgl: Use TGL stepping info for applying WAs
On Mon, Jan 11, 2021 at 10:13:15PM +0200, Jani Nikula wrote:
On Fri, 08 Jan 2021, Matt Roper wrote:
On Fri, Jan 08, 2021 at 03:18:52PM -0800, Aditya Swarup wrote:
TGL adds another level of indirection for applying WA based on stepping
information rather than PCI REVID. So change TGL_REVID enum into
stepping enum and use PCI REVID as index into revid to stepping table to
fetch correct display and GT stepping for application of WAs as
suggested by Matt Roper.
So to clarify the goal is to rename "revid" -> "stepping" because the
values like "A1," "C0," etc. are't the actual PCI revision ID, but
rather descriptions of the stepping of a given IP block; the enum values
we use to represent those are arbitrary and don't matter as long as
they're monotonically increasing for comparisons. The PCI revision ID
is just the input we use today to deduce what the IP steppings are, and
there's talk that we could determine the IP steppings in a different way
at some point in the future.
Furthermore, since the same scheme will be used at least for ADL-S, we
should drop the "TGL" prefix since there's no need to name these general
enum values in a platform-specific manner.
Reviewed-by: Matt Roper
We should probably make the same kind of change to KBL (and use the same
stepping enum) too since it has the same kind of extra indirection as
TGL/ADL-S, but we can do that as a followup patch.
FWIW I have a wip series changing the whole thing to abstract steppings
enums that are shared between platforms, but it's in a bit of limbo
because the previous revid changes were applied to drm-intel-gt-next,
and it's fallen pretty far out of sync with drm-intel-next. All of this
really belongs to drm-intel-next, but can't do that until the branches
sync up again.
in the end both sides will need that (even if it was a mistake to merge
it in drm-intel-gt-next). I got an ack from Rodrigo to actually
cherry-pick the single patch we are missing so this can unblock both
merging this patch (after rebasing) and you can continue your series.
My series also completely hides the arrays into a separate .c file,
because the externs with direct array access are turning into
nightmare. The ARRAY_SIZE() checks rely on the extern declaration and
the actual array definition to have the sizes in sync, but the compiler
does not check that. Really.
not following what the ARRAY_SIZE is not checking. It actually is, since
the declaration is explicitly telling the size of the array. If the
definition had more items, you'd get a compilation error.
IDK, feels like this merging this series is going to be extra churn.
I'm not against the refactor you're talking about, but this seems an
improvement to unblock the ADL-S patches that are pending. The patches
could also be split to remove this dependency, but I'm not sure it's
worth it.
Lucas De Marchi
BR,
Jani.
Matt
Cc: Matt Roper
Cc: Lucas De Marchi
Cc: José Roberto de Souza
Signed-off-by: Aditya Swarup
---
.../drm/i915/display/intel_display_power.c| 2 +-
drivers/gpu/drm/i915/display/intel_psr.c | 4 +-
drivers/gpu/drm/i915/display/intel_sprite.c | 2 +-
drivers/gpu/drm/i915/gt/intel_workarounds.c | 26 +-
drivers/gpu/drm/i915/i915_drv.h | 50 +--
drivers/gpu/drm/i915/intel_pm.c | 2 +-
6 files changed, 43 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index d52374f01316..bb04b502a442 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -5340,7 +5340,7 @@ static void tgl_bw_buddy_init(struct drm_i915_private
*dev_priv)
int config, i;
if (IS_DG1_REVID(dev_priv, DG1_REVID_A0, DG1_REVID_A0) ||
- IS_TGL_DISP_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_B0))
+ IS_TGL_DISP_STEPPING(dev_priv, STEP_A0, STEP_B0))
/* Wa_1409767108:tgl,dg1 */
table = wa_1409767108_buddy_page_masks;
else
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index c24ae69426cf..a93717178957 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -550,7 +550,7 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
if (dev_priv->psr.psr2_sel_fetch_enabled) {
/* WA 1408330847 */
- if (IS_TGL_DISP_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_A0) ||
+ if (IS_TGL_DISP_STEPPING(dev_priv, STEP_A0, STEP_A0) ||
IS_RKL_REVID(dev_priv, RKL_REVID_A0, RKL_REVID_A0))
intel_de_rmw(dev_priv, CHICKEN_PAR1_1,
DIS_RAM_BYPASS_PSR2_MAN_TRACK,
@@ -1102,7 +1102,7 @@ static void intel_psr_disable_locked(struct intel_dp
*intel_dp)
/* WA 1408330847 */
if (dev_priv->psr.psr2_sel_fetch
[Intel-gfx] [PATCH] drm/i915/selftests: Allow huge_gem_object to kick the shrinker
A new fi-cml-dallium CI machine has 8G and apparently plenty free, yet
fails some selftests with ENOMEM. The failures all seem to be from
huge_gem_object which does not try very hard to allocate memory,
skipping reclaim entirely. Let's try a bit harder and direct reclaim
before failing.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/selftests/huge_gem_object.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_gem_object.c
b/drivers/gpu/drm/i915/gem/selftests/huge_gem_object.c
index a768ec61e966..2fb501a78a85 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_gem_object.c
@@ -27,7 +27,7 @@ static void huge_free_pages(struct drm_i915_gem_object *obj,
static int huge_get_pages(struct drm_i915_gem_object *obj)
{
-#define GFP (GFP_KERNEL | __GFP_NOWARN | __GFP_NORETRY)
+#define GFP (GFP_KERNEL | __GFP_NOWARN | __GFP_RETRY_MAYFAIL)
const unsigned long nreal = obj->scratch / PAGE_SIZE;
const unsigned long npages = obj->base.size / PAGE_SIZE;
struct scatterlist *sg, *src, *end;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Only enable DFP 4:4:4->4:2:0 conversion when outputting YCbCr 4:4:4 (rev2)
== Series Details == Series: drm/i915: Only enable DFP 4:4:4->4:2:0 conversion when outputting YCbCr 4:4:4 (rev2) URL : https://patchwork.freedesktop.org/series/85715/ State : success == Summary == CI Bug Log - changes from CI_DRM_9585 -> Patchwork_19319 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19319/index.html Known issues Here are the changes found in Patchwork_19319 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@nop-compute0: - fi-tgl-y: NOTRUN -> [SKIP][1] ([fdo#109315] / [i915#2575]) +9 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19319/fi-tgl-y/igt@amdgpu/amd_cs_...@nop-compute0.html * igt@i915_getparams_basic@basic-subslice-total: - fi-tgl-y: [PASS][2] -> [DMESG-WARN][3] ([i915#402]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9585/fi-tgl-y/igt@i915_getparams_ba...@basic-subslice-total.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19319/fi-tgl-y/igt@i915_getparams_ba...@basic-subslice-total.html * igt@runner@aborted: - fi-bdw-5557u: NOTRUN -> [FAIL][4] ([i915#2029]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19319/fi-bdw-5557u/igt@run...@aborted.html Possible fixes * igt@gem_exec_suspend@basic-s0: - fi-tgl-u2: [FAIL][5] ([i915#1888]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9585/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19319/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html * igt@gem_render_tiled_blits@basic: - fi-tgl-y: [DMESG-WARN][7] ([i915#402]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9585/fi-tgl-y/igt@gem_render_tiled_bl...@basic.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19319/fi-tgl-y/igt@gem_render_tiled_bl...@basic.html * igt@i915_selftest@live@active: - fi-kbl-soraka: [DMESG-FAIL][9] ([i915#2291] / [i915#666]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9585/fi-kbl-soraka/igt@i915_selftest@l...@active.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19319/fi-kbl-soraka/igt@i915_selftest@l...@active.html * igt@i915_selftest@live@gt_heartbeat: - fi-kbl-soraka: [DMESG-FAIL][11] ([i915#2291] / [i915#541]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9585/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19319/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html Warnings * igt@i915_pm_rpm@basic-pci-d3-state: - fi-kbl-guc: [SKIP][13] ([fdo#109271]) -> [FAIL][14] ([i915#704]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9585/fi-kbl-guc/igt@i915_pm_...@basic-pci-d3-state.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19319/fi-kbl-guc/igt@i915_pm_...@basic-pci-d3-state.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315 [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888 [i915#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029 [i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291 [i915#2575]: https://gitlab.freedesktop.org/drm/intel/issues/2575 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 [i915#541]: https://gitlab.freedesktop.org/drm/intel/issues/541 [i915#666]: https://gitlab.freedesktop.org/drm/intel/issues/666 [i915#704]: https://gitlab.freedesktop.org/drm/intel/issues/704 Participating hosts (44 -> 38) -- Missing(6): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-cml-drallion fi-bdw-samus Build changes - * Linux: CI_DRM_9585 -> Patchwork_19319 CI-20190529: 20190529 CI_DRM_9585: ce8ee6513f0f9d00ea44e1c4b7aff8b4883cda13 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5954: 2763c0977004bed596ee876c755b0768187ea9ab @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19319: c54c72aa7d1b4f7908782a467c29e3d022092159 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == c54c72aa7d1b drm/i915: Only enable DFP 4:4:4->4:2:0 conversion when outputting YCbCr 4:4:4 == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19319/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gem: Remove stolen node before releasing the region
If this stolen object holds the last reference to the region, we need to
remove our drm_mm_node before freeing the region's drm_mm.
<4> [431.679591] Memory manager not clean during takedown.
<4> [431.679633] WARNING: CPU: 0 PID: 110 at drivers/gpu/drm/drm_mm.c:999
drm_mm_takedown+0x51/0x100
<4> [431.679655] Modules linked in: i915 vgem btusb snd_hda_codec_hdmi btrtl
btbcm btintel snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio
bluetooth coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel
ecdh_generic ecc r8169 realtek lpc_ich snd_intel_dspcfg snd_hda_codec snd_hwdep
snd_hda_core snd_pcm pinctrl_cherryview prime_numbers [last unloaded: i915]
<4> [431.679883] CPU: 0 PID: 110 Comm: kworker/u4:3 Tainted: G U
5.11.0-rc3-CI-CI_DRM_9583+ #1
<4> [431.679895] Hardware name: /NUC5CPYB, BIOS
PYBSWCEL.86A.0058.2016.1102.1842 11/02/2016
<4> [431.679905] Workqueue: i915 __i915_gem_free_work [i915]
<4> [431.680831] RIP: 0010:drm_mm_takedown+0x51/0x100
<4> [431.680850] Code: 44 24 08 65 48 33 04 25 28 00 00 00 0f 85 b6 00 00 00 48
83 c4 10 5b 5d 41 5c c3 48 89 fb 48 c7 c7 c8 b7 38 82 e8 00 d6 37 00 <0f> 0b 48
8b 3d 96 d5 d1 00 ba 00 10 00 00 be c0 0c 00 00 e8 d7 64
<4> [431.680862] RSP: 0018:c9ad7dc0 EFLAGS: 00010282
<4> [431.680879] RAX: RBX: 8881109aa140 RCX:
0001
<4> [431.680888] RDX: 8001 RSI: 8235a70f RDI:
<4> [431.680897] RBP: 8881109aa178 R08: 0001 R09:
0001
<4> [431.680906] R10: 25eaec48 R11: f5b271a7 R12:
88810a38ddc0
<4> [431.680916] R13: R14: 82861b70 R15:
88810b715538
<4> [431.680925] FS: () GS:88817b80()
knlGS:
<4> [431.680935] CS: 0010 DS: ES: CR0: 80050033
<4> [431.680945] CR2: 56377cfd7c48 CR3: 0001045de000 CR4:
001006f0
<4> [431.680954] Call Trace:
<4> [431.680977] __intel_memory_region_destroy+0x24/0x50 [i915]
<4> [431.681340] i915_gem_object_release_stolen+0x26/0x40 [i915]
<4> [431.681637] __i915_gem_free_objects.isra.21+0x1ef/0x3b0 [i915]
<4> [431.681935] process_one_work+0x270/0x5c0
<4> [431.682022] worker_thread+0x37/0x380
<4> [431.682047] ? process_one_work+0x5c0/0x5c0
<4> [431.682062] kthread+0x146/0x170
<4> [431.682077] ? kthread_park+0x80/0x80
<4> [431.682098] ret_from_fork+0x22/0x30
<4> [431.682153] irq event stamp: 1872905
<4> [431.682162] hardirqs last enabled at (1872911): []
console_unlock+0x49a/0x580
<4> [431.682176] hardirqs last disabled at (1872916): []
console_unlock+0x406/0x580
<4> [431.682187] softirqs last enabled at (1872850): []
__do_softirq+0x342/0x48e
<4> [431.682201] softirqs last disabled at (1872845): []
asm_call_irq_on_stack+0x12/0x20
<4> [431.682214] ---[ end trace 5d3bcd818e2e3816 ]---
<3> [431.686188] [drm:drm_mm_takedown] *ERROR* node [0002d000 + 4000]:
inserted at
drm_mm_insert_node_in_range+0x34a/0x5b0
i915_gem_stolen_insert_node_in_range+0x7b/0xa0 [i915]
_i915_gem_object_create_stolen+0x83/0xd0 [i915]
i915_gem_object_create_region+0x61/0x140 [i915]
intel_engine_create_ring+0x176/0x230 [i915]
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2927
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index 29bffc6afcc1..41b9fbf4dbcc 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -608,11 +608,10 @@ i915_gem_object_release_stolen(struct drm_i915_gem_object
*obj)
struct drm_mm_node *stolen = fetch_and_zero(&obj->stolen);
GEM_BUG_ON(!stolen);
-
- i915_gem_object_release_memory_region(obj);
-
i915_gem_stolen_remove_node(i915, stolen);
kfree(stolen);
+
+ i915_gem_object_release_memory_region(obj);
}
static const struct drm_i915_gem_object_ops i915_gem_object_stolen_ops = {
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH V4] drm/i915/gen9_bc : Add TGP PCH support
On Mon, Jan 11, 2021 at 07:21:55PM -0500, Rodrigo Vivi wrote:
> On Fri, Jan 08, 2021 at 05:39:22PM +0530, Tejas Upadhyay wrote:
> > We have TGP PCH support for Tigerlake and Rocketlake. Similarly
> > now TGP PCH can be used with Cometlake CPU.
> >
> > Changes since V3 :
> > - Rebased to top drm-tip commit
> > - dev_priv replaced with i915 for new API
> > - Enable default Port B,C,D detection for TGP && GEN9_BC
> > Changes since V2 :
> > - IS_COMETLAKE replaced with IS_GEN9_BC
> > - VBT ddc pin remapping added
> > - Added dedicated HPD pin and DDC pin handling API
> > Changes since V1 :
> > - Matched HPD Pin mapping for PORT C and PORT D of CML CPU.
> >
> > Cc: Matt Roper
> > Cc: Jani Nikula
> > Signed-off-by: Tejas Upadhyay
> > ---
> > drivers/gpu/drm/i915/display/intel_bios.c| 9 +
> > drivers/gpu/drm/i915/display/intel_ddi.c | 7 +--
> > drivers/gpu/drm/i915/display/intel_display.c | 9 -
> > drivers/gpu/drm/i915/display/intel_hdmi.c| 20
> > drivers/gpu/drm/i915/intel_pch.c | 3 ++-
> > 5 files changed, 44 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> > b/drivers/gpu/drm/i915/display/intel_bios.c
> > index 987cf509337f..730b7f45e5d4 100644
> > --- a/drivers/gpu/drm/i915/display/intel_bios.c
> > +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> > @@ -1630,6 +1630,12 @@ static const u8 rkl_pch_tgp_ddc_pin_map[] = {
> > [RKL_DDC_BUS_DDI_E] = GMBUS_PIN_10_TC2_ICP,
> > };
> >
> > +static const u8 gen9bc_tgp_ddc_pin_map[] = {
> > + [DDC_BUS_DDI_B] = GMBUS_PIN_2_BXT,
> > + [DDC_BUS_DDI_C] = GMBUS_PIN_9_TC1_ICP,
> > + [DDC_BUS_DDI_D] = GMBUS_PIN_10_TC2_ICP,
> > +};
>
> Could you please point out the spec you are using here?
>
> VBT's spec at BSpec - at Block 2
> I can see the TGP table is same as ICP.
>
> So I'm kind of confused now.
It's a weird place to document it, but bspec 49181 has a compatibility
section that describes how to map the TGP pins when paired with a gen9bc
CPU.
>
> > +
> > static u8 map_ddc_pin(struct drm_i915_private *dev_priv, u8 vbt_pin)
> > {
> > const u8 *ddc_pin_map;
> > @@ -1640,6 +1646,9 @@ static u8 map_ddc_pin(struct drm_i915_private
> > *dev_priv, u8 vbt_pin)
> > } else if (IS_ROCKETLAKE(dev_priv) && INTEL_PCH_TYPE(dev_priv) ==
> > PCH_TGP) {
> > ddc_pin_map = rkl_pch_tgp_ddc_pin_map;
> > n_entries = ARRAY_SIZE(rkl_pch_tgp_ddc_pin_map);
> > + } else if (HAS_PCH_TGP(dev_priv) && IS_GEN9_BC(dev_priv)) {
> > + ddc_pin_map = gen9bc_tgp_ddc_pin_map;
> > + n_entries = ARRAY_SIZE(gen9bc_tgp_ddc_pin_map);
> > } else if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP) {
> > ddc_pin_map = icp_ddc_pin_map;
> > n_entries = ARRAY_SIZE(icp_ddc_pin_map);
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index 3df6913369bc..13f1268e2cff 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -5337,7 +5337,9 @@ static enum hpd_pin dg1_hpd_pin(struct
> > drm_i915_private *dev_priv,
> > static enum hpd_pin tgl_hpd_pin(struct drm_i915_private *dev_priv,
> > enum port port)
> > {
> > - if (port >= PORT_TC1)
> > + if (IS_GEN9_BC(dev_priv) && port >= PORT_C)
>
> gen9 in tgl function?!
> please, no!
We should probably rename this function to tgp since it ultimately gets
called on every possible TGP platform (TGL+TGP, RKL+TGP, gen9+TGP). If
it weren't for RKL+CMP, I'd say that all these functions should just be
named after the PCH, but I guess the TC ports on RKL+CMP break the
pattern.
I think the real plan once we get some free time is to kill off a bunch
of these output-based functions and define DDI/port/phy/VBT/HPD/DDC
mapping for outputs declaratively in a table since all the special cases
we're running into on recent platforms are turning the logic-based
approach into a mess.
>
> > + return HPD_PORT_TC1 + port - PORT_C;
> > + else if (port >= PORT_TC1)
> > return HPD_PORT_TC1 + port - PORT_TC1;
> > else
> > return HPD_PORT_A + port - PORT_A;
> > @@ -5493,7 +5495,8 @@ void intel_ddi_init(struct drm_i915_private
> > *dev_priv, enum port port)
> > encoder->hpd_pin = dg1_hpd_pin(dev_priv, port);
> > else if (IS_ROCKETLAKE(dev_priv))
> > encoder->hpd_pin = rkl_hpd_pin(dev_priv, port);
> > - else if (INTEL_GEN(dev_priv) >= 12)
> > + else if (INTEL_GEN(dev_priv) >= 12 || (IS_GEN9_BC(dev_priv) &&
> > + HAS_PCH_TGP(dev_priv)))
>
> Here's another aspect that I don't like in this code.
> It mixes the gfx gen with the PCH in many places.
>
> Something is not right...
>
> > encoder->hpd_pin = tgl_hpd_pin(dev_priv, port);
> > else if (IS_JSL_EHL(dev_priv))
> >
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/3] drm/i915/gt: Limit VFE threads based on GT
== Series Details == Series: series starting with [CI,1/3] drm/i915/gt: Limit VFE threads based on GT URL : https://patchwork.freedesktop.org/series/85726/ State : success == Summary == CI Bug Log - changes from CI_DRM_9584 -> Patchwork_19318 Summary --- **WARNING** Minor unknown changes coming with Patchwork_19318 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19318, 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_19318/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_19318: ### IGT changes ### Warnings * igt@i915_hangman@error-state-basic: - fi-apl-guc: [DMESG-WARN][1] ([i915#1610]) -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9584/fi-apl-guc/igt@i915_hang...@error-state-basic.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19318/fi-apl-guc/igt@i915_hang...@error-state-basic.html Known issues Here are the changes found in Patchwork_19318 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@gt_heartbeat: - fi-tgl-y: [PASS][3] -> [DMESG-FAIL][4] ([i915#2601]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9584/fi-tgl-y/igt@i915_selftest@live@gt_heartbeat.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19318/fi-tgl-y/igt@i915_selftest@live@gt_heartbeat.html * igt@vgem_basic@dmabuf-fence-before: - fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([i915#402]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9584/fi-tgl-y/igt@vgem_ba...@dmabuf-fence-before.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19318/fi-tgl-y/igt@vgem_ba...@dmabuf-fence-before.html Possible fixes * igt@i915_module_load@reload: - fi-ilk-650: [DMESG-WARN][7] ([i915#164]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9584/fi-ilk-650/igt@i915_module_l...@reload.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19318/fi-ilk-650/igt@i915_module_l...@reload.html * igt@kms_chamelium@dp-crc-fast: - fi-kbl-7500u: [FAIL][9] ([i915#1161] / [i915#262]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9584/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19318/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html * igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1: - fi-bsw-kefka: [FAIL][11] ([i915#2122]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9584/fi-bsw-kefka/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19318/fi-bsw-kefka/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html * igt@prime_vgem@basic-read: - fi-tgl-y: [DMESG-WARN][13] ([i915#402]) -> [PASS][14] +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9584/fi-tgl-y/igt@prime_v...@basic-read.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19318/fi-tgl-y/igt@prime_v...@basic-read.html [i915#1161]: https://gitlab.freedesktop.org/drm/intel/issues/1161 [i915#1610]: https://gitlab.freedesktop.org/drm/intel/issues/1610 [i915#164]: https://gitlab.freedesktop.org/drm/intel/issues/164 [i915#2122]: https://gitlab.freedesktop.org/drm/intel/issues/2122 [i915#2601]: https://gitlab.freedesktop.org/drm/intel/issues/2601 [i915#262]: https://gitlab.freedesktop.org/drm/intel/issues/262 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 Participating hosts (44 -> 38) -- Missing(6): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-cml-drallion fi-bdw-samus Build changes - * Linux: CI_DRM_9584 -> Patchwork_19318 CI-20190529: 20190529 CI_DRM_9584: 5f4b4c212cde385b40395f78925950b1fb00 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5954: 2763c0977004bed596ee876c755b0768187ea9ab @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19318: 8d67e886d81701a12ab6c2e7588987c7bf2b3388 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 8d67e886d817 drm/i915: Allow the sysadmin to override security mitigations 5c4e9fc2dcd5 drm/i915/gt: Restore clear-residual mitigations for Ivybridge, Baytrail e2979c887600 drm/i915/gt: Limit VFE threads based on GT == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19318/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.or
Re: [Intel-gfx] [PATCH V4] drm/i915/gen9_bc : Add TGP PCH support
On Fri, Jan 08, 2021 at 05:39:22PM +0530, Tejas Upadhyay wrote:
> We have TGP PCH support for Tigerlake and Rocketlake. Similarly
> now TGP PCH can be used with Cometlake CPU.
>
> Changes since V3 :
> - Rebased to top drm-tip commit
> - dev_priv replaced with i915 for new API
> - Enable default Port B,C,D detection for TGP && GEN9_BC
> Changes since V2 :
> - IS_COMETLAKE replaced with IS_GEN9_BC
> - VBT ddc pin remapping added
> - Added dedicated HPD pin and DDC pin handling API
> Changes since V1 :
> - Matched HPD Pin mapping for PORT C and PORT D of CML CPU.
>
> Cc: Matt Roper
> Cc: Jani Nikula
> Signed-off-by: Tejas Upadhyay
> ---
> drivers/gpu/drm/i915/display/intel_bios.c| 9 +
> drivers/gpu/drm/i915/display/intel_ddi.c | 7 +--
> drivers/gpu/drm/i915/display/intel_display.c | 9 -
> drivers/gpu/drm/i915/display/intel_hdmi.c| 20
> drivers/gpu/drm/i915/intel_pch.c | 3 ++-
> 5 files changed, 44 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index 987cf509337f..730b7f45e5d4 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -1630,6 +1630,12 @@ static const u8 rkl_pch_tgp_ddc_pin_map[] = {
> [RKL_DDC_BUS_DDI_E] = GMBUS_PIN_10_TC2_ICP,
> };
>
> +static const u8 gen9bc_tgp_ddc_pin_map[] = {
> + [DDC_BUS_DDI_B] = GMBUS_PIN_2_BXT,
> + [DDC_BUS_DDI_C] = GMBUS_PIN_9_TC1_ICP,
> + [DDC_BUS_DDI_D] = GMBUS_PIN_10_TC2_ICP,
> +};
Could you please point out the spec you are using here?
VBT's spec at BSpec - at Block 2
I can see the TGP table is same as ICP.
So I'm kind of confused now.
> +
> static u8 map_ddc_pin(struct drm_i915_private *dev_priv, u8 vbt_pin)
> {
> const u8 *ddc_pin_map;
> @@ -1640,6 +1646,9 @@ static u8 map_ddc_pin(struct drm_i915_private
> *dev_priv, u8 vbt_pin)
> } else if (IS_ROCKETLAKE(dev_priv) && INTEL_PCH_TYPE(dev_priv) ==
> PCH_TGP) {
> ddc_pin_map = rkl_pch_tgp_ddc_pin_map;
> n_entries = ARRAY_SIZE(rkl_pch_tgp_ddc_pin_map);
> + } else if (HAS_PCH_TGP(dev_priv) && IS_GEN9_BC(dev_priv)) {
> + ddc_pin_map = gen9bc_tgp_ddc_pin_map;
> + n_entries = ARRAY_SIZE(gen9bc_tgp_ddc_pin_map);
> } else if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP) {
> ddc_pin_map = icp_ddc_pin_map;
> n_entries = ARRAY_SIZE(icp_ddc_pin_map);
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 3df6913369bc..13f1268e2cff 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -5337,7 +5337,9 @@ static enum hpd_pin dg1_hpd_pin(struct drm_i915_private
> *dev_priv,
> static enum hpd_pin tgl_hpd_pin(struct drm_i915_private *dev_priv,
> enum port port)
> {
> - if (port >= PORT_TC1)
> + if (IS_GEN9_BC(dev_priv) && port >= PORT_C)
gen9 in tgl function?!
please, no!
> + return HPD_PORT_TC1 + port - PORT_C;
> + else if (port >= PORT_TC1)
> return HPD_PORT_TC1 + port - PORT_TC1;
> else
> return HPD_PORT_A + port - PORT_A;
> @@ -5493,7 +5495,8 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
> enum port port)
> encoder->hpd_pin = dg1_hpd_pin(dev_priv, port);
> else if (IS_ROCKETLAKE(dev_priv))
> encoder->hpd_pin = rkl_hpd_pin(dev_priv, port);
> - else if (INTEL_GEN(dev_priv) >= 12)
> + else if (INTEL_GEN(dev_priv) >= 12 || (IS_GEN9_BC(dev_priv) &&
> +HAS_PCH_TGP(dev_priv)))
Here's another aspect that I don't like in this code.
It mixes the gfx gen with the PCH in many places.
Something is not right...
> encoder->hpd_pin = tgl_hpd_pin(dev_priv, port);
> else if (IS_JSL_EHL(dev_priv))
> encoder->hpd_pin = ehl_hpd_pin(dev_priv, port);
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 0189d379a55e..81c93c49ddef 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -16212,7 +16212,14 @@ static void intel_setup_outputs(struct
> drm_i915_private *dev_priv)
>
> /* DDI B, C, D, and F detection is indicated by the SFUSE_STRAP
>* register */
> - found = intel_de_read(dev_priv, SFUSE_STRAP);
> + if (HAS_PCH_TGP(dev_priv)) {
> + /* W/A due to lack of STRAP config on TGP PCH*/
> + found = (SFUSE_STRAP_DDIB_DETECTED |
> + SFUSE_STRAP_DDIC_DETECTED |
> + SFUSE_STRAP_DDID_DETECTED);
> + } else {
> + found = int
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/3] drm/i915/gt: Limit VFE threads based on GT
== Series Details == Series: series starting with [CI,1/3] drm/i915/gt: Limit VFE threads based on GT URL : https://patchwork.freedesktop.org/series/85726/ State : warning == Summary == $ dim checkpatch origin/drm-tip e2979c887600 drm/i915/gt: Limit VFE threads based on GT 5c4e9fc2dcd5 drm/i915/gt: Restore clear-residual mitigations for Ivybridge, Baytrail 8d67e886d817 drm/i915: Allow the sysadmin to override security mitigations -:59: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #59: new file mode 100644 -:196: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #196: FILE: drivers/gpu/drm/i915/i915_mitigations.c:133: +MODULE_PARM_DESC(mitigations, +"Selectively enable security mitigations for all Intel® GPUs in the system.\n" total: 0 errors, 1 warnings, 1 checks, 182 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC-v19 04/13] drm/i915/pxp: Create the arbitrary session after boot
Hi Rodrigo,
Quoted from Joonas at
https://patchwork.freedesktop.org/patch/412397/?series=84620&rev=19
" Generally the trend on the GT side is to contain in a .c file if there are
no shared users like these. So they should be at this spot, yet the rest
of the review comments apply."
So I think the define GEN12_KCR_SIP should stay in intel_pxp_arb.c since it's
no shared users.
But anyway please let me know if you insist to move it to i915_reg.h
Best regards,
Sean
-Original Message-
From: Vivi, Rodrigo
Sent: Thursday, January 7, 2021 7:40 AM
To: Huang, Sean Z ; Intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [RFC-v19 04/13] drm/i915/pxp: Create the arbitrary
session after boot
On Wed, 2021-01-06 at 15:12 -0800, Huang, Sean Z wrote:
> Create the arbitrary session, with the fixed session id 0xf, after
> system boot, for the case that application allocates the protected
> buffer without establishing any protection session. Because the
> hardware requires at least one alive session for protected buffer
> creation. This arbitrary session needs to be re-created after
> teardown or power event because hardware encryption key won't be valid
> after such cases.
>
> Signed-off-by: Huang, Sean Z
> ---
> drivers/gpu/drm/i915/Makefile| 1 +
> drivers/gpu/drm/i915/pxp/intel_pxp.c | 1 +
> drivers/gpu/drm/i915/pxp/intel_pxp.h | 16 +++
> drivers/gpu/drm/i915/pxp/intel_pxp_arb.c | 131
> +++
> drivers/gpu/drm/i915/pxp/intel_pxp_arb.h | 16 +++
> drivers/gpu/drm/i915/pxp/intel_pxp_context.h | 1 +
> drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 73 +++
> drivers/gpu/drm/i915/pxp/intel_pxp_tee.h | 3 +
> drivers/gpu/drm/i915/pxp/intel_pxp_types.h | 26
> 9 files changed, 268 insertions(+)
> create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_arb.c
> create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_arb.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile
> b/drivers/gpu/drm/i915/Makefile index 5494c30cb54f..af9e87e4c63a
> 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -262,6 +262,7 @@ i915-y += i915_perf.o # Protected execution
> platform (PXP) support
> i915-$(CONFIG_DRM_I915_PXP) += \
> pxp/intel_pxp.o \
> + pxp/intel_pxp_arb.o \
> pxp/intel_pxp_context.o \
> pxp/intel_pxp_tee.o
>
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> index c819f3791ee4..3868e8c697f9 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> @@ -6,6 +6,7 @@
> #include "intel_pxp.h"
> #include "intel_pxp_context.h"
> #include "intel_pxp_tee.h"
> +#include "intel_pxp_arb.h"
>
> /* KCR register definitions */
> #define KCR_INIT_MMIO(0x320f0)
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
> b/drivers/gpu/drm/i915/pxp/intel_pxp.h
> index f47bc6bea34f..8fc91e900b16 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
> @@ -8,6 +8,22 @@
>
> #include "intel_pxp_types.h"
>
> +enum pxp_session_types {
> + SESSION_TYPE_TYPE0 = 0,
> + SESSION_TYPE_TYPE1 = 1,
> +
> + SESSION_TYPE_MAX
> +};
> +
> +enum pxp_protection_modes {
> + PROTECTION_MODE_NONE = 0,
> + PROTECTION_MODE_LM = 2,
> + PROTECTION_MODE_HM = 3,
> + PROTECTION_MODE_SM = 6,
> +
> + PROTECTION_MODE_ALL
> +};
> +
> #ifdef CONFIG_DRM_I915_PXP
> 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_arb.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp_arb.c
> new file mode 100644
> index ..640d7103c04d
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_arb.c
> @@ -0,0 +1,131 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright(c) 2020, Intel Corporation. All rights reserved.
> + */
> +
> +#include "gt/intel_context.h"
> +#include "gt/intel_engine_pm.h"
> +
> +#include "intel_pxp_types.h"
> +#include "intel_pxp_arb.h"
> +#include "intel_pxp.h"
> +#include "intel_pxp_tee.h"
> +
> +#define GEN12_KCR_SIP _MMIO(0x32260) /* KCR type0 session in play 0-
> 31 */
> +
> +/* Arbitrary session */
> +#define ARB_SESSION_INDEX 0xf
> +#define ARB_SESSION_TYPE SESSION_TYPE_TYPE0
All reg defines should be in i915_reg.h
> +
> +bool intel_pxp_arb_session_is_in_play(struct intel_pxp *pxp) {
> + u32 regval_sip = 0;
> + intel_wakeref_t wakeref;
> + struct intel_gt *gt = container_of(pxp, struct intel_gt,
> pxp);
> +
> + with_intel_runtime_pm(>->i915->runtime_pm, wakeref) {
> + regval_sip = intel_uncore_read(gt->uncore,
> GEN12_KCR_SIP);
> + }
> +
> + return regval_sip & BIT(ARB_SESSION_INDEX); }
> +
> +/* wait hw session_in_play reg to match the current sw state */
> +static int wait_arb_hw_sw_state(struct intel_pxp *pxp) {
> + const int max_ret
Re: [Intel-gfx] [PATCH 1/2] drm/i915/tgl: Use TGL stepping info for applying WAs
On 1/11/21 12:57 PM, Matt Roper wrote: > On Mon, Jan 11, 2021 at 10:18:45PM +0200, Jani Nikula wrote: >> On Mon, 11 Jan 2021, Jani Nikula wrote: >>> On Fri, 08 Jan 2021, Matt Roper wrote: On Fri, Jan 08, 2021 at 03:18:52PM -0800, Aditya Swarup wrote: > TGL adds another level of indirection for applying WA based on stepping > information rather than PCI REVID. So change TGL_REVID enum into > stepping enum and use PCI REVID as index into revid to stepping table to > fetch correct display and GT stepping for application of WAs as > suggested by Matt Roper. So to clarify the goal is to rename "revid" -> "stepping" because the values like "A1," "C0," etc. are't the actual PCI revision ID, but rather descriptions of the stepping of a given IP block; the enum values we use to represent those are arbitrary and don't matter as long as they're monotonically increasing for comparisons. The PCI revision ID is just the input we use today to deduce what the IP steppings are, and there's talk that we could determine the IP steppings in a different way at some point in the future. Furthermore, since the same scheme will be used at least for ADL-S, we should drop the "TGL" prefix since there's no need to name these general enum values in a platform-specific manner. Reviewed-by: Matt Roper We should probably make the same kind of change to KBL (and use the same stepping enum) too since it has the same kind of extra indirection as TGL/ADL-S, but we can do that as a followup patch. >>> >>> FWIW I have a wip series changing the whole thing to abstract steppings >>> enums that are shared between platforms, but it's in a bit of limbo >>> because the previous revid changes were applied to drm-intel-gt-next, >>> and it's fallen pretty far out of sync with drm-intel-next. All of this >>> really belongs to drm-intel-next, but can't do that until the branches >>> sync up again. >> >> Btw this series doesn't apply to drm-intel-next either, for the same >> reason, and the ADL-S platform definition and PCI IDs must *not* be >> applied to drm-intel-gt-next. The reason behind this patch not cleanly applying on drm-intel-next is because drm/i915/tgl: Add bound checks and simplify TGL REVID macros isn't present on that branch but present on gt-next. The patch doesn't apply on gt-next because of a conflict in the following hunk: /* Wa_1409825376:tgl (pre-prod)*/ - if (IS_TGL_DISP_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_B1)) + if (IS_TGL_DISP_STEPPING(dev_priv, STEP_A0, STEP_B1)) which can be easily fixed during backmerge process as I was able apply the patch cleanly on gt-next. I don't understand the "must *not*" reasoning behind not applying this patch on gt-next. It was common consesus during initial review that separating stepping/revid parsing in a separate .c file will be pushed in after ADLS changes and adding this patch won't add any extra churn, just a minor rebase for your approach. Regards, aswarup > > So to clarify, it looks like we have a bunch of revid changes to the > display code that got merged to the gt-next tree but not to the > intel-next tree? Should we be going back and also merging / > cherry-picking those over to intel-next since that's where the display > changes are supposed to go, or is it too late to do that cleanly at this > point? > > Going forward, what should the general strategy be for stuff like > platform definitions and such? Merge such enablement patches to both > intel-next and gt-next at the same time so that the basic definitions > are available to both trees? It seems like the whole split into two > trees really isn't working well and is just leading to more mistakes and > bottlenecks. What benefit are we supposed to be getting from this > split?> > > Matt > > >> >> BR, >> Jani. >> >>> >>> My series also completely hides the arrays into a separate .c file, >>> because the externs with direct array access are turning into >>> nightmare. The ARRAY_SIZE() checks rely on the extern declaration and >>> the actual array definition to have the sizes in sync, but the compiler >>> does not check that. Really. >>> >>> IDK, feels like this merging this series is going to be extra churn. >>> >>> >>> BR, >>> Jani. >>> >>> Matt > > Cc: Matt Roper > Cc: Lucas De Marchi > Cc: José Roberto de Souza > Signed-off-by: Aditya Swarup > --- > .../drm/i915/display/intel_display_power.c| 2 +- > drivers/gpu/drm/i915/display/intel_psr.c | 4 +- > drivers/gpu/drm/i915/display/intel_sprite.c | 2 +- > drivers/gpu/drm/i915/gt/intel_workarounds.c | 26 +- > drivers/gpu/drm/i915/i915_drv.h | 50 +-- > drivers/gpu/drm/i915/intel_pm.c | 2 +- > 6 files changed, 43 insertions(+), 43 deletions(-) > > diff --git a/drivers/g
[Intel-gfx] [CI 3/3] drm/i915: Allow the sysadmin to override security mitigations
The clear-residuals mitigation is a relatively heavy hammer and under some
circumstances the user may wish to forgo the context isolation in order
to meet some performance requirement. Introduce a generic module
parameter to allow selectively enabling/disabling different mitigations.
To disable just the clear-residuals mitigation (on Ivybridge, Baytrail,
or Haswell) use the module parameter: i915.mitigations=auto,!residuals
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1858
Fixes: 47f8253d2b89 ("drm/i915/gen7: Clear all EU/L3 residual contexts")
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Jon Bloomfield
Cc: Rodrigo Vivi
Cc: sta...@vger.kernel.org # v5.7
Reviewed-by: Jon Bloomfield
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/Makefile | 1 +
.../gpu/drm/i915/gt/intel_ring_submission.c | 4 +-
drivers/gpu/drm/i915/i915_mitigations.c | 146 ++
drivers/gpu/drm/i915/i915_mitigations.h | 13 ++
4 files changed, 163 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/i915/i915_mitigations.c
create mode 100644 drivers/gpu/drm/i915/i915_mitigations.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 4074d8cb0d6e..48f82c354611 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -38,6 +38,7 @@ i915-y += i915_drv.o \
i915_config.o \
i915_irq.o \
i915_getparam.o \
+ i915_mitigations.o \
i915_params.o \
i915_pci.o \
i915_scatterlist.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
index 724d56c9583d..657afd8ebc14 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
@@ -32,6 +32,7 @@
#include "gen6_ppgtt.h"
#include "gen7_renderclear.h"
#include "i915_drv.h"
+#include "i915_mitigations.h"
#include "intel_breadcrumbs.h"
#include "intel_context.h"
#include "intel_gt.h"
@@ -918,7 +919,8 @@ static int switch_context(struct i915_request *rq)
GEM_BUG_ON(HAS_EXECLISTS(engine->i915));
if (engine->wa_ctx.vma && ce != engine->kernel_context) {
- if (engine->wa_ctx.vma->private != ce) {
+ if (engine->wa_ctx.vma->private != ce &&
+ i915_mitigate_clear_residuals()) {
ret = clear_residuals(rq);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/i915_mitigations.c
b/drivers/gpu/drm/i915/i915_mitigations.c
new file mode 100644
index ..84f12598d145
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_mitigations.c
@@ -0,0 +1,146 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2021 Intel Corporation
+ */
+
+#include
+#include
+#include
+#include
+
+#include "i915_drv.h"
+#include "i915_mitigations.h"
+
+static unsigned long mitigations __read_mostly = ~0UL;
+
+enum {
+ CLEAR_RESIDUALS = 0,
+};
+
+static const char * const names[] = {
+ [CLEAR_RESIDUALS] = "residuals",
+};
+
+bool i915_mitigate_clear_residuals(void)
+{
+ return READ_ONCE(mitigations) & BIT(CLEAR_RESIDUALS);
+}
+
+static int mitigations_set(const char *val, const struct kernel_param *kp)
+{
+ unsigned long new = ~0UL;
+ char *str, *sep, *tok;
+ bool first = true;
+ int err = 0;
+
+ BUILD_BUG_ON(ARRAY_SIZE(names) >= BITS_PER_TYPE(mitigations));
+
+ str = kstrdup(val, GFP_KERNEL);
+ if (!str)
+ return -ENOMEM;
+
+ for (sep = str; (tok = strsep(&sep, ","));) {
+ bool enable = true;
+ int i;
+
+ /* Be tolerant of leading/trailing whitespace */
+ tok = strim(tok);
+
+ if (first) {
+ first = false;
+
+ if (!strcmp(tok, "auto"))
+ continue;
+
+ new = 0;
+ if (!strcmp(tok, "off"))
+ continue;
+ }
+
+ if (*tok == '!') {
+ enable = !enable;
+ tok++;
+ }
+
+ if (!strncmp(tok, "no", 2)) {
+ enable = !enable;
+ tok += 2;
+ }
+
+ if (*tok == '\0')
+ continue;
+
+ for (i = 0; i < ARRAY_SIZE(names); i++) {
+ if (!strcmp(tok, names[i])) {
+ if (enable)
+ new |= BIT(i);
+ else
+ new &= ~BIT(i);
+ break;
+ }
+ }
+ if (i == ARRAY_SIZE(names)) {
+ pr_err("Bad \"%s.mitigations=%s\", '%s' is unknown\n",
+
[Intel-gfx] [CI 2/3] drm/i915/gt: Restore clear-residual mitigations for Ivybridge, Baytrail
The mitigation is required for all gen7 platforms, now that it does not
cause GPU hangs, restore it for Ivybridge and Baytrail.
Fixes: 47f8253d2b89 ("drm/i915/gen7: Clear all EU/L3 residual contexts")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Prathap Kumar Valsan
Cc: Akeem G Abodunrin
Cc: Bloomfield Jon
Reviewed-by: Akeem G Abodunrin
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/gt/intel_ring_submission.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
index 1c6d421f6fe5..724d56c9583d 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
@@ -1324,7 +1324,7 @@ int intel_ring_submission_setup(struct intel_engine_cs
*engine)
GEM_BUG_ON(timeline->hwsp_ggtt != engine->status_page.vma);
- if (IS_HASWELL(engine->i915) && engine->class == RENDER_CLASS) {
+ if (IS_GEN(engine->i915, 7) && engine->class == RENDER_CLASS) {
err = gen7_ctx_switch_bb_init(engine);
if (err)
goto err_ring_unpin;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 1/3] drm/i915/gt: Limit VFE threads based on GT
MEDIA_STATE_VFE only accepts the 'maximum number of threads' in the
range [0, n-1] where n is #EU * (#threads/EU) with the number of threads
based on plaform and the number of EU based on the number of slices and
subslices. This is a fixed number per platform/gt, so appropriately
limit the number of threads we spawn to match the device.
v2: Oversaturate the system with tasks to force execution on every HW
thread; if the thread idles it is returned to the pool and may be reused
again before an unused thread.
v3: Fix more state commands, which was causing Baytrail to barf.
v4: STATE_CACHE_INVALIDATE requires a stall on Ivybridge
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2024
Fixes: 47f8253d2b89 ("drm/i915/gen7: Clear all EU/L3 residual contexts")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Prathap Kumar Valsan
Cc: Akeem G Abodunrin
Cc: Jon Bloomfield
Cc: Rodrigo Vivi
Cc: Randy Wright
Cc: sta...@vger.kernel.org # v5.7+
Reviewed-by: Akeem G Abodunrin
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/gt/gen7_renderclear.c | 157 -
1 file changed, 94 insertions(+), 63 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/gen7_renderclear.c
b/drivers/gpu/drm/i915/gt/gen7_renderclear.c
index d93d85cd3027..94465374ca2f 100644
--- a/drivers/gpu/drm/i915/gt/gen7_renderclear.c
+++ b/drivers/gpu/drm/i915/gt/gen7_renderclear.c
@@ -7,8 +7,6 @@
#include "i915_drv.h"
#include "intel_gpu_commands.h"
-#define MAX_URB_ENTRIES 64
-#define STATE_SIZE (4 * 1024)
#define GT3_INLINE_DATA_DELAYS 0x1E00
#define batch_advance(Y, CS) GEM_BUG_ON((Y)->end != (CS))
@@ -34,38 +32,59 @@ struct batch_chunk {
};
struct batch_vals {
- u32 max_primitives;
- u32 max_urb_entries;
- u32 cmd_size;
- u32 state_size;
+ u32 max_threads;
u32 state_start;
- u32 batch_size;
+ u32 surface_start;
u32 surface_height;
u32 surface_width;
- u32 scratch_size;
- u32 max_size;
+ u32 size;
};
+static inline int num_primitives(const struct batch_vals *bv)
+{
+ /*
+* We need to saturate the GPU with work in order to dispatch
+* a shader on every HW thread, and clear the thread-local registers.
+* In short, we have to dispatch work faster than the shaders can
+* run in order to fill the EU and occupy each HW thread.
+*/
+ return bv->max_threads;
+}
+
static void
batch_get_defaults(struct drm_i915_private *i915, struct batch_vals *bv)
{
if (IS_HASWELL(i915)) {
- bv->max_primitives = 280;
- bv->max_urb_entries = MAX_URB_ENTRIES;
+ switch (INTEL_INFO(i915)->gt) {
+ default:
+ case 1:
+ bv->max_threads = 70;
+ break;
+ case 2:
+ bv->max_threads = 140;
+ break;
+ case 3:
+ bv->max_threads = 280;
+ break;
+ }
bv->surface_height = 16 * 16;
bv->surface_width = 32 * 2 * 16;
} else {
- bv->max_primitives = 128;
- bv->max_urb_entries = MAX_URB_ENTRIES / 2;
+ switch (INTEL_INFO(i915)->gt) {
+ default:
+ case 1: /* including vlv */
+ bv->max_threads = 36;
+ break;
+ case 2:
+ bv->max_threads = 128;
+ break;
+ }
bv->surface_height = 16 * 8;
bv->surface_width = 32 * 16;
}
- bv->cmd_size = bv->max_primitives * 4096;
- bv->state_size = STATE_SIZE;
- bv->state_start = bv->cmd_size;
- bv->batch_size = bv->cmd_size + bv->state_size;
- bv->scratch_size = bv->surface_height * bv->surface_width;
- bv->max_size = bv->batch_size + bv->scratch_size;
+ bv->state_start = round_up(SZ_1K + num_primitives(bv) * 64, SZ_4K);
+ bv->surface_start = bv->state_start + SZ_4K;
+ bv->size = bv->surface_start + bv->surface_height * bv->surface_width;
}
static void batch_init(struct batch_chunk *bc,
@@ -155,7 +174,8 @@ static u32
gen7_fill_binding_table(struct batch_chunk *state,
const struct batch_vals *bv)
{
- u32 surface_start = gen7_fill_surface_state(state, bv->batch_size, bv);
+ u32 surface_start =
+ gen7_fill_surface_state(state, bv->surface_start, bv);
u32 *cs = batch_alloc_items(state, 32, 8);
u32 offset = batch_offset(state, cs);
@@ -214,9 +234,9 @@ static void
gen7_emit_state_base_address(struct batch_chunk *batch,
u32 surface_state_base)
{
- u32 *cs = batch_alloc_items(batch, 0, 12);
+ u32 *cs = batch_alloc_items(batch, 0, 10);
- *cs++ = STATE_BASE_ADDRESS | (12 - 2);
+ *cs++ = STATE_BASE_ADDRESS | (10
Re: [Intel-gfx] [RFC-v19 03/13] drm/i915/pxp: Implement funcs to create the TEE channel
Hi Rodrigo,
I removed the debug print print_hex_dump() in this patch, this change will
reflect at rev20.
Regarding to the Chris's question for mutex, actually what I'm doing the
similar with the existing hdcp_comp_added and hdcp_comp_mutex in
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/i915/display/intel_hdcp.c#L2002
During the bind/unbind, we would need to protect pxp_tee_comp_added with
pxp_tee_comp_mutex, to make sure no race condition between
intel_pxp_tee_component_init() and intel_pxp_tee_component_fini().
So hopefully this mutex is acceptable. Thank you!
Best regards,
Sean
-Original Message-
From: Vivi, Rodrigo
Sent: Thursday, January 7, 2021 7:36 AM
To: Huang, Sean Z ; Intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [RFC-v19 03/13] drm/i915/pxp: Implement funcs to
create the TEE channel
On Wed, 2021-01-06 at 15:12 -0800, Huang, Sean Z wrote:
> Implement the funcs to create the TEE channel, so kernel can send the
> TEE commands directly to TEE for creating the arbitrary
> (defualt) session.
>
> Signed-off-by: Huang, Sean Z
> ---
> drivers/gpu/drm/i915/Makefile| 3 +-
> drivers/gpu/drm/i915/i915_drv.c | 1 +
> drivers/gpu/drm/i915/i915_drv.h | 6 +
> drivers/gpu/drm/i915/pxp/intel_pxp.c | 5 +
> drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 137
> +++
> drivers/gpu/drm/i915/pxp/intel_pxp_tee.h | 14 +++
> include/drm/i915_component.h | 1 +
> include/drm/i915_pxp_tee_interface.h | 45
> 8 files changed, 211 insertions(+), 1 deletion(-) create mode 100644
> drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_tee.h
> create mode 100644 include/drm/i915_pxp_tee_interface.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile
> b/drivers/gpu/drm/i915/Makefile index cbf2f0594b4d..5494c30cb54f
> 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -262,7 +262,8 @@ i915-y += i915_perf.o # Protected execution
> platform (PXP) support
> i915-$(CONFIG_DRM_I915_PXP) += \
> pxp/intel_pxp.o \
> - pxp/intel_pxp_context.o
> + pxp/intel_pxp_context.o \
> + pxp/intel_pxp_tee.o
>
> # Post-mortem debug and GPU hang state capture
> i915-$(CONFIG_DRM_I915_CAPTURE_ERROR) += i915_gpu_error.o diff --git
> a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 3e504247f2da..207d50226e64 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -322,6 +322,7 @@ static int i915_driver_early_probe(struct
> drm_i915_private *dev_priv)
> mutex_init(&dev_priv->wm.wm_mutex);
> mutex_init(&dev_priv->pps_mutex);
> mutex_init(&dev_priv->hdcp_comp_mutex);
> + mutex_init(&dev_priv->pxp_tee_comp_mutex);
>
> i915_memcpy_init_early(dev_priv);
> intel_runtime_pm_init_early(&dev_priv->runtime_pm);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h index 5e5bcef20e33..c2f47daef5a5
> 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1209,6 +1209,12 @@ struct drm_i915_private {
> /* Mutex to protect the above hdcp component related values.
> */
> struct mutex hdcp_comp_mutex;
>
> + struct i915_pxp_comp_master *pxp_tee_master;
> + bool pxp_tee_comp_added;
> +
> + /* Mutex to protect the above pxp_tee component related
> values. */
> + struct mutex pxp_tee_comp_mutex;
> +
> I915_SELFTEST_DECLARE(struct i915_selftest_stash selftest;)
>
> /*
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> index f566a4fda044..c819f3791ee4 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> @@ -5,6 +5,7 @@
> #include "i915_drv.h"
> #include "intel_pxp.h"
> #include "intel_pxp_context.h"
> +#include "intel_pxp_tee.h"
>
> /* KCR register definitions */
> #define KCR_INIT_MMIO(0x320f0)
> @@ -23,6 +24,8 @@ void intel_pxp_init(struct intel_pxp *pxp)
>
> intel_uncore_write(gt->uncore, KCR_INIT,
> KCR_INIT_ALLOW_DISPLAY_ME_WRITES);
>
> + intel_pxp_tee_component_init(pxp);
> +
> drm_info(>->i915->drm, "Protected Xe Path (PXP) protected
> content support initialized\n"); }
>
> @@ -33,5 +36,7 @@ void intel_pxp_fini(struct intel_pxp *pxp)
> if (INTEL_GEN(gt->i915) < 12)
> return;
>
> + intel_pxp_tee_component_fini(pxp);
> +
> intel_pxp_ctx_fini(&pxp->ctx); } diff --git
> a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> new file mode 100644
> index ..5a1ffcc703e2
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> @@ -0,0 +1,137 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright(c) 2020 Intel Corporation.
> + */
> +
> +#include
[Intel-gfx] ✗ Fi.CI.IGT: failure for Use TGL stepping info and add ADLS platform changes (rev2)
== Series Details == Series: Use TGL stepping info and add ADLS platform changes (rev2) URL : https://patchwork.freedesktop.org/series/85639/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9581_full -> Patchwork_19317_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_19317_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19317_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_19317_full: ### IGT changes ### Possible regressions * igt@gem_ctx_persistence@close-replace-race: - shard-kbl: [PASS][1] -> [TIMEOUT][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9581/shard-kbl2/igt@gem_ctx_persiste...@close-replace-race.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19317/shard-kbl4/igt@gem_ctx_persiste...@close-replace-race.html * igt@sysfs_timeslice_duration@timeout@rcs0: - shard-skl: [PASS][3] -> [FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9581/shard-skl9/igt@sysfs_timeslice_duration@time...@rcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19317/shard-skl8/igt@sysfs_timeslice_duration@time...@rcs0.html Known issues Here are the changes found in Patchwork_19317_full that come from known issues: ### IGT changes ### Issues hit * igt@drm_import_export@prime: - shard-kbl: [PASS][5] -> [INCOMPLETE][6] ([i915#2895]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9581/shard-kbl1/igt@drm_import_exp...@prime.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19317/shard-kbl6/igt@drm_import_exp...@prime.html * igt@gem_ctx_persistence@engines-hang: - shard-hsw: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#1099]) +3 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19317/shard-hsw4/igt@gem_ctx_persiste...@engines-hang.html * igt@gem_exec_reloc@basic-wide-active@bcs0: - shard-hsw: NOTRUN -> [FAIL][8] ([i915#2389]) +3 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19317/shard-hsw2/igt@gem_exec_reloc@basic-wide-act...@bcs0.html * igt@gem_exec_whisper@basic-fds-forked-all: - shard-glk: [PASS][9] -> [DMESG-WARN][10] ([i915#118] / [i915#95]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9581/shard-glk9/igt@gem_exec_whis...@basic-fds-forked-all.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19317/shard-glk4/igt@gem_exec_whis...@basic-fds-forked-all.html * igt@kms_color@pipe-c-ctm-red-to-blue: - shard-skl: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9581/shard-skl8/igt@kms_co...@pipe-c-ctm-red-to-blue.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19317/shard-skl5/igt@kms_co...@pipe-c-ctm-red-to-blue.html * igt@kms_color_chamelium@pipe-d-ctm-0-75: - shard-hsw: NOTRUN -> [SKIP][13] ([fdo#109271] / [fdo#111827]) +14 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19317/shard-hsw4/igt@kms_color_chamel...@pipe-d-ctm-0-75.html * igt@kms_cursor_crc@pipe-c-cursor-256x85-sliding: - shard-skl: [PASS][14] -> [FAIL][15] ([i915#54]) +4 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9581/shard-skl6/igt@kms_cursor_...@pipe-c-cursor-256x85-sliding.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19317/shard-skl7/igt@kms_cursor_...@pipe-c-cursor-256x85-sliding.html * igt@kms_cursor_legacy@cursor-vs-flip-toggle: - shard-hsw: [PASS][16] -> [FAIL][17] ([i915#2370]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9581/shard-hsw2/igt@kms_cursor_leg...@cursor-vs-flip-toggle.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19317/shard-hsw8/igt@kms_cursor_leg...@cursor-vs-flip-toggle.html * igt@kms_cursor_legacy@flip-vs-cursor-varying-size: - shard-skl: [PASS][18] -> [FAIL][19] ([i915#2346]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9581/shard-skl10/igt@kms_cursor_leg...@flip-vs-cursor-varying-size.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19317/shard-skl6/igt@kms_cursor_leg...@flip-vs-cursor-varying-size.html * igt@kms_flip@flip-vs-expired-vblank-interruptible@c-hdmi-a1: - shard-glk: [PASS][20] -> [FAIL][21] ([i915#79]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9581/shard-glk4/igt@kms_flip@flip-vs-expired-vblank-interrupti...@c-hdmi-a1.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19317/shard-glk1/
Re: [Intel-gfx] [RFC-v19 01/13] drm/i915/pxp: Introduce Intel PXP component
Hi Rodrigo, Regarding to Chris comment in v4: >> +config DRM_I915_PXP >> + bool "Enable Intel PXP support for Intel Gen12+ platform" >> + depends on DRM_I915 >> + select INTEL_MEI_PXP > >Doesn't exist. > >Kconfig dependency resolution is not recursive; you probably will need a >depends on INTEL_MEI Since select INTEL_MEI_PXP isn't recursive so I have add "select INTEL_MEI" accordingly based on Chris suggestion. In the rev20, I removed the term "Mesa" from the help description, modification as below: This patch series is to allow the kernel space to create and manage a single hardware session (a.k.a default session or - arbitrary session). So Mesa can allocate the protected buffer, + arbitrary session). So user space can allocate the protected buffer, which is encrypted with the leverage of the arbitrary hardware session. Best regards, Sean -Original Message- From: Vivi, Rodrigo Sent: Thursday, January 7, 2021 7:29 AM To: Huang, Sean Z ; Intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] [RFC-v19 01/13] drm/i915/pxp: Introduce Intel PXP component On Wed, 2021-01-06 at 15:12 -0800, Huang, Sean Z wrote: > PXP (Protected Xe Path) is an i915 componment, available on GEN12+, > that helps to establish the hardware protected session and manage the > status of the alive software session, as well as its life cycle. > > This patch series is to allow the kernel space to create and manage a > single hardware session (a.k.a default session or arbitrary session). > So Mesa can allocate the protected buffer, which is encrypted with the > leverage of the arbitrary hardware session. > > Signed-off-by: Huang, Sean Z > --- > drivers/gpu/drm/i915/Kconfig | 22 +++ > drivers/gpu/drm/i915/Makefile| 5 > drivers/gpu/drm/i915/gt/intel_gt.c | 5 > drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 ++ > drivers/gpu/drm/i915/pxp/intel_pxp.c | 29 > > drivers/gpu/drm/i915/pxp/intel_pxp.h | 25 + > drivers/gpu/drm/i915/pxp/intel_pxp_context.c | 25 + > drivers/gpu/drm/i915/pxp/intel_pxp_context.h | 15 ++ > drivers/gpu/drm/i915/pxp/intel_pxp_types.h | 23 > 9 files changed, 152 insertions(+) > create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp.c > create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp.h > create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_context.c > create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_context.h > create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_types.h > > diff --git a/drivers/gpu/drm/i915/Kconfig > b/drivers/gpu/drm/i915/Kconfig index 1e1cb245fca7..594775c11e19 100644 > --- a/drivers/gpu/drm/i915/Kconfig > +++ b/drivers/gpu/drm/i915/Kconfig > @@ -130,6 +130,28 @@ config DRM_I915_GVT_KVMGT > Choose this option if you want to enable KVMGT support for > Intel GVT-g. > > +config DRM_I915_PXP > + bool "Enable Intel PXP support for Intel Gen12+ platform" > + depends on DRM_I915 > + select INTEL_MEI > + select INTEL_MEI_ME > + select INTEL_MEI_TXE > + select INTEL_MEI_PXP I'm afraid you haven't addressed any of the Chris' comments from V4. I saw you marked as "done", but I'm seeing everything back here. So I'm not sure what's going on here. > + default y > + help > + This option selects INTEL_MEI_ME if it isn't already > selected to > + enabled full PXP Services on Intel platforms. > + > + PXP (Protected Xe Path) is an i915 componment, available on > GEN12+, > + that helps to establish the hardware protected session and > manage > + the status of the alive software session, as well as its > life cycle. > + > + This patch series is to allow the kernel space to create > and > + manage a single hardware session (a.k.a default session or > + arbitrary session). So Mesa can allocate the protected > buffer, > + which is encrypted with the leverage of the arbitrary > hardware > + session. > + > menu "drm/i915 Debugging" > depends on DRM_I915 > depends on EXPERT > diff --git a/drivers/gpu/drm/i915/Makefile > b/drivers/gpu/drm/i915/Makefile index 4074d8cb0d6e..cbf2f0594b4d > 100644 > --- a/drivers/gpu/drm/i915/Makefile > +++ b/drivers/gpu/drm/i915/Makefile > @@ -259,6 +259,11 @@ i915-y += \ > > i915-y += i915_perf.o > > +# Protected execution platform (PXP) support > +i915-$(CONFIG_DRM_I915_PXP) += \ > + pxp/intel_pxp.o \ > + pxp/intel_pxp_context.o > + > # Post-mortem debug and GPU hang state capture > i915-$(CONFIG_DRM_I915_CAPTURE_ERROR) += i915_gpu_error.o > i915-$(CONFIG_DRM_I915_SELFTEST) += \ diff --git > a/drivers/gpu/drm/i915/gt/intel_gt.c > b/drivers/gpu/drm/i915/gt/intel_gt.c > index d8e1ab412634..336ad7deae06 100644 > --- a/drivers/gpu/drm/i91
Re: [Intel-gfx] [PATCH 3/4] drm/i915/gt: Perform an arbitration check before busywaiting
Quoting Tvrtko Ursulin (2021-01-11 17:12:57) > > On 11/01/2021 16:27, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2021-01-11 16:19:40) > >> > >> On 11/01/2021 10:57, Chris Wilson wrote: > >>> During igt_reset_nop_engine, it was observed that an unexpected failed > >>> engine reset lead to us busywaiting on the stop-ring semaphore (set > >>> during the reset preparations) on the first request afterwards. There was > >>> no explicit MI_ARB_CHECK in this sequence as the presumption was that > >>> the failed MI_SEMAPHORE_WAIT would itself act as an arbitration point. > >>> It did not in this circumstance, so force it. > >> > >> In other words MI_SEMAPHORE_POLL is not a preemption point? Can't > >> remember if I knew that or not.. > > > > MI_SEMAPHORE_WAIT | POLL is most definitely a preemption point on a > > miss. > > > >> 1) > >> Why not the same handling in !gen12 version? > > > > Because I think it's a bug in tgl [a0 at least]. I think I've seen the > > same symptoms on tgl before, but not earlier. This is the first time the > > sequence clicked as to why it was busy spinning. Random engine reset > > failures are rare enough -- I was meant to also write a test case to > > inject failure. > > Random engine reset failure you think is a TGL issue? The MI_SEMAPHORE_WAIT | POLL miss not generating an arbitration point. We have quite a few selftests and IGT that use this feature. So I was wondering if this was similar to one of those tgl issues with semaphores and CS events. The random engine reset failure here is also decidedly odd. The engine was idle! > >> 2) > >> Failed reset leads to busy-hang in following request _tail_? But there > >> is an arb check at the start of following request as well. Or in cases > >> where we context switch into the middle of a previously executing request? > > > > It was the first request submitted after the failed reset. We expect to > > clear the ring-stop flag on the CS IDLE->ACTIVE event. > > > >> But why would that busy hang? Hasn't the failed request unpaused the ring? > > > > The engine was idle at the time of the failed reset. We left the > > ring-stop set, and submitted the next batch of requests. We hit the > > MI_SEMAPHORE_WAIT(ring-stop) at the end of the first request, but > > without hitting an arbitration point (first request, no init-breadcrumb > > in this case), the semaphore was stuck. > > So a kernel context request? Ish. The selftest is using empty requests, and not emitting the initial breadcrumb. (So acting like a kernel context.) > Why hasn't IDLE->ACTIVE cleared ring stop? There hasn't been an idle->active event, not a single CS event after writing to ELSP and timing out while still spinning on the semaphore. > Presumably this CSB must come after the first request has been submitted > so apparently I am still not getting how it hangs. It was never sent. The context is still in pending[0] (not active[0]) and there's no sign in the trace of any interrupts/tasklet handing other than the semaphore-wait interrupt. > Just because igt_reset_nop_engine does things "quickly"? It prevents the > CSB from arriving? More that the since we do very little we hit the semaphore before the CS has recovered from the shock of being asked to do something. > So ARB_CHECK pickups up on the fact ELSP has been > rewritten before the IDLE->ACTIVE even received and/or engine reset > prevented it from arriving? The ARB_CHECK should trigger the CS to generate the IDLE->ACTIVE event. (Of course assuming that the bug is in the semaphore not triggering the event due to strange circumstances and not a bug in the event generator itself.) I'm suspicious of the semaphore due to the earlier CS bugs with lite-restores + semaphores, and am expecting that since the MI_ARB_CHECK is explicit, it actually works. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC-v19 02/13] drm/i915/pxp: set KCR reg init during the boot time
Hello, I see, based on Joonas and Rodrigo's feedback. I made the modification as below, I will still keep the macro in this .c instead of i915_reg.h, and this change will be reflected in rev20. /* KCR register definitions */ #define KCR_INIT_MMIO(0x320f0) -#define KCR_INIT_MASK_SHIFT (16) + /* Setting KCR Init bit is required after system boot */ -#define KCR_INIT_ALLOW_DISPLAY_ME_WRITES (BIT(14) | (BIT(14) << KCR_INIT_MASK_SHIFT)) +#define KCR_INIT_ALLOW_DISPLAY_ME_WRITES (BIT(14) | (BIT(14) << 16)) Best regards, Sean -Original Message- From: Joonas Lahtinen Sent: Friday, January 8, 2021 3:31 AM To: Huang, Sean Z ; Intel-gfx@lists.freedesktop.org; Vivi, Rodrigo Subject: Re: [Intel-gfx] [RFC-v19 02/13] drm/i915/pxp: set KCR reg init during the boot time Quoting Vivi, Rodrigo (2021-01-07 17:31:36) > On Wed, 2021-01-06 at 15:12 -0800, Huang, Sean Z wrote: > > Set the KCR init during the boot time, which is required by > > hardware, to allow us doing further protection operation such as > > sending commands to GPU or TEE. > > > > Signed-off-by: Huang, Sean Z > > --- > > drivers/gpu/drm/i915/pxp/intel_pxp.c | 8 > > 1 file changed, 8 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c > > b/drivers/gpu/drm/i915/pxp/intel_pxp.c > > index 9bc3c7e30654..f566a4fda044 100644 > > --- a/drivers/gpu/drm/i915/pxp/intel_pxp.c > > +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c > > @@ -6,6 +6,12 @@ > > #include "intel_pxp.h" > > #include "intel_pxp_context.h" > > > > +/* KCR register definitions */ > > please define this in i915_reg.h Generally the trend on the GT side is to contain in a .c file if there are no shared users like these. So they should be at this spot, yet the rest of the review comments apply. The spurious comments should be dropped and like Rodrigo pointed out, we should be using the appropriate macros for a masked writes, not baking in the #define. Regards, Joonas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm: Check actual format for legacy pageflip.
On Mon, Jan 11, 2021 at 11:39 AM Bas Nieuwenhuizen
wrote:
>
> On Mon, Jan 11, 2021 at 4:02 PM Alex Deucher wrote:
> >
> > On Sat, Jan 9, 2021 at 9:11 PM Bas Nieuwenhuizen
> > wrote:
> > >
> > > With modifiers one can actually have different format_info structs
> > > for the same format, which now matters for AMDGPU since we convert
> > > implicit modifiers to explicit modifiers with multiple planes.
> > >
> > > I checked other drivers and it doesn't look like they end up triggering
> > > this case so I think this is safe to relax.
> > >
> > > Signed-off-by: Bas Nieuwenhuizen
> > > Reviewed-by: Daniel Vetter
> > > Reviewed-by: Zhan Liu
> > > Acked-by: Christian König
> > > Acked-by: Alex Deucher
> > > Fixes: 816853f9dc40 ("drm/amd/display: Set new format info for converted
> > > metadata.")
> >
> > Do you have commit rights to drm-misc or do you need someone to commit
> > this for you?
>
> I don't have commit rights so if the patch could be committed for me
> that would be appreciated!
Pushed to drm-misc-fixes. Thanks!
If you want access to drm-misc, I don't see any reason you shouldn't have it.
Alex
> >
> > Thanks!
> >
> > Alex
> >
> > > ---
> > > drivers/gpu/drm/drm_plane.c | 9 -
> > > 1 file changed, 8 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> > > index e6231947f987..a0cb746bcb0a 100644
> > > --- a/drivers/gpu/drm/drm_plane.c
> > > +++ b/drivers/gpu/drm/drm_plane.c
> > > @@ -1163,7 +1163,14 @@ int drm_mode_page_flip_ioctl(struct drm_device
> > > *dev,
> > > if (ret)
> > > goto out;
> > >
> > > - if (old_fb->format != fb->format) {
> > > + /*
> > > +* Only check the FOURCC format code, excluding modifiers. This is
> > > +* enough for all legacy drivers. Atomic drivers have their own
> > > +* checks in their ->atomic_check implementation, which will
> > > +* return -EINVAL if any hw or driver constraint is violated due
> > > +* to modifier changes.
> > > +*/
> > > + if (old_fb->format->format != fb->format->format) {
> > > DRM_DEBUG_KMS("Page flip is not allowed to change frame
> > > buffer format.\n");
> > > ret = -EINVAL;
> > > goto out;
> > > --
> > > 2.29.2
> > >
> > > ___
> > > amd-gfx mailing list
> > > amd-...@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/tgl: Use TGL stepping info for applying WAs
On Mon, Jan 11, 2021 at 12:57:43PM -0800, Matt Roper wrote: On Mon, Jan 11, 2021 at 10:18:45PM +0200, Jani Nikula wrote: On Mon, 11 Jan 2021, Jani Nikula wrote: > On Fri, 08 Jan 2021, Matt Roper wrote: >> On Fri, Jan 08, 2021 at 03:18:52PM -0800, Aditya Swarup wrote: >>> TGL adds another level of indirection for applying WA based on stepping >>> information rather than PCI REVID. So change TGL_REVID enum into >>> stepping enum and use PCI REVID as index into revid to stepping table to >>> fetch correct display and GT stepping for application of WAs as >>> suggested by Matt Roper. >> >> So to clarify the goal is to rename "revid" -> "stepping" because the >> values like "A1," "C0," etc. are't the actual PCI revision ID, but >> rather descriptions of the stepping of a given IP block; the enum values >> we use to represent those are arbitrary and don't matter as long as >> they're monotonically increasing for comparisons. The PCI revision ID >> is just the input we use today to deduce what the IP steppings are, and >> there's talk that we could determine the IP steppings in a different way >> at some point in the future. >> >> Furthermore, since the same scheme will be used at least for ADL-S, we >> should drop the "TGL" prefix since there's no need to name these general >> enum values in a platform-specific manner. >> >> Reviewed-by: Matt Roper >> >> We should probably make the same kind of change to KBL (and use the same >> stepping enum) too since it has the same kind of extra indirection as >> TGL/ADL-S, but we can do that as a followup patch. > > FWIW I have a wip series changing the whole thing to abstract steppings > enums that are shared between platforms, but it's in a bit of limbo > because the previous revid changes were applied to drm-intel-gt-next, > and it's fallen pretty far out of sync with drm-intel-next. All of this > really belongs to drm-intel-next, but can't do that until the branches > sync up again. Btw this series doesn't apply to drm-intel-next either, for the same reason, and the ADL-S platform definition and PCI IDs must *not* be applied to drm-intel-gt-next. So to clarify, it looks like we have a bunch of revid changes to the display code that got merged to the gt-next tree but not to the intel-next tree? Should we be going back and also merging / cherry-picking those over to intel-next since that's where the display changes are supposed to go, or is it too late to do that cleanly at this point? it was my mistake to merge them to drm-intel-gt-next. They should have been in drm-intel-next. Going forward, what should the general strategy be for stuff like platform definitions and such? Merge such enablement patches to both last time we talked about this was regarding dg1 AFAIR and the consensus was to create a topic branch and that topic branch to be merged in both branches. That would avoid having 2 commits in different branches. Not sure if it would work out nicely for getting test on CI though. Since the changes are spread through the codebase, we could very easily hit a situation that this topic branch creates conflicts for other patches getting merged on either drm-intel-next or drm-intel-gt-next. +Joonas, +Rodrigo Lucas De Marchi intel-next and gt-next at the same time so that the basic definitions are available to both trees? It seems like the whole split into two trees really isn't working well and is just leading to more mistakes and bottlenecks. What benefit are we supposed to be getting from this split? Matt BR, Jani. > > My series also completely hides the arrays into a separate .c file, > because the externs with direct array access are turning into > nightmare. The ARRAY_SIZE() checks rely on the extern declaration and > the actual array definition to have the sizes in sync, but the compiler > does not check that. Really. > > IDK, feels like this merging this series is going to be extra churn. > > > BR, > Jani. > > >> >> >> Matt >> >>> >>> Cc: Matt Roper >>> Cc: Lucas De Marchi >>> Cc: José Roberto de Souza >>> Signed-off-by: Aditya Swarup >>> --- >>> .../drm/i915/display/intel_display_power.c| 2 +- >>> drivers/gpu/drm/i915/display/intel_psr.c | 4 +- >>> drivers/gpu/drm/i915/display/intel_sprite.c | 2 +- >>> drivers/gpu/drm/i915/gt/intel_workarounds.c | 26 +- >>> drivers/gpu/drm/i915/i915_drv.h | 50 +-- >>> drivers/gpu/drm/i915/intel_pm.c | 2 +- >>> 6 files changed, 43 insertions(+), 43 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c b/drivers/gpu/drm/i915/display/intel_display_power.c >>> index d52374f01316..bb04b502a442 100644 >>> --- a/drivers/gpu/drm/i915/display/intel_display_power.c >>> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c >>> @@ -5340,7 +5340,7 @@ static void tgl_bw_buddy_init(struct drm_i915_private *dev_priv) >>>int config, i; >>> >>>if (IS_DG1_REVID(dev_priv, DG1_REVID_A0, DG1_REVID_
Re: [Intel-gfx] [PATCH 03/11] drm/i915: Allow the sysadmin to override security mitigations
Quoting Abodunrin, Akeem G (2021-01-11 20:58:42) > > > > -Original Message- > > From: Intel-gfx On Behalf Of Chris > > Wilson > > Sent: Sunday, January 10, 2021 7:04 AM > > To: intel-gfx@lists.freedesktop.org > > Cc: sta...@vger.kernel.org; Chris Wilson > > Subject: [Intel-gfx] [PATCH 03/11] drm/i915: Allow the sysadmin to override > > security mitigations > > > > The clear-residuals mitigation is a relatively heavy hammer and under some > > circumstances the user may wish to forgo the context isolation in order to > > meet some performance requirement. Introduce a generic module parameter > > to allow selectively enabling/disabling different mitigations. > Although this seems like ideal solution - giving users option to choose > *potential* performance over security or vice-versa - However, I would have > expected that this patch adds a DRM warning to inform users of the > consequences of their action, whenever module parameter is used to disable > any kind of mitigations. Well, that is my own perspective, not as a legal > expert. It's marked as unsafe; setting this parameter will issue a notice and taint the kernel. That should be enough to warn of the consequences of their actions, without going into the gruesome details. I very briefly considered a few pr_warn_once() for each disabled mitigation, but I am not sure what we should say to the user. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915/gt: Limit VFE threads based on GT
> -Original Message-
> From: Chris Wilson
> Sent: Monday, January 11, 2021 1:03 PM
> To: Abodunrin, Akeem G ; intel-
> g...@lists.freedesktop.org
> Cc: stable@ ; Randy Wright
>
> Subject: Re: [Intel-gfx] [PATCH 1/3] drm/i915/gt: Limit VFE threads based on
> GT
>
> Quoting Abodunrin, Akeem G (2021-01-11 20:25:34)
> > > static void
> > > batch_get_defaults(struct drm_i915_private *i915, struct batch_vals *bv)
> {
> > > if (IS_HASWELL(i915)) {
> > > - bv->max_primitives = 280;
> > > - bv->max_urb_entries = MAX_URB_ENTRIES;
> > > + switch (INTEL_INFO(i915)->gt) {
> > > + default:
> > > + case 1:
> > > + bv->max_threads = 70;
> > > + break;
> > > + case 2:
> > > + bv->max_threads = 140;
> > > + break;
> > > + case 3:
> > > + bv->max_threads = 280;
> > > + break;
> > > + }
> > > bv->surface_height = 16 * 16;
> > > bv->surface_width = 32 * 2 * 16;
> > > } else {
> > > - bv->max_primitives = 128;
> > > - bv->max_urb_entries = MAX_URB_ENTRIES / 2;
> > > + switch (INTEL_INFO(i915)->gt) {
> > > + default:
> > > + case 1: /* including vlv */
> > > + bv->max_threads = 36;
> > > + break;
> > > + case 2:
> > > + bv->max_threads = 128;
> > > + break;
> > > + }
> > Do we really need to hardcode max number of threads per gt/platform?
> Why not calculating the number of active threads from the no_of_slices *
> 1024? - Also, is "64" not the minimum number of threads supported?
>
> ivb,byt,hsw each has different numbers of threads per subslice, and each gt
> has a different number of subslice/slice (and not a simple doubling of
> subslice/slice from 1 -> 2 -> 3, although the total is!).
>
> It's a choice between encoding a tuple for (num_threads, num_subslices,
> num_slices) or the combined value.
>
> The goal is to run a shader in each HW thread to clear the thread-local
> registers, and only one shader in each.
> -Chris
Okay, let's go with simplified solution to achieve our goal here, instead of
complex calculation...
Reviewed-by: Akeem G Abodunrin
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/11] drm/i915/gt: Limit VFE threads based on GT
On Mon, Jan 11, 2021 at 08:51:23PM +, Chris Wilson wrote:
> Quoting Rodrigo Vivi (2021-01-11 17:35:12)
> > On Sun, Jan 10, 2021 at 03:03:54PM +, Chris Wilson wrote:
> > > MEDIA_STATE_VFE only accepts the 'maximum number of threads' in the
> > > range [0, n-1] where n is #EU * (#threads/EU) with the number of threads
> > > based on plaform and the number of EU based on the number of slices and
> > > subslices. This is a fixed number per platform/gt, so appropriately
> > > limit the number of threads we spawn to match the device.
> > >
> > > v2: Oversaturate the system with tasks to force execution on every HW
> > > thread; if the thread idles it is returned to the pool and may be reused
> > > again before an unused thread.
> > >
> > > v3: Fix more state commands, which was causing Baytrail to barf.
> >
> > CI is still not happy with byt right? or is that false positive?
>
> After v3, ivb still failed.
>
> > > v4: STATE_CACHE_INVALIDATE requires a stall on Ivybridge
>
> Right now with the multiple pipecontrls around the PIPELINE_SELECT *and*
> STATE_BASE, CI has been happy for multiple runs. I was able to reproduce
> the same selftests failures and confirm that we do not see any of those
> failures in a thousand iterations. High level of confidence, but since
> we are dealing with empirical results with cross-referencing to mesa who
> also have seen similar undocumented failures, there's still an element
> of doubt as to whether it is truly watertight.
>
> The CI results for this series passed on the all important ivb,byt,hsw.
great!
>
> > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2024
> > > Fixes: 47f8253d2b89 ("drm/i915/gen7: Clear all EU/L3 residual contexts")
> > > Signed-off-by: Chris Wilson
> > > Cc: Mika Kuoppala
> > > Cc: Prathap Kumar Valsan
> > > Cc: Akeem G Abodunrin
> > > Cc: Jon Bloomfield
> > > Cc: Rodrigo Vivi
> > > Cc: Randy Wright
> > > Cc: sta...@vger.kernel.org # v5.7+
> > > ---
> > > drivers/gpu/drm/i915/gt/gen7_renderclear.c | 157 -
> > > 1 file changed, 94 insertions(+), 63 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/gen7_renderclear.c
> > > b/drivers/gpu/drm/i915/gt/gen7_renderclear.c
> > > index d93d85cd3027..f32a8e8040b2 100644
> > > --- a/drivers/gpu/drm/i915/gt/gen7_renderclear.c
> > > +++ b/drivers/gpu/drm/i915/gt/gen7_renderclear.c
> > > @@ -7,8 +7,6 @@
> > > #include "i915_drv.h"
> > > #include "intel_gpu_commands.h"
> > >
> > > -#define MAX_URB_ENTRIES 64
> > > -#define STATE_SIZE (4 * 1024)
> > > #define GT3_INLINE_DATA_DELAYS 0x1E00
> > > #define batch_advance(Y, CS) GEM_BUG_ON((Y)->end != (CS))
> > >
> > > @@ -34,38 +32,59 @@ struct batch_chunk {
> > > };
> > >
> > > struct batch_vals {
> > > - u32 max_primitives;
> > > - u32 max_urb_entries;
> > > - u32 cmd_size;
> > > - u32 state_size;
> > > + u32 max_threads;
> > > u32 state_start;
> > > - u32 batch_size;
> > > + u32 surface_start;
> > > u32 surface_height;
> > > u32 surface_width;
> > > - u32 scratch_size;
> > > - u32 max_size;
> > > + u32 size;
> > > };
> > >
> > > +static inline int num_primitives(const struct batch_vals *bv)
> > > +{
> > > + /*
> > > + * We need to saturate the GPU with work in order to dispatch
> > > + * a shader on every HW thread, and clear the thread-local
> > > registers.
> > > + * In short, we have to dispatch work faster than the shaders can
> > > + * run in order to fill occupy each HW thread.
> > > + */
> > > + return bv->max_threads;
> > > +}
> > > +
> > > static void
> > > batch_get_defaults(struct drm_i915_private *i915, struct batch_vals *bv)
> > > {
> > > if (IS_HASWELL(i915)) {
> > > - bv->max_primitives = 280;
> > > - bv->max_urb_entries = MAX_URB_ENTRIES;
> > > + switch (INTEL_INFO(i915)->gt) {
> > > + default:
> > > + case 1:
> > > + bv->max_threads = 70;
> > > + break;
> > > + case 2:
> > > + bv->max_threads = 140;
> > > + break;
> > > + case 3:
> > > + bv->max_threads = 280;
> > > + break;
> > > + }
> > > bv->surface_height = 16 * 16;
> > > bv->surface_width = 32 * 2 * 16;
> > > } else {
> > > - bv->max_primitives = 128;
> > > - bv->max_urb_entries = MAX_URB_ENTRIES / 2;
> > > + switch (INTEL_INFO(i915)->gt) {
> > > + default:
> > > + case 1: /* including vlv */
> > > + bv->max_threads = 36;
> > > + break;
> > > + case 2:
> > > + bv->max_threads = 128;
> > > + break;
> > > + }
> > > bv->surface_height = 16 * 8;
> > > bv->surface_width = 32 * 16;
> >
Re: [Intel-gfx] [PATCH 1/3] drm/i915/gt: Limit VFE threads based on GT
Quoting Abodunrin, Akeem G (2021-01-11 20:25:34)
> > static void
> > batch_get_defaults(struct drm_i915_private *i915, struct batch_vals *bv) {
> > if (IS_HASWELL(i915)) {
> > - bv->max_primitives = 280;
> > - bv->max_urb_entries = MAX_URB_ENTRIES;
> > + switch (INTEL_INFO(i915)->gt) {
> > + default:
> > + case 1:
> > + bv->max_threads = 70;
> > + break;
> > + case 2:
> > + bv->max_threads = 140;
> > + break;
> > + case 3:
> > + bv->max_threads = 280;
> > + break;
> > + }
> > bv->surface_height = 16 * 16;
> > bv->surface_width = 32 * 2 * 16;
> > } else {
> > - bv->max_primitives = 128;
> > - bv->max_urb_entries = MAX_URB_ENTRIES / 2;
> > + switch (INTEL_INFO(i915)->gt) {
> > + default:
> > + case 1: /* including vlv */
> > + bv->max_threads = 36;
> > + break;
> > + case 2:
> > + bv->max_threads = 128;
> > + break;
> > + }
> Do we really need to hardcode max number of threads per gt/platform? Why not
> calculating the number of active threads from the no_of_slices * 1024? -
> Also, is "64" not the minimum number of threads supported?
ivb,byt,hsw each has different numbers of threads per subslice, and each
gt has a different number of subslice/slice (and not a simple doubling
of subslice/slice from 1 -> 2 -> 3, although the total is!).
It's a choice between encoding a tuple for (num_threads, num_subslices,
num_slices) or the combined value.
The goal is to run a shader in each HW thread to clear the thread-local
registers, and only one shader in each.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/11] drm/i915: Allow the sysadmin to override security mitigations
> -Original Message-
> From: Intel-gfx On Behalf Of Chris
> Wilson
> Sent: Sunday, January 10, 2021 7:04 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: sta...@vger.kernel.org; Chris Wilson
> Subject: [Intel-gfx] [PATCH 03/11] drm/i915: Allow the sysadmin to override
> security mitigations
>
> The clear-residuals mitigation is a relatively heavy hammer and under some
> circumstances the user may wish to forgo the context isolation in order to
> meet some performance requirement. Introduce a generic module parameter
> to allow selectively enabling/disabling different mitigations.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1858
> Fixes: 47f8253d2b89 ("drm/i915/gen7: Clear all EU/L3 residual contexts")
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Jon Bloomfield
> Cc: Rodrigo Vivi
> Cc: sta...@vger.kernel.org # v5.7
> ---
> drivers/gpu/drm/i915/Makefile | 1 +
> .../gpu/drm/i915/gt/intel_ring_submission.c | 4 +-
> drivers/gpu/drm/i915/i915_mitigations.c | 148 ++
> drivers/gpu/drm/i915/i915_mitigations.h | 13 ++
> 4 files changed, 165 insertions(+), 1 deletion(-) create mode 100644
> drivers/gpu/drm/i915/i915_mitigations.c
> create mode 100644 drivers/gpu/drm/i915/i915_mitigations.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 4074d8cb0d6e..48f82c354611 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -38,6 +38,7 @@ i915-y += i915_drv.o \
> i915_config.o \
> i915_irq.o \
> i915_getparam.o \
> + i915_mitigations.o \
> i915_params.o \
> i915_pci.o \
> i915_scatterlist.o \
> diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> index 724d56c9583d..657afd8ebc14 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> @@ -32,6 +32,7 @@
> #include "gen6_ppgtt.h"
> #include "gen7_renderclear.h"
> #include "i915_drv.h"
> +#include "i915_mitigations.h"
> #include "intel_breadcrumbs.h"
> #include "intel_context.h"
> #include "intel_gt.h"
> @@ -918,7 +919,8 @@ static int switch_context(struct i915_request *rq)
> GEM_BUG_ON(HAS_EXECLISTS(engine->i915));
>
> if (engine->wa_ctx.vma && ce != engine->kernel_context) {
> - if (engine->wa_ctx.vma->private != ce) {
> + if (engine->wa_ctx.vma->private != ce &&
> + i915_mitigate_clear_residuals()) {
> ret = clear_residuals(rq);
> if (ret)
> return ret;
> diff --git a/drivers/gpu/drm/i915/i915_mitigations.c
> b/drivers/gpu/drm/i915/i915_mitigations.c
> new file mode 100644
> index ..8d5637cfa734
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/i915_mitigations.c
> @@ -0,0 +1,148 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2021 Intel Corporation
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include "i915_drv.h"
> +#include "i915_mitigations.h"
> +
> +static unsigned long mitigations = ~0UL;
> +
> +enum {
> + CLEAR_RESIDUALS = 0,
> +};
> +
> +static const char * const names[] = {
> + [CLEAR_RESIDUALS] = "residuals",
> +};
> +
> +bool i915_mitigate_clear_residuals(void)
> +{
> + return READ_ONCE(mitigations) & BIT(CLEAR_RESIDUALS); }
> +
> +static int mitigations_set(const char *val, const struct kernel_param
> +*kp) {
> + unsigned long new = ~0UL;
> + char *str, *sep, *tok;
> + bool first = true;
> + int err = 0;
> +
> + BUILD_BUG_ON(ARRAY_SIZE(names) >=
> BITS_PER_TYPE(mitigations));
> +
> + str = kstrdup(val, GFP_KERNEL);
> + if (!str)
> + return -ENOMEM;
> +
> + for (sep = str; (tok = strsep(&sep, ","));) {
> + bool enable = true;
> + int i;
> +
> + /* Be tolerant of leading/trailing whitespace */
> + tok = strim(tok);
> +
> + if (first) {
> + first = false;
> +
> + if (!strcmp(tok, "auto")) {
> + new = ~0UL;
> + continue;
> + }
> +
> + new = 0;
> + if (!strcmp(tok, "off"))
> + continue;
> + }
> +
> + if (*tok == '!') {
> + enable = !enable;
> + tok++;
> + }
> +
> + if (!strncmp(tok, "no", 2)) {
> + enable = !enable;
> + tok += 2;
> + }
> +
> + if (*tok == '\0')
> + continue;
> +
> + for (i = 0; i < ARRAY_SIZE(names); i++) {
> + if (!strcmp(tok, names[i])) {
> + if (enable)
> + new |=
Re: [Intel-gfx] [PATCH 1/2] drm/i915/tgl: Use TGL stepping info for applying WAs
On Mon, Jan 11, 2021 at 10:18:45PM +0200, Jani Nikula wrote: > On Mon, 11 Jan 2021, Jani Nikula wrote: > > On Fri, 08 Jan 2021, Matt Roper wrote: > >> On Fri, Jan 08, 2021 at 03:18:52PM -0800, Aditya Swarup wrote: > >>> TGL adds another level of indirection for applying WA based on stepping > >>> information rather than PCI REVID. So change TGL_REVID enum into > >>> stepping enum and use PCI REVID as index into revid to stepping table to > >>> fetch correct display and GT stepping for application of WAs as > >>> suggested by Matt Roper. > >> > >> So to clarify the goal is to rename "revid" -> "stepping" because the > >> values like "A1," "C0," etc. are't the actual PCI revision ID, but > >> rather descriptions of the stepping of a given IP block; the enum values > >> we use to represent those are arbitrary and don't matter as long as > >> they're monotonically increasing for comparisons. The PCI revision ID > >> is just the input we use today to deduce what the IP steppings are, and > >> there's talk that we could determine the IP steppings in a different way > >> at some point in the future. > >> > >> Furthermore, since the same scheme will be used at least for ADL-S, we > >> should drop the "TGL" prefix since there's no need to name these general > >> enum values in a platform-specific manner. > >> > >> Reviewed-by: Matt Roper > >> > >> We should probably make the same kind of change to KBL (and use the same > >> stepping enum) too since it has the same kind of extra indirection as > >> TGL/ADL-S, but we can do that as a followup patch. > > > > FWIW I have a wip series changing the whole thing to abstract steppings > > enums that are shared between platforms, but it's in a bit of limbo > > because the previous revid changes were applied to drm-intel-gt-next, > > and it's fallen pretty far out of sync with drm-intel-next. All of this > > really belongs to drm-intel-next, but can't do that until the branches > > sync up again. > > Btw this series doesn't apply to drm-intel-next either, for the same > reason, and the ADL-S platform definition and PCI IDs must *not* be > applied to drm-intel-gt-next. So to clarify, it looks like we have a bunch of revid changes to the display code that got merged to the gt-next tree but not to the intel-next tree? Should we be going back and also merging / cherry-picking those over to intel-next since that's where the display changes are supposed to go, or is it too late to do that cleanly at this point? Going forward, what should the general strategy be for stuff like platform definitions and such? Merge such enablement patches to both intel-next and gt-next at the same time so that the basic definitions are available to both trees? It seems like the whole split into two trees really isn't working well and is just leading to more mistakes and bottlenecks. What benefit are we supposed to be getting from this split? Matt > > BR, > Jani. > > > > > My series also completely hides the arrays into a separate .c file, > > because the externs with direct array access are turning into > > nightmare. The ARRAY_SIZE() checks rely on the extern declaration and > > the actual array definition to have the sizes in sync, but the compiler > > does not check that. Really. > > > > IDK, feels like this merging this series is going to be extra churn. > > > > > > BR, > > Jani. > > > > > >> > >> > >> Matt > >> > >>> > >>> Cc: Matt Roper > >>> Cc: Lucas De Marchi > >>> Cc: José Roberto de Souza > >>> Signed-off-by: Aditya Swarup > >>> --- > >>> .../drm/i915/display/intel_display_power.c| 2 +- > >>> drivers/gpu/drm/i915/display/intel_psr.c | 4 +- > >>> drivers/gpu/drm/i915/display/intel_sprite.c | 2 +- > >>> drivers/gpu/drm/i915/gt/intel_workarounds.c | 26 +- > >>> drivers/gpu/drm/i915/i915_drv.h | 50 +-- > >>> drivers/gpu/drm/i915/intel_pm.c | 2 +- > >>> 6 files changed, 43 insertions(+), 43 deletions(-) > >>> > >>> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c > >>> b/drivers/gpu/drm/i915/display/intel_display_power.c > >>> index d52374f01316..bb04b502a442 100644 > >>> --- a/drivers/gpu/drm/i915/display/intel_display_power.c > >>> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c > >>> @@ -5340,7 +5340,7 @@ static void tgl_bw_buddy_init(struct > >>> drm_i915_private *dev_priv) > >>> int config, i; > >>> > >>> if (IS_DG1_REVID(dev_priv, DG1_REVID_A0, DG1_REVID_A0) || > >>> - IS_TGL_DISP_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_B0)) > >>> + IS_TGL_DISP_STEPPING(dev_priv, STEP_A0, STEP_B0)) > >>> /* Wa_1409767108:tgl,dg1 */ > >>> table = wa_1409767108_buddy_page_masks; > >>> else > >>> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c > >>> b/drivers/gpu/drm/i915/display/intel_psr.c > >>> index c24ae69426cf..a93717178957 100644 > >>> --- a/drivers/gpu/drm/i915/display/intel_psr.c > >>> +++ b/drivers/gpu/drm/i915/display/intel_psr.c > >
Re: [Intel-gfx] [PATCH v6 16/64] drm/i915: Fix userptr so we do not have to worry about obj->mm.lock, v5.
On Wed, 6 Jan 2021 at 01:46, Maarten Lankhorst
wrote:
>
> Instead of doing what we do currently, which will never work with
> PROVE_LOCKING, do the same as AMD does, and something similar to
> relocation slowpath. When all locks are dropped, we acquire the
> pages for pinning. When the locks are taken, we transfer those
> pages in .get_pages() to the bo. As a final check before installing
> the fences, we ensure that the mmu notifier was not called; if it is,
> we return -EAGAIN to userspace to signal it has to start over.
>
> Changes since v1:
> - Unbinding is done in submit_init only. submit_begin() removed.
> - MMU_NOTFIER -> MMU_NOTIFIER
> Changes since v2:
> - Make i915->mm.notifier a spinlock.
> Changes since v3:
> - Add WARN_ON if there are any page references left, should have been 0.
> - Return 0 on success in submit_init(), bug from spinlock conversion.
> - Release pvec outside of notifier_lock (Thomas).
> Changes since v4:
> - Mention why we're clearing eb->[i + 1].vma in the code. (Thomas)
> - Actually check all invalidations in eb_move_to_gpu. (Thomas)
> - Do not wait when process is exiting to fix gem_ctx_persistence.userptr.
>
> Signed-off-by: Maarten Lankhorst
Acked-by: Dave Airlie
This isn't a review so much as a land this over objections.
Dave.
> ---
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 101 ++-
> drivers/gpu/drm/i915/gem/i915_gem_object.h| 35 +-
> .../gpu/drm/i915/gem/i915_gem_object_types.h | 10 +-
> drivers/gpu/drm/i915/gem/i915_gem_pages.c | 2 +-
> drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 765 ++
> drivers/gpu/drm/i915/i915_drv.h | 9 +-
> drivers/gpu/drm/i915/i915_gem.c | 5 +-
> 7 files changed, 344 insertions(+), 583 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 77de94e45f55..d4c065c1da06 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -53,14 +53,16 @@ enum {
> /* __EXEC_OBJECT_NO_RESERVE is BIT(31), defined in i915_vma.h */
> #define __EXEC_OBJECT_HAS_PIN BIT(30)
> #define __EXEC_OBJECT_HAS_FENCEBIT(29)
> -#define __EXEC_OBJECT_NEEDS_MAPBIT(28)
> -#define __EXEC_OBJECT_NEEDS_BIAS BIT(27)
> -#define __EXEC_OBJECT_INTERNAL_FLAGS (~0u << 27) /* all of the above + */
> +#define __EXEC_OBJECT_USERPTR_INIT BIT(28)
> +#define __EXEC_OBJECT_NEEDS_MAPBIT(27)
> +#define __EXEC_OBJECT_NEEDS_BIAS BIT(26)
> +#define __EXEC_OBJECT_INTERNAL_FLAGS (~0u << 26) /* all of the above + */
> #define __EXEC_OBJECT_RESERVED (__EXEC_OBJECT_HAS_PIN |
> __EXEC_OBJECT_HAS_FENCE)
>
> #define __EXEC_HAS_RELOC BIT(31)
> #define __EXEC_ENGINE_PINNED BIT(30)
> -#define __EXEC_INTERNAL_FLAGS (~0u << 30)
> +#define __EXEC_USERPTR_USEDBIT(29)
> +#define __EXEC_INTERNAL_FLAGS (~0u << 29)
> #define UPDATE PIN_OFFSET_FIXED
>
> #define BATCH_OFFSET_BIAS (256*1024)
> @@ -864,6 +866,26 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb)
> }
>
> eb_add_vma(eb, i, batch, vma);
> +
> + if (i915_gem_object_is_userptr(vma->obj)) {
> + err = i915_gem_object_userptr_submit_init(vma->obj);
> + if (err) {
> + if (i + 1 < eb->buffer_count) {
> + /*
> +* Execbuffer code expects last vma
> entry to be NULL,
> +* since we already initialized this
> entry,
> +* set the next value to NULL or we
> mess up
> +* cleanup handling.
> +*/
> + eb->vma[i + 1].vma = NULL;
> + }
> +
> + return err;
> + }
> +
> + eb->vma[i].flags |= __EXEC_OBJECT_USERPTR_INIT;
> + eb->args->flags |= __EXEC_USERPTR_USED;
> + }
> }
>
> if (unlikely(eb->batch->flags & EXEC_OBJECT_WRITE)) {
> @@ -965,7 +987,7 @@ eb_get_vma(const struct i915_execbuffer *eb, unsigned
> long handle)
> }
> }
>
> -static void eb_release_vmas(struct i915_execbuffer *eb, bool final)
> +static void eb_release_vmas(struct i915_execbuffer *eb, bool final, bool
> release_userptr)
> {
> const unsigned int count = eb->buffer_count;
> unsigned int i;
> @@ -979,6 +1001,11 @@ static void eb_release_vmas(struct i915_execbuffer *eb,
> bool final)
>
> eb_unreserve_vma(ev);
>
> + if (release_userptr && ev->flags &
> __EXEC_OBJECT_USERPTR_INIT) {
> + ev->flags &= ~__EXEC_OBJECT_USERPTR_INIT;
> +
Re: [Intel-gfx] [PATCH 01/11] drm/i915/gt: Limit VFE threads based on GT
Quoting Rodrigo Vivi (2021-01-11 17:35:12)
> On Sun, Jan 10, 2021 at 03:03:54PM +, Chris Wilson wrote:
> > MEDIA_STATE_VFE only accepts the 'maximum number of threads' in the
> > range [0, n-1] where n is #EU * (#threads/EU) with the number of threads
> > based on plaform and the number of EU based on the number of slices and
> > subslices. This is a fixed number per platform/gt, so appropriately
> > limit the number of threads we spawn to match the device.
> >
> > v2: Oversaturate the system with tasks to force execution on every HW
> > thread; if the thread idles it is returned to the pool and may be reused
> > again before an unused thread.
> >
> > v3: Fix more state commands, which was causing Baytrail to barf.
>
> CI is still not happy with byt right? or is that false positive?
After v3, ivb still failed.
> > v4: STATE_CACHE_INVALIDATE requires a stall on Ivybridge
Right now with the multiple pipecontrls around the PIPELINE_SELECT *and*
STATE_BASE, CI has been happy for multiple runs. I was able to reproduce
the same selftests failures and confirm that we do not see any of those
failures in a thousand iterations. High level of confidence, but since
we are dealing with empirical results with cross-referencing to mesa who
also have seen similar undocumented failures, there's still an element
of doubt as to whether it is truly watertight.
The CI results for this series passed on the all important ivb,byt,hsw.
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2024
> > Fixes: 47f8253d2b89 ("drm/i915/gen7: Clear all EU/L3 residual contexts")
> > Signed-off-by: Chris Wilson
> > Cc: Mika Kuoppala
> > Cc: Prathap Kumar Valsan
> > Cc: Akeem G Abodunrin
> > Cc: Jon Bloomfield
> > Cc: Rodrigo Vivi
> > Cc: Randy Wright
> > Cc: sta...@vger.kernel.org # v5.7+
> > ---
> > drivers/gpu/drm/i915/gt/gen7_renderclear.c | 157 -
> > 1 file changed, 94 insertions(+), 63 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/gen7_renderclear.c
> > b/drivers/gpu/drm/i915/gt/gen7_renderclear.c
> > index d93d85cd3027..f32a8e8040b2 100644
> > --- a/drivers/gpu/drm/i915/gt/gen7_renderclear.c
> > +++ b/drivers/gpu/drm/i915/gt/gen7_renderclear.c
> > @@ -7,8 +7,6 @@
> > #include "i915_drv.h"
> > #include "intel_gpu_commands.h"
> >
> > -#define MAX_URB_ENTRIES 64
> > -#define STATE_SIZE (4 * 1024)
> > #define GT3_INLINE_DATA_DELAYS 0x1E00
> > #define batch_advance(Y, CS) GEM_BUG_ON((Y)->end != (CS))
> >
> > @@ -34,38 +32,59 @@ struct batch_chunk {
> > };
> >
> > struct batch_vals {
> > - u32 max_primitives;
> > - u32 max_urb_entries;
> > - u32 cmd_size;
> > - u32 state_size;
> > + u32 max_threads;
> > u32 state_start;
> > - u32 batch_size;
> > + u32 surface_start;
> > u32 surface_height;
> > u32 surface_width;
> > - u32 scratch_size;
> > - u32 max_size;
> > + u32 size;
> > };
> >
> > +static inline int num_primitives(const struct batch_vals *bv)
> > +{
> > + /*
> > + * We need to saturate the GPU with work in order to dispatch
> > + * a shader on every HW thread, and clear the thread-local registers.
> > + * In short, we have to dispatch work faster than the shaders can
> > + * run in order to fill occupy each HW thread.
> > + */
> > + return bv->max_threads;
> > +}
> > +
> > static void
> > batch_get_defaults(struct drm_i915_private *i915, struct batch_vals *bv)
> > {
> > if (IS_HASWELL(i915)) {
> > - bv->max_primitives = 280;
> > - bv->max_urb_entries = MAX_URB_ENTRIES;
> > + switch (INTEL_INFO(i915)->gt) {
> > + default:
> > + case 1:
> > + bv->max_threads = 70;
> > + break;
> > + case 2:
> > + bv->max_threads = 140;
> > + break;
> > + case 3:
> > + bv->max_threads = 280;
> > + break;
> > + }
> > bv->surface_height = 16 * 16;
> > bv->surface_width = 32 * 2 * 16;
> > } else {
> > - bv->max_primitives = 128;
> > - bv->max_urb_entries = MAX_URB_ENTRIES / 2;
> > + switch (INTEL_INFO(i915)->gt) {
> > + default:
> > + case 1: /* including vlv */
> > + bv->max_threads = 36;
> > + break;
> > + case 2:
> > + bv->max_threads = 128;
> > + break;
> > + }
> > bv->surface_height = 16 * 8;
> > bv->surface_width = 32 * 16;
>
> all the values above matches the spec.
>
> > }
> > - bv->cmd_size = bv->max_primitives * 4096;
> > - bv->state_size = STATE_SIZE;
> > - bv->state_start = bv->cmd_size;
> > - bv->batch_size = bv->cmd_size + bv->state_size;
> > - bv->scratch_size = bv->surface_height * bv->surface_width;
> > -
Re: [Intel-gfx] [PATCH v6 14/64] drm/i915: Reject UNSYNCHRONIZED for userptr, v2.
Acked-by: Dave Airlie
burn with the fire.
Dave.
On Wed, 6 Jan 2021 at 01:46, Maarten Lankhorst
wrote:
>
> We should not allow this any more, as it will break with the new userptr
> implementation, it could still be made to work, but there's no point in
> doing so.
>
> Inspection of the beignet opencl driver shows that it's only used
> when normal userptr is not available, which means for new kernels
> you will need CONFIG_I915_USERPTR.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 10 ++
> 1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> index 64a946d5f753..241f865077b9 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> @@ -224,7 +224,7 @@ i915_gem_userptr_init__mmu_notifier(struct
> drm_i915_gem_object *obj,
> struct i915_mmu_object *mo;
>
> if (flags & I915_USERPTR_UNSYNCHRONIZED)
> - return capable(CAP_SYS_ADMIN) ? 0 : -EPERM;
> + return -ENODEV;
>
> if (GEM_WARN_ON(!obj->userptr.mm))
> return -EINVAL;
> @@ -274,13 +274,7 @@ static int
> i915_gem_userptr_init__mmu_notifier(struct drm_i915_gem_object *obj,
> unsigned flags)
> {
> - if ((flags & I915_USERPTR_UNSYNCHRONIZED) == 0)
> - return -ENODEV;
> -
> - if (!capable(CAP_SYS_ADMIN))
> - return -EPERM;
> -
> - return 0;
> + return -ENODEV;
> }
>
> static void
> --
> 2.30.0.rc1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915/gt: Restore clear-residual mitigations for Ivybridge, Baytrail
> -Original Message-
> From: Chris Wilson
> Sent: Saturday, January 09, 2021 7:50 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Chris Wilson ; Mika Kuoppala
> ; Kumar Valsan, Prathap
> ; Abodunrin, Akeem G
> ; Bloomfield, Jon
>
> Subject: [PATCH 2/3] drm/i915/gt: Restore clear-residual mitigations for
> Ivybridge, Baytrail
>
> The mitigation is required for all gen7 platforms, now that it does not cause
> GPU hangs, restore it for Ivybridge and Baytrail.
>
> Fixes: 47f8253d2b89 ("drm/i915/gen7: Clear all EU/L3 residual contexts")
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Prathap Kumar Valsan
> Cc: Akeem G Abodunrin
> Cc: Bloomfield Jon
> ---
> drivers/gpu/drm/i915/gt/intel_ring_submission.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> index 4ea741f488a8..72d4722441bf 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> @@ -1326,7 +1326,7 @@ int intel_ring_submission_setup(struct
> intel_engine_cs *engine)
>
> GEM_BUG_ON(timeline->hwsp_ggtt != engine->status_page.vma);
>
> - if (IS_HASWELL(engine->i915) && engine->class == RENDER_CLASS) {
> + if (IS_GEN(engine->i915, 7) && engine->class == RENDER_CLASS) {
> err = gen7_ctx_switch_bb_init(engine);
> if (err)
> goto err_ring_unpin;
> --
> 2.20.1
I tried hard to remember why checking for HSW platform specifically in this
case, since mitigation is applicable to all gen 7 (including 7.5) platforms -
but couldn't recall why, and see no reason in the code doing it that way - so
the changes make sense...
Reviewed-by: Akeem G Abodunrin
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915/gt: Limit VFE threads based on GT
> -Original Message-
> From: Chris Wilson
> Sent: Saturday, January 09, 2021 7:49 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Chris Wilson ; Mika Kuoppala
> ; Kumar Valsan, Prathap
> ; Abodunrin, Akeem G
> ; Bloomfield, Jon
> ; Vivi, Rodrigo ; Randy
> Wright ; sta...@vger.kernel.org
> Subject: [PATCH 1/3] drm/i915/gt: Limit VFE threads based on GT
>
> MEDIA_STATE_VFE only accepts the 'maximum number of threads' in the
> range [0, n-1] where n is #EU * (#threads/EU) with the number of threads
> based on plaform and the number of EU based on the number of slices and
> subslices. This is a fixed number per platform/gt, so appropriately limit the
> number of threads we spawn to match the device.
>
> v2: Oversaturate the system with tasks to force execution on every HW
> thread; if the thread idles it is returned to the pool and may be reused again
> before an unused thread.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2024
> Fixes: 47f8253d2b89 ("drm/i915/gen7: Clear all EU/L3 residual contexts")
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Prathap Kumar Valsan
> Cc: Akeem G Abodunrin
> Cc: Jon Bloomfield
> Cc: Rodrigo Vivi
> Cc: Randy Wright
> Cc: sta...@vger.kernel.org # v5.7+
> ---
> drivers/gpu/drm/i915/gt/gen7_renderclear.c | 91 --
> 1 file changed, 49 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/gen7_renderclear.c
> b/drivers/gpu/drm/i915/gt/gen7_renderclear.c
> index d93d85cd3027..3ea7c9cc0f3d 100644
> --- a/drivers/gpu/drm/i915/gt/gen7_renderclear.c
> +++ b/drivers/gpu/drm/i915/gt/gen7_renderclear.c
> @@ -7,8 +7,6 @@
> #include "i915_drv.h"
> #include "intel_gpu_commands.h"
>
> -#define MAX_URB_ENTRIES 64
> -#define STATE_SIZE (4 * 1024)
> #define GT3_INLINE_DATA_DELAYS 0x1E00
> #define batch_advance(Y, CS) GEM_BUG_ON((Y)->end != (CS))
>
> @@ -34,38 +32,57 @@ struct batch_chunk { };
>
> struct batch_vals {
> - u32 max_primitives;
> - u32 max_urb_entries;
> - u32 cmd_size;
> - u32 state_size;
> + u32 max_threads;
> u32 state_start;
> - u32 batch_size;
> + u32 surface_start;
> u32 surface_height;
> u32 surface_width;
> - u32 scratch_size;
> - u32 max_size;
> + u32 size;
> };
>
> +static inline int num_primitives(const struct batch_vals *bv) {
> + /*
> + * We need to oversaturate the GPU with work in order to dispatch
> + * a shader on every HW thread.
> + */
> + return bv->max_threads + 2;
> +}
> +
> static void
> batch_get_defaults(struct drm_i915_private *i915, struct batch_vals *bv) {
> if (IS_HASWELL(i915)) {
> - bv->max_primitives = 280;
> - bv->max_urb_entries = MAX_URB_ENTRIES;
> + switch (INTEL_INFO(i915)->gt) {
> + default:
> + case 1:
> + bv->max_threads = 70;
> + break;
> + case 2:
> + bv->max_threads = 140;
> + break;
> + case 3:
> + bv->max_threads = 280;
> + break;
> + }
> bv->surface_height = 16 * 16;
> bv->surface_width = 32 * 2 * 16;
> } else {
> - bv->max_primitives = 128;
> - bv->max_urb_entries = MAX_URB_ENTRIES / 2;
> + switch (INTEL_INFO(i915)->gt) {
> + default:
> + case 1: /* including vlv */
> + bv->max_threads = 36;
> + break;
> + case 2:
> + bv->max_threads = 128;
> + break;
> + }
Do we really need to hardcode max number of threads per gt/platform? Why not
calculating the number of active threads from the no_of_slices * 1024? - Also,
is "64" not the minimum number of threads supported?
Thanks,
~Akeem
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/tgl: Use TGL stepping info for applying WAs
On 1/11/21 12:13 PM, Jani Nikula wrote:
> On Fri, 08 Jan 2021, Matt Roper wrote:
>> On Fri, Jan 08, 2021 at 03:18:52PM -0800, Aditya Swarup wrote:
>>> TGL adds another level of indirection for applying WA based on stepping
>>> information rather than PCI REVID. So change TGL_REVID enum into
>>> stepping enum and use PCI REVID as index into revid to stepping table to
>>> fetch correct display and GT stepping for application of WAs as
>>> suggested by Matt Roper.
>>
>> So to clarify the goal is to rename "revid" -> "stepping" because the
>> values like "A1," "C0," etc. are't the actual PCI revision ID, but
>> rather descriptions of the stepping of a given IP block; the enum values
>> we use to represent those are arbitrary and don't matter as long as
>> they're monotonically increasing for comparisons. The PCI revision ID
>> is just the input we use today to deduce what the IP steppings are, and
>> there's talk that we could determine the IP steppings in a different way
>> at some point in the future.
>>
>> Furthermore, since the same scheme will be used at least for ADL-S, we
>> should drop the "TGL" prefix since there's no need to name these general
>> enum values in a platform-specific manner.
>>
>> Reviewed-by: Matt Roper
>>
>> We should probably make the same kind of change to KBL (and use the same
>> stepping enum) too since it has the same kind of extra indirection as
>> TGL/ADL-S, but we can do that as a followup patch.
>
> FWIW I have a wip series changing the whole thing to abstract steppings
> enums that are shared between platforms, but it's in a bit of limbo
> because the previous revid changes were applied to drm-intel-gt-next,
> and it's fallen pretty far out of sync with drm-intel-next. All of this
> really belongs to drm-intel-next, but can't do that until the branches
> sync up again.
>
> My series also completely hides the arrays into a separate .c file,
> because the externs with direct array access are turning into
> nightmare. The ARRAY_SIZE() checks rely on the extern declaration and
> the actual array definition to have the sizes in sync, but the compiler
> does not check that. Really.
>
> IDK, feels like this merging this series is going to be extra churn.
We need ADLS support on drm-tip by WW05 and I don't think this should change
anything
as far as rebase is concerned as it will be just deletion of this entire
section to move
into the separate stepping/revid file in your implementation.
I think as a stop gap and to achieve the goal of ADLS patches being pushed in,
these patches
look good enough. If extern/array declaration was a concern, why were the
KBL/TGL pathces accepted
in the first place?
I will be happy to help with the rebase but the process of pushing ADLS patches
is stuck because of this.
Regards,
aswarup
>
>
> BR,
> Jani.
>
>
>>
>>
>> Matt
>>
>>>
>>> Cc: Matt Roper
>>> Cc: Lucas De Marchi
>>> Cc: José Roberto de Souza
>>> Signed-off-by: Aditya Swarup
>>> ---
>>> .../drm/i915/display/intel_display_power.c| 2 +-
>>> drivers/gpu/drm/i915/display/intel_psr.c | 4 +-
>>> drivers/gpu/drm/i915/display/intel_sprite.c | 2 +-
>>> drivers/gpu/drm/i915/gt/intel_workarounds.c | 26 +-
>>> drivers/gpu/drm/i915/i915_drv.h | 50 +--
>>> drivers/gpu/drm/i915/intel_pm.c | 2 +-
>>> 6 files changed, 43 insertions(+), 43 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
>>> b/drivers/gpu/drm/i915/display/intel_display_power.c
>>> index d52374f01316..bb04b502a442 100644
>>> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
>>> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
>>> @@ -5340,7 +5340,7 @@ static void tgl_bw_buddy_init(struct drm_i915_private
>>> *dev_priv)
>>> int config, i;
>>>
>>> if (IS_DG1_REVID(dev_priv, DG1_REVID_A0, DG1_REVID_A0) ||
>>> - IS_TGL_DISP_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_B0))
>>> + IS_TGL_DISP_STEPPING(dev_priv, STEP_A0, STEP_B0))
>>> /* Wa_1409767108:tgl,dg1 */
>>> table = wa_1409767108_buddy_page_masks;
>>> else
>>> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
>>> b/drivers/gpu/drm/i915/display/intel_psr.c
>>> index c24ae69426cf..a93717178957 100644
>>> --- a/drivers/gpu/drm/i915/display/intel_psr.c
>>> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
>>> @@ -550,7 +550,7 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
>>>
>>> if (dev_priv->psr.psr2_sel_fetch_enabled) {
>>> /* WA 1408330847 */
>>> - if (IS_TGL_DISP_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_A0) ||
>>> + if (IS_TGL_DISP_STEPPING(dev_priv, STEP_A0, STEP_A0) ||
>>> IS_RKL_REVID(dev_priv, RKL_REVID_A0, RKL_REVID_A0))
>>> intel_de_rmw(dev_priv, CHICKEN_PAR1_1,
>>> DIS_RAM_BYPASS_PSR2_MAN_TRACK,
>>> @@ -1102,7 +1102,7 @@ static void intel_psr_disable_locked(struct intel_dp
Re: [Intel-gfx] [PATCH 1/2] drm/i915/tgl: Use TGL stepping info for applying WAs
On Mon, 11 Jan 2021, Jani Nikula wrote:
> On Fri, 08 Jan 2021, Matt Roper wrote:
>> On Fri, Jan 08, 2021 at 03:18:52PM -0800, Aditya Swarup wrote:
>>> TGL adds another level of indirection for applying WA based on stepping
>>> information rather than PCI REVID. So change TGL_REVID enum into
>>> stepping enum and use PCI REVID as index into revid to stepping table to
>>> fetch correct display and GT stepping for application of WAs as
>>> suggested by Matt Roper.
>>
>> So to clarify the goal is to rename "revid" -> "stepping" because the
>> values like "A1," "C0," etc. are't the actual PCI revision ID, but
>> rather descriptions of the stepping of a given IP block; the enum values
>> we use to represent those are arbitrary and don't matter as long as
>> they're monotonically increasing for comparisons. The PCI revision ID
>> is just the input we use today to deduce what the IP steppings are, and
>> there's talk that we could determine the IP steppings in a different way
>> at some point in the future.
>>
>> Furthermore, since the same scheme will be used at least for ADL-S, we
>> should drop the "TGL" prefix since there's no need to name these general
>> enum values in a platform-specific manner.
>>
>> Reviewed-by: Matt Roper
>>
>> We should probably make the same kind of change to KBL (and use the same
>> stepping enum) too since it has the same kind of extra indirection as
>> TGL/ADL-S, but we can do that as a followup patch.
>
> FWIW I have a wip series changing the whole thing to abstract steppings
> enums that are shared between platforms, but it's in a bit of limbo
> because the previous revid changes were applied to drm-intel-gt-next,
> and it's fallen pretty far out of sync with drm-intel-next. All of this
> really belongs to drm-intel-next, but can't do that until the branches
> sync up again.
Btw this series doesn't apply to drm-intel-next either, for the same
reason, and the ADL-S platform definition and PCI IDs must *not* be
applied to drm-intel-gt-next.
BR,
Jani.
>
> My series also completely hides the arrays into a separate .c file,
> because the externs with direct array access are turning into
> nightmare. The ARRAY_SIZE() checks rely on the extern declaration and
> the actual array definition to have the sizes in sync, but the compiler
> does not check that. Really.
>
> IDK, feels like this merging this series is going to be extra churn.
>
>
> BR,
> Jani.
>
>
>>
>>
>> Matt
>>
>>>
>>> Cc: Matt Roper
>>> Cc: Lucas De Marchi
>>> Cc: José Roberto de Souza
>>> Signed-off-by: Aditya Swarup
>>> ---
>>> .../drm/i915/display/intel_display_power.c| 2 +-
>>> drivers/gpu/drm/i915/display/intel_psr.c | 4 +-
>>> drivers/gpu/drm/i915/display/intel_sprite.c | 2 +-
>>> drivers/gpu/drm/i915/gt/intel_workarounds.c | 26 +-
>>> drivers/gpu/drm/i915/i915_drv.h | 50 +--
>>> drivers/gpu/drm/i915/intel_pm.c | 2 +-
>>> 6 files changed, 43 insertions(+), 43 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
>>> b/drivers/gpu/drm/i915/display/intel_display_power.c
>>> index d52374f01316..bb04b502a442 100644
>>> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
>>> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
>>> @@ -5340,7 +5340,7 @@ static void tgl_bw_buddy_init(struct drm_i915_private
>>> *dev_priv)
>>> int config, i;
>>>
>>> if (IS_DG1_REVID(dev_priv, DG1_REVID_A0, DG1_REVID_A0) ||
>>> - IS_TGL_DISP_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_B0))
>>> + IS_TGL_DISP_STEPPING(dev_priv, STEP_A0, STEP_B0))
>>> /* Wa_1409767108:tgl,dg1 */
>>> table = wa_1409767108_buddy_page_masks;
>>> else
>>> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
>>> b/drivers/gpu/drm/i915/display/intel_psr.c
>>> index c24ae69426cf..a93717178957 100644
>>> --- a/drivers/gpu/drm/i915/display/intel_psr.c
>>> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
>>> @@ -550,7 +550,7 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
>>>
>>> if (dev_priv->psr.psr2_sel_fetch_enabled) {
>>> /* WA 1408330847 */
>>> - if (IS_TGL_DISP_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_A0) ||
>>> + if (IS_TGL_DISP_STEPPING(dev_priv, STEP_A0, STEP_A0) ||
>>> IS_RKL_REVID(dev_priv, RKL_REVID_A0, RKL_REVID_A0))
>>> intel_de_rmw(dev_priv, CHICKEN_PAR1_1,
>>> DIS_RAM_BYPASS_PSR2_MAN_TRACK,
>>> @@ -1102,7 +1102,7 @@ static void intel_psr_disable_locked(struct intel_dp
>>> *intel_dp)
>>>
>>> /* WA 1408330847 */
>>> if (dev_priv->psr.psr2_sel_fetch_enabled &&
>>> - (IS_TGL_DISP_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_A0) ||
>>> + (IS_TGL_DISP_STEPPING(dev_priv, STEP_A0, STEP_A0) ||
>>> IS_RKL_REVID(dev_priv, RKL_REVID_A0, RKL_REVID_A0)))
>>> intel_de_rmw(dev_priv, CHICKEN_PAR1_1,
>>> DIS_RAM_BYPASS_PSR2
[Intel-gfx] ✓ Fi.CI.BAT: success for Use TGL stepping info and add ADLS platform changes (rev2)
== Series Details == Series: Use TGL stepping info and add ADLS platform changes (rev2) URL : https://patchwork.freedesktop.org/series/85639/ State : success == Summary == CI Bug Log - changes from CI_DRM_9581 -> Patchwork_19317 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19317/index.html Known issues Here are the changes found in Patchwork_19317 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@semaphore: - fi-bdw-5557u: NOTRUN -> [SKIP][1] ([fdo#109271]) +26 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19317/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html * igt@amdgpu/amd_cs_nop@fork-gfx0: - fi-tgl-y: NOTRUN -> [SKIP][2] ([fdo#109315] / [i915#2575]) +15 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19317/fi-tgl-y/igt@amdgpu/amd_cs_...@fork-gfx0.html * igt@amdgpu/amd_cs_nop@sync-compute0: - fi-kbl-r: NOTRUN -> [SKIP][3] ([fdo#109271]) +20 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19317/fi-kbl-r/igt@amdgpu/amd_cs_...@sync-compute0.html * igt@core_hotunplug@unbind-rebind: - fi-bdw-5557u: NOTRUN -> [WARN][4] ([i915#2283]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19317/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html * igt@gem_huc_copy@huc-copy: - fi-kbl-r: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#2190]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19317/fi-kbl-r/igt@gem_huc_c...@huc-copy.html * igt@gem_tiled_blits@basic: - fi-tgl-y: NOTRUN -> [DMESG-WARN][6] ([i915#402]) +2 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19317/fi-tgl-y/igt@gem_tiled_bl...@basic.html * igt@i915_selftest@live@gt_lrc: - fi-tgl-y: NOTRUN -> [DMESG-FAIL][7] ([i915#2373]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19317/fi-tgl-y/igt@i915_selftest@live@gt_lrc.html * igt@i915_selftest@live@gt_pm: - fi-tgl-y: NOTRUN -> [DMESG-FAIL][8] ([i915#1759]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19317/fi-tgl-y/igt@i915_selftest@live@gt_pm.html * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy: - fi-snb-2600:NOTRUN -> [SKIP][9] ([fdo#109271]) +30 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19317/fi-snb-2600/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html * igt@kms_chamelium@dp-crc-fast: - fi-bdw-5557u: NOTRUN -> [SKIP][10] ([fdo#109271] / [fdo#111827]) +8 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19317/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html * igt@kms_chamelium@hdmi-crc-fast: - fi-snb-2600:NOTRUN -> [SKIP][11] ([fdo#109271] / [fdo#111827]) +8 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19317/fi-snb-2600/igt@kms_chamel...@hdmi-crc-fast.html * igt@kms_chamelium@hdmi-edid-read: - fi-kbl-r: NOTRUN -> [SKIP][12] ([fdo#109271] / [fdo#111827]) +8 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19317/fi-kbl-r/igt@kms_chamel...@hdmi-edid-read.html * igt@kms_chamelium@vga-edid-read: - fi-tgl-y: NOTRUN -> [SKIP][13] ([fdo#111827]) +8 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19317/fi-tgl-y/igt@kms_chamel...@vga-edid-read.html * igt@kms_force_connector_basic@force-load-detect: - fi-tgl-y: NOTRUN -> [SKIP][14] ([fdo#109285]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19317/fi-tgl-y/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-kbl-r: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#533]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19317/fi-kbl-r/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html Possible fixes * igt@gem_exec_suspend@basic-s3: - fi-snb-2600:[DMESG-WARN][16] ([i915#2772]) -> [PASS][17] [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9581/fi-snb-2600/igt@gem_exec_susp...@basic-s3.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19317/fi-snb-2600/igt@gem_exec_susp...@basic-s3.html Warnings * igt@i915_hangman@error-state-basic: - fi-apl-guc: [DMESG-WARN][18] -> [DMESG-WARN][19] ([i915#1610]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9581/fi-apl-guc/igt@i915_hang...@error-state-basic.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19317/fi-apl-guc/igt@i915_hang...@error-state-basic.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
Re: [Intel-gfx] [PATCH 1/2] drm/i915/tgl: Use TGL stepping info for applying WAs
On Fri, 08 Jan 2021, Matt Roper wrote:
> On Fri, Jan 08, 2021 at 03:18:52PM -0800, Aditya Swarup wrote:
>> TGL adds another level of indirection for applying WA based on stepping
>> information rather than PCI REVID. So change TGL_REVID enum into
>> stepping enum and use PCI REVID as index into revid to stepping table to
>> fetch correct display and GT stepping for application of WAs as
>> suggested by Matt Roper.
>
> So to clarify the goal is to rename "revid" -> "stepping" because the
> values like "A1," "C0," etc. are't the actual PCI revision ID, but
> rather descriptions of the stepping of a given IP block; the enum values
> we use to represent those are arbitrary and don't matter as long as
> they're monotonically increasing for comparisons. The PCI revision ID
> is just the input we use today to deduce what the IP steppings are, and
> there's talk that we could determine the IP steppings in a different way
> at some point in the future.
>
> Furthermore, since the same scheme will be used at least for ADL-S, we
> should drop the "TGL" prefix since there's no need to name these general
> enum values in a platform-specific manner.
>
> Reviewed-by: Matt Roper
>
> We should probably make the same kind of change to KBL (and use the same
> stepping enum) too since it has the same kind of extra indirection as
> TGL/ADL-S, but we can do that as a followup patch.
FWIW I have a wip series changing the whole thing to abstract steppings
enums that are shared between platforms, but it's in a bit of limbo
because the previous revid changes were applied to drm-intel-gt-next,
and it's fallen pretty far out of sync with drm-intel-next. All of this
really belongs to drm-intel-next, but can't do that until the branches
sync up again.
My series also completely hides the arrays into a separate .c file,
because the externs with direct array access are turning into
nightmare. The ARRAY_SIZE() checks rely on the extern declaration and
the actual array definition to have the sizes in sync, but the compiler
does not check that. Really.
IDK, feels like this merging this series is going to be extra churn.
BR,
Jani.
>
>
> Matt
>
>>
>> Cc: Matt Roper
>> Cc: Lucas De Marchi
>> Cc: José Roberto de Souza
>> Signed-off-by: Aditya Swarup
>> ---
>> .../drm/i915/display/intel_display_power.c| 2 +-
>> drivers/gpu/drm/i915/display/intel_psr.c | 4 +-
>> drivers/gpu/drm/i915/display/intel_sprite.c | 2 +-
>> drivers/gpu/drm/i915/gt/intel_workarounds.c | 26 +-
>> drivers/gpu/drm/i915/i915_drv.h | 50 +--
>> drivers/gpu/drm/i915/intel_pm.c | 2 +-
>> 6 files changed, 43 insertions(+), 43 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
>> b/drivers/gpu/drm/i915/display/intel_display_power.c
>> index d52374f01316..bb04b502a442 100644
>> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
>> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
>> @@ -5340,7 +5340,7 @@ static void tgl_bw_buddy_init(struct drm_i915_private
>> *dev_priv)
>> int config, i;
>>
>> if (IS_DG1_REVID(dev_priv, DG1_REVID_A0, DG1_REVID_A0) ||
>> -IS_TGL_DISP_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_B0))
>> +IS_TGL_DISP_STEPPING(dev_priv, STEP_A0, STEP_B0))
>> /* Wa_1409767108:tgl,dg1 */
>> table = wa_1409767108_buddy_page_masks;
>> else
>> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
>> b/drivers/gpu/drm/i915/display/intel_psr.c
>> index c24ae69426cf..a93717178957 100644
>> --- a/drivers/gpu/drm/i915/display/intel_psr.c
>> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
>> @@ -550,7 +550,7 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
>>
>> if (dev_priv->psr.psr2_sel_fetch_enabled) {
>> /* WA 1408330847 */
>> -if (IS_TGL_DISP_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_A0) ||
>> +if (IS_TGL_DISP_STEPPING(dev_priv, STEP_A0, STEP_A0) ||
>> IS_RKL_REVID(dev_priv, RKL_REVID_A0, RKL_REVID_A0))
>> intel_de_rmw(dev_priv, CHICKEN_PAR1_1,
>> DIS_RAM_BYPASS_PSR2_MAN_TRACK,
>> @@ -1102,7 +1102,7 @@ static void intel_psr_disable_locked(struct intel_dp
>> *intel_dp)
>>
>> /* WA 1408330847 */
>> if (dev_priv->psr.psr2_sel_fetch_enabled &&
>> -(IS_TGL_DISP_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_A0) ||
>> +(IS_TGL_DISP_STEPPING(dev_priv, STEP_A0, STEP_A0) ||
>> IS_RKL_REVID(dev_priv, RKL_REVID_A0, RKL_REVID_A0)))
>> intel_de_rmw(dev_priv, CHICKEN_PAR1_1,
>> DIS_RAM_BYPASS_PSR2_MAN_TRACK, 0);
>> diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
>> b/drivers/gpu/drm/i915/display/intel_sprite.c
>> index cf3589fd0ddb..4ce32df3855f 100644
>> --- a/drivers/gpu/drm/i915/display/intel_sprite.c
>> +++ b/drivers/gpu/drm/i915/display/intel_sprite.c
>> @@ -3033,7 +3033,7 @@ static bool gen12_p
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Use TGL stepping info and add ADLS platform changes (rev2)
== Series Details == Series: Use TGL stepping info and add ADLS platform changes (rev2) URL : https://patchwork.freedesktop.org/series/85639/ State : warning == Summary == $ dim checkpatch origin/drm-tip 5e2bd50d9a37 drm/i915/tgl: Use TGL stepping info for applying WAs -:197: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'p' - possible side-effects? #197: FILE: drivers/gpu/drm/i915/i915_drv.h:1595: +#define IS_TGL_DISP_STEPPING(p, since, until) \ (IS_TIGERLAKE(p) && \ +tgl_stepping_get(p)->disp_stepping >= (since) && \ +tgl_stepping_get(p)->disp_stepping <= (until)) -:205: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'p' - possible side-effects? #205: FILE: drivers/gpu/drm/i915/i915_drv.h:1600: +#define IS_TGL_UY_GT_STEPPING(p, since, until) \ ((IS_TGL_U(p) || IS_TGL_Y(p)) && \ +tgl_stepping_get(p)->gt_stepping >= (since) && \ +tgl_stepping_get(p)->gt_stepping <= (until)) -:213: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'p' - possible side-effects? #213: FILE: drivers/gpu/drm/i915/i915_drv.h:1605: +#define IS_TGL_GT_STEPPING(p, since, until) \ (IS_TIGERLAKE(p) && \ !(IS_TGL_U(p) || IS_TGL_Y(p)) && \ +tgl_stepping_get(p)->gt_stepping >= (since) && \ +tgl_stepping_get(p)->gt_stepping <= (until)) total: 0 errors, 0 warnings, 3 checks, 182 lines checked f919d3dd38ae drm/i915/adl_s: Add ADL-S platform info and PCI ids -:126: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'p' - possible side-effects? #126: FILE: drivers/gpu/drm/i915/i915_drv.h:1639: +#define IS_ADLS_DISP_STEPPING(p, since, until) \ + (IS_ALDERLAKE_S(p) && \ +tgl_stepping_get(p)->disp_stepping >= (since) && \ +tgl_stepping_get(p)->disp_stepping <= (until)) -:131: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'p' - possible side-effects? #131: FILE: drivers/gpu/drm/i915/i915_drv.h:1644: +#define IS_ADLS_GT_STEPPING(p, since, until) \ + (IS_ALDERLAKE_S(p) && \ +tgl_stepping_get(p)->gt_stepping >= (since) && \ +tgl_stepping_get(p)->gt_stepping <= (until)) -:203: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in parentheses #203: FILE: include/drm/i915_pciids.h:638: +#define INTEL_ADLS_IDS(info) \ + INTEL_VGA_DEVICE(0x4680, info), \ + INTEL_VGA_DEVICE(0x4681, info), \ + INTEL_VGA_DEVICE(0x4682, info), \ + INTEL_VGA_DEVICE(0x4683, info), \ + INTEL_VGA_DEVICE(0x4690, info), \ + INTEL_VGA_DEVICE(0x4691, info), \ + INTEL_VGA_DEVICE(0x4692, info), \ + INTEL_VGA_DEVICE(0x4693, info) -:203: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'info' - possible side-effects? #203: FILE: include/drm/i915_pciids.h:638: +#define INTEL_ADLS_IDS(info) \ + INTEL_VGA_DEVICE(0x4680, info), \ + INTEL_VGA_DEVICE(0x4681, info), \ + INTEL_VGA_DEVICE(0x4682, info), \ + INTEL_VGA_DEVICE(0x4683, info), \ + INTEL_VGA_DEVICE(0x4690, info), \ + INTEL_VGA_DEVICE(0x4691, info), \ + INTEL_VGA_DEVICE(0x4692, info), \ + INTEL_VGA_DEVICE(0x4693, info) total: 1 errors, 0 warnings, 3 checks, 128 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/adl_s: Add ADL-S platform info and PCI ids
On 1/8/21 4:20 PM, Matt Roper wrote:
> On Fri, Jan 08, 2021 at 03:18:53PM -0800, Aditya Swarup wrote:
>> From: Caz Yokoyama
>>
>> - Add the initial platform information for Alderlake-S.
>> - Specify ppgtt_size value
>> - Add dma_mask_size
>> - Add ADLS REVIDs
>> - HW tracking(Selective Update Tracking Enable) has been
>> removed from ADLS. Disable PSR2 till we enable software/
>> manual tracking.
>>
>> v2:
>> - Add support for different ADLS SOC steppings to select
>> correct GT/DISP stepping based on Bspec 53655 based on
>> feedback from Matt Roper.(aswarup)
>>
>> v3:
>> - Make display/gt steppings info generic for reuse with TGL and ADLS.
>> - Modify the macros to reuse tgl_revids_get()
>> - Add HTI support to adls device info.(mdroper)
>>
>> v4:
>> - Rebase on TGL patch for applying WAs based on stepping info from
>> Matt Roper's feedback.(aswarup)
>>
>> Bspec: 53597
>> Bspec: 53648
>> Bspec: 53655
>> Bspec: 48028
>> Bspec: 53650
>> BSpec: 50422
>>
>> Cc: José Roberto de Souza
>> Cc: Matt Roper
>> Cc: Lucas De Marchi
>> Cc: Anusha Srivatsa
>> Cc: Jani Nikula
>> Cc: Ville Syrjälä
>> Cc: Imre Deak
>> Signed-off-by: Caz Yokoyama
>> Signed-off-by: Aditya Swarup
>> ---
>> drivers/gpu/drm/i915/gt/intel_workarounds.c | 8 ++
>> drivers/gpu/drm/i915/i915_drv.h | 27 -
>> drivers/gpu/drm/i915/i915_pci.c | 13 ++
>> drivers/gpu/drm/i915/intel_device_info.c| 1 +
>> drivers/gpu/drm/i915/intel_device_info.h| 1 +
>> include/drm/i915_pciids.h | 11 +
>> 6 files changed, 60 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
>> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
>> index 111d01e2f81e..c89bd653af17 100644
>> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
>> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
>> @@ -84,6 +84,14 @@ const struct i915_rev_steppings tgl_revid_step_tbl[] = {
>> [1] = { .gt_stepping = STEP_B0, .disp_stepping = STEP_D0 },
>> };
>>
>> +const struct i915_rev_steppings adls_revid_step_tbl[] = {
>> +[ADLS_REVID_A0] = { .gt_stepping = STEP_A0, .disp_stepping = STEP_A0 },
>> +[ADLS_REVID_A2] = { .gt_stepping = STEP_A0, .disp_stepping = STEP_A2 },
>> +[ADLS_REVID_B0] = { .gt_stepping = STEP_B0, .disp_stepping = STEP_B0 },
>> +[ADLS_REVID_G0] = { .gt_stepping = STEP_C0, .disp_stepping = STEP_B0 },
>> +[ADLS_REVID_C0] = { .gt_stepping = STEP_D0, .disp_stepping = STEP_C0 },
>> +};
>
> Now that we've disassociated IP steppings from revision ID, I don't
> think we should use stepping terminology for the constant inputs to the
> array anymore. The terms you're using seem to roughly correspond to
> what the bspec refers to as "SOC stepping" but even that's not terribly
> accurate since, for example, PCI revision ID 0xC is used for SoC
> steppings C0, C1, D0, and H0. I'd just use the exact numeric PCI ID as
> documented in the bspec to remove any ambiguity:
>
> const struct i915_rev_steppings adls_revid_step_tbl[] = {
> [0x0] = { .gt_stepping = STEP_A0, .disp_stepping = STEP_A0 },
> [0x1] = { .gt_stepping = STEP_A0, .disp_stepping = STEP_A2 },
> [0x4] = { .gt_stepping = STEP_B0, .disp_stepping = STEP_B0 },
> [0x8] = { .gt_stepping = STEP_C0, .disp_stepping = STEP_B0 },
> [0xC] = { .gt_stepping = STEP_D0, .disp_stepping = STEP_C0 },
> };
>
> That also matches how we're indexing into the TGL arrays.
I don't think there is a difference between SOC steppings and PCI ids from
display and graphics perspective.
As in all the SOC steppings that share the same PCI IDs have the same display
and graphics stepping.
But I do agree with you that changing the index to numeric PCI IDs perhaps
removes ambiguity and makes it
consitent with the tables used for earlier platforms. I have sent a v2
addressing this change.
aswarup
>
>
> Matt
>
>> +
>> static void wa_init_start(struct i915_wa_list *wal, const char *name, const
>> char *engine_name)
>> {
>> wal->name = name;
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index 11d6e8abde46..8d8a046a7b0c 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -1417,6 +1417,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
>> #define IS_TIGERLAKE(dev_priv) IS_PLATFORM(dev_priv, INTEL_TIGERLAKE)
>> #define IS_ROCKETLAKE(dev_priv) IS_PLATFORM(dev_priv, INTEL_ROCKETLAKE)
>> #define IS_DG1(dev_priv)IS_PLATFORM(dev_priv, INTEL_DG1)
>> +#define IS_ALDERLAKE_S(dev_priv) IS_PLATFORM(dev_priv, INTEL_ALDERLAKE_S)
>> #define IS_HSW_EARLY_SDV(dev_priv) (IS_HASWELL(dev_priv) && \
>> (INTEL_DEVID(dev_priv) & 0xFF00) == 0x0C00)
>> #define IS_BDW_ULT(dev_priv) \
>> @@ -1560,6 +1561,7 @@ extern const struct i915_rev_steppings kbl_revids[];
>>
>> e
[Intel-gfx] [PATCH 0/2] Use TGL stepping info and add ADLS platform changes
v1: 1. Change TGL REVID enums/macros to TGL stepping info to apply TGL WAs. 2. Add ADL-S platform info and PCI IDs and add TGL style stepping macros for applying WAs. v2: - Replace macros with PCI IDs based on Matt Roper's suggestion. Aditya Swarup (1): drm/i915/tgl: Use TGL stepping info for applying WAs Caz Yokoyama (1): drm/i915/adl_s: Add ADL-S platform info and PCI ids .../drm/i915/display/intel_display_power.c| 2 +- drivers/gpu/drm/i915/display/intel_psr.c | 4 +- drivers/gpu/drm/i915/display/intel_sprite.c | 2 +- drivers/gpu/drm/i915/gt/intel_workarounds.c | 34 +--- drivers/gpu/drm/i915/i915_drv.h | 79 --- drivers/gpu/drm/i915/i915_pci.c | 13 +++ drivers/gpu/drm/i915/intel_device_info.c | 1 + drivers/gpu/drm/i915/intel_device_info.h | 1 + drivers/gpu/drm/i915/intel_pm.c | 2 +- include/drm/i915_pciids.h | 11 +++ 10 files changed, 104 insertions(+), 45 deletions(-) -- 2.27.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/adl_s: Add ADL-S platform info and PCI ids
From: Caz Yokoyama
- Add the initial platform information for Alderlake-S.
- Specify ppgtt_size value
- Add dma_mask_size
- Add ADLS REVIDs
- HW tracking(Selective Update Tracking Enable) has been
removed from ADLS. Disable PSR2 till we enable software/
manual tracking.
v2:
- Add support for different ADLS SOC steppings to select
correct GT/DISP stepping based on Bspec 53655 based on
feedback from Matt Roper.(aswarup)
v3:
- Make display/gt steppings info generic for reuse with TGL and ADLS.
- Modify the macros to reuse tgl_revids_get()
- Add HTI support to adls device info.(mdroper)
v4:
- Rebase on TGL patch for applying WAs based on stepping info from
Matt Roper's feedback.(aswarup)
v5:
- Replace macros with PCI IDs in revid to stepping table.
Bspec: 53597
Bspec: 53648
Bspec: 53655
Bspec: 48028
Bspec: 53650
BSpec: 50422
Cc: José Roberto de Souza
Cc: Matt Roper
Cc: Lucas De Marchi
Cc: Anusha Srivatsa
Cc: Jani Nikula
Cc: Ville Syrjälä
Cc: Imre Deak
Signed-off-by: Caz Yokoyama
Signed-off-by: Aditya Swarup
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 8 ++
drivers/gpu/drm/i915/i915_drv.h | 27 -
drivers/gpu/drm/i915/i915_pci.c | 13 ++
drivers/gpu/drm/i915/intel_device_info.c| 1 +
drivers/gpu/drm/i915/intel_device_info.h| 1 +
include/drm/i915_pciids.h | 11 +
6 files changed, 60 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 111d01e2f81e..cb9220925fe7 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -84,6 +84,14 @@ const struct i915_rev_steppings tgl_revid_step_tbl[] = {
[1] = { .gt_stepping = STEP_B0, .disp_stepping = STEP_D0 },
};
+const struct i915_rev_steppings adls_revid_step_tbl[] = {
+ [0x0] = { .gt_stepping = STEP_A0, .disp_stepping = STEP_A0 },
+ [0x1] = { .gt_stepping = STEP_A0, .disp_stepping = STEP_A2 },
+ [0x4] = { .gt_stepping = STEP_B0, .disp_stepping = STEP_B0 },
+ [0x8] = { .gt_stepping = STEP_C0, .disp_stepping = STEP_B0 },
+ [0xC] = { .gt_stepping = STEP_D0, .disp_stepping = STEP_C0 },
+};
+
static void wa_init_start(struct i915_wa_list *wal, const char *name, const
char *engine_name)
{
wal->name = name;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 11d6e8abde46..8d8a046a7b0c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1417,6 +1417,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
#define IS_TIGERLAKE(dev_priv) IS_PLATFORM(dev_priv, INTEL_TIGERLAKE)
#define IS_ROCKETLAKE(dev_priv)IS_PLATFORM(dev_priv, INTEL_ROCKETLAKE)
#define IS_DG1(dev_priv)IS_PLATFORM(dev_priv, INTEL_DG1)
+#define IS_ALDERLAKE_S(dev_priv) IS_PLATFORM(dev_priv, INTEL_ALDERLAKE_S)
#define IS_HSW_EARLY_SDV(dev_priv) (IS_HASWELL(dev_priv) && \
(INTEL_DEVID(dev_priv) & 0xFF00) == 0x0C00)
#define IS_BDW_ULT(dev_priv) \
@@ -1560,6 +1561,7 @@ extern const struct i915_rev_steppings kbl_revids[];
enum {
STEP_A0,
+ STEP_A2,
STEP_B0,
STEP_B1,
STEP_C0,
@@ -1568,9 +1570,11 @@ enum {
#define TGL_UY_REVID_STEP_TBL_SIZE 4
#define TGL_REVID_STEP_TBL_SIZE2
+#define ADLS_REVID_STEP_TBL_SIZE 13
extern const struct i915_rev_steppings
tgl_uy_revid_step_tbl[TGL_UY_REVID_STEP_TBL_SIZE];
extern const struct i915_rev_steppings
tgl_revid_step_tbl[TGL_REVID_STEP_TBL_SIZE];
+extern const struct i915_rev_steppings
adls_revid_step_tbl[ADLS_REVID_STEP_TBL_SIZE];
static inline const struct i915_rev_steppings *
tgl_stepping_get(struct drm_i915_private *dev_priv)
@@ -1579,7 +1583,10 @@ tgl_stepping_get(struct drm_i915_private *dev_priv)
u8 size;
const struct i915_rev_steppings *revid_step_tbl;
- if (IS_TGL_U(dev_priv) || IS_TGL_Y(dev_priv)) {
+ if (IS_ALDERLAKE_S(dev_priv)) {
+ revid_step_tbl = adls_revid_step_tbl;
+ size = ARRAY_SIZE(adls_revid_step_tbl);
+ } else if (IS_TGL_U(dev_priv) || IS_TGL_Y(dev_priv)) {
revid_step_tbl = tgl_uy_revid_step_tbl;
size = ARRAY_SIZE(tgl_uy_revid_step_tbl);
} else {
@@ -1621,6 +1628,24 @@ tgl_stepping_get(struct drm_i915_private *dev_priv)
#define IS_DG1_REVID(p, since, until) \
(IS_DG1(p) && IS_REVID(p, since, until))
+#define ADLS_REVID_A0 0x0
+#define ADLS_REVID_A2 0x1
+#define ADLS_REVID_B0 0x4
+#define ADLS_REVID_G0 0x8
+#define ADLS_REVID_C0 0xC /*Same as H0 ADLS SOC stepping*/
+
+extern const struct i915_rev_steppings adls_revids[];
+
+#define IS_ADLS_DISP_STEPPING(p, since, until) \
+ (IS_ALDERLAKE_S(p) && \
+tgl_stepping_get(p)->disp_stepping >= (since) && \
+tgl_stepping_get(p)->di
[Intel-gfx] [PATCH 1/2] drm/i915/tgl: Use TGL stepping info for applying WAs
TGL adds another level of indirection for applying WA based on stepping
information rather than PCI REVID. So change TGL_REVID enum into
stepping enum and use PCI REVID as index into revid to stepping table to
fetch correct display and GT stepping for application of WAs as
suggested by Matt Roper.
Cc: Matt Roper
Cc: Lucas De Marchi
Cc: José Roberto de Souza
Signed-off-by: Aditya Swarup
---
.../drm/i915/display/intel_display_power.c| 2 +-
drivers/gpu/drm/i915/display/intel_psr.c | 4 +-
drivers/gpu/drm/i915/display/intel_sprite.c | 2 +-
drivers/gpu/drm/i915/gt/intel_workarounds.c | 26 +-
drivers/gpu/drm/i915/i915_drv.h | 50 +--
drivers/gpu/drm/i915/intel_pm.c | 2 +-
6 files changed, 43 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index d52374f01316..bb04b502a442 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -5340,7 +5340,7 @@ static void tgl_bw_buddy_init(struct drm_i915_private
*dev_priv)
int config, i;
if (IS_DG1_REVID(dev_priv, DG1_REVID_A0, DG1_REVID_A0) ||
- IS_TGL_DISP_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_B0))
+ IS_TGL_DISP_STEPPING(dev_priv, STEP_A0, STEP_B0))
/* Wa_1409767108:tgl,dg1 */
table = wa_1409767108_buddy_page_masks;
else
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index c24ae69426cf..a93717178957 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -550,7 +550,7 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
if (dev_priv->psr.psr2_sel_fetch_enabled) {
/* WA 1408330847 */
- if (IS_TGL_DISP_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_A0) ||
+ if (IS_TGL_DISP_STEPPING(dev_priv, STEP_A0, STEP_A0) ||
IS_RKL_REVID(dev_priv, RKL_REVID_A0, RKL_REVID_A0))
intel_de_rmw(dev_priv, CHICKEN_PAR1_1,
DIS_RAM_BYPASS_PSR2_MAN_TRACK,
@@ -1102,7 +1102,7 @@ static void intel_psr_disable_locked(struct intel_dp
*intel_dp)
/* WA 1408330847 */
if (dev_priv->psr.psr2_sel_fetch_enabled &&
- (IS_TGL_DISP_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_A0) ||
+ (IS_TGL_DISP_STEPPING(dev_priv, STEP_A0, STEP_A0) ||
IS_RKL_REVID(dev_priv, RKL_REVID_A0, RKL_REVID_A0)))
intel_de_rmw(dev_priv, CHICKEN_PAR1_1,
DIS_RAM_BYPASS_PSR2_MAN_TRACK, 0);
diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
b/drivers/gpu/drm/i915/display/intel_sprite.c
index cf3589fd0ddb..4ce32df3855f 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -3033,7 +3033,7 @@ static bool gen12_plane_supports_mc_ccs(struct
drm_i915_private *dev_priv,
{
/* Wa_14010477008:tgl[a0..c0],rkl[all],dg1[all] */
if (IS_DG1(dev_priv) || IS_ROCKETLAKE(dev_priv) ||
- IS_TGL_DISP_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_C0))
+ IS_TGL_DISP_STEPPING(dev_priv, STEP_A0, STEP_C0))
return false;
return plane_id < PLANE_SPRITE4;
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index c21a9726326a..111d01e2f81e 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -71,17 +71,17 @@ const struct i915_rev_steppings kbl_revids[] = {
[7] = { .gt_stepping = KBL_REVID_G0, .disp_stepping = KBL_REVID_C0 },
};
-const struct i915_rev_steppings tgl_uy_revids[] = {
- [0] = { .gt_stepping = TGL_REVID_A0, .disp_stepping = TGL_REVID_A0 },
- [1] = { .gt_stepping = TGL_REVID_B0, .disp_stepping = TGL_REVID_C0 },
- [2] = { .gt_stepping = TGL_REVID_B1, .disp_stepping = TGL_REVID_C0 },
- [3] = { .gt_stepping = TGL_REVID_C0, .disp_stepping = TGL_REVID_D0 },
+const struct i915_rev_steppings tgl_uy_revid_step_tbl[] = {
+ [0] = { .gt_stepping = STEP_A0, .disp_stepping = STEP_A0 },
+ [1] = { .gt_stepping = STEP_B0, .disp_stepping = STEP_C0 },
+ [2] = { .gt_stepping = STEP_B1, .disp_stepping = STEP_C0 },
+ [3] = { .gt_stepping = STEP_C0, .disp_stepping = STEP_D0 },
};
/* Same GT stepping between tgl_uy_revids and tgl_revids don't mean the same
HW */
-const struct i915_rev_steppings tgl_revids[] = {
- [0] = { .gt_stepping = TGL_REVID_A0, .disp_stepping = TGL_REVID_B0 },
- [1] = { .gt_stepping = TGL_REVID_B0, .disp_stepping = TGL_REVID_D0 },
+const struct i915_rev_steppings tgl_revid_step_tbl[] = {
+ [0] = { .gt_stepping = STEP_A0, .disp_stepping = STEP_B0 },
+ [1] = { .gt_stepping = STEP_B0, .disp_stepping = STEP_D0 },
Re: [Intel-gfx] [PATCH] drm/i915/backlight: fix CPU mode backlight takeover on LPT
On Mon, 11 Jan 2021, Jani Nikula wrote: > On Fri, 08 Jan 2021, Lyude Paul wrote: >> Reviewed-by: Lyude Paul >> >> Let me know when you've pushed this upstream and I'll go ahead and send out a >> rebased version of my backlight series. > > Pushed, thanks for the review. > > I'm hoping to do more review of the series today, so please hold off on > actually sending the rebased version for a bit longer. Done, go ahead! BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 4/4] drm/dp: Revert "drm/dp: Introduce EDID-based quirks"
On Mon, 11 Jan 2021, Jani Nikula wrote: > On Thu, 07 Jan 2021, Lyude Paul wrote: >> This reverts commit 0883ce8146ed6074c76399f4e70dbed788582e12. Originally >> these quirks were added because of the issues with using the eDP >> backlight interfaces on certain laptop panels, which made it impossible >> to properly probe for DPCD backlight support without having a whitelist >> for panels that we know have working VESA backlight control interfaces >> over DPCD. As well, it should be noted it was impossible to use the >> normal sink OUI for recognizing these panels as none of them actually >> filled out their OUIs, hence needing to resort to checking EDIDs. >> >> At the time we weren't really sure why certain panels had issues with >> DPCD backlight controls, but we eventually figured out that there was a >> second interface that these problematic laptop panels actually did work >> with and advertise properly: Intel's proprietary backlight interface for >> HDR panels. So far the testing we've done hasn't brought any panels to >> light that advertise this interface and don't support it properly, which >> means we finally have a real solution to this problem. >> >> As a result, we now have no need for the force DPCD backlight quirk, and >> furthermore this also removes the need for any kind of EDID quirk >> checking in DRM. So, let's just revert it for now since we were the only >> driver using this. >> >> v3: >> * Rebase >> v2: >> * Fix indenting error picked up by checkpatch in >> intel_edp_init_connector() >> >> Signed-off-by: Lyude Paul >> Acked-by: Jani Nikula > > Still stands. PS. You'll still need drm or drm-misc maintainer ack if you want to merge this through drm-intel-next. -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 4/4] drm/dp: Revert "drm/dp: Introduce EDID-based quirks"
On Thu, 07 Jan 2021, Lyude Paul wrote:
> This reverts commit 0883ce8146ed6074c76399f4e70dbed788582e12. Originally
> these quirks were added because of the issues with using the eDP
> backlight interfaces on certain laptop panels, which made it impossible
> to properly probe for DPCD backlight support without having a whitelist
> for panels that we know have working VESA backlight control interfaces
> over DPCD. As well, it should be noted it was impossible to use the
> normal sink OUI for recognizing these panels as none of them actually
> filled out their OUIs, hence needing to resort to checking EDIDs.
>
> At the time we weren't really sure why certain panels had issues with
> DPCD backlight controls, but we eventually figured out that there was a
> second interface that these problematic laptop panels actually did work
> with and advertise properly: Intel's proprietary backlight interface for
> HDR panels. So far the testing we've done hasn't brought any panels to
> light that advertise this interface and don't support it properly, which
> means we finally have a real solution to this problem.
>
> As a result, we now have no need for the force DPCD backlight quirk, and
> furthermore this also removes the need for any kind of EDID quirk
> checking in DRM. So, let's just revert it for now since we were the only
> driver using this.
>
> v3:
> * Rebase
> v2:
> * Fix indenting error picked up by checkpatch in
> intel_edp_init_connector()
>
> Signed-off-by: Lyude Paul
> Acked-by: Jani Nikula
Still stands.
BR,
Jani.
> Cc: thay...@noraisin.net
> Cc: Vasily Khoruzhick
> ---
> drivers/gpu/drm/drm_dp_helper.c | 83 +--
> drivers/gpu/drm/drm_dp_mst_topology.c | 3 +-
> .../drm/i915/display/intel_display_types.h| 1 -
> drivers/gpu/drm/i915/display/intel_dp.c | 9 +-
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 3 +-
> drivers/gpu/drm/i915/display/intel_psr.c | 2 +-
> include/drm/drm_dp_helper.h | 21 +
> 7 files changed, 9 insertions(+), 113 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 3ecde451f523..19dbdeb581cb 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -1236,7 +1236,7 @@ bool drm_dp_read_sink_count_cap(struct drm_connector
> *connector,
> return connector->connector_type != DRM_MODE_CONNECTOR_eDP &&
> dpcd[DP_DPCD_REV] >= DP_DPCD_REV_11 &&
> dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT &&
> - !drm_dp_has_quirk(desc, 0, DP_DPCD_QUIRK_NO_SINK_COUNT);
> + !drm_dp_has_quirk(desc, DP_DPCD_QUIRK_NO_SINK_COUNT);
> }
> EXPORT_SYMBOL(drm_dp_read_sink_count_cap);
>
> @@ -1957,87 +1957,6 @@ drm_dp_get_quirks(const struct drm_dp_dpcd_ident
> *ident, bool is_branch)
> #undef DEVICE_ID_ANY
> #undef DEVICE_ID
>
> -struct edid_quirk {
> - u8 mfg_id[2];
> - u8 prod_id[2];
> - u32 quirks;
> -};
> -
> -#define MFG(first, second) { (first), (second) }
> -#define PROD_ID(first, second) { (first), (second) }
> -
> -/*
> - * Some devices have unreliable OUIDs where they don't set the device ID
> - * correctly, and as a result we need to use the EDID for finding additional
> - * DP quirks in such cases.
> - */
> -static const struct edid_quirk edid_quirk_list[] = {
> - /* Optional 4K AMOLED panel in the ThinkPad X1 Extreme 2nd Generation
> - * only supports DPCD backlight controls
> - */
> - { MFG(0x4c, 0x83), PROD_ID(0x41, 0x41),
> BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
> - /*
> - * Some Dell CML 2020 systems have panels support both AUX and PWM
> - * backlight control, and some only support AUX backlight control. All
> - * said panels start up in AUX mode by default, and we don't have any
> - * support for disabling HDR mode on these panels which would be
> - * required to switch to PWM backlight control mode (plus, I'm not
> - * even sure we want PWM backlight controls over DPCD backlight
> - * controls anyway...). Until we have a better way of detecting these,
> - * force DPCD backlight mode on all of them.
> - */
> - { MFG(0x06, 0xaf), PROD_ID(0x9b, 0x32),
> BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
> - { MFG(0x06, 0xaf), PROD_ID(0xeb, 0x41),
> BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
> - { MFG(0x4d, 0x10), PROD_ID(0xc7, 0x14),
> BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
> - { MFG(0x4d, 0x10), PROD_ID(0xe6, 0x14),
> BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
> - { MFG(0x4c, 0x83), PROD_ID(0x47, 0x41),
> BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
> - { MFG(0x09, 0xe5), PROD_ID(0xde, 0x08),
> BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
> -};
> -
> -#undef MFG
> -#undef PROD_ID
> -
> -/**
> - * drm_dp_get_edid_quirks() - Check the EDID of a DP device to find
> additional
> - * DP-specific quirks
> - * @edid: The EDID to check
> - *
> - * While OUIDs are meant to be used to
Re: [Intel-gfx] [PATCH v5 3/4] drm/i915/dp: Allow forcing specific interfaces through enable_dpcd_backlight
On Thu, 07 Jan 2021, Lyude Paul wrote:
> Since we now support controlling panel backlights through DPCD using
> both the standard VESA interface, and Intel's proprietary HDR backlight
> interface, we should allow the user to be able to explicitly choose
> between one or the other in the event that we're wrong about panels
> reliably reporting support for the Intel HDR interface.
>
> So, this commit adds support for this by introducing two new
> enable_dpcd_backlight options: 2 which forces i915 to only probe for the
> VESA interface, and 3 which forces i915 to only probe for the Intel
> backlight interface (might be useful if we find panels in the wild that
> report the VESA interface in their VBT, but actually only support the
> Intel backlight interface).
>
> v3:
> * Rebase
>
> Signed-off-by: Lyude Paul
> Reviewed-by: Jani Nikula
Yup. Feels maybe a bit convoluted, but I'll trust your judgement as
you've been playing with these.
BR,
Jani.
> Cc: thay...@noraisin.net
> Cc: Vasily Khoruzhick
> ---
> .../drm/i915/display/intel_dp_aux_backlight.c | 45 +--
> drivers/gpu/drm/i915/i915_params.c| 2 +-
> 2 files changed, 43 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> index 5e761fb49a14..4b2cb20b1f94 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> @@ -613,15 +613,54 @@ static const struct intel_panel_bl_funcs
> intel_dp_vesa_bl_funcs = {
> .get = intel_dp_aux_vesa_get_backlight,
> };
>
> +enum intel_dp_aux_backlight_modparam {
> + INTEL_DP_AUX_BACKLIGHT_AUTO = -1,
> + INTEL_DP_AUX_BACKLIGHT_OFF = 0,
> + INTEL_DP_AUX_BACKLIGHT_ON = 1,
> + INTEL_DP_AUX_BACKLIGHT_FORCE_VESA = 2,
> + INTEL_DP_AUX_BACKLIGHT_FORCE_INTEL = 3,
> +};
> +
> int intel_dp_aux_init_backlight_funcs(struct intel_connector *connector)
> {
> struct drm_device *dev = connector->base.dev;
> struct intel_panel *panel = &connector->panel;
> struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> + bool try_intel_interface = false, try_vesa_interface = false;
>
> - if (i915->params.enable_dpcd_backlight == 0)
> + /* Check the VBT and user's module parameters to figure out which
> + * interfaces to probe
> + */
> + switch (i915->params.enable_dpcd_backlight) {
> + case INTEL_DP_AUX_BACKLIGHT_OFF:
> return -ENODEV;
> + case INTEL_DP_AUX_BACKLIGHT_AUTO:
> + switch (i915->vbt.backlight.type) {
> + case INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE:
> + try_vesa_interface = true;
> + break;
> + case INTEL_BACKLIGHT_DISPLAY_DDI:
> + try_intel_interface = true;
> + try_vesa_interface = true;
> + break;
> + default:
> + return -ENODEV;
> + }
> + break;
> + case INTEL_DP_AUX_BACKLIGHT_ON:
> + if (i915->vbt.backlight.type !=
> INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE)
> + try_intel_interface = true;
> +
> + try_vesa_interface = true;
> + break;
> + case INTEL_DP_AUX_BACKLIGHT_FORCE_VESA:
> + try_vesa_interface = true;
> + break;
> + case INTEL_DP_AUX_BACKLIGHT_FORCE_INTEL:
> + try_intel_interface = true;
> + break;
> + }
>
> /*
>* A lot of eDP panels in the wild will report supporting both the
> @@ -630,13 +669,13 @@ int intel_dp_aux_init_backlight_funcs(struct
> intel_connector *connector)
>* and will only work with the Intel interface. So, always probe for
>* that first.
>*/
> - if (intel_dp_aux_supports_hdr_backlight(connector)) {
> + if (try_intel_interface &&
> intel_dp_aux_supports_hdr_backlight(connector)) {
> drm_dbg_kms(dev, "Using Intel proprietary eDP backlight
> controls\n");
> panel->backlight.funcs = &intel_dp_hdr_bl_funcs;
> return 0;
> }
>
> - if (intel_dp_aux_supports_vesa_backlight(connector)) {
> + if (try_vesa_interface &&
> intel_dp_aux_supports_vesa_backlight(connector)) {
> drm_dbg_kms(dev, "Using VESA eDP backlight controls\n");
> panel->backlight.funcs = &intel_dp_vesa_bl_funcs;
> return 0;
> diff --git a/drivers/gpu/drm/i915/i915_params.c
> b/drivers/gpu/drm/i915/i915_params.c
> index 7f139ea4a90b..6939634e56ed 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -185,7 +185,7 @@ i915_param_named_unsafe(inject_probe_failure, uint, 0400,
>
> i915_param_named(enable_dpcd_backlight, int, 0400,
> "Enable support for DPCD backlight con
Re: [Intel-gfx] [PATCH v5 2/4] drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now)
On Thu, 07 Jan 2021, Lyude Paul wrote:
> So-recently a bunch of laptops on the market have started using DPCD
> backlight controls instead of the traditional DDI backlight controls.
> Originally we thought we had this handled by adding VESA backlight
> control support to i915, but the story ended up being a lot more
> complicated then that.
>
> Simply put-there's two main backlight interfaces Intel can see in the
> wild. Intel's proprietary HDR backlight interface, and the standard VESA
> backlight interface. Note that many panels have been observed to report
> support for both backlight interfaces, but testing has shown far more
> panels work with the Intel HDR backlight interface at the moment.
> Additionally, the VBT appears to be capable of reporting support for the
> VESA backlight interface but not the Intel HDR interface which needs to
> be probed by setting the right magic OUI.
>
> On top of that however, there's also actually two different variants of
> the Intel HDR backlight interface. The first uses the AUX channel for
> controlling the brightness of the screen in both SDR and HDR mode, and
> the second only uses the AUX channel for setting the brightness level in
> HDR mode - relying on PWM for setting the brightness level in SDR mode.
>
> For the time being we've been using EDIDs to maintain a list of quirks
> for panels that safely do support the VESA backlight interface. Adding
> support for Intel's HDR backlight interface in addition however, should
> finally allow us to auto-detect eDP backlight controls properly so long
> as we probe like so:
>
> * If the panel's VBT reports VESA backlight support, assume it really
> does support it
> * If the panel's VBT reports DDI backlight controls:
> * First probe for Intel's HDR backlight interface
> * If that fails, probe for VESA's backlight interface
> * If that fails, assume no DPCD backlight control
> * If the panel's VBT reports any other backlight type: just assume it
> doesn't have DPCD backlight controls
>
> Changes since v4:
> * Fix checkpatch issues
> Changes since v3:
> * Stop using drm_device and use drm_i915_private instead
> * Don't forget to return from intel_dp_aux_hdr_get_backlight() if we fail
> to read the current backlight mode from the DPCD
> * s/uint8_t/u8/
> * Remove unneeded parenthesis in intel_dp_aux_hdr_enable_backlight()
> * Use drm_dbg_kms() in intel_dp_aux_init_backlight_funcs()
>
> Signed-off-by: Lyude Paul
> Acked-by: Jani Nikula
> Cc: thay...@noraisin.net
> Cc: Vasily Khoruzhick
> ---
> .../drm/i915/display/intel_display_types.h| 9 +-
> .../drm/i915/display/intel_dp_aux_backlight.c | 248 --
> drivers/gpu/drm/i915/display/intel_panel.c| 42 ++-
> drivers/gpu/drm/i915/display/intel_panel.h| 4 +
> 4 files changed, 271 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index ee5c2d50b81a..b24d80ffd18b 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -261,7 +261,14 @@ struct intel_panel {
> struct pwm_state pwm_state;
>
> /* DPCD backlight */
> - u8 pwmgen_bit_count;
> + union {
> + struct {
> + u8 pwmgen_bit_count;
> + } vesa;
> + struct {
> + bool sdr_uses_aux;
> + } intel;
> + } edp;
>
> struct backlight_device *device;
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> index 9775f33d1aac..5e761fb49a14 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> @@ -22,8 +22,26 @@
> *
> */
>
> +/*
> + * Laptops with Intel GPUs which have panels that support controlling the
> + * backlight through DP AUX can actually use two different interfaces:
> Intel's
> + * proprietary DP AUX backlight interface, and the standard VESA backlight
> + * interface. Unfortunately, at the time of writing this a lot of laptops
> will
> + * advertise support for the standard VESA backlight interface when they
> + * don't properly support it. However, on these systems the Intel backlight
> + * interface generally does work properly. Additionally, these systems will
> + * usually just indicate that they use PWM backlight controls in their VBIOS
> + * for some reason.
> + */
> +
> #include "intel_display_types.h"
> #include "intel_dp_aux_backlight.h"
> +#include "intel_panel.h"
> +
> +/* TODO:
> + * Implement HDR, right now we just implement the bare minimum to bring us
> back into SDR mode so we
> + * can make people's backlights work in the mean time
> + */
>
> /*
> * DP AUX registers for Intel's proprietary HDR backlight
Re: [Intel-gfx] [PATCH v5 1/4] drm/i915: Keep track of pwm-related backlight hooks separately
On Thu, 07 Jan 2021, Lyude Paul wrote:
> Currently, every different type of backlight hook that i915 supports is
> pretty straight forward - you have a backlight, probably through PWM
> (but maybe DPCD), with a single set of platform-specific hooks that are
> used for controlling it.
>
> HDR backlights, in particular VESA and Intel's HDR backlight
> implementations, can end up being more complicated. With Intel's
> proprietary interface, HDR backlight controls always run through the
> DPCD. When the backlight is in SDR backlight mode however, the driver
> may need to bypass the TCON and control the backlight directly through
> PWM.
>
> So, in order to support this we'll need to split our backlight callbacks
> into two groups: a set of high-level backlight control callbacks in
> intel_panel, and an additional set of pwm-specific backlight control
> callbacks. This also implies a functional changes for how these
> callbacks are used:
>
> * We now keep track of two separate backlight level ranges, one for the
> high-level backlight, and one for the pwm backlight range
> * We also keep track of backlight enablement and PWM backlight
> enablement separately
> * Since the currently set backlight level might not be the same as the
> currently programmed PWM backlight level, we stop setting
> panel->backlight.level with the currently programmed PWM backlight
> level in panel->backlight.pwm_funcs->setup(). Instead, we rely
> on the higher level backlight control functions to retrieve the
> current PWM backlight level (in this case, intel_pwm_get_backlight()).
> Note that there are still a few PWM backlight setup callbacks that
> do actually need to retrieve the current PWM backlight level, although
> we no longer save this value in panel->backlight.level like before.
>
> Additionally, we drop the call to lpt_get_backlight() in
> lpt_setup_backlight(), and avoid unconditionally writing the PWM value that
> we get from it and only write it back if we're in CPU mode, and switching
> to PCH mode. The reason for this is because in the original codepath for
> this, it was expected that the intel_panel_bl_funcs->setup() hook would be
> responsible for fetching the initial backlight level. On lpt systems, the
> only time we could ever be in PCH backlight mode is during the initial
> driver load - meaning that outside of the setup() hook, lpt_get_backlight()
> will always be the callback used for retrieving the current backlight
> level. After this patch we still need to fetch and write-back the PCH
> backlight value if we're switching from CPU mode to PCH, but because
> intel_pwm_setup_backlight() will retrieve the backlight level after setup()
> using the get() hook, which always ends up being lpt_get_backlight(). Thus
> - an additional call to lpt_get_backlight() in lpt_setup_backlight() is
> made redundant.
>
> v5:
> * Fix indenting warnings from checkpatch
> v4:
> * Fix commit message
> * Remove outdated comment in intel_panel.c
> * Rename pwm_(min|max) to pwm_level_(min|max)
> * Use intel_pwm_get_backlight() in intel_pwm_setup_backlight() instead of
> indirection
> * Don't move intel_dp_aux_init_bcklight_funcs() call to bottom of
> intel_panel_init_backlight_funcs() quite yet
> v3:
> * Reuse intel_panel_bl_funcs() for pwm_funcs
> * Explain why we drop lpt_get_backlight()
>
> Signed-off-by: Lyude Paul
> Cc: thay...@noraisin.net
> Cc: Vasily Khoruzhick
> ---
> .../drm/i915/display/intel_display_types.h| 4 +
> drivers/gpu/drm/i915/display/intel_panel.c| 333 ++
> 2 files changed, 187 insertions(+), 150 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 1067bd073c95..ee5c2d50b81a 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -252,6 +252,9 @@ struct intel_panel {
> bool alternate_pwm_increment; /* lpt+ */
>
> /* PWM chip */
> + u32 pwm_level_min;
> + u32 pwm_level_max;
> + bool pwm_enabled;
> bool util_pin_active_low; /* bxt+ */
> u8 controller; /* bxt+ only */
> struct pwm_device *pwm;
> @@ -263,6 +266,7 @@ struct intel_panel {
> struct backlight_device *device;
>
> const struct intel_panel_bl_funcs *funcs;
> + const struct intel_panel_bl_funcs *pwm_funcs;
> void (*power)(struct intel_connector *, bool enable);
> } backlight;
> };
> diff --git a/drivers/gpu/drm/i915/display/intel_panel.c
> b/drivers/gpu/drm/i915/display/intel_panel.c
> index 67f81ae995c4..8c99bf404a32 100644
> --- a/drivers/gpu/drm/i915/display/intel_panel.c
> +++ b/drivers/gpu/drm/i915/display/intel_panel.c
> @@ -511,25 +511,34 @@ static u32 scale_hw_to_user(struct intel_connector
> *connector,
>0, user_max);
> }
>
>
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Async flips for all ilk+ platforms (rev2)
== Series Details == Series: drm/i915: Async flips for all ilk+ platforms (rev2) URL : https://patchwork.freedesktop.org/series/85627/ State : success == Summary == CI Bug Log - changes from CI_DRM_9580_full -> Patchwork_19315_full Summary --- **WARNING** Minor unknown changes coming with Patchwork_19315_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19315_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_19315_full: ### IGT changes ### Warnings * igt@kms_async_flips@invalid-async-flip: - shard-snb: [SKIP][1] ([fdo#109271]) -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9580/shard-snb2/igt@kms_async_fl...@invalid-async-flip.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19315/shard-snb5/igt@kms_async_fl...@invalid-async-flip.html Known issues Here are the changes found in Patchwork_19315_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_9580/shard-iclb2/igt@feature_discov...@psr2.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19315/shard-iclb7/igt@feature_discov...@psr2.html * igt@gem_exec_whisper@basic-contexts-priority: - shard-glk: [PASS][5] -> [DMESG-WARN][6] ([i915#118] / [i915#95]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9580/shard-glk5/igt@gem_exec_whis...@basic-contexts-priority.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19315/shard-glk8/igt@gem_exec_whis...@basic-contexts-priority.html * igt@gem_render_copy@y-tiled-to-vebox-x-tiled: - shard-iclb: NOTRUN -> [SKIP][7] ([i915#768]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19315/shard-iclb4/igt@gem_render_c...@y-tiled-to-vebox-x-tiled.html * igt@gem_userptr_blits@readonly-pwrite-unsync: - shard-iclb: NOTRUN -> [SKIP][8] ([fdo#110426] / [i915#1704]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19315/shard-iclb4/igt@gem_userptr_bl...@readonly-pwrite-unsync.html * igt@gen3_render_linear_blits: - shard-iclb: NOTRUN -> [SKIP][9] ([fdo#109289]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19315/shard-iclb4/igt@gen3_render_linear_blits.html * igt@i915_pm_dc@dc6-psr: - shard-iclb: [PASS][10] -> [FAIL][11] ([i915#454]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9580/shard-iclb4/igt@i915_pm...@dc6-psr.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19315/shard-iclb8/igt@i915_pm...@dc6-psr.html * igt@i915_selftest@live@gem: - shard-skl: [PASS][12] -> [DMESG-FAIL][13] ([i915#2927]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9580/shard-skl2/igt@i915_selftest@l...@gem.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19315/shard-skl2/igt@i915_selftest@l...@gem.html * igt@i915_selftest@live@gt_heartbeat: - shard-skl: [PASS][14] -> [DMESG-FAIL][15] ([i915#2291] / [i915#541]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9580/shard-skl2/igt@i915_selftest@live@gt_heartbeat.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19315/shard-skl2/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_selftest@live@perf: - shard-skl: [PASS][16] -> [SKIP][17] ([fdo#109271]) +12 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9580/shard-skl2/igt@i915_selftest@l...@perf.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19315/shard-skl2/igt@i915_selftest@l...@perf.html * igt@kms_color@pipe-d-ctm-max: - shard-iclb: NOTRUN -> [SKIP][18] ([fdo#109278] / [i915#1149]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19315/shard-iclb4/igt@kms_co...@pipe-d-ctm-max.html * igt@kms_color_chamelium@pipe-a-gamma: - shard-iclb: NOTRUN -> [SKIP][19] ([fdo#109284] / [fdo#111827]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19315/shard-iclb4/igt@kms_color_chamel...@pipe-a-gamma.html - shard-kbl: NOTRUN -> [SKIP][20] ([fdo#109271] / [fdo#111827]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19315/shard-kbl3/igt@kms_color_chamel...@pipe-a-gamma.html * igt@kms_cursor_crc@pipe-b-cursor-256x85-random: - shard-skl: [PASS][21] -> [FAIL][22] ([i915#54]) +6 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9580/shard-skl1/igt@kms_cursor_...@pipe-b-cursor-256x85-random.html [22]: https://intel-gfx-ci.01.org/tr
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure
On Thu, Jan 07, 2021 at 08:20:25PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Some new eDP panels don't like to operate at the max parameters, and
> instead we need to go for an optimal confiugration. That unfortunately
> doesn't work with older eDP panels which are generally only guaranteed
> to work at the max parameters.
>
> To solve these two conflicting requirements let's start with the optimal
> setup, and if that fails we start again with the max parameters. The
> downside is probably an extra modeset when we switch strategies but
> I don't see a good way to avoid that.
>
> For a bit of history we first tried to go for the fast+narrow in
> commit 7769db588384 ("drm/i915/dp: optimize eDP 1.4+ link config
> fast and narrow"). but that had to be reverted due to regression
> on older panels in commit f11cb1c19ad0 ("drm/i915/dp: revert back
> to max link rate and lane count on eDP"). So now we try to get
> the best of both worlds by using both strategies.
Pushed. Fingers crossed for no regressions...
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PULL] gvt-fixes
On Fri, 08 Jan 2021, Zhenyu Wang wrote: > Hi, > > Here's one gvt fixes for VFIO edid on APL/BXT with virtual display > hotplug fixed that feature is enabled again. Thanks, merged to drm-intel-fixes. BR, Jani. > > Thanks. > -- > The following changes since commit e71ba9452f0b5b2e8dc8aa5445198cd9214a6a62: > > Linux 5.11-rc2 (2021-01-03 15:55:30 -0800) > > are available in the Git repository at: > > https://github.com/intel/gvt-linux tags/gvt-fixes-2020-01-08 > > for you to fetch changes up to 4ceb06e7c336f4a8d3f3b6ac9a4fea2e9c97dc07: > > drm/i915/gvt: Fix vfio_edid issue for BXT/APL (2021-01-06 11:19:15 +0800) > > > gvt-fixes-2020-01-08 > > - Fix VFIO EDID on APL/BXT (Colin) > > > Colin Xu (1): > drm/i915/gvt: Fix vfio_edid issue for BXT/APL > > drivers/gpu/drm/i915/gvt/display.c | 81 > +++--- > drivers/gpu/drm/i915/gvt/vgpu.c| 5 +-- > 2 files changed, 59 insertions(+), 27 deletions(-) -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Only enable DFP 4:4:4->4:2:0 conversion when outputting YCbCr 4:4:4
== Series Details == Series: drm/i915: Only enable DFP 4:4:4->4:2:0 conversion when outputting YCbCr 4:4:4 URL : https://patchwork.freedesktop.org/series/85715/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9580 -> Patchwork_19316 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_19316 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19316, 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_19316/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_19316: ### IGT changes ### Possible regressions * igt@i915_selftest@live@hugepages: - fi-kbl-soraka: [PASS][1] -> [DMESG-FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9580/fi-kbl-soraka/igt@i915_selftest@l...@hugepages.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19316/fi-kbl-soraka/igt@i915_selftest@l...@hugepages.html Known issues Here are the changes found in Patchwork_19316 that come from known issues: ### IGT changes ### Issues hit * igt@gem_huc_copy@huc-copy: - fi-byt-j1900: NOTRUN -> [SKIP][3] ([fdo#109271]) +27 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19316/fi-byt-j1900/igt@gem_huc_c...@huc-copy.html * igt@gem_ringfill@basic-all: - fi-tgl-y: [PASS][4] -> [DMESG-WARN][5] ([i915#402]) +1 similar issue [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9580/fi-tgl-y/igt@gem_ringf...@basic-all.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19316/fi-tgl-y/igt@gem_ringf...@basic-all.html * igt@i915_pm_rpm@module-reload: - fi-kbl-guc: [PASS][6] -> [SKIP][7] ([fdo#109271]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9580/fi-kbl-guc/igt@i915_pm_...@module-reload.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19316/fi-kbl-guc/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live@blt: - fi-snb-2600:[PASS][8] -> [DMESG-FAIL][9] ([i915#1409]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9580/fi-snb-2600/igt@i915_selftest@l...@blt.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19316/fi-snb-2600/igt@i915_selftest@l...@blt.html * igt@i915_selftest@live@gt_heartbeat: - fi-tgl-y: [PASS][10] -> [DMESG-FAIL][11] ([i915#2601]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9580/fi-tgl-y/igt@i915_selftest@live@gt_heartbeat.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19316/fi-tgl-y/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_selftest@live@reset: - fi-kbl-soraka: [PASS][12] -> [SKIP][13] ([fdo#109271]) +10 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9580/fi-kbl-soraka/igt@i915_selftest@l...@reset.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19316/fi-kbl-soraka/igt@i915_selftest@l...@reset.html * igt@kms_chamelium@dp-crc-fast: - fi-kbl-7500u: [PASS][14] -> [FAIL][15] ([i915#1161] / [i915#262]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9580/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19316/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html * igt@kms_chamelium@hdmi-crc-fast: - fi-byt-j1900: NOTRUN -> [SKIP][16] ([fdo#109271] / [fdo#111827]) +8 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19316/fi-byt-j1900/igt@kms_chamel...@hdmi-crc-fast.html * igt@runner@aborted: - fi-kbl-soraka: NOTRUN -> [FAIL][17] ([i915#1436] / [i915#2295]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19316/fi-kbl-soraka/igt@run...@aborted.html Possible fixes * igt@vgem_basic@dmabuf-fence-before: - fi-tgl-y: [DMESG-WARN][18] ([i915#402]) -> [PASS][19] +1 similar issue [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9580/fi-tgl-y/igt@vgem_ba...@dmabuf-fence-before.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19316/fi-tgl-y/igt@vgem_ba...@dmabuf-fence-before.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#1161]: https://gitlab.freedesktop.org/drm/intel/issues/1161 [i915#1409]: https://gitlab.freedesktop.org/drm/intel/issues/1409 [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436 [i915#2295]: https://gitlab.freedesktop.org/drm/intel/issues/2295 [i915#2601]: https://gitlab.freedesktop.org/drm/intel/issues/2601 [i915#262]: https://gitlab.freedesktop.org/drm/intel
Re: [Intel-gfx] [PATCH 03/11] drm/i915: Allow the sysadmin to override security mitigations
On Sun, Jan 10, 2021 at 03:03:56PM +, Chris Wilson wrote:
> The clear-residuals mitigation is a relatively heavy hammer and under some
> circumstances the user may wish to forgo the context isolation in order
> to meet some performance requirement. Introduce a generic module
> parameter to allow selectively enabling/disabling different mitigations.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1858
I'm afraid this will have the same faith as the rc6 and the validation impact :/
> Fixes: 47f8253d2b89 ("drm/i915/gen7: Clear all EU/L3 residual contexts")
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Jon Bloomfield
> Cc: Rodrigo Vivi
> Cc: sta...@vger.kernel.org # v5.7
> ---
> drivers/gpu/drm/i915/Makefile | 1 +
> .../gpu/drm/i915/gt/intel_ring_submission.c | 4 +-
> drivers/gpu/drm/i915/i915_mitigations.c | 148 ++
> drivers/gpu/drm/i915/i915_mitigations.h | 13 ++
> 4 files changed, 165 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/i915/i915_mitigations.c
> create mode 100644 drivers/gpu/drm/i915/i915_mitigations.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 4074d8cb0d6e..48f82c354611 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -38,6 +38,7 @@ i915-y += i915_drv.o \
> i915_config.o \
> i915_irq.o \
> i915_getparam.o \
> + i915_mitigations.o \
> i915_params.o \
> i915_pci.o \
> i915_scatterlist.o \
> diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> index 724d56c9583d..657afd8ebc14 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> @@ -32,6 +32,7 @@
> #include "gen6_ppgtt.h"
> #include "gen7_renderclear.h"
> #include "i915_drv.h"
> +#include "i915_mitigations.h"
> #include "intel_breadcrumbs.h"
> #include "intel_context.h"
> #include "intel_gt.h"
> @@ -918,7 +919,8 @@ static int switch_context(struct i915_request *rq)
> GEM_BUG_ON(HAS_EXECLISTS(engine->i915));
>
> if (engine->wa_ctx.vma && ce != engine->kernel_context) {
> - if (engine->wa_ctx.vma->private != ce) {
> + if (engine->wa_ctx.vma->private != ce &&
> + i915_mitigate_clear_residuals()) {
> ret = clear_residuals(rq);
> if (ret)
> return ret;
> diff --git a/drivers/gpu/drm/i915/i915_mitigations.c
> b/drivers/gpu/drm/i915/i915_mitigations.c
> new file mode 100644
> index ..8d5637cfa734
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/i915_mitigations.c
> @@ -0,0 +1,148 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2021 Intel Corporation
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include "i915_drv.h"
> +#include "i915_mitigations.h"
> +
> +static unsigned long mitigations = ~0UL;
> +
> +enum {
> + CLEAR_RESIDUALS = 0,
specially worse if this list grows...
> +};
> +
> +static const char * const names[] = {
> + [CLEAR_RESIDUALS] = "residuals",
> +};
> +
> +bool i915_mitigate_clear_residuals(void)
> +{
> + return READ_ONCE(mitigations) & BIT(CLEAR_RESIDUALS);
> +}
> +
> +static int mitigations_set(const char *val, const struct kernel_param *kp)
> +{
> + unsigned long new = ~0UL;
> + char *str, *sep, *tok;
> + bool first = true;
> + int err = 0;
> +
> + BUILD_BUG_ON(ARRAY_SIZE(names) >= BITS_PER_TYPE(mitigations));
> +
> + str = kstrdup(val, GFP_KERNEL);
> + if (!str)
> + return -ENOMEM;
> +
> + for (sep = str; (tok = strsep(&sep, ","));) {
> + bool enable = true;
> + int i;
> +
> + /* Be tolerant of leading/trailing whitespace */
> + tok = strim(tok);
> +
> + if (first) {
> + first = false;
> +
> + if (!strcmp(tok, "auto")) {
> + new = ~0UL;
> + continue;
> + }
> +
> + new = 0;
> + if (!strcmp(tok, "off"))
> + continue;
> + }
> +
> + if (*tok == '!') {
> + enable = !enable;
> + tok++;
> + }
> +
> + if (!strncmp(tok, "no", 2)) {
> + enable = !enable;
> + tok += 2;
> + }
> +
> + if (*tok == '\0')
> + continue;
> +
> + for (i = 0; i < ARRAY_SIZE(names); i++) {
> + if (!strcmp(tok, names[i])) {
> + if (enable)
> + new |= BIT(i);
> + else
> + new &= ~BIT(i);
> +
Re: [Intel-gfx] [PATCH v2] drm/i915/dg1: Update voltage swing tables for DP
On 1/8/21 2:25 PM, Matt Roper wrote:
DG1's vswing tables are the same for eDP and HDMI but have slight
differences from ICL/TGL for DP.
v2:
- Use a "_hbr2_hbr3" suffix on the table name to make it more clear
that the same table is used for both HBR2 and HBR3 link rates.
(Swathi)
Bspec: 49291
Cc: Clinton Taylor
Cc: José Roberto de Souza
Cc: Radhakrishna Sripada
Cc: Swathi Dhanavanthri
Signed-off-by: Matt Roper
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_ddi.c | 34
1 file changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 3df6913369bc..a047fd81e433 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -611,6 +611,34 @@ static const struct cnl_ddi_buf_trans
jsl_combo_phy_ddi_translations_edp_hbr2[]
{ 0xA, 0x35, 0x3F, 0x00, 0x00 },/* 350 350 0.0 */
};
+static const struct cnl_ddi_buf_trans dg1_combo_phy_ddi_translations_dp_hbr[] = {
If we are following the same logic for struct naming this should be
_rbr_hbr. Probably a NIT but it would be consistent.
Feel free to change the name or leave it. The code appears to match the
current BSPEC table.
Reviewed-by: Clint Taylor
-Clint
+ /* NT mV Trans mV db*/
+ { 0xA, 0x32, 0x3F, 0x00, 0x00 },/* 350 350 0.0 */
+ { 0xA, 0x48, 0x35, 0x00, 0x0A },/* 350 500 3.1 */
+ { 0xC, 0x63, 0x2F, 0x00, 0x10 },/* 350 700 6.0 */
+ { 0x6, 0x7F, 0x2C, 0x00, 0x13 },/* 350 900 8.2 */
+ { 0xA, 0x43, 0x3F, 0x00, 0x00 },/* 500 500 0.0 */
+ { 0xC, 0x60, 0x36, 0x00, 0x09 },/* 500 700 2.9 */
+ { 0x6, 0x7F, 0x30, 0x00, 0x0F },/* 500 900 5.1 */
+ { 0xC, 0x60, 0x3F, 0x00, 0x00 },/* 650 700 0.6 */
+ { 0x6, 0x7F, 0x37, 0x00, 0x08 },/* 600 900 3.5 */
+ { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 900 900 0.0 */
+};
+
+static const struct cnl_ddi_buf_trans
dg1_combo_phy_ddi_translations_dp_hbr2_hbr3[] = {
+ /* NT mV Trans mV db*/
+ { 0xA, 0x32, 0x3F, 0x00, 0x00 },/* 350 350 0.0 */
+ { 0xA, 0x48, 0x35, 0x00, 0x0A },/* 350 500 3.1 */
+ { 0xC, 0x63, 0x2F, 0x00, 0x10 },/* 350 700 6.0 */
+ { 0x6, 0x7F, 0x2C, 0x00, 0x13 },/* 350 900 8.2 */
+ { 0xA, 0x43, 0x3F, 0x00, 0x00 },/* 500 500 0.0 */
+ { 0xC, 0x60, 0x36, 0x00, 0x09 },/* 500 700 2.9 */
+ { 0x6, 0x7F, 0x30, 0x00, 0x0F },/* 500 900 5.1 */
+ { 0xC, 0x58, 0x3F, 0x00, 0x00 },/* 650 700 0.6 */
+ { 0x6, 0x7F, 0x35, 0x00, 0x0A },/* 600 900 3.5 */
+ { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 900 900 0.0 */
+};
+
struct icl_mg_phy_ddi_buf_trans {
u32 cri_txdeemph_override_11_6;
u32 cri_txdeemph_override_5_0;
@@ -1121,6 +1149,12 @@ icl_get_combo_buf_trans_edp(struct intel_encoder
*encoder,
} else if (dev_priv->vbt.edp.low_vswing) {
*n_entries =
ARRAY_SIZE(icl_combo_phy_ddi_translations_edp_hbr2);
return icl_combo_phy_ddi_translations_edp_hbr2;
+ } else if (IS_DG1(dev_priv) && crtc_state->port_clock > 27) {
+ *n_entries =
ARRAY_SIZE(dg1_combo_phy_ddi_translations_dp_hbr2_hbr3);
+ return dg1_combo_phy_ddi_translations_dp_hbr2_hbr3;
+ } else if (IS_DG1(dev_priv)) {
+ *n_entries = ARRAY_SIZE(dg1_combo_phy_ddi_translations_dp_hbr);
+ return dg1_combo_phy_ddi_translations_dp_hbr;
}
return icl_get_combo_buf_trans_dp(encoder, crtc_state, n_entries);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/11] drm/i915/gt: Restore clear-residual mitigations for Ivybridge, Baytrail
On Sun, Jan 10, 2021 at 03:03:55PM +, Chris Wilson wrote:
> The mitigation is required for all gen7 platforms, now that it does not
> cause GPU hangs, restore it for Ivybridge and Baytrail.
>
> Fixes: 47f8253d2b89 ("drm/i915/gen7: Clear all EU/L3 residual contexts")
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Prathap Kumar Valsan
> Cc: Akeem G Abodunrin
> Cc: Bloomfield Jon
> ---
> drivers/gpu/drm/i915/gt/intel_ring_submission.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> index 1c6d421f6fe5..724d56c9583d 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> @@ -1324,7 +1324,7 @@ int intel_ring_submission_setup(struct intel_engine_cs
> *engine)
>
> GEM_BUG_ON(timeline->hwsp_ggtt != engine->status_page.vma);
>
> - if (IS_HASWELL(engine->i915) && engine->class == RENDER_CLASS) {
> + if (IS_GEN(engine->i915, 7) && engine->class == RENDER_CLASS) {
when CI is really happy
Reviewed-by: Rodrigo Vivi
> err = gen7_ctx_switch_bb_init(engine);
> if (err)
> goto err_ring_unpin;
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/11] drm/i915/gt: Limit VFE threads based on GT
On Sun, Jan 10, 2021 at 03:03:54PM +, Chris Wilson wrote:
> MEDIA_STATE_VFE only accepts the 'maximum number of threads' in the
> range [0, n-1] where n is #EU * (#threads/EU) with the number of threads
> based on plaform and the number of EU based on the number of slices and
> subslices. This is a fixed number per platform/gt, so appropriately
> limit the number of threads we spawn to match the device.
>
> v2: Oversaturate the system with tasks to force execution on every HW
> thread; if the thread idles it is returned to the pool and may be reused
> again before an unused thread.
>
> v3: Fix more state commands, which was causing Baytrail to barf.
CI is still not happy with byt right? or is that false positive?
> v4: STATE_CACHE_INVALIDATE requires a stall on Ivybridge
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2024
> Fixes: 47f8253d2b89 ("drm/i915/gen7: Clear all EU/L3 residual contexts")
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Prathap Kumar Valsan
> Cc: Akeem G Abodunrin
> Cc: Jon Bloomfield
> Cc: Rodrigo Vivi
> Cc: Randy Wright
> Cc: sta...@vger.kernel.org # v5.7+
> ---
> drivers/gpu/drm/i915/gt/gen7_renderclear.c | 157 -
> 1 file changed, 94 insertions(+), 63 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/gen7_renderclear.c
> b/drivers/gpu/drm/i915/gt/gen7_renderclear.c
> index d93d85cd3027..f32a8e8040b2 100644
> --- a/drivers/gpu/drm/i915/gt/gen7_renderclear.c
> +++ b/drivers/gpu/drm/i915/gt/gen7_renderclear.c
> @@ -7,8 +7,6 @@
> #include "i915_drv.h"
> #include "intel_gpu_commands.h"
>
> -#define MAX_URB_ENTRIES 64
> -#define STATE_SIZE (4 * 1024)
> #define GT3_INLINE_DATA_DELAYS 0x1E00
> #define batch_advance(Y, CS) GEM_BUG_ON((Y)->end != (CS))
>
> @@ -34,38 +32,59 @@ struct batch_chunk {
> };
>
> struct batch_vals {
> - u32 max_primitives;
> - u32 max_urb_entries;
> - u32 cmd_size;
> - u32 state_size;
> + u32 max_threads;
> u32 state_start;
> - u32 batch_size;
> + u32 surface_start;
> u32 surface_height;
> u32 surface_width;
> - u32 scratch_size;
> - u32 max_size;
> + u32 size;
> };
>
> +static inline int num_primitives(const struct batch_vals *bv)
> +{
> + /*
> + * We need to saturate the GPU with work in order to dispatch
> + * a shader on every HW thread, and clear the thread-local registers.
> + * In short, we have to dispatch work faster than the shaders can
> + * run in order to fill occupy each HW thread.
> + */
> + return bv->max_threads;
> +}
> +
> static void
> batch_get_defaults(struct drm_i915_private *i915, struct batch_vals *bv)
> {
> if (IS_HASWELL(i915)) {
> - bv->max_primitives = 280;
> - bv->max_urb_entries = MAX_URB_ENTRIES;
> + switch (INTEL_INFO(i915)->gt) {
> + default:
> + case 1:
> + bv->max_threads = 70;
> + break;
> + case 2:
> + bv->max_threads = 140;
> + break;
> + case 3:
> + bv->max_threads = 280;
> + break;
> + }
> bv->surface_height = 16 * 16;
> bv->surface_width = 32 * 2 * 16;
> } else {
> - bv->max_primitives = 128;
> - bv->max_urb_entries = MAX_URB_ENTRIES / 2;
> + switch (INTEL_INFO(i915)->gt) {
> + default:
> + case 1: /* including vlv */
> + bv->max_threads = 36;
> + break;
> + case 2:
> + bv->max_threads = 128;
> + break;
> + }
> bv->surface_height = 16 * 8;
> bv->surface_width = 32 * 16;
all the values above matches the spec.
> }
> - bv->cmd_size = bv->max_primitives * 4096;
> - bv->state_size = STATE_SIZE;
> - bv->state_start = bv->cmd_size;
> - bv->batch_size = bv->cmd_size + bv->state_size;
> - bv->scratch_size = bv->surface_height * bv->surface_width;
> - bv->max_size = bv->batch_size + bv->scratch_size;
> + bv->state_start = round_up(SZ_1K + num_primitives(bv) * 64, SZ_4K);
> + bv->surface_start = bv->state_start + SZ_4K;
> + bv->size = bv->surface_start + bv->surface_height * bv->surface_width;
I liked this batch values simplification...
> }
>
> static void batch_init(struct batch_chunk *bc,
> @@ -155,7 +174,8 @@ static u32
> gen7_fill_binding_table(struct batch_chunk *state,
> const struct batch_vals *bv)
> {
> - u32 surface_start = gen7_fill_surface_state(state, bv->batch_size, bv);
> + u32 surface_start =
> + gen7_fill_surface_state(state, bv->surface_start, bv);
> u32 *cs = batch_alloc_items(state, 32, 8);
> u32 offset = batch_offset(state, cs);
>
> @@ -214,9 +234,9 @@ static void
> gen7_emit_state_base_address(st
Re: [Intel-gfx] [PATCH 03/11] drm/i915: Allow the sysadmin to override security mitigations
> -Original Message-
> From: Chris Wilson
> Sent: Sunday, January 10, 2021 7:04 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Chris Wilson ; Joonas Lahtinen
> ; Bloomfield, Jon
> ; Vivi, Rodrigo ;
> sta...@vger.kernel.org
> Subject: [PATCH 03/11] drm/i915: Allow the sysadmin to override security
> mitigations
>
> The clear-residuals mitigation is a relatively heavy hammer and under some
> circumstances the user may wish to forgo the context isolation in order
> to meet some performance requirement. Introduce a generic module
> parameter to allow selectively enabling/disabling different mitigations.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1858
> Fixes: 47f8253d2b89 ("drm/i915/gen7: Clear all EU/L3 residual contexts")
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Jon Bloomfield
> Cc: Rodrigo Vivi
> Cc: sta...@vger.kernel.org # v5.7
> ---
Reviewed-by: Jon Bloomfield ?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Async flips for all ilk+ platforms (rev2)
== Series Details == Series: drm/i915: Async flips for all ilk+ platforms (rev2) URL : https://patchwork.freedesktop.org/series/85627/ State : success == Summary == CI Bug Log - changes from CI_DRM_9580 -> Patchwork_19315 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19315/index.html Known issues Here are the changes found in Patchwork_19315 that come from known issues: ### IGT changes ### Issues hit * igt@gem_flink_basic@basic: - fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] ([i915#402]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9580/fi-tgl-y/igt@gem_flink_ba...@basic.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19315/fi-tgl-y/igt@gem_flink_ba...@basic.html * igt@gem_huc_copy@huc-copy: - fi-byt-j1900: NOTRUN -> [SKIP][3] ([fdo#109271]) +27 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19315/fi-byt-j1900/igt@gem_huc_c...@huc-copy.html * igt@i915_pm_rpm@module-reload: - fi-kbl-guc: [PASS][4] -> [SKIP][5] ([fdo#109271]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9580/fi-kbl-guc/igt@i915_pm_...@module-reload.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19315/fi-kbl-guc/igt@i915_pm_...@module-reload.html * igt@kms_chamelium@hdmi-crc-fast: - fi-byt-j1900: NOTRUN -> [SKIP][6] ([fdo#109271] / [fdo#111827]) +8 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19315/fi-byt-j1900/igt@kms_chamel...@hdmi-crc-fast.html Possible fixes * igt@vgem_basic@dmabuf-fence-before: - fi-tgl-y: [DMESG-WARN][7] ([i915#402]) -> [PASS][8] +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9580/fi-tgl-y/igt@vgem_ba...@dmabuf-fence-before.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19315/fi-tgl-y/igt@vgem_ba...@dmabuf-fence-before.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 Participating hosts (43 -> 38) -- Additional (1): fi-byt-j1900 Missing(6): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-cml-drallion fi-bdw-samus Build changes - * Linux: CI_DRM_9580 -> Patchwork_19315 CI-20190529: 20190529 CI_DRM_9580: 117f9c9bca0ebb0e22ce282eab531575f5154055 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5953: 65c5eea699141e6f942ce0a8fc85db76ce53cd19 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19315: b5239b3cf416cfc73090ddd8ec7bba725278ecaa @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == b5239b3cf416 drm/i915: Implement async flips for vlv/chv 6601effeab9e drm/i915: Implement async flip for ilk/snb 711c4297a93a drm/i915: Implement async flip for ivb/hsw 2fd4cac00c8a drm/i915: Implement async flips for bdw 94917f63b8f7 drm/i915: Reuse the async_flip() hook for the async flip disable w/a 89770394ed91 drm/i915: Move the async_flip bit setup into the .async_flip() hook 9655ad213677 drm/i915: Add plane vfuncs to enable/disable flip_done interrupt 2e1ed4a184df drm/i915: Generalize the async flip capability check 87a8d5da85f9 drm/i915: Drop redundant parens 492c717aeb30 drm/i915: Limit plane stride to below TILEOFF.x limit 27179a0516e5 drm/i915: WARN if plane src coords are too big == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19315/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915/gt: Perform an arbitration check before busywaiting
On 11/01/2021 16:27, Chris Wilson wrote: Quoting Tvrtko Ursulin (2021-01-11 16:19:40) On 11/01/2021 10:57, Chris Wilson wrote: During igt_reset_nop_engine, it was observed that an unexpected failed engine reset lead to us busywaiting on the stop-ring semaphore (set during the reset preparations) on the first request afterwards. There was no explicit MI_ARB_CHECK in this sequence as the presumption was that the failed MI_SEMAPHORE_WAIT would itself act as an arbitration point. It did not in this circumstance, so force it. In other words MI_SEMAPHORE_POLL is not a preemption point? Can't remember if I knew that or not.. MI_SEMAPHORE_WAIT | POLL is most definitely a preemption point on a miss. 1) Why not the same handling in !gen12 version? Because I think it's a bug in tgl [a0 at least]. I think I've seen the same symptoms on tgl before, but not earlier. This is the first time the sequence clicked as to why it was busy spinning. Random engine reset failures are rare enough -- I was meant to also write a test case to inject failure. Random engine reset failure you think is a TGL issue? 2) Failed reset leads to busy-hang in following request _tail_? But there is an arb check at the start of following request as well. Or in cases where we context switch into the middle of a previously executing request? It was the first request submitted after the failed reset. We expect to clear the ring-stop flag on the CS IDLE->ACTIVE event. But why would that busy hang? Hasn't the failed request unpaused the ring? The engine was idle at the time of the failed reset. We left the ring-stop set, and submitted the next batch of requests. We hit the MI_SEMAPHORE_WAIT(ring-stop) at the end of the first request, but without hitting an arbitration point (first request, no init-breadcrumb in this case), the semaphore was stuck. So a kernel context request? Why hasn't IDLE->ACTIVE cleared ring stop? Presumably this CSB must come after the first request has been submitted so apparently I am still not getting how it hangs. Just because igt_reset_nop_engine does things "quickly"? It prevents the CSB from arriving? So ARB_CHECK pickups up on the fact ELSP has been rewritten before the IDLE->ACTIVE even received and/or engine reset prevented it from arriving? Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Only enable DFP 4:4:4->4:2:0 conversion when outputting YCbCr 4:4:4
From: Ville Syrjälä Let's not enable the 4:4:4->4:2:0 conversion bit in the DFP unless we're actually outputting YCbCr 4:4:4. It would appear some protocol converters blindy consult this bit even when the source is outputting RGB, resulting in a visual mess. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2914 Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_dp.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c index 4f190a82d4ad..aa30ef9f6906 100644 --- a/drivers/gpu/drm/i915/display/intel_dp.c +++ b/drivers/gpu/drm/i915/display/intel_dp.c @@ -4368,8 +4368,8 @@ void intel_dp_configure_protocol_converter(struct intel_dp *intel_dp, drm_dbg_kms(&i915->drm, "Failed to set protocol converter HDMI mode to %s\n", enableddisabled(intel_dp->has_hdmi_sink)); - tmp = intel_dp->dfp.ycbcr_444_to_420 ? - DP_CONVERSION_TO_YCBCR420_ENABLE : 0; + tmp = crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR444 && + intel_dp->dfp.ycbcr_444_to_420 ? DP_CONVERSION_TO_YCBCR420_ENABLE : 0; if (drm_dp_dpcd_writeb(&intel_dp->aux, DP_PROTOCOL_CONVERTER_CONTROL_1, tmp) != 1) -- 2.26.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm: Check actual format for legacy pageflip.
On Mon, Jan 11, 2021 at 4:02 PM Alex Deucher wrote:
>
> On Sat, Jan 9, 2021 at 9:11 PM Bas Nieuwenhuizen
> wrote:
> >
> > With modifiers one can actually have different format_info structs
> > for the same format, which now matters for AMDGPU since we convert
> > implicit modifiers to explicit modifiers with multiple planes.
> >
> > I checked other drivers and it doesn't look like they end up triggering
> > this case so I think this is safe to relax.
> >
> > Signed-off-by: Bas Nieuwenhuizen
> > Reviewed-by: Daniel Vetter
> > Reviewed-by: Zhan Liu
> > Acked-by: Christian König
> > Acked-by: Alex Deucher
> > Fixes: 816853f9dc40 ("drm/amd/display: Set new format info for converted
> > metadata.")
>
> Do you have commit rights to drm-misc or do you need someone to commit
> this for you?
I don't have commit rights so if the patch could be committed for me
that would be appreciated!
>
> Thanks!
>
> Alex
>
> > ---
> > drivers/gpu/drm/drm_plane.c | 9 -
> > 1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> > index e6231947f987..a0cb746bcb0a 100644
> > --- a/drivers/gpu/drm/drm_plane.c
> > +++ b/drivers/gpu/drm/drm_plane.c
> > @@ -1163,7 +1163,14 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
> > if (ret)
> > goto out;
> >
> > - if (old_fb->format != fb->format) {
> > + /*
> > +* Only check the FOURCC format code, excluding modifiers. This is
> > +* enough for all legacy drivers. Atomic drivers have their own
> > +* checks in their ->atomic_check implementation, which will
> > +* return -EINVAL if any hw or driver constraint is violated due
> > +* to modifier changes.
> > +*/
> > + if (old_fb->format->format != fb->format->format) {
> > DRM_DEBUG_KMS("Page flip is not allowed to change frame
> > buffer format.\n");
> > ret = -EINVAL;
> > goto out;
> > --
> > 2.29.2
> >
> > ___
> > amd-gfx mailing list
> > amd-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 11/11] drm/i915: Implement async flips for vlv/chv
From: Ville Syrjälä
Add support for async flips on vlv/chv. Unlike all the other
platforms vlv/chv do not use the async flip bit in DSPCNTR and
instead we select between async vs. sync flips based on the
surface address register. The normal DSPSURF generates sync
flips DSPADDR_VLV generates async flips. And as usual the
interrupt bits are different from the other platforms.
Cc: Karthik B S
Cc: Vandita Kulkarni
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/i9xx_plane.c| 49 ++--
drivers/gpu/drm/i915/display/intel_display.c | 4 +-
drivers/gpu/drm/i915/i915_irq.c | 3 ++
drivers/gpu/drm/i915/i915_reg.h | 2 +
4 files changed, 52 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/i9xx_plane.c
b/drivers/gpu/drm/i915/display/i9xx_plane.c
index 488ed01bb342..d30374df67f0 100644
--- a/drivers/gpu/drm/i915/display/i9xx_plane.c
+++ b/drivers/gpu/drm/i915/display/i9xx_plane.c
@@ -517,6 +517,23 @@ g4x_primary_async_flip(struct intel_plane *plane,
spin_unlock_irqrestore(&dev_priv->uncore.lock, irqflags);
}
+static void
+vlv_primary_async_flip(struct intel_plane *plane,
+ const struct intel_crtc_state *crtc_state,
+ const struct intel_plane_state *plane_state,
+ bool async_flip)
+{
+ struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
+ u32 dspaddr_offset = plane_state->color_plane[0].offset;
+ enum i9xx_plane_id i9xx_plane = plane->i9xx_plane;
+ unsigned long irqflags;
+
+ spin_lock_irqsave(&dev_priv->uncore.lock, irqflags);
+ intel_de_write_fw(dev_priv, DSPADDR_VLV(i9xx_plane),
+ intel_plane_ggtt_offset(plane_state) +
dspaddr_offset);
+ spin_unlock_irqrestore(&dev_priv->uncore.lock, irqflags);
+}
+
static void
bdw_primary_enable_flip_done(struct intel_plane *plane)
{
@@ -579,6 +596,28 @@ ilk_primary_disable_flip_done(struct intel_plane *plane)
spin_unlock_irq(&i915->irq_lock);
}
+static void
+vlv_primary_enable_flip_done(struct intel_plane *plane)
+{
+ struct drm_i915_private *i915 = to_i915(plane->base.dev);
+ enum pipe pipe = plane->pipe;
+
+ spin_lock_irq(&i915->irq_lock);
+ i915_enable_pipestat(i915, pipe, PLANE_FLIP_DONE_INT_STATUS_VLV);
+ spin_unlock_irq(&i915->irq_lock);
+}
+
+static void
+vlv_primary_disable_flip_done(struct intel_plane *plane)
+{
+ struct drm_i915_private *i915 = to_i915(plane->base.dev);
+ enum pipe pipe = plane->pipe;
+
+ spin_lock_irq(&i915->irq_lock);
+ i915_disable_pipestat(i915, pipe, PLANE_FLIP_DONE_INT_STATUS_VLV);
+ spin_unlock_irq(&i915->irq_lock);
+}
+
static bool i9xx_plane_get_hw_state(struct intel_plane *plane,
enum pipe *pipe)
{
@@ -792,16 +831,20 @@ intel_primary_plane_create(struct drm_i915_private
*dev_priv, enum pipe pipe)
plane->get_hw_state = i9xx_plane_get_hw_state;
plane->check_plane = i9xx_plane_check;
- if (IS_BROADWELL(dev_priv)) {
+ if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
+ plane->async_flip = vlv_primary_async_flip;
+ plane->enable_flip_done = vlv_primary_enable_flip_done;
+ plane->disable_flip_done = vlv_primary_disable_flip_done;
+ } else if (IS_BROADWELL(dev_priv)) {
plane->need_async_flip_disable_wa = true;
plane->async_flip = g4x_primary_async_flip;
plane->enable_flip_done = bdw_primary_enable_flip_done;
plane->disable_flip_done = bdw_primary_disable_flip_done;
- } else if (IS_HASWELL(dev_priv) || IS_IVYBRIDGE(dev_priv)) {
+ } else if (INTEL_GEN(dev_priv) >= 7) {
plane->async_flip = g4x_primary_async_flip;
plane->enable_flip_done = ivb_primary_enable_flip_done;
plane->disable_flip_done = ivb_primary_disable_flip_done;
- } else if (IS_GEN_RANGE(dev_priv, 5, 6)) {
+ } else if (INTEL_GEN(dev_priv) >= 5) {
plane->async_flip = g4x_primary_async_flip;
plane->enable_flip_done = ilk_primary_enable_flip_done;
plane->disable_flip_done = ilk_primary_disable_flip_done;
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 67add1166d5a..8cf0777535ca 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -2122,9 +2122,7 @@ static unsigned int intel_linear_alignment(const struct
drm_i915_private *dev_pr
static bool has_async_flips(struct drm_i915_private *i915)
{
- return INTEL_GEN(i915) >= 9 || IS_BROADWELL(i915) ||
- IS_HASWELL(i915) || IS_IVYBRIDGE(i915) ||
- IS_GEN_RANGE(i915, 5, 6);
+ return INTEL_GEN(i915) >= 5;
}
static unsigned int intel_surf_alignment(const struct drm_framebuff
[Intel-gfx] [PATCH v2 10/11] drm/i915: Implement async flip for ilk/snb
From: Ville Syrjälä
Add support for async flips on ivb/hsw. Again no need for any
workarounds and just have to deal with the interrupt bits being
shuffled around a bit.
Cc: Karthik B S
Cc: Vandita Kulkarni
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/i9xx_plane.c| 24
drivers/gpu/drm/i915/display/intel_display.c | 3 ++-
drivers/gpu/drm/i915/i915_irq.c | 5
3 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/i9xx_plane.c
b/drivers/gpu/drm/i915/display/i9xx_plane.c
index f75be2292caa..488ed01bb342 100644
--- a/drivers/gpu/drm/i915/display/i9xx_plane.c
+++ b/drivers/gpu/drm/i915/display/i9xx_plane.c
@@ -559,6 +559,26 @@ ivb_primary_disable_flip_done(struct intel_plane *plane)
spin_unlock_irq(&i915->irq_lock);
}
+static void
+ilk_primary_enable_flip_done(struct intel_plane *plane)
+{
+ struct drm_i915_private *i915 = to_i915(plane->base.dev);
+
+ spin_lock_irq(&i915->irq_lock);
+ ilk_enable_display_irq(i915, DE_PLANE_FLIP_DONE(plane->i9xx_plane));
+ spin_unlock_irq(&i915->irq_lock);
+}
+
+static void
+ilk_primary_disable_flip_done(struct intel_plane *plane)
+{
+ struct drm_i915_private *i915 = to_i915(plane->base.dev);
+
+ spin_lock_irq(&i915->irq_lock);
+ ilk_disable_display_irq(i915, DE_PLANE_FLIP_DONE(plane->i9xx_plane));
+ spin_unlock_irq(&i915->irq_lock);
+}
+
static bool i9xx_plane_get_hw_state(struct intel_plane *plane,
enum pipe *pipe)
{
@@ -781,6 +801,10 @@ intel_primary_plane_create(struct drm_i915_private
*dev_priv, enum pipe pipe)
plane->async_flip = g4x_primary_async_flip;
plane->enable_flip_done = ivb_primary_enable_flip_done;
plane->disable_flip_done = ivb_primary_disable_flip_done;
+ } else if (IS_GEN_RANGE(dev_priv, 5, 6)) {
+ plane->async_flip = g4x_primary_async_flip;
+ plane->enable_flip_done = ilk_primary_enable_flip_done;
+ plane->disable_flip_done = ilk_primary_disable_flip_done;
}
if (INTEL_GEN(dev_priv) >= 5 || IS_G4X(dev_priv))
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 25da68f12df1..67add1166d5a 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -2123,7 +2123,8 @@ static unsigned int intel_linear_alignment(const struct
drm_i915_private *dev_pr
static bool has_async_flips(struct drm_i915_private *i915)
{
return INTEL_GEN(i915) >= 9 || IS_BROADWELL(i915) ||
- IS_HASWELL(i915) || IS_IVYBRIDGE(i915);
+ IS_HASWELL(i915) || IS_IVYBRIDGE(i915) ||
+ IS_GEN_RANGE(i915, 5, 6);
}
static unsigned int intel_surf_alignment(const struct drm_framebuffer *fb,
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 3518f6f23896..9e04c6b28c12 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2029,6 +2029,9 @@ static void ilk_display_irq_handler(struct
drm_i915_private *dev_priv,
if (de_iir & DE_PIPE_VBLANK(pipe))
intel_handle_vblank(dev_priv, pipe);
+ if (de_iir & DE_PLANE_FLIP_DONE(pipe))
+ flip_done_handler(dev_priv, pipe);
+
if (de_iir & DE_PIPE_FIFO_UNDERRUN(pipe))
intel_cpu_fifo_underrun_irq_handler(dev_priv, pipe);
@@ -3577,6 +3580,8 @@ static void ilk_irq_postinstall(struct drm_i915_private
*dev_priv)
DE_PIPEA_CRC_DONE | DE_POISON);
extra_mask = (DE_PIPEA_VBLANK | DE_PIPEB_VBLANK |
DE_PIPEB_FIFO_UNDERRUN | DE_PIPEA_FIFO_UNDERRUN |
+ DE_PLANE_FLIP_DONE(PLANE_A) |
+ DE_PLANE_FLIP_DONE(PLANE_B) |
DE_DP_A_HOTPLUG);
}
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 09/11] drm/i915: Implement async flip for ivb/hsw
From: Ville Syrjälä
Add support for async flips on ivb/hsw. Unlike bdw+ we don't need
any workarounds to disable async flips. Apart from that the only
real difference from the bdw implementation is the location of the
flip_done interrupt bits.
Cc: Karthik B S
Cc: Vandita Kulkarni
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/i9xx_plane.c| 24
drivers/gpu/drm/i915/display/intel_display.c | 3 ++-
drivers/gpu/drm/i915/i915_irq.c | 6 +
3 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/i9xx_plane.c
b/drivers/gpu/drm/i915/display/i9xx_plane.c
index 44004558ebbd..f75be2292caa 100644
--- a/drivers/gpu/drm/i915/display/i9xx_plane.c
+++ b/drivers/gpu/drm/i915/display/i9xx_plane.c
@@ -539,6 +539,26 @@ bdw_primary_disable_flip_done(struct intel_plane *plane)
spin_unlock_irq(&i915->irq_lock);
}
+static void
+ivb_primary_enable_flip_done(struct intel_plane *plane)
+{
+ struct drm_i915_private *i915 = to_i915(plane->base.dev);
+
+ spin_lock_irq(&i915->irq_lock);
+ ilk_enable_display_irq(i915, DE_PLANE_FLIP_DONE_IVB(plane->i9xx_plane));
+ spin_unlock_irq(&i915->irq_lock);
+}
+
+static void
+ivb_primary_disable_flip_done(struct intel_plane *plane)
+{
+ struct drm_i915_private *i915 = to_i915(plane->base.dev);
+
+ spin_lock_irq(&i915->irq_lock);
+ ilk_disable_display_irq(i915,
DE_PLANE_FLIP_DONE_IVB(plane->i9xx_plane));
+ spin_unlock_irq(&i915->irq_lock);
+}
+
static bool i9xx_plane_get_hw_state(struct intel_plane *plane,
enum pipe *pipe)
{
@@ -757,6 +777,10 @@ intel_primary_plane_create(struct drm_i915_private
*dev_priv, enum pipe pipe)
plane->async_flip = g4x_primary_async_flip;
plane->enable_flip_done = bdw_primary_enable_flip_done;
plane->disable_flip_done = bdw_primary_disable_flip_done;
+ } else if (IS_HASWELL(dev_priv) || IS_IVYBRIDGE(dev_priv)) {
+ plane->async_flip = g4x_primary_async_flip;
+ plane->enable_flip_done = ivb_primary_enable_flip_done;
+ plane->disable_flip_done = ivb_primary_disable_flip_done;
}
if (INTEL_GEN(dev_priv) >= 5 || IS_G4X(dev_priv))
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 6db3e6b69a53..25da68f12df1 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -2122,7 +2122,8 @@ static unsigned int intel_linear_alignment(const struct
drm_i915_private *dev_pr
static bool has_async_flips(struct drm_i915_private *i915)
{
- return INTEL_GEN(i915) >= 9 || IS_BROADWELL(i915);
+ return INTEL_GEN(i915) >= 9 || IS_BROADWELL(i915) ||
+ IS_HASWELL(i915) || IS_IVYBRIDGE(i915);
}
static unsigned int intel_surf_alignment(const struct drm_framebuffer *fb,
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 407a9dd0a21e..3518f6f23896 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2081,6 +2081,9 @@ static void ivb_display_irq_handler(struct
drm_i915_private *dev_priv,
for_each_pipe(dev_priv, pipe) {
if (de_iir & DE_PIPE_VBLANK_IVB(pipe))
intel_handle_vblank(dev_priv, pipe);
+
+ if (de_iir & DE_PLANE_FLIP_DONE_IVB(pipe))
+ flip_done_handler(dev_priv, pipe);
}
/* check event from PCH */
@@ -3564,6 +3567,9 @@ static void ilk_irq_postinstall(struct drm_i915_private
*dev_priv)
DE_PCH_EVENT_IVB | DE_AUX_CHANNEL_A_IVB);
extra_mask = (DE_PIPEC_VBLANK_IVB | DE_PIPEB_VBLANK_IVB |
DE_PIPEA_VBLANK_IVB | DE_ERR_INT_IVB |
+ DE_PLANE_FLIP_DONE_IVB(PLANE_C) |
+ DE_PLANE_FLIP_DONE_IVB(PLANE_B) |
+ DE_PLANE_FLIP_DONE_IVB(PLANE_A) |
DE_DP_A_HOTPLUG_IVB);
} else {
display_mask = (DE_MASTER_IRQ_CONTROL | DE_GSE | DE_PCH_EVENT |
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 04/11] drm/i915: Generalize the async flip capability check
From: Ville Syrjälä Only assign the plane->async_flip() vfunc when the plane supports async flips. For now we keep this artificially limited to the primary plane since thats the only thing the legacy page flip uapi can target and there is no async flip support in the atomic uapi yet. Cc: Karthik B S Cc: Vandita Kulkarni Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_display.c | 2 +- drivers/gpu/drm/i915/display/intel_sprite.c | 4 +++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index 7735c28b2467..1ad92fcaee7b 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -14377,7 +14377,7 @@ static int intel_atomic_check_async(struct intel_atomic_state *state) * this(vlv/chv and icl+) should be added when async flip is * enabled in the atomic IOCTL path. */ - if (plane->id != PLANE_PRIMARY) + if (!plane->async_flip) return -EINVAL; /* diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c b/drivers/gpu/drm/i915/display/intel_sprite.c index b24c8fc8e83e..0a5648d5dcf8 100644 --- a/drivers/gpu/drm/i915/display/intel_sprite.c +++ b/drivers/gpu/drm/i915/display/intel_sprite.c @@ -3309,7 +3309,9 @@ skl_universal_plane_create(struct drm_i915_private *dev_priv, plane->get_hw_state = skl_plane_get_hw_state; plane->check_plane = skl_plane_check; plane->min_cdclk = skl_plane_min_cdclk; - plane->async_flip = skl_plane_async_flip; + + if (plane_id == PLANE_PRIMARY) + plane->async_flip = skl_plane_async_flip; if (INTEL_GEN(dev_priv) >= 11) formats = icl_get_plane_formats(dev_priv, pipe, -- 2.26.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 08/11] drm/i915: Implement async flips for bdw
From: Ville Syrjälä
Implement async flip support for BDW. The implementation is
similar to the skl+ code. And just like skl/bxt/glk bdw also
needs the disable w/a, thus we need to plumb the desired state
of the async flip all the way down to i9xx_plane_ctl_crtc().
According to the spec we do need to bump the surface alignment
to 256KiB for this. Async flips require an X-tiled buffer so
we don't have to worry about linear.
Cc: Karthik B S
Cc: Vandita Kulkarni
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/i9xx_plane.c| 51
drivers/gpu/drm/i915/display/intel_display.c | 10 ++--
drivers/gpu/drm/i915/i915_irq.c | 25 +-
drivers/gpu/drm/i915/i915_reg.h | 1 +
4 files changed, 73 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/i9xx_plane.c
b/drivers/gpu/drm/i915/display/i9xx_plane.c
index 7d968ca890da..44004558ebbd 100644
--- a/drivers/gpu/drm/i915/display/i9xx_plane.c
+++ b/drivers/gpu/drm/i915/display/i9xx_plane.c
@@ -495,6 +495,50 @@ static void i9xx_disable_plane(struct intel_plane *plane,
spin_unlock_irqrestore(&dev_priv->uncore.lock, irqflags);
}
+static void
+g4x_primary_async_flip(struct intel_plane *plane,
+ const struct intel_crtc_state *crtc_state,
+ const struct intel_plane_state *plane_state,
+ bool async_flip)
+{
+ struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
+ u32 dspcntr = plane_state->ctl | i9xx_plane_ctl_crtc(crtc_state);
+ u32 dspaddr_offset = plane_state->color_plane[0].offset;
+ enum i9xx_plane_id i9xx_plane = plane->i9xx_plane;
+ unsigned long irqflags;
+
+ if (async_flip)
+ dspcntr |= DISPPLANE_ASYNC_FLIP;
+
+ spin_lock_irqsave(&dev_priv->uncore.lock, irqflags);
+ intel_de_write_fw(dev_priv, DSPCNTR(i9xx_plane), dspcntr);
+ intel_de_write_fw(dev_priv, DSPSURF(i9xx_plane),
+ intel_plane_ggtt_offset(plane_state) +
dspaddr_offset);
+ spin_unlock_irqrestore(&dev_priv->uncore.lock, irqflags);
+}
+
+static void
+bdw_primary_enable_flip_done(struct intel_plane *plane)
+{
+ struct drm_i915_private *i915 = to_i915(plane->base.dev);
+ enum pipe pipe = plane->pipe;
+
+ spin_lock_irq(&i915->irq_lock);
+ bdw_enable_pipe_irq(i915, pipe, GEN8_PIPE_PRIMARY_FLIP_DONE);
+ spin_unlock_irq(&i915->irq_lock);
+}
+
+static void
+bdw_primary_disable_flip_done(struct intel_plane *plane)
+{
+ struct drm_i915_private *i915 = to_i915(plane->base.dev);
+ enum pipe pipe = plane->pipe;
+
+ spin_lock_irq(&i915->irq_lock);
+ bdw_disable_pipe_irq(i915, pipe, GEN8_PIPE_PRIMARY_FLIP_DONE);
+ spin_unlock_irq(&i915->irq_lock);
+}
+
static bool i9xx_plane_get_hw_state(struct intel_plane *plane,
enum pipe *pipe)
{
@@ -708,6 +752,13 @@ intel_primary_plane_create(struct drm_i915_private
*dev_priv, enum pipe pipe)
plane->get_hw_state = i9xx_plane_get_hw_state;
plane->check_plane = i9xx_plane_check;
+ if (IS_BROADWELL(dev_priv)) {
+ plane->need_async_flip_disable_wa = true;
+ plane->async_flip = g4x_primary_async_flip;
+ plane->enable_flip_done = bdw_primary_enable_flip_done;
+ plane->disable_flip_done = bdw_primary_disable_flip_done;
+ }
+
if (INTEL_GEN(dev_priv) >= 5 || IS_G4X(dev_priv))
ret = drm_universal_plane_init(&dev_priv->drm, &plane->base,
0, plane_funcs,
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 9ea7a89432d6..6db3e6b69a53 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -2120,6 +2120,11 @@ static unsigned int intel_linear_alignment(const struct
drm_i915_private *dev_pr
return 0;
}
+static bool has_async_flips(struct drm_i915_private *i915)
+{
+ return INTEL_GEN(i915) >= 9 || IS_BROADWELL(i915);
+}
+
static unsigned int intel_surf_alignment(const struct drm_framebuffer *fb,
int color_plane)
{
@@ -2134,7 +2139,7 @@ static unsigned int intel_surf_alignment(const struct
drm_framebuffer *fb,
case DRM_FORMAT_MOD_LINEAR:
return intel_linear_alignment(dev_priv);
case I915_FORMAT_MOD_X_TILED:
- if (INTEL_GEN(dev_priv) >= 9)
+ if (has_async_flips(dev_priv))
return 256 * 1024;
return 0;
case I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS:
@@ -17097,8 +17102,7 @@ static void intel_mode_config_init(struct
drm_i915_private *i915)
mode_config->funcs = &intel_mode_funcs;
- if (INTEL_GEN(i915) >= 9)
- mode_config->async_page_flip = true;
+ mode_config->async_
[Intel-gfx] [PATCH v2 07/11] drm/i915: Reuse the async_flip() hook for the async flip disable w/a
From: Ville Syrjälä
On some platforms we need to trigger an extra async flip with
the async flip bit disabled, and then wait for the next vblank
until the async flip bit off state will actually latch.
Currently the w/a is just open coded for skl+ universal planes.
Instead of doing that lets reuse the .async_flip() hook for this
purpose since it needs to write the exact same set of registers.
In order to do this we'll just have the caller pass in the state
of the async flip bit explicitly.
Cc: Karthik B S
Cc: Vandita Kulkarni
Signed-off-by: Ville Syrjälä
---
.../gpu/drm/i915/display/intel_atomic_plane.c | 2 +-
drivers/gpu/drm/i915/display/intel_display.c | 59 ---
.../drm/i915/display/intel_display_types.h| 4 +-
drivers/gpu/drm/i915/display/intel_sprite.c | 7 ++-
4 files changed, 35 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index b5e1ee99535c..4683f98f7e54 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -452,7 +452,7 @@ void intel_update_plane(struct intel_plane *plane,
trace_intel_update_plane(&plane->base, crtc);
if (crtc_state->uapi.async_flip && plane->async_flip)
- plane->async_flip(plane, crtc_state, plane_state);
+ plane->async_flip(plane, crtc_state, plane_state, true);
else
plane->update_plane(plane, crtc_state, plane_state);
}
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index fc932028c368..9ea7a89432d6 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6166,41 +6166,36 @@ static void intel_crtc_disable_flip_done(struct
intel_atomic_state *state,
}
}
-static void skl_disable_async_flip_wa(struct intel_atomic_state *state,
- struct intel_crtc *crtc,
- const struct intel_crtc_state
*new_crtc_state)
+static void intel_crtc_async_flip_disable_wa(struct intel_atomic_state *state,
+struct intel_crtc *crtc)
{
- struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+ struct drm_i915_private *i915 = to_i915(state->base.dev);
+ const struct intel_crtc_state *old_crtc_state =
+ intel_atomic_get_old_crtc_state(state, crtc);
+ const struct intel_crtc_state *new_crtc_state =
+ intel_atomic_get_new_crtc_state(state, crtc);
+ u8 update_planes = new_crtc_state->update_planes;
+ const struct intel_plane_state *old_plane_state;
struct intel_plane *plane;
- struct intel_plane_state *new_plane_state;
+ bool need_vbl_wait = false;
int i;
- for_each_new_intel_plane_in_state(state, plane, new_plane_state, i) {
- u32 update_mask = new_crtc_state->update_planes;
- u32 plane_ctl, surf_addr;
- enum plane_id plane_id;
- unsigned long irqflags;
- enum pipe pipe;
-
- if (crtc->pipe != plane->pipe ||
- !(update_mask & BIT(plane->id)))
- continue;
-
- plane_id = plane->id;
- pipe = plane->pipe;
-
- spin_lock_irqsave(&dev_priv->uncore.lock, irqflags);
- plane_ctl = intel_de_read_fw(dev_priv, PLANE_CTL(pipe,
plane_id));
- surf_addr = intel_de_read_fw(dev_priv, PLANE_SURF(pipe,
plane_id));
-
- plane_ctl &= ~PLANE_CTL_ASYNC_FLIP;
-
- intel_de_write_fw(dev_priv, PLANE_CTL(pipe, plane_id),
plane_ctl);
- intel_de_write_fw(dev_priv, PLANE_SURF(pipe, plane_id),
surf_addr);
- spin_unlock_irqrestore(&dev_priv->uncore.lock, irqflags);
+ for_each_old_intel_plane_in_state(state, plane, old_plane_state, i) {
+ if (plane->need_async_flip_disable_wa &&
+ plane->pipe == crtc->pipe &&
+ update_planes & BIT(plane->id)) {
+ /*
+* Apart from the async flip bit we want to
+* preserve the old state for the plane.
+*/
+ plane->async_flip(plane, old_crtc_state,
+ old_plane_state, false);
+ need_vbl_wait = true;
+ }
}
- intel_wait_for_vblank(dev_priv, crtc->pipe);
+ if (need_vbl_wait)
+ intel_wait_for_vblank(i915, crtc->pipe);
}
static void intel_pre_plane_update(struct intel_atomic_state *state,
@@ -6293,10 +6288,8 @@ static void intel_pre_plane_update(struct
intel_atomic_state *state,
* WA for platforms where async address update enable bit
* is double buffered and on
[Intel-gfx] [PATCH v2 06/11] drm/i915: Move the async_flip bit setup into the .async_flip() hook
From: Ville Syrjälä Set up the async flip PLANE_CTL bit directly in the .async_flip() hook. Neither .update_plane() nor .disable_plane() ever need to set this so having it done by skl_plane_ctl_crtc() is rather pointless. Cc: Karthik B S Cc: Vandita Kulkarni Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_display.c | 3 --- drivers/gpu/drm/i915/display/intel_sprite.c | 2 ++ 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index f12b74cfe974..fc932028c368 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -4250,9 +4250,6 @@ u32 skl_plane_ctl_crtc(const struct intel_crtc_state *crtc_state) struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev); u32 plane_ctl = 0; - if (crtc_state->uapi.async_flip) - plane_ctl |= PLANE_CTL_ASYNC_FLIP; - if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) return plane_ctl; diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c b/drivers/gpu/drm/i915/display/intel_sprite.c index 8e01cd4ebe36..1188e0f92223 100644 --- a/drivers/gpu/drm/i915/display/intel_sprite.c +++ b/drivers/gpu/drm/i915/display/intel_sprite.c @@ -782,6 +782,8 @@ skl_plane_async_flip(struct intel_plane *plane, plane_ctl |= skl_plane_ctl_crtc(crtc_state); + plane_ctl |= PLANE_CTL_ASYNC_FLIP; + spin_lock_irqsave(&dev_priv->uncore.lock, irqflags); intel_de_write_fw(dev_priv, PLANE_CTL(pipe, plane_id), plane_ctl); -- 2.26.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 05/11] drm/i915: Add plane vfuncs to enable/disable flip_done interrupt
From: Ville Syrjälä
Prepare for more platforms with async flip support by turning
the flip_done interrupt enable/disable into plane vfuncs.
Cc: Karthik B S
Cc: Vandita Kulkarni
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 42 +--
.../drm/i915/display/intel_display_types.h| 2 +
drivers/gpu/drm/i915/display/intel_sprite.c | 27 +++-
drivers/gpu/drm/i915/i915_irq.c | 26
drivers/gpu/drm/i915/i915_irq.h | 3 --
5 files changed, 67 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 1ad92fcaee7b..f12b74cfe974 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6133,6 +6133,42 @@ static void intel_post_plane_update(struct
intel_atomic_state *state,
icl_wa_scalerclkgating(dev_priv, pipe, false);
}
+static void intel_crtc_enable_flip_done(struct intel_atomic_state *state,
+ struct intel_crtc *crtc)
+{
+ const struct intel_crtc_state *crtc_state =
+ intel_atomic_get_new_crtc_state(state, crtc);
+ u8 update_planes = crtc_state->update_planes;
+ const struct intel_plane_state *plane_state;
+ struct intel_plane *plane;
+ int i;
+
+ for_each_new_intel_plane_in_state(state, plane, plane_state, i) {
+ if (plane->enable_flip_done &&
+ plane->pipe == crtc->pipe &&
+ update_planes & BIT(plane->id))
+ plane->enable_flip_done(plane);
+ }
+}
+
+static void intel_crtc_disable_flip_done(struct intel_atomic_state *state,
+struct intel_crtc *crtc)
+{
+ const struct intel_crtc_state *crtc_state =
+ intel_atomic_get_new_crtc_state(state, crtc);
+ u8 update_planes = crtc_state->update_planes;
+ const struct intel_plane_state *plane_state;
+ struct intel_plane *plane;
+ int i;
+
+ for_each_new_intel_plane_in_state(state, plane, plane_state, i) {
+ if (plane->disable_flip_done &&
+ plane->pipe == crtc->pipe &&
+ update_planes & BIT(plane->id))
+ plane->disable_flip_done(plane);
+ }
+}
+
static void skl_disable_async_flip_wa(struct intel_atomic_state *state,
struct intel_crtc *crtc,
const struct intel_crtc_state
*new_crtc_state)
@@ -14333,7 +14369,7 @@ static void kill_bigjoiner_slave(struct
intel_atomic_state *state,
* Async flip can only change the plane surface address, so anything else
* changing is rejected from the intel_atomic_check_async() function.
* Once this check is cleared, flip done interrupt is enabled using
- * the skl_enable_flip_done() function.
+ * the intel_crtc_enable_flip_done() function.
*
* As soon as the surface address register is written, flip done interrupt is
* generated and the requested events are sent to the usersapce in the
interrupt
@@ -15289,7 +15325,7 @@ static void intel_atomic_commit_tail(struct
intel_atomic_state *state)
for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
if (new_crtc_state->uapi.async_flip)
- skl_enable_flip_done(crtc);
+ intel_crtc_enable_flip_done(state, crtc);
}
/* Now enable the clocks, plane, pipe, and connectors that we set up. */
@@ -15314,7 +15350,7 @@ static void intel_atomic_commit_tail(struct
intel_atomic_state *state)
for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
if (new_crtc_state->uapi.async_flip)
- skl_disable_flip_done(crtc);
+ intel_crtc_disable_flip_done(state, crtc);
if (new_crtc_state->hw.active &&
!intel_crtc_needs_modeset(new_crtc_state) &&
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 1067bd073c95..255648ab0fa7 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1258,6 +1258,8 @@ struct intel_plane {
void (*async_flip)(struct intel_plane *plane,
const struct intel_crtc_state *crtc_state,
const struct intel_plane_state *plane_state);
+ void (*enable_flip_done)(struct intel_plane *plane);
+ void (*disable_flip_done)(struct intel_plane *plane);
};
struct intel_watermark_params {
diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
b/drivers/gpu/drm/i915/display/intel_sprite.c
index 0a5648d5dcf8..8e01cd4ebe36 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/i
[Intel-gfx] [PATCH v2 03/11] drm/i915: Drop redundant parens
From: Ville Syrjälä
Drop the pointless extra parens.
Cc: Karthik B S
Cc: Vandita Kulkarni
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index dd1971040bbc..4484609d870d 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2079,7 +2079,7 @@ static void ivb_display_irq_handler(struct
drm_i915_private *dev_priv,
intel_opregion_asle_intr(dev_priv);
for_each_pipe(dev_priv, pipe) {
- if (de_iir & (DE_PIPE_VBLANK_IVB(pipe)))
+ if (de_iir & DE_PIPE_VBLANK_IVB(pipe))
intel_handle_vblank(dev_priv, pipe);
}
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 02/11] drm/i915: Limit plane stride to below TILEOFF.x limit
From: Ville Syrjälä
Limit pre-skl plane stride to below 4k or 8k pixels (depending on
the platform). We do this in order guarantee that TILEOFF/OFFSET.x
does not get too big.
Currently this is not a problem as we align SURF to 4k, and so
TILEOFF/OFFSET only have to deal with a single tile's worth of
pixels. But for async flips we're going to have to bump SURF
alignment to 256k, and thus we can no longer guarantee
TILEOFF/OFFSET.x will stay within acceptable bounds. We can avoid
this by borrowing a trick from the skl+ code and limit the max
plane stride to whatever value we can fit into TILEOFF/OFFSET.x.
The slight downside is that we may end up doing GTT remapping in
a few more cases where previously we did not have to. But since
that will only happen with huge buffers I'm not really concerned
about it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/i9xx_plane.c | 64 ++---
drivers/gpu/drm/i915/display/i9xx_plane.h | 2 +-
drivers/gpu/drm/i915/display/intel_sprite.c | 33 +--
3 files changed, 83 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/i9xx_plane.c
b/drivers/gpu/drm/i915/display/i9xx_plane.c
index b1158ce4df92..7d968ca890da 100644
--- a/drivers/gpu/drm/i915/display/i9xx_plane.c
+++ b/drivers/gpu/drm/i915/display/i9xx_plane.c
@@ -530,21 +530,56 @@ static bool i9xx_plane_get_hw_state(struct intel_plane
*plane,
return ret;
}
+static unsigned int
+hsw_primary_max_stride(struct intel_plane *plane,
+ u32 pixel_format, u64 modifier,
+ unsigned int rotation)
+{
+ const struct drm_format_info *info = drm_format_info(pixel_format);
+ int cpp = info->cpp[0];
+
+ /* Limit to 8k pixels to guarantee OFFSET.x doesn't get too big. */
+ return min(8192 * cpp, 32 * 1024);
+}
+
+static unsigned int
+ilk_primary_max_stride(struct intel_plane *plane,
+ u32 pixel_format, u64 modifier,
+ unsigned int rotation)
+{
+ const struct drm_format_info *info = drm_format_info(pixel_format);
+ int cpp = info->cpp[0];
+
+ /* Limit to 4k pixels to guarantee TILEOFF.x doesn't get too big. */
+ if (modifier == I915_FORMAT_MOD_X_TILED)
+ return min(4096 * cpp, 32 * 1024);
+ else
+ return 32 * 1024;
+}
+
unsigned int
+i965_plane_max_stride(struct intel_plane *plane,
+ u32 pixel_format, u64 modifier,
+ unsigned int rotation)
+{
+ const struct drm_format_info *info = drm_format_info(pixel_format);
+ int cpp = info->cpp[0];
+
+ /* Limit to 4k pixels to guarantee TILEOFF.x doesn't get too big. */
+ if (modifier == I915_FORMAT_MOD_X_TILED)
+ return min(4096 * cpp, 16 * 1024);
+ else
+ return 32 * 1024;
+}
+
+static unsigned int
i9xx_plane_max_stride(struct intel_plane *plane,
u32 pixel_format, u64 modifier,
unsigned int rotation)
{
struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
- if (!HAS_GMCH(dev_priv)) {
- return 32*1024;
- } else if (INTEL_GEN(dev_priv) >= 4) {
- if (modifier == I915_FORMAT_MOD_X_TILED)
- return 16*1024;
- else
- return 32*1024;
- } else if (INTEL_GEN(dev_priv) >= 3) {
+ if (INTEL_GEN(dev_priv) >= 3) {
if (modifier == I915_FORMAT_MOD_X_TILED)
return 8*1024;
else
@@ -656,7 +691,18 @@ intel_primary_plane_create(struct drm_i915_private
*dev_priv, enum pipe pipe)
else
plane->min_cdclk = i9xx_plane_min_cdclk;
- plane->max_stride = i9xx_plane_max_stride;
+ if (HAS_GMCH(dev_priv)) {
+ if (INTEL_GEN(dev_priv) >= 4)
+ plane->max_stride = i965_plane_max_stride;
+ else
+ plane->max_stride = i9xx_plane_max_stride;
+ } else {
+ if (IS_BROADWELL(dev_priv) || IS_HASWELL(dev_priv))
+ plane->max_stride = hsw_primary_max_stride;
+ else
+ plane->max_stride = ilk_primary_max_stride;
+ }
+
plane->update_plane = i9xx_update_plane;
plane->disable_plane = i9xx_disable_plane;
plane->get_hw_state = i9xx_plane_get_hw_state;
diff --git a/drivers/gpu/drm/i915/display/i9xx_plane.h
b/drivers/gpu/drm/i915/display/i9xx_plane.h
index bc2834a62735..ca963c2a8457 100644
--- a/drivers/gpu/drm/i915/display/i9xx_plane.h
+++ b/drivers/gpu/drm/i915/display/i9xx_plane.h
@@ -13,7 +13,7 @@ struct drm_i915_private;
struct intel_plane;
struct intel_plane_state;
-unsigned int i9xx_plane_max_stride(struct intel_plane *plane,
+unsigned int i965_plane_max_stride(struct intel_plane *plane,
u32 pixel_format, u64 modifier,
[Intel-gfx] [PATCH v2 01/11] drm/i915: WARN if plane src coords are too big
From: Ville Syrjälä
Inform us if we're buggy and are about to exceed the size of the
bitfields in the plane TILEOFF/OFFSET registers.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/i9xx_plane.c| 7 +++
drivers/gpu/drm/i915/display/intel_display.c | 4
2 files changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/i9xx_plane.c
b/drivers/gpu/drm/i915/display/i9xx_plane.c
index b78985c855a5..b1158ce4df92 100644
--- a/drivers/gpu/drm/i915/display/i9xx_plane.c
+++ b/drivers/gpu/drm/i915/display/i9xx_plane.c
@@ -276,6 +276,13 @@ int i9xx_check_plane_surface(struct intel_plane_state
*plane_state)
}
}
+ if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
+ drm_WARN_ON(&dev_priv->drm, src_x > 8191 || src_y > 4095);
+ } else if (INTEL_GEN(dev_priv) >= 4 &&
+ fb->modifier == I915_FORMAT_MOD_X_TILED) {
+ drm_WARN_ON(&dev_priv->drm, src_x > 4095 || src_y > 4095);
+ }
+
plane_state->color_plane[0].offset = offset;
plane_state->color_plane[0].x = src_x;
plane_state->color_plane[0].y = src_y;
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 0189d379a55e..7735c28b2467 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -3854,6 +3854,8 @@ static int skl_check_main_surface(struct
intel_plane_state *plane_state)
}
}
+ drm_WARN_ON(&dev_priv->drm, x > 8191 || y > 8191);
+
plane_state->color_plane[0].offset = offset;
plane_state->color_plane[0].x = x;
plane_state->color_plane[0].y = y;
@@ -3926,6 +3928,8 @@ static int skl_check_nv12_aux_surface(struct
intel_plane_state *plane_state)
}
}
+ drm_WARN_ON(&i915->drm, x > 8191 || y > 8191);
+
plane_state->color_plane[uv_plane].offset = offset;
plane_state->color_plane[uv_plane].x = x;
plane_state->color_plane[uv_plane].y = y;
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 00/11] drm/i915: Async flips for all ilk+ platforms
From: Ville Syrjälä Second attempt at hooking up async flips for everyone, this time taking care to keep the plane src coordinates below the limits of the TILEOFF/OFFSET register. Ville Syrjälä (11): drm/i915: WARN if plane src coords are too big drm/i915: Limit plane stride to below TILEOFF.x limit drm/i915: Drop redundant parens drm/i915: Generalize the async flip capability check drm/i915: Add plane vfuncs to enable/disable flip_done interrupt drm/i915: Move the async_flip bit setup into the .async_flip() hook drm/i915: Reuse the async_flip() hook for the async flip disable w/a drm/i915: Implement async flips for bdw drm/i915: Implement async flip for ivb/hsw drm/i915: Implement async flip for ilk/snb drm/i915: Implement async flips for vlv/chv drivers/gpu/drm/i915/display/i9xx_plane.c | 213 +- drivers/gpu/drm/i915/display/i9xx_plane.h | 2 +- .../gpu/drm/i915/display/intel_atomic_plane.c | 2 +- drivers/gpu/drm/i915/display/intel_display.c | 112 + .../drm/i915/display/intel_display_types.h| 6 +- drivers/gpu/drm/i915/display/intel_sprite.c | 69 +- drivers/gpu/drm/i915/i915_irq.c | 67 +++--- drivers/gpu/drm/i915/i915_irq.h | 3 - drivers/gpu/drm/i915/i915_reg.h | 3 + 9 files changed, 377 insertions(+), 100 deletions(-) -- 2.26.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915/gt: Perform an arbitration check before busywaiting
Quoting Tvrtko Ursulin (2021-01-11 16:19:40) > > On 11/01/2021 10:57, Chris Wilson wrote: > > During igt_reset_nop_engine, it was observed that an unexpected failed > > engine reset lead to us busywaiting on the stop-ring semaphore (set > > during the reset preparations) on the first request afterwards. There was > > no explicit MI_ARB_CHECK in this sequence as the presumption was that > > the failed MI_SEMAPHORE_WAIT would itself act as an arbitration point. > > It did not in this circumstance, so force it. > > In other words MI_SEMAPHORE_POLL is not a preemption point? Can't > remember if I knew that or not.. MI_SEMAPHORE_WAIT | POLL is most definitely a preemption point on a miss. > 1) > Why not the same handling in !gen12 version? Because I think it's a bug in tgl [a0 at least]. I think I've seen the same symptoms on tgl before, but not earlier. This is the first time the sequence clicked as to why it was busy spinning. Random engine reset failures are rare enough -- I was meant to also write a test case to inject failure. > 2) > Failed reset leads to busy-hang in following request _tail_? But there > is an arb check at the start of following request as well. Or in cases > where we context switch into the middle of a previously executing request? It was the first request submitted after the failed reset. We expect to clear the ring-stop flag on the CS IDLE->ACTIVE event. > But why would that busy hang? Hasn't the failed request unpaused the ring? The engine was idle at the time of the failed reset. We left the ring-stop set, and submitted the next batch of requests. We hit the MI_SEMAPHORE_WAIT(ring-stop) at the end of the first request, but without hitting an arbitration point (first request, no init-breadcrumb in this case), the semaphore was stuck. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915/selftests: Include engine name after reset failure
On 11/01/2021 10:57, Chris Wilson wrote:
During igt_reset_nop_engine, an engine reset unexpectedly failed. For the
next time this happens, mention which engine that was.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
index 28f71cc2004d..09301e8b92c7 100644
--- a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
+++ b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
@@ -506,7 +506,8 @@ static int igt_reset_nop_engine(void *arg)
}
err = intel_engine_reset(engine, NULL);
if (err) {
- pr_err("i915_reset_engine failed\n");
+ pr_err("intel_engine_reset(%s) failed,
err:%d\n",
+ engine->name, err);
break;
}
@@ -610,7 +611,8 @@ static int __igt_reset_engine(struct intel_gt *gt, bool active)
err = intel_engine_reset(engine, NULL);
if (err) {
- pr_err("i915_reset_engine failed\n");
+ pr_err("intel_engine_reset(%s) failed,
err:%d\n",
+ engine->name, err);
break;
}
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915/gt: Perform an arbitration check before busywaiting
On 11/01/2021 10:57, Chris Wilson wrote:
During igt_reset_nop_engine, it was observed that an unexpected failed
engine reset lead to us busywaiting on the stop-ring semaphore (set
during the reset preparations) on the first request afterwards. There was
no explicit MI_ARB_CHECK in this sequence as the presumption was that
the failed MI_SEMAPHORE_WAIT would itself act as an arbitration point.
It did not in this circumstance, so force it.
In other words MI_SEMAPHORE_POLL is not a preemption point? Can't
remember if I knew that or not..
1)
Why not the same handling in !gen12 version?
2)
Failed reset leads to busy-hang in following request _tail_? But there
is an arb check at the start of following request as well. Or in cases
where we context switch into the middle of a previously executing request?
But why would that busy hang? Hasn't the failed request unpaused the ring?
Regards,
Tvrtko
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 9a182652a35e..e9ac281644cc 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -567,6 +567,7 @@ u32 *gen11_emit_fini_breadcrumb_rcs(struct i915_request
*rq, u32 *cs)
static u32 *gen12_emit_preempt_busywait(struct i915_request *rq, u32 *cs)
{
+ *cs++ = MI_ARB_CHECK;
*cs++ = MI_SEMAPHORE_WAIT_TOKEN |
MI_SEMAPHORE_GLOBAL_GTT |
MI_SEMAPHORE_POLL |
@@ -575,7 +576,6 @@ static u32 *gen12_emit_preempt_busywait(struct i915_request
*rq, u32 *cs)
*cs++ = preempt_address(rq->engine);
*cs++ = 0;
*cs++ = 0;
- *cs++ = MI_NOOP;
return cs;
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915/gt: Check for arbitration after writing start seqno
Quoting Tvrtko Ursulin (2021-01-11 16:03:48) > > On 11/01/2021 10:57, Chris Wilson wrote: > > On the off chance that we need to arbitrate before launching the > > payload, perform the check after we signal the request is ready to > > start. Assuming instantaneous processing of the CS event, the request > > will then be treated as having started when we make the decisions as to > > how to process that CS event. > > What is the wider context with this change? Just thinking about the impact of MI_ARB_ONOFF. It's the next patch that sparked the curiosity at that is trying to address a missed arbitration point on the semaphore-wait miss. > > Signed-off-by: Chris Wilson > > --- > > drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 12 ++-- > > 1 file changed, 6 insertions(+), 6 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c > > b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c > > index 2e36e0a9d8a6..9a182652a35e 100644 > > --- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c > > +++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c > > @@ -361,19 +361,19 @@ int gen8_emit_init_breadcrumb(struct i915_request *rq) > > if (IS_ERR(cs)) > > return PTR_ERR(cs); > > > > + *cs++ = MI_STORE_DWORD_IMM_GEN4 | MI_USE_GGTT; > > + *cs++ = hwsp_offset(rq); > > + *cs++ = 0; > > + *cs++ = rq->fence.seqno - 1; > > + > > Strictly this movement even makes the existing comment (below) more correct. > > > /* > >* Check if we have been preempted before we even get started. > >* > >* After this point i915_request_started() reports true, even if > >* we get preempted and so are no longer running. > >*/ > > - *cs++ = MI_ARB_CHECK; > > *cs++ = MI_NOOP; > > - > > - *cs++ = MI_STORE_DWORD_IMM_GEN4 | MI_USE_GGTT; > > - *cs++ = hwsp_offset(rq); > > - *cs++ = 0; > > - *cs++ = rq->fence.seqno - 1; > > + *cs++ = MI_ARB_CHECK; > > Special reason to have NOOP before MI_ARB_CHECK or would more common > NOOP padding at the end be suitable? The so small it's barely a reason was to put as much distance (those whole 6 cycles) between the store and the arbitration point. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915/gt: Check for arbitration after writing start seqno
On 11/01/2021 10:57, Chris Wilson wrote: On the off chance that we need to arbitrate before launching the payload, perform the check after we signal the request is ready to start. Assuming instantaneous processing of the CS event, the request will then be treated as having started when we make the decisions as to how to process that CS event. What is the wider context with this change? Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c index 2e36e0a9d8a6..9a182652a35e 100644 --- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c +++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c @@ -361,19 +361,19 @@ int gen8_emit_init_breadcrumb(struct i915_request *rq) if (IS_ERR(cs)) return PTR_ERR(cs); + *cs++ = MI_STORE_DWORD_IMM_GEN4 | MI_USE_GGTT; + *cs++ = hwsp_offset(rq); + *cs++ = 0; + *cs++ = rq->fence.seqno - 1; + Strictly this movement even makes the existing comment (below) more correct. /* * Check if we have been preempted before we even get started. * * After this point i915_request_started() reports true, even if * we get preempted and so are no longer running. */ - *cs++ = MI_ARB_CHECK; *cs++ = MI_NOOP; - - *cs++ = MI_STORE_DWORD_IMM_GEN4 | MI_USE_GGTT; - *cs++ = hwsp_offset(rq); - *cs++ = 0; - *cs++ = rq->fence.seqno - 1; + *cs++ = MI_ARB_CHECK; Special reason to have NOOP before MI_ARB_CHECK or would more common NOOP padding at the end be suitable? Regards, Tvrtko intel_ring_advance(rq, cs); ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915/gt: Disable arbitration around Braswell's pdp updates
Quoting Tvrtko Ursulin (2021-01-11 15:53:47) > > On 11/01/2021 10:57, Chris Wilson wrote: > > Braswell's pdp workaround is full of dragons, that may be being angered > > when they are interrupted. Let's not take that risk and disable > > arbitrartion during the update. > > > > Signed-off-by: Chris Wilson > > --- > > drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 11 ++- > > 1 file changed, 10 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c > > b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c > > index 52c1fe62bdfe..10e9940cf3f5 100644 > > --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c > > +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c > > @@ -2539,6 +2539,14 @@ static int emit_pdps(struct i915_request *rq) > >* GPU hangs to forcewake errors and machine lockups! > >*/ > > > > + cs = intel_ring_begin(rq, 2); > > + if (IS_ERR(cs)) > > + return PTR_ERR(cs); > > + > > + *cs++ = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > + *cs++ = MI_NOOP; > > + intel_ring_advance(rq, cs); > > + > > /* Flush any residual operations from the context load */ > > err = engine->emit_flush(rq, EMIT_FLUSH); > > if (err) > > @@ -2564,7 +2572,8 @@ static int emit_pdps(struct i915_request *rq) > > *cs++ = i915_mmio_reg_offset(GEN8_RING_PDP_LDW(base, i)); > > *cs++ = lower_32_bits(pd_daddr); > > } > > - *cs++ = MI_NOOP; > > + *cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE; > > + intel_ring_advance(rq, cs); > > > > intel_ring_advance(rq, cs); > > > > > > I had to remind myself that Gen8LP is indeed the only platform with > 32-bit ppgtt. > > I presume you are fixing some sporadic CI failures here, anyway: There's an odd one showing up in Braswell CI, but didn't occur locally in several hours of running the selftest. Given the history of how sensitive Braswell is to these PDP updates, I think this wild stab in the dark is likely to hit something. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915/gt: Disable arbitration around Braswell's pdp updates
On 11/01/2021 10:57, Chris Wilson wrote: Braswell's pdp workaround is full of dragons, that may be being angered when they are interrupted. Let's not take that risk and disable arbitrartion during the update. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c index 52c1fe62bdfe..10e9940cf3f5 100644 --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c @@ -2539,6 +2539,14 @@ static int emit_pdps(struct i915_request *rq) * GPU hangs to forcewake errors and machine lockups! */ + cs = intel_ring_begin(rq, 2); + if (IS_ERR(cs)) + return PTR_ERR(cs); + + *cs++ = MI_ARB_ON_OFF | MI_ARB_DISABLE; + *cs++ = MI_NOOP; + intel_ring_advance(rq, cs); + /* Flush any residual operations from the context load */ err = engine->emit_flush(rq, EMIT_FLUSH); if (err) @@ -2564,7 +2572,8 @@ static int emit_pdps(struct i915_request *rq) *cs++ = i915_mmio_reg_offset(GEN8_RING_PDP_LDW(base, i)); *cs++ = lower_32_bits(pd_daddr); } - *cs++ = MI_NOOP; + *cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE; + intel_ring_advance(rq, cs); intel_ring_advance(rq, cs); I had to remind myself that Gen8LP is indeed the only platform with 32-bit ppgtt. I presume you are fixing some sporadic CI failures here, anyway: Reviewed-by: Tvrtko Ursulin Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: selftest_lrc: Fix error code in live_preempt_user()
Hi Dan,
On Mon, Jan 11, 2021 at 05:18:08PM +0300, Dan Carpenter wrote:
> This error path should return a negative error code instead of success.
>
> Fixes: c92724de6db1 ("drm/i915/selftests: Try to detect rollback during
> batchbuffer preemption")
> Signed-off-by: Dan Carpenter
> Reviewed-by: Chris Wilson
Reviewed-by: Andi Shyti
Thanks,
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm: Check actual format for legacy pageflip.
On Sat, Jan 9, 2021 at 9:11 PM Bas Nieuwenhuizen
wrote:
>
> With modifiers one can actually have different format_info structs
> for the same format, which now matters for AMDGPU since we convert
> implicit modifiers to explicit modifiers with multiple planes.
>
> I checked other drivers and it doesn't look like they end up triggering
> this case so I think this is safe to relax.
>
> Signed-off-by: Bas Nieuwenhuizen
> Reviewed-by: Daniel Vetter
> Reviewed-by: Zhan Liu
> Acked-by: Christian König
> Acked-by: Alex Deucher
> Fixes: 816853f9dc40 ("drm/amd/display: Set new format info for converted
> metadata.")
Do you have commit rights to drm-misc or do you need someone to commit
this for you?
Thanks!
Alex
> ---
> drivers/gpu/drm/drm_plane.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index e6231947f987..a0cb746bcb0a 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -1163,7 +1163,14 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
> if (ret)
> goto out;
>
> - if (old_fb->format != fb->format) {
> + /*
> +* Only check the FOURCC format code, excluding modifiers. This is
> +* enough for all legacy drivers. Atomic drivers have their own
> +* checks in their ->atomic_check implementation, which will
> +* return -EINVAL if any hw or driver constraint is violated due
> +* to modifier changes.
> +*/
> + if (old_fb->format->format != fb->format->format) {
> DRM_DEBUG_KMS("Page flip is not allowed to change frame
> buffer format.\n");
> ret = -EINVAL;
> goto out;
> --
> 2.29.2
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/selftests: Fix some error codes (rev2)
Quoting Patchwork (2021-01-11 14:52:15) > == Series Details == > > Series: drm/i915/selftests: Fix some error codes (rev2) > URL : https://patchwork.freedesktop.org/series/85704/ > State : failure > > == Summary == > > Applying: drm/i915: selftest_lrc: Fix error code in live_preempt_user() > Using index info to reconstruct a base tree... > M drivers/gpu/drm/i915/gt/selftest_lrc.c > Falling back to patching base and 3-way merge... > Auto-merging drivers/gpu/drm/i915/gt/selftest_lrc.c > CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/gt/selftest_lrc.c Don't worry; I've applied the patch manually and pushed. Thanks, -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/selftests: Fix some error codes (rev2)
== Series Details == Series: drm/i915/selftests: Fix some error codes (rev2) URL : https://patchwork.freedesktop.org/series/85704/ State : failure == Summary == Applying: drm/i915: selftest_lrc: Fix error code in live_preempt_user() Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/gt/selftest_lrc.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/gt/selftest_lrc.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/gt/selftest_lrc.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 drm/i915: selftest_lrc: Fix error code in live_preempt_user() When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [patch V3 13/37] mips/mm/highmem: Switch to generic kmap atomic
On Sat, Jan 09, 2021 at 12:58:05AM +0100, Thomas Bogendoerfer wrote: > On Fri, Jan 08, 2021 at 08:20:43PM +, Paul Cercueil wrote: > > Hi Thomas, > > > > 5.11 does not boot anymore on Ingenic SoCs, I bisected it to this commit. > > > > Any idea what could be happening? > > not yet, kernel crash log of a Malta QEMU is below. update: This dirty hack lets the Malta QEMU boot again: diff --git a/mm/highmem.c b/mm/highmem.c index c3a9ea7875ef..190cdda1149d 100644 --- a/mm/highmem.c +++ b/mm/highmem.c @@ -515,7 +515,7 @@ void *__kmap_local_pfn_prot(unsigned long pfn, pgprot_t prot) vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx); BUG_ON(!pte_none(*(kmap_pte - idx))); pteval = pfn_pte(pfn, prot); - set_pte_at(&init_mm, vaddr, kmap_pte - idx, pteval); + set_pte(kmap_pte - idx, pteval); arch_kmap_local_post_map(vaddr, pteval); current->kmap_ctrl.pteval[kmap_local_idx()] = pteval; preempt_enable(); set_pte_at() tries to update cache and could do an kmap_atomic() there. Not sure, if this is allowed at this point. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ] ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [patch V3 13/37] mips/mm/highmem: Switch to generic kmap atomic
> Am 10.01.2021 um 12:35 schrieb Paul Cercueil : > > Hi Thomas, > > Le sam. 9 janv. 2021 à 1:33, Thomas Bogendoerfer > a écrit : >> On Sat, Jan 09, 2021 at 12:58:05AM +0100, Thomas Bogendoerfer wrote: >>> On Fri, Jan 08, 2021 at 08:20:43PM +, Paul Cercueil wrote: >>> > Hi Thomas, >>> > >>> > 5.11 does not boot anymore on Ingenic SoCs, I bisected it to this commit. Just for completeness, I have no such problems booting CI20/jz4780 or Skytone400/jz4730 (unpublished work) with 5.11-rc2. But may depend on board capabilites (ram size, memory layout or something else). >>> > >>> > Any idea what could be happening? >>> not yet, kernel crash log of a Malta QEMU is below. >> update: >> This dirty hack lets the Malta QEMU boot again: >> diff --git a/mm/highmem.c b/mm/highmem.c >> index c3a9ea7875ef..190cdda1149d 100644 >> --- a/mm/highmem.c >> +++ b/mm/highmem.c >> @@ -515,7 +515,7 @@ void *__kmap_local_pfn_prot(unsigned long pfn, pgprot_t >> prot) >> vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx); >> BUG_ON(!pte_none(*(kmap_pte - idx))); >> pteval = pfn_pte(pfn, prot); >> -set_pte_at(&init_mm, vaddr, kmap_pte - idx, pteval); >> +set_pte(kmap_pte - idx, pteval); >> arch_kmap_local_post_map(vaddr, pteval); >> current->kmap_ctrl.pteval[kmap_local_idx()] = pteval; >> preempt_enable(); >> set_pte_at() tries to update cache and could do an kmap_atomic() there. >> Not sure, if this is allowed at this point. > > Yes, I can confirm that your workaround works here too. > > Cheers, > -Paul > > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [patch V3 13/37] mips/mm/highmem: Switch to generic kmap atomic
Hi Thomas, Le sam. 9 janv. 2021 à 1:33, Thomas Bogendoerfer a écrit : On Sat, Jan 09, 2021 at 12:58:05AM +0100, Thomas Bogendoerfer wrote: On Fri, Jan 08, 2021 at 08:20:43PM +, Paul Cercueil wrote: > Hi Thomas, > > 5.11 does not boot anymore on Ingenic SoCs, I bisected it to this commit. > > Any idea what could be happening? not yet, kernel crash log of a Malta QEMU is below. update: This dirty hack lets the Malta QEMU boot again: diff --git a/mm/highmem.c b/mm/highmem.c index c3a9ea7875ef..190cdda1149d 100644 --- a/mm/highmem.c +++ b/mm/highmem.c @@ -515,7 +515,7 @@ void *__kmap_local_pfn_prot(unsigned long pfn, pgprot_t prot) vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx); BUG_ON(!pte_none(*(kmap_pte - idx))); pteval = pfn_pte(pfn, prot); - set_pte_at(&init_mm, vaddr, kmap_pte - idx, pteval); + set_pte(kmap_pte - idx, pteval); arch_kmap_local_post_map(vaddr, pteval); current->kmap_ctrl.pteval[kmap_local_idx()] = pteval; preempt_enable(); set_pte_at() tries to update cache and could do an kmap_atomic() there. Not sure, if this is allowed at this point. Yes, I can confirm that your workaround works here too. Cheers, -Paul ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [patch V3 13/37] mips/mm/highmem: Switch to generic kmap atomic
Hi Thomas, 5.11 does not boot anymore on Ingenic SoCs, I bisected it to this commit. Any idea what could be happening? Cheers, -Paul ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [patch V3 13/37] mips/mm/highmem: Switch to generic kmap atomic
On Fri, Jan 08, 2021 at 08:20:43PM +, Paul Cercueil wrote: > Hi Thomas, > > 5.11 does not boot anymore on Ingenic SoCs, I bisected it to this commit. > > Any idea what could be happening? not yet, kernel crash log of a Malta QEMU is below. Thomas. Kernel bug detected[#1]: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.11.0-rc1-00017-gccb21774863a #2 $ 0 : 0001 0010 $ 4 : 0001 05cf 9e00059f $ 8 : 00118173 809e6db8 9e00059f $12 : 82023c00 0001 810da04c 0212422f $16 : 810da000 00027800 05cf 80b4bf9c $20 : 809e968c 82602400 810da000 000b $24 : 021558f9 $28 : 820e 820e3928 80b1 802710d0 Hi: 346c Lo: 02dd epc : 80271114 __kmap_local_pfn_prot+0x78/0x1c0 ra: 802710d0 __kmap_local_pfn_prot+0x34/0x1c0 Status: 1000a403KERNEL EXL IE Cause : 00800034 (ExcCode 0d) PrId : 0001a800 (MIPS P5600) Modules linked in: Process swapper/0 (pid: 1, threadinfo=(ptrval), task=(ptrval), tls=) Stack : 7fff 820c2408 820e3990 ff04 0a00 80518224 81a4 810da000 0001 05cf fff64000 8011c77c 820e3b26 ff04 0a00 80518440 80b3 80b4bf64 9e0005cf 05cf fff64000 80271188 820e3a60 80b1 80194478 005e 80954406 809e 810da000 0001 05cf fff68000 8011c77c 8088fd44 809f6074 00f4 80b4bf68 ... Call Trace: [<80271114>] __kmap_local_pfn_prot+0x78/0x1c0 [<8011c77c>] __update_cache+0x16c/0x174 [<80271188>] __kmap_local_pfn_prot+0xec/0x1c0 [<8011c77c>] __update_cache+0x16c/0x174 [<80271188>] __kmap_local_pfn_prot+0xec/0x1c0 [<8011c77c>] __update_cache+0x16c/0x174 [<80271188>] __kmap_local_pfn_prot+0xec/0x1c0 [<8011c77c>] __update_cache+0x16c/0x174 [<80271188>] __kmap_local_pfn_prot+0xec/0x1c0 [<8011c77c>] __update_cache+0x16c/0x174 [<80271188>] __kmap_local_pfn_prot+0xec/0x1c0 [<8011c77c>] __update_cache+0x16c/0x174 [<80271188>] __kmap_local_pfn_prot+0xec/0x1c0 [<8011c77c>] __update_cache+0x16c/0x174 [<80271188>] __kmap_local_pfn_prot+0xec/0x1c0 [<8011c77c>] __update_cache+0x16c/0x174 [<80271188>] __kmap_local_pfn_prot+0xec/0x1c0 [<8011c77c>] __update_cache+0x16c/0x174 [<80271188>] __kmap_local_pfn_prot+0xec/0x1c0 [<8011c77c>] __update_cache+0x16c/0x174 [<80271188>] __kmap_local_pfn_prot+0xec/0x1c0 [<8011c77c>] __update_cache+0x16c/0x174 [<80271188>] __kmap_local_pfn_prot+0xec/0x1c0 [<8011c77c>] __update_cache+0x16c/0x174 [<80271188>] __kmap_local_pfn_prot+0xec/0x1c0 [<8011c77c>] __update_cache+0x16c/0x174 [<80271188>] __kmap_local_pfn_prot+0xec/0x1c0 [<8011c77c>] __update_cache+0x16c/0x174 [<80271188>] __kmap_local_pfn_prot+0xec/0x1c0 [<8011c77c>] __update_cache+0x16c/0x174 [<80271188>] __kmap_local_pfn_prot+0xec/0x1c0 [<802c49a0>] copy_string_kernel+0x168/0x264 [<802c5d18>] kernel_execve+0xd0/0x164 [<801006cc>] try_to_run_init_process+0x18/0x5c [<80859e0c>] kernel_init+0xd0/0x120 [<801037f8>] ret_from_kernel_thread+0x14/0x1c Code: 8c630564 28640010 38840001 <00040336> 8f82000c 2463 00021100 00431021 2403ffbf -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ] ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
