[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Retry RING_HEAD reset until it sticks
== Series Details == Series: drm/i915/gt: Retry RING_HEAD reset until it sticks URL : https://patchwork.freedesktop.org/series/106377/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11900_full -> Patchwork_106377v1_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_106377v1_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_106377v1_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (12 -> 12) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_106377v1_full: ### IGT changes ### Possible regressions * igt@kms_panel_fitting@atomic-fastset@pipe-b-edp-1: - shard-tglb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11900/shard-tglb3/igt@kms_panel_fitting@atomic-fast...@pipe-b-edp-1.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106377v1/shard-tglb8/igt@kms_panel_fitting@atomic-fast...@pipe-b-edp-1.html Known issues Here are the changes found in Patchwork_106377v1_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-apl: NOTRUN -> [DMESG-WARN][3] ([i915#4991]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106377v1/shard-apl7/igt@gem_cre...@create-massive.html * igt@gem_ctx_exec@basic-nohangcheck: - shard-tglb: [PASS][4] -> [FAIL][5] ([i915#6268]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11900/shard-tglb7/igt@gem_ctx_e...@basic-nohangcheck.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106377v1/shard-tglb7/igt@gem_ctx_e...@basic-nohangcheck.html * igt@gem_eio@unwedge-stress: - shard-iclb: [PASS][6] -> [TIMEOUT][7] ([i915#3070]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11900/shard-iclb5/igt@gem_...@unwedge-stress.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106377v1/shard-iclb4/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-none@rcs0: - shard-kbl: [PASS][8] -> [FAIL][9] ([i915#2842]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11900/shard-kbl4/igt@gem_exec_fair@basic-n...@rcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106377v1/shard-kbl1/igt@gem_exec_fair@basic-n...@rcs0.html * igt@gem_exec_fair@basic-pace@rcs0: - shard-glk: [PASS][10] -> [FAIL][11] ([i915#2842]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11900/shard-glk2/igt@gem_exec_fair@basic-p...@rcs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106377v1/shard-glk2/igt@gem_exec_fair@basic-p...@rcs0.html - shard-iclb: [PASS][12] -> [FAIL][13] ([i915#2842]) +1 similar issue [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11900/shard-iclb6/igt@gem_exec_fair@basic-p...@rcs0.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106377v1/shard-iclb8/igt@gem_exec_fair@basic-p...@rcs0.html * igt@gem_huc_copy@huc-copy: - shard-tglb: [PASS][14] -> [SKIP][15] ([i915#2190]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11900/shard-tglb2/igt@gem_huc_c...@huc-copy.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106377v1/shard-tglb7/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - shard-glk: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#4613]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106377v1/shard-glk5/igt@gem_lmem_swapp...@basic.html * igt@gem_lmem_swapping@parallel-random-verify: - shard-kbl: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#4613]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106377v1/shard-kbl1/igt@gem_lmem_swapp...@parallel-random-verify.html * igt@gem_lmem_swapping@verify: - shard-apl: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#4613]) +3 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106377v1/shard-apl6/igt@gem_lmem_swapp...@verify.html * igt@gem_lmem_swapping@verify-random: - shard-skl: NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#4613]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106377v1/shard-skl9/igt@gem_lmem_swapp...@verify-random.html * igt@i915_pm_dc@dc6-dpms: - shard-kbl: NOTRUN -> [FAIL][20] ([i915#454]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106377v1/shard-kbl1/igt@i915_pm...@dc6-dpms.html * igt@i915_pm_dc@dc6-psr: - shard-iclb: [PASS][21] -> [FAIL][22] ([i915#454]) [21]:
Re: [Intel-gfx] [PATCH v2 20/29] platform/x86: acer-wmi: Move backlight DMI quirks to acpi/video_detect.c
Hi,
On 7/12/22 22:24, Daniel Dadap wrote:
> I'll ask around to see if there's some DMI property we can match in order to
> detect whether a system is expected to use the EC backlight driver: if so,
> maybe we can avoid the WMI interactions in patch 16/29 of this series.
> Although I suppose even if there were a DMI property, we'd still need to call
> the WMI-wrapped ACPI method to check whether the system is currently
> configured to drive the backlight through the EC, unless the system somehow
> exports a different DMI table depending on the current backlight control
> configuration, which I imagine to be unlikely.
IMHO the duplication is fine, it is also important that
the video_detect.c code and the actual backlight driver use
the same detection mechanism where possible.
Otherwise acpi_video_get_backlight_type() may return
acpi_backlight_nvidia_wmi_ec while the EC backlight driver
refuses to load...
Regards,
Hans
>
> This change looks fine to me, although I suppose somebody who maintains the
> acer-wmi driver should comment. The bugzilla links are a nice touch.
>
> On 7/12/22 14:39, Hans de Goede wrote:
>> Move the backlight DMI quirks to acpi/video_detect.c, so that
>> the driver no longer needs to call acpi_video_set_dmi_backlight_type().
>>
>> acpi_video_set_dmi_backlight_type() is troublesome because it may end up
>> getting called after other backlight drivers have already called
>> acpi_video_get_backlight_type() resulting in the other drivers
>> already being registered even though they should not.
>>
>> Note that even though the DMI quirk table name was video_vendor_dmi_table,
>> 5/6 quirks were actually quirks to use the GPU native backlight.
>>
>> These 5 quirks also had a callback in their dmi_system_id entry which
>> disabled the acer-wmi vendor driver; and any DMI match resulted in:
>>
>> acpi_video_set_dmi_backlight_type(acpi_backlight_vendor);
>>
>> which disabled the acpi_video driver, so only the native driver was left.
>> The new entries for these 5/6 devices correctly marks these as needing
>> the native backlight driver.
>>
>> Also note that other changes in this series change the native backlight
>> drivers to no longer unconditionally register their backlight. Instead
>> these drivers now do this check:
>>
>> if (acpi_video_get_backlight_type(false) != acpi_backlight_native)
>> return 0; /* bail */
>>
>> which without this patch would have broken these 5/6 "special" quirks.
>>
>> Since I had to look at all the commits adding the quirks anyways, to make
>> sure that I understood the code correctly, I've also added links to
>> the various original bugzillas for these quirks to the new entries.
>>
>> Signed-off-by: Hans de Goede
>> ---
>> drivers/acpi/video_detect.c | 53 ++
>> drivers/platform/x86/acer-wmi.c | 66 -
>> 2 files changed, 53 insertions(+), 66 deletions(-)
>>
>> diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
>> index a514adaec14d..cd51cb0d7821 100644
>> --- a/drivers/acpi/video_detect.c
>> +++ b/drivers/acpi/video_detect.c
>> @@ -147,6 +147,15 @@ static const struct dmi_system_id
>> video_detect_dmi_table[] = {
>> DMI_MATCH(DMI_BOARD_NAME, "X360"),
>> },
>> },
>> + {
>> + /* https://bugzilla.redhat.com/show_bug.cgi?id=1128309 */
>> + .callback = video_detect_force_vendor,
>> + /* Acer KAV80 */
>> + .matches = {
>> + DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
>> + DMI_MATCH(DMI_PRODUCT_NAME, "KAV80"),
>> + },
>> + },
>> {
>> .callback = video_detect_force_vendor,
>> /* Asus UL30VT */
>> @@ -427,6 +436,41 @@ static const struct dmi_system_id
>> video_detect_dmi_table[] = {
>> DMI_MATCH(DMI_BOARD_NAME, "JV50"),
>> },
>> },
>> + {
>> + /* https://bugzilla.redhat.com/show_bug.cgi?id=1012674 */
>> + .callback = video_detect_force_native,
>> + /* Acer Aspire 5741 */
>> + .matches = {
>> + DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
>> + DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5741"),
>> + },
>> + },
>> + {
>> + /* https://bugzilla.kernel.org/show_bug.cgi?id=42993 */
>> + .callback = video_detect_force_native,
>> + /* Acer Aspire 5750 */
>> + .matches = {
>> + DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
>> + DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5750"),
>> + },
>> + },
>> + {
>> + /* https://bugzilla.kernel.org/show_bug.cgi?id=42833 */
>> + .callback = video_detect_force_native,
>> + /* Acer Extensa 5235 */
>> + .matches = {
>> + DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
>> + DMI_MATCH(DMI_PRODUCT_NAME, "Extensa 5235"),
>> + },
>> + },
>> + {
>> + .callback = video_detect_force_native,
>> + /* Acer TravelMate 4750 */
>> + .matches = {
>> + DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
>> + DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate
Re: [Intel-gfx] [PATCH v2 16/29] ACPI: video: Add Nvidia WMI EC brightness control detection
Hi Daniel,
On 7/12/22 22:13, Daniel Dadap wrote:
> Thanks, Hans:
>
> On 7/12/22 14:38, Hans de Goede wrote:
>> On some new laptop designs a new Nvidia specific WMI interface is present
>> which gives info about panel brightness control and may allow controlling
>> the brightness through this interface when the embedded controller is used
>> for brightness control.
>>
>> When this WMI interface is present and indicates that the EC is used,
>> then this interface should be used for brightness control.
>>
>> Signed-off-by: Hans de Goede
>> ---
>> drivers/acpi/Kconfig | 1 +
>> drivers/acpi/video_detect.c | 35 ++
>> drivers/gpu/drm/gma500/Kconfig | 2 ++
>> drivers/gpu/drm/i915/Kconfig | 2 ++
>> include/acpi/video.h | 1 +
>> 5 files changed, 41 insertions(+)
>>
>> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>> index 1e34f846508f..c372385cfc3f 100644
>> --- a/drivers/acpi/Kconfig
>> +++ b/drivers/acpi/Kconfig
>> @@ -212,6 +212,7 @@ config ACPI_VIDEO
>> tristate "Video"
>> depends on X86 && BACKLIGHT_CLASS_DEVICE
>> depends on INPUT
>> + depends on ACPI_WMI
>> select THERMAL
>> help
>> This driver implements the ACPI Extensions For Display Adapters
>> diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
>> index 8c2863403040..7b89dc9a04a2 100644
>> --- a/drivers/acpi/video_detect.c
>> +++ b/drivers/acpi/video_detect.c
>> @@ -75,6 +75,35 @@ find_video(acpi_handle handle, u32 lvl, void *context,
>> void **rv)
>> return AE_OK;
>> }
>> +#define WMI_BRIGHTNESS_METHOD_SOURCE 2
>> +#define WMI_BRIGHTNESS_MODE_GET 0
>> +#define WMI_BRIGHTNESS_SOURCE_EC 2
>> +
>> +struct wmi_brightness_args {
>> + u32 mode;
>> + u32 val;
>> + u32 ret;
>> + u32 ignored[3];
>> +};
>> +
>> +static bool nvidia_wmi_ec_supported(void)
>> +{
>> + struct wmi_brightness_args args = {
>> + .mode = WMI_BRIGHTNESS_MODE_GET,
>> + .val = 0,
>> + .ret = 0,
>> + };
>> + struct acpi_buffer buf = { (acpi_size)sizeof(args), };
>> + acpi_status status;
>> +
>> + status = wmi_evaluate_method("603E9613-EF25-4338-A3D0-C46177516DB7", 0,
>> + WMI_BRIGHTNESS_METHOD_SOURCE, , );
>> + if (ACPI_FAILURE(status))
>> + return false;
>> +
>> + return args.ret == WMI_BRIGHTNESS_SOURCE_EC;
>> +}
>> +
>
>
> The code duplication here with nvidia-wmi-ec-backlight.c is a little
> unfortunate. Can we move the constants, struct definition, and WMI GUID from
> that file to a header file that's used both by the EC backlight driver and
> the ACPI video driver?
Yes that is a good idea. I suggest using
include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h
to move the shared definitions there.
If you can submit 2 patches on top of this series:
1. Moving the definitions from drivers/platform/x86/nvidia-wmi-ec-backlight.c to
include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h
2. Switching the code from this patch over to using the new
nvidia-wmi-ec-backlight.h
Then for the next version I'll add patch 1. to the series and squash patch 2.
into this one.
> I was thinking it might be nice to add a wrapper around
> wmi_brightness_notify() in nvidia-wmi-ec-backlight.c that does this source ==
> WMI_BRIGHTNESS_SOURCE_EC test, and then export it so that it can be called
> both here and in the EC backlight driver's probe routine, but then I guess
> that would make video.ko depend on nvidia-wmi-ec-backlight.ko, which seems
> wrong. It also seems wrong to implement the WMI plumbing in the ACPI video
> driver, and export it so that the EC backlight driver can use it, so I guess
> I can live with the duplication of the relatively simple WMI stuff here, it
> would just be nice to not have to define all of the API constants, structure,
> and GUID twice.
Agreed.
>
>
>> /* Force to use vendor driver when the ACPI device is known to be
>> * buggy */
>> static int video_detect_force_vendor(const struct dmi_system_id *d)
>> @@ -518,6 +547,7 @@ static const struct dmi_system_id
>> video_detect_dmi_table[] = {
>> static enum acpi_backlight_type __acpi_video_get_backlight_type(bool
>> native)
>> {
>> static DEFINE_MUTEX(init_mutex);
>> + static bool nvidia_wmi_ec_present;
>> static bool native_available;
>> static bool init_done;
>> static long video_caps;
>> @@ -530,6 +560,7 @@ static enum acpi_backlight_type
>> __acpi_video_get_backlight_type(bool native)
>> acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
>> ACPI_UINT32_MAX, find_video, NULL,
>> _caps, NULL);
>> + nvidia_wmi_ec_present = nvidia_wmi_ec_supported();
>> init_done = true;
>> }
>> if (native)
>> @@ -547,6 +578,10 @@ static enum acpi_backlight_type
>> __acpi_video_get_backlight_type(bool native)
>>
[Intel-gfx] [PATCH i-g-t] tests/i915/gem_create: use 48b addressing
The object here could be very large (8G+), so make sure we allow using the entire address space, to avoid sometimes hitting -ENOSPC. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6446 Signed-off-by: Matthew Auld Cc: Nirmoy Das --- tests/i915/gem_create.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tests/i915/gem_create.c b/tests/i915/gem_create.c index 1b694c6a..ff022713 100644 --- a/tests/i915/gem_create.c +++ b/tests/i915/gem_create.c @@ -538,7 +538,9 @@ static int upload(int fd, uint32_t handle) * for sure placed in one of requested regions. */ exec[0].handle = handle; + exec[0].flags = EXEC_OBJECT_SUPPORTS_48B_ADDRESS; exec[1].handle = batch_create_size(fd, PAGE_SIZE); + exec[1].flags = EXEC_OBJECT_SUPPORTS_48B_ADDRESS; return __gem_execbuf(fd, ); } -- 2.36.1
[Intel-gfx] ✓ Fi.CI.IGT: success for Fixes integer overflow or integer truncation issues in page lookups, ttm place configuration and scatterlist creation (rev5)
== Series Details == Series: Fixes integer overflow or integer truncation issues in page lookups, ttm place configuration and scatterlist creation (rev5) URL : https://patchwork.freedesktop.org/series/104704/ State : success == Summary == CI Bug Log - changes from CI_DRM_11899_full -> Patchwork_104704v5_full Summary --- **SUCCESS** No regressions found. Participating hosts (12 -> 12) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_104704v5_full that come from known issues: ### IGT changes ### Issues hit * igt@feature_discovery@chamelium: - shard-tglb: NOTRUN -> [SKIP][1] ([fdo#111827]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104704v5/shard-tglb1/igt@feature_discov...@chamelium.html - shard-iclb: NOTRUN -> [SKIP][2] ([fdo#111827]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104704v5/shard-iclb7/igt@feature_discov...@chamelium.html * igt@gem_ctx_persistence@legacy-engines-queued: - shard-snb: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104704v5/shard-snb2/igt@gem_ctx_persiste...@legacy-engines-queued.html * igt@gem_eio@in-flight-10ms: - shard-tglb: [PASS][4] -> [TIMEOUT][5] ([i915#3063]) +1 similar issue [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11899/shard-tglb3/igt@gem_...@in-flight-10ms.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104704v5/shard-tglb2/igt@gem_...@in-flight-10ms.html * igt@gem_eio@unwedge-stress: - shard-iclb: [PASS][6] -> [TIMEOUT][7] ([i915#3070]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11899/shard-iclb3/igt@gem_...@unwedge-stress.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104704v5/shard-iclb8/igt@gem_...@unwedge-stress.html * igt@gem_exec_balancer@parallel-bb-first: - shard-iclb: [PASS][8] -> [SKIP][9] ([i915#4525]) +1 similar issue [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11899/shard-iclb1/igt@gem_exec_balan...@parallel-bb-first.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104704v5/shard-iclb8/igt@gem_exec_balan...@parallel-bb-first.html * igt@gem_exec_fair@basic-none-rrul@rcs0: - shard-glk: NOTRUN -> [FAIL][10] ([i915#2842]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104704v5/shard-glk7/igt@gem_exec_fair@basic-none-r...@rcs0.html - shard-iclb: NOTRUN -> [FAIL][11] ([i915#2842]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104704v5/shard-iclb7/igt@gem_exec_fair@basic-none-r...@rcs0.html - shard-tglb: NOTRUN -> [FAIL][12] ([i915#2842]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104704v5/shard-tglb1/igt@gem_exec_fair@basic-none-r...@rcs0.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-tglb: [PASS][13] -> [FAIL][14] ([i915#2842]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11899/shard-tglb7/igt@gem_exec_fair@basic-none-sh...@rcs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104704v5/shard-tglb8/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_suspend@basic-s3@smem: - shard-kbl: [PASS][15] -> [INCOMPLETE][16] ([i915#3614] / [i915#4939]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11899/shard-kbl4/igt@gem_exec_suspend@basic...@smem.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104704v5/shard-kbl4/igt@gem_exec_suspend@basic...@smem.html * igt@gem_huc_copy@huc-copy: - shard-skl: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#2190]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104704v5/shard-skl1/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@smem-oom: - shard-skl: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#4613]) +3 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104704v5/shard-skl1/igt@gem_lmem_swapp...@smem-oom.html - shard-apl: NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#4613]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104704v5/shard-apl1/igt@gem_lmem_swapp...@smem-oom.html - shard-tglb: NOTRUN -> [SKIP][20] ([i915#4613]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104704v5/shard-tglb1/igt@gem_lmem_swapp...@smem-oom.html - shard-glk: NOTRUN -> [SKIP][21] ([fdo#109271] / [i915#4613]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104704v5/shard-glk7/igt@gem_lmem_swapp...@smem-oom.html - shard-iclb: NOTRUN -> [SKIP][22] ([i915#4613]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104704v5/shard-iclb7/igt@gem_lmem_swapp...@smem-oom.html - shard-kbl: NOTRUN -> [SKIP][23] ([fdo#109271] / [i915#4613]) [23]:
Re: [Intel-gfx] [PATCH RFC] drm/i915/gt: Retry RING_HEAD reset until it sticks
On 15.07.2022 10:26, Mauro Carvalho Chehab wrote:
From: Chris Wilson
On Haswell, in particular, we see an issue where resets fails because
the engine resumes from an incorrect RING_HEAD. Since the RING_HEAD
doesn't point to the remaining requests to re-run, but may instead point
into the uninitialised portion of the ring, the GPU may be then fed
invalid instructions from a privileged context, oft pushing the GPU into
an unrecoverable hang.
If at first the write doesn't succeed, try, try again.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/5432
Testcase: igt/i915_selftest/hangcheck
Signed-off-by: Chris Wilson
Cc: Andrzej Hajda
Cc: Mika Kuoppala
Signed-off-by: Mauro Carvalho Chehab
That is pity hw does not provide reliable way of reset.
Reviewed-by: Andrzej Hajda
Regards
Andrzej
---
.../gpu/drm/i915/gt/intel_ring_submission.c | 44 +--
drivers/gpu/drm/i915/i915_utils.h | 10 +
2 files changed, 40 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
index d5d6f1fadcae..cc53feb1f8ed 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
@@ -190,6 +190,7 @@ static bool stop_ring(struct intel_engine_cs *engine)
static int xcs_resume(struct intel_engine_cs *engine)
{
struct intel_ring *ring = engine->legacy.ring;
+ ktime_t kt;
ENGINE_TRACE(engine, "ring:{HEAD:%04x, TAIL:%04x}\n",
ring->head, ring->tail);
@@ -228,9 +229,20 @@ static int xcs_resume(struct intel_engine_cs *engine)
set_pp_dir(engine);
/* First wake the ring up to an empty/idle ring */
- ENGINE_WRITE_FW(engine, RING_HEAD, ring->head);
+ until_timeout_ns(kt, 2 * NSEC_PER_MSEC) {
+ ENGINE_WRITE_FW(engine, RING_HEAD, ring->head);
+ if (ENGINE_READ_FW(engine, RING_HEAD) == ring->head)
+ break;
+ }
+
ENGINE_WRITE_FW(engine, RING_TAIL, ring->head);
- ENGINE_POSTING_READ(engine, RING_TAIL);
+ if (ENGINE_READ_FW(engine, RING_HEAD) != ENGINE_READ_FW(engine,
RING_TAIL)) {
+ ENGINE_TRACE(engine, "failed to reset empty ring: [%x, %x]:
%x\n",
+ENGINE_READ_FW(engine, RING_HEAD),
+ENGINE_READ_FW(engine, RING_TAIL),
+ring->head);
+ goto err;
+ }
ENGINE_WRITE_FW(engine, RING_CTL,
RING_CTL_SIZE(ring->size) | RING_VALID);
@@ -239,12 +251,16 @@ static int xcs_resume(struct intel_engine_cs *engine)
if (__intel_wait_for_register_fw(engine->uncore,
RING_CTL(engine->mmio_base),
RING_VALID, RING_VALID,
-5000, 0, NULL))
+5000, 0, NULL)) {
+ ENGINE_TRACE(engine, "failed to restart\n");
goto err;
+ }
- if (GRAPHICS_VER(engine->i915) > 2)
+ if (GRAPHICS_VER(engine->i915) > 2) {
ENGINE_WRITE_FW(engine,
RING_MI_MODE, _MASKED_BIT_DISABLE(STOP_RING));
+ ENGINE_POSTING_READ(engine, RING_MI_MODE);
+ }
/* Now awake, let it get started */
if (ring->tail != ring->head) {
@@ -257,16 +273,16 @@ static int xcs_resume(struct intel_engine_cs *engine)
return 0;
err:
- drm_err(>i915->drm,
- "%s initialization failed; "
- "ctl %08x (valid? %d) head %08x [%08x] tail %08x [%08x] start %08x
[expected %08x]\n",
- engine->name,
- ENGINE_READ(engine, RING_CTL),
- ENGINE_READ(engine, RING_CTL) & RING_VALID,
- ENGINE_READ(engine, RING_HEAD), ring->head,
- ENGINE_READ(engine, RING_TAIL), ring->tail,
- ENGINE_READ(engine, RING_START),
- i915_ggtt_offset(ring->vma));
+ ENGINE_TRACE(engine,
+"initialization failed; "
+"ctl %08x (valid? %d) head %08x [%08x] tail %08x [%08x] start
%08x [expected %08x]\n",
+ENGINE_READ(engine, RING_CTL),
+ENGINE_READ(engine, RING_CTL) & RING_VALID,
+ENGINE_READ(engine, RING_HEAD), ring->head,
+ENGINE_READ(engine, RING_TAIL), ring->tail,
+ENGINE_READ(engine, RING_START),
+i915_ggtt_offset(ring->vma));
+ GEM_TRACE_DUMP();
return -EIO;
}
diff --git a/drivers/gpu/drm/i915/i915_utils.h b/drivers/gpu/drm/i915/i915_utils.h
index c10d68cdc3ca..717fb6b9cc15 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -256,6 +256,16 @@ wait_remaining_ms_from_jiffies(unsigned long
timestamp_jiffies, int to_wait_ms)
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Retry RING_HEAD reset until it sticks
== Series Details == Series: drm/i915/gt: Retry RING_HEAD reset until it sticks URL : https://patchwork.freedesktop.org/series/106377/ State : success == Summary == CI Bug Log - changes from CI_DRM_11900 -> Patchwork_106377v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106377v1/index.html Participating hosts (43 -> 34) -- Additional (2): fi-rkl-11600 bat-jsl-3 Missing(11): bat-dg1-5 bat-dg2-8 bat-adlm-1 fi-icl-u2 bat-dg2-9 bat-adlp-6 bat-adlp-4 bat-adln-1 bat-rpls-1 bat-rpls-2 bat-jsl-1 Known issues Here are the changes found in Patchwork_106377v1 that come from known issues: ### IGT changes ### Issues hit * igt@gem_huc_copy@huc-copy: - fi-rkl-11600: NOTRUN -> [SKIP][1] ([i915#2190]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106377v1/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@parallel-random-engines: - fi-rkl-11600: NOTRUN -> [SKIP][2] ([i915#4613]) +3 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106377v1/fi-rkl-11600/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@gem_tiled_pread_basic: - fi-rkl-11600: NOTRUN -> [SKIP][3] ([i915#3282]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106377v1/fi-rkl-11600/igt@gem_tiled_pread_basic.html * igt@i915_pm_backlight@basic-brightness: - fi-rkl-11600: NOTRUN -> [SKIP][4] ([i915#3012]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106377v1/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html * igt@i915_selftest@live@requests: - fi-pnv-d510:[PASS][5] -> [DMESG-FAIL][6] ([i915#4528]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11900/fi-pnv-d510/igt@i915_selftest@l...@requests.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106377v1/fi-pnv-d510/igt@i915_selftest@l...@requests.html * igt@i915_suspend@basic-s3-without-i915: - fi-rkl-11600: NOTRUN -> [INCOMPLETE][7] ([i915#5982]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106377v1/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-snb-2600:NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106377v1/fi-snb-2600/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-rkl-11600: NOTRUN -> [SKIP][9] ([fdo#111827]) +7 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106377v1/fi-rkl-11600/igt@kms_chamel...@hdmi-hpd-fast.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor: - fi-rkl-11600: NOTRUN -> [SKIP][10] ([i915#4103]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106377v1/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions: - fi-bsw-kefka: [PASS][11] -> [FAIL][12] ([i915#6298]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11900/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106377v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html * igt@kms_force_connector_basic@force-load-detect: - fi-rkl-11600: NOTRUN -> [SKIP][13] ([fdo#109285] / [i915#4098]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106377v1/fi-rkl-11600/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_psr@sprite_plane_onoff: - fi-rkl-11600: NOTRUN -> [SKIP][14] ([i915#1072]) +3 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106377v1/fi-rkl-11600/igt@kms_psr@sprite_plane_onoff.html * igt@kms_setmode@basic-clone-single-crtc: - fi-rkl-11600: NOTRUN -> [SKIP][15] ([i915#3555] / [i915#4098]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106377v1/fi-rkl-11600/igt@kms_setm...@basic-clone-single-crtc.html * igt@prime_vgem@basic-read: - fi-rkl-11600: NOTRUN -> [SKIP][16] ([fdo#109295] / [i915#3291] / [i915#3708]) +2 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106377v1/fi-rkl-11600/igt@prime_v...@basic-read.html * igt@prime_vgem@basic-userptr: - fi-rkl-11600: NOTRUN -> [SKIP][17] ([fdo#109295] / [i915#3301] / [i915#3708]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106377v1/fi-rkl-11600/igt@prime_v...@basic-userptr.html * igt@runner@aborted: - fi-pnv-d510:NOTRUN -> [FAIL][18] ([fdo#109271] / [i915#2403] / [i915#4312]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106377v1/fi-pnv-d510/igt@run...@aborted.html Possible fixes
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gt: Retry RING_HEAD reset until it sticks
== Series Details == Series: drm/i915/gt: Retry RING_HEAD reset until it sticks URL : https://patchwork.freedesktop.org/series/106377/ State : warning == Summary == Error: dim checkpatch failed 8af7dbc6eea2 drm/i915/gt: Retry RING_HEAD reset until it sticks -:116: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'end' - possible side-effects? #116: FILE: drivers/gpu/drm/i915/i915_utils.h:264: +#define until_timeout_ns(end, timeout_ns) \ + for ((end) = ktime_get() + (timeout_ns); \ +ktime_before(ktime_get(), (end)); \ +cpu_relax()) total: 0 errors, 0 warnings, 1 checks, 89 lines checked
Re: [Intel-gfx] [PATCH 1/1] drm/i915/guc: Update to GuC version 70.1.1 #forregzbot
[TLDR: I'm adding this regression report to the list of tracked regressions; all text from me you find below is based on a few templates paragraphs you might have encountered already already in similar form.] Hi, this is your Linux kernel regression tracker. On 15.07.22 01:08, Dave Airlie wrote: > On Fri, 15 Apr 2022 at 10:15, Matt Roper wrote: >> >> On Tue, Apr 12, 2022 at 03:59:55PM -0700, john.c.harri...@intel.com wrote: >>> From: John Harrison >>> >>> The latest GuC firmware drops the context descriptor pool in favour of >>> passing all creation data in the create H2G. It also greatly simplifies >>> the work queue and removes the process descriptor used for multi-LRC >>> submission. So, remove all mention of LRC and process descriptors and >>> update the registration code accordingly. >>> >>> Unfortunately, the new API also removes the ability to set default >>> values for the scheduling policies at context registration time. >>> Instead, a follow up H2G must be sent. The individual scheduling >>> policy update H2G commands are also dropped in favour of a single KLV >>> based H2G. So, change the update wrappers accordingly and call this >>> during context registration.. >>> >>> Of course, this second H2G per registration might fail due to being >>> backed up. The registration code has a complicated state machine to >>> cope with the actual registration call failing. However, if that works >>> then there is no support for unwinding if a further call should fail. >>> Unwinding would require sending a H2G to de-register - but that can't >>> be done because the CTB is already backed up. >>> >>> So instead, add a new flag to say whether the context has a pending >>> policy update. This is set if the policy H2G fails at registration >>> time. The submission code checks for this flag and retries the policy >>> update if set. If that call fails, the submission path early exists >>> with a retry error. This is something that is already supported for >>> other reasons. >>> >>> Signed-off-by: John Harrison >>> Reviewed-by: Daniele Ceraolo Spurio >> >> Applied to drm-intel-gt-next. Thanks for the patch and review. >> > > (cc'ing Linus and danvet, as a headsup, there is also a phoronix > article where this was discovered). > > Okay WTF. > > This is in no way acceptable. This needs to be fixed in 5.19-rc ASAP. > > Once hardware is released and we remove the gate flag by default, you > cannot just bump firmware versions blindly. > > The kernel needs to retain compatibility with all released firmwares > since a device was declared supported. > > This needs to be reverted, and then 70 should be introduced with a > fallback to 69 versions. > > Very disappointing, I expect this to get dealt with v.quickly. To be sure below issue doesn't fall through the cracks unnoticed, I'm adding it to regzbot, my Linux kernel regression tracking bot: #regzbot ^introduced 2584b3549f4c4081 #regzbot title #regzbot ignore-activity This isn't a regression? This issue or a fix for it are already discussed somewhere else? It was fixed already? You want to clarify when the regression started to happen? Or point out I got the title or something else totally wrong? Then just reply -- ideally with also telling regzbot about it, as explained here: https://linux-regtracking.leemhuis.info/tracked-regression/ Reminder for developers: When fixing the issue, add 'Link:' tags pointing to the report (the mail this one replies to), as explained for in the Linux kernel's documentation; above webpage explains why this is important for tracked regressions. Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) P.S.: As the Linux kernel's regression tracker I deal with a lot of reports and sometimes miss something important when writing mails like this. If that's the case here, don't hesitate to tell me in a public reply, it's in everyone's interest to set the public record straight.
[Intel-gfx] ✓ Fi.CI.BAT: success for Fixes integer overflow or integer truncation issues in page lookups, ttm place configuration and scatterlist creation (rev5)
== Series Details == Series: Fixes integer overflow or integer truncation issues in page lookups, ttm place configuration and scatterlist creation (rev5) URL : https://patchwork.freedesktop.org/series/104704/ State : success == Summary == CI Bug Log - changes from CI_DRM_11899 -> Patchwork_104704v5 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104704v5/index.html Participating hosts (41 -> 43) -- Additional (3): fi-hsw-4770 fi-bxt-dsi fi-icl-u2 Missing(1): bat-jsl-3 Known issues Here are the changes found in Patchwork_104704v5 that come from known issues: ### IGT changes ### Issues hit * igt@gem_huc_copy@huc-copy: - fi-icl-u2: NOTRUN -> [SKIP][1] ([i915#2190]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104704v5/fi-icl-u2/igt@gem_huc_c...@huc-copy.html - fi-bxt-dsi: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#2190]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104704v5/fi-bxt-dsi/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@parallel-random-engines: - fi-bxt-dsi: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#4613]) +3 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104704v5/fi-bxt-dsi/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@gem_lmem_swapping@random-engines: - fi-icl-u2: NOTRUN -> [SKIP][4] ([i915#4613]) +3 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104704v5/fi-icl-u2/igt@gem_lmem_swapp...@random-engines.html * igt@gem_softpin@allocator-basic-reserve: - fi-hsw-4770:NOTRUN -> [SKIP][5] ([fdo#109271]) +9 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104704v5/fi-hsw-4770/igt@gem_soft...@allocator-basic-reserve.html * igt@gem_tiled_blits@basic: - fi-bxt-dsi: NOTRUN -> [SKIP][6] ([fdo#109271]) +12 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104704v5/fi-bxt-dsi/igt@gem_tiled_bl...@basic.html * igt@i915_pm_backlight@basic-brightness: - fi-hsw-4770:NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#3012]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104704v5/fi-hsw-4770/igt@i915_pm_backli...@basic-brightness.html * igt@i915_selftest@live@hangcheck: - fi-hsw-4770:NOTRUN -> [INCOMPLETE][8] ([i915#4785]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104704v5/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html * igt@i915_suspend@basic-s3-without-i915: - fi-icl-u2: NOTRUN -> [SKIP][9] ([i915#5903]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104704v5/fi-icl-u2/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-bdw-5557u: NOTRUN -> [SKIP][10] ([fdo#109271] / [fdo#111827]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104704v5/fi-bdw-5557u/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_chamelium@dp-crc-fast: - fi-hsw-4770:NOTRUN -> [SKIP][11] ([fdo#109271] / [fdo#111827]) +7 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104704v5/fi-hsw-4770/igt@kms_chamel...@dp-crc-fast.html * igt@kms_chamelium@hdmi-edid-read: - fi-bxt-dsi: NOTRUN -> [SKIP][12] ([fdo#109271] / [fdo#111827]) +8 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104704v5/fi-bxt-dsi/igt@kms_chamel...@hdmi-edid-read.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-icl-u2: NOTRUN -> [SKIP][13] ([fdo#111827]) +8 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104704v5/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor: - fi-icl-u2: NOTRUN -> [SKIP][14] ([i915#4103]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104704v5/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html * igt@kms_force_connector_basic@force-connector-state: - fi-icl-u2: NOTRUN -> [WARN][15] ([i915#6008]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104704v5/fi-icl-u2/igt@kms_force_connector_ba...@force-connector-state.html * igt@kms_force_connector_basic@force-load-detect: - fi-icl-u2: NOTRUN -> [SKIP][16] ([fdo#109285]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104704v5/fi-icl-u2/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_psr@sprite_plane_onoff: - fi-hsw-4770:NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#1072]) +3 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104704v5/fi-hsw-4770/igt@kms_psr@sprite_plane_onoff.html * igt@kms_setmode@basic-clone-single-crtc: - fi-icl-u2: NOTRUN -> [SKIP][18] ([i915#3555])
Re: [Intel-gfx] [PATCH 2/2] drm/i915/psr: Disable PSR before disable pipe
On Fri, Jul 15, 2022 at 08:33:43AM +0300, Hogander, Jouni wrote:
> On Thu, 2022-07-14 at 08:07 -0700, José Roberto de Souza wrote:
> > The issue here was on for_each_intel_encoder_mask_with_psr() over the
> > new_crtc_state encoder mask, so if the CRTC was being disabled mask
> > would be zero and it would not have any chance to disable PSR.
> >
> > So here doing for_each_intel_encoder_mask_with_psr() over the
> > old_crtc_state encoder mask and then using the new_crtc_state to
> > check if PSR needs to be disabled.
Are we sure that using old_crtc_state mask is safe here?
Because currently we would be basically mixing a usage of
encoder from old_crtc_state mask with new_crtc_state.
If you mention a specific scenario, when this happens(i.e crtc
is being disabled and new mask is 0) should we add a specific check
instructing us to use old_crtc_state mask only?
Because currently you might be touching some other scenarios as
well, that is what I'm concerned about.
Stan
> >
> > Cc: Jouni Högander
> > Cc: Stanislav Lisovskiy
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/display/intel_psr.c | 14 --
> > 1 file changed, 8 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > b/drivers/gpu/drm/i915/display/intel_psr.c
> > index e6a870641cd25..98c3c8015a5c4 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -1863,7 +1863,9 @@ void intel_psr_pre_plane_update(struct
> > intel_atomic_state *state,
> > struct intel_crtc *crtc)
> > {
> > struct drm_i915_private *i915 = to_i915(state->base.dev);
> > - const struct intel_crtc_state *crtc_state =
> > + 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);
> > struct intel_encoder *encoder;
> >
> > @@ -1871,7 +1873,7 @@ void intel_psr_pre_plane_update(struct
> > intel_atomic_state *state,
> > return;
> >
> > for_each_intel_encoder_mask_with_psr(state->base.dev, encoder,
> > - crtc_state-
> > >uapi.encoder_mask) {
> > + old_crtc_state-
> > >uapi.encoder_mask) {
>
> I would add comment here explaining why using encoder mask from
> old_crtc_state, but using new_crtc_state inside the loop. It's up to
> you:
>
> Reviewed-by: Jouni Högander
>
> > struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > struct intel_psr *psr = _dp->psr;
> > bool needs_to_disable = false;
> > @@ -1884,10 +1886,10 @@ void intel_psr_pre_plane_update(struct
> > intel_atomic_state *state,
> >* - All planes will go inactive
> >* - Changing between PSR versions
> >*/
> > - needs_to_disable |=
> > intel_crtc_needs_modeset(crtc_state);
> > - needs_to_disable |= !crtc_state->has_psr;
> > - needs_to_disable |= !crtc_state->active_planes;
> > - needs_to_disable |= crtc_state->has_psr2 != psr-
> > >psr2_enabled;
> > + needs_to_disable |=
> > intel_crtc_needs_modeset(new_crtc_state);
> > + needs_to_disable |= !new_crtc_state->has_psr;
> > + needs_to_disable |= !new_crtc_state->active_planes;
> > + needs_to_disable |= new_crtc_state->has_psr2 != psr-
> > >psr2_enabled;
> >
> > if (psr->enabled && needs_to_disable)
> > intel_psr_disable_locked(intel_dp);
>
[Intel-gfx] [PATCH RFC] drm/i915/gt: Retry RING_HEAD reset until it sticks
From: Chris Wilson
On Haswell, in particular, we see an issue where resets fails because
the engine resumes from an incorrect RING_HEAD. Since the RING_HEAD
doesn't point to the remaining requests to re-run, but may instead point
into the uninitialised portion of the ring, the GPU may be then fed
invalid instructions from a privileged context, oft pushing the GPU into
an unrecoverable hang.
If at first the write doesn't succeed, try, try again.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/5432
Testcase: igt/i915_selftest/hangcheck
Signed-off-by: Chris Wilson
Cc: Andrzej Hajda
Cc: Mika Kuoppala
Signed-off-by: Mauro Carvalho Chehab
---
.../gpu/drm/i915/gt/intel_ring_submission.c | 44 +--
drivers/gpu/drm/i915/i915_utils.h | 10 +
2 files changed, 40 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
index d5d6f1fadcae..cc53feb1f8ed 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
@@ -190,6 +190,7 @@ static bool stop_ring(struct intel_engine_cs *engine)
static int xcs_resume(struct intel_engine_cs *engine)
{
struct intel_ring *ring = engine->legacy.ring;
+ ktime_t kt;
ENGINE_TRACE(engine, "ring:{HEAD:%04x, TAIL:%04x}\n",
ring->head, ring->tail);
@@ -228,9 +229,20 @@ static int xcs_resume(struct intel_engine_cs *engine)
set_pp_dir(engine);
/* First wake the ring up to an empty/idle ring */
- ENGINE_WRITE_FW(engine, RING_HEAD, ring->head);
+ until_timeout_ns(kt, 2 * NSEC_PER_MSEC) {
+ ENGINE_WRITE_FW(engine, RING_HEAD, ring->head);
+ if (ENGINE_READ_FW(engine, RING_HEAD) == ring->head)
+ break;
+ }
+
ENGINE_WRITE_FW(engine, RING_TAIL, ring->head);
- ENGINE_POSTING_READ(engine, RING_TAIL);
+ if (ENGINE_READ_FW(engine, RING_HEAD) != ENGINE_READ_FW(engine,
RING_TAIL)) {
+ ENGINE_TRACE(engine, "failed to reset empty ring: [%x, %x]:
%x\n",
+ENGINE_READ_FW(engine, RING_HEAD),
+ENGINE_READ_FW(engine, RING_TAIL),
+ring->head);
+ goto err;
+ }
ENGINE_WRITE_FW(engine, RING_CTL,
RING_CTL_SIZE(ring->size) | RING_VALID);
@@ -239,12 +251,16 @@ static int xcs_resume(struct intel_engine_cs *engine)
if (__intel_wait_for_register_fw(engine->uncore,
RING_CTL(engine->mmio_base),
RING_VALID, RING_VALID,
-5000, 0, NULL))
+5000, 0, NULL)) {
+ ENGINE_TRACE(engine, "failed to restart\n");
goto err;
+ }
- if (GRAPHICS_VER(engine->i915) > 2)
+ if (GRAPHICS_VER(engine->i915) > 2) {
ENGINE_WRITE_FW(engine,
RING_MI_MODE, _MASKED_BIT_DISABLE(STOP_RING));
+ ENGINE_POSTING_READ(engine, RING_MI_MODE);
+ }
/* Now awake, let it get started */
if (ring->tail != ring->head) {
@@ -257,16 +273,16 @@ static int xcs_resume(struct intel_engine_cs *engine)
return 0;
err:
- drm_err(>i915->drm,
- "%s initialization failed; "
- "ctl %08x (valid? %d) head %08x [%08x] tail %08x [%08x] start
%08x [expected %08x]\n",
- engine->name,
- ENGINE_READ(engine, RING_CTL),
- ENGINE_READ(engine, RING_CTL) & RING_VALID,
- ENGINE_READ(engine, RING_HEAD), ring->head,
- ENGINE_READ(engine, RING_TAIL), ring->tail,
- ENGINE_READ(engine, RING_START),
- i915_ggtt_offset(ring->vma));
+ ENGINE_TRACE(engine,
+"initialization failed; "
+"ctl %08x (valid? %d) head %08x [%08x] tail %08x [%08x]
start %08x [expected %08x]\n",
+ENGINE_READ(engine, RING_CTL),
+ENGINE_READ(engine, RING_CTL) & RING_VALID,
+ENGINE_READ(engine, RING_HEAD), ring->head,
+ENGINE_READ(engine, RING_TAIL), ring->tail,
+ENGINE_READ(engine, RING_START),
+i915_ggtt_offset(ring->vma));
+ GEM_TRACE_DUMP();
return -EIO;
}
diff --git a/drivers/gpu/drm/i915/i915_utils.h
b/drivers/gpu/drm/i915/i915_utils.h
index c10d68cdc3ca..717fb6b9cc15 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -256,6 +256,16 @@ wait_remaining_ms_from_jiffies(unsigned long
timestamp_jiffies, int to_wait_ms)
}
}
+/**
+ * until_timeout_ns - Keep retrying (busy spin) until the duration has passed
+ * @end: temporary var to be used to track the spent time
+ *
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Fixes integer overflow or integer truncation issues in page lookups, ttm place configuration and scatterlist creation (rev5)
== Series Details ==
Series: Fixes integer overflow or integer truncation issues in page lookups,
ttm place configuration and scatterlist creation (rev5)
URL : https://patchwork.freedesktop.org/series/104704/
State : warning
== Summary ==
Error: dim checkpatch failed
50a1609cfb0b drm: Move and add a few utility macros into drm util header
-:86: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'x' - possible side-effects?
#86: FILE: include/drm/drm_util.h:92:
+#define overflows_type(x, T) \
+ (is_type_unsigned(x) ? \
+ is_type_unsigned(T) ? \
+ (sizeof(x) > sizeof(T) && (x) >> BITS_PER_TYPE(T)) ? 1
: 0 \
+ : (sizeof(x) >= sizeof(T) && (x) >> (BITS_PER_TYPE(T) -
1)) ? 1 : 0 \
+ : is_type_unsigned(T) ? \
+ ((x) < 0) ? 1 : (sizeof(x) > sizeof(T) && (x) >>
BITS_PER_TYPE(T)) ? 1 : 0 \
+ : (sizeof(x) > sizeof(T)) ? \
+ ((x) < 0) ? (((x) * -1) >> BITS_PER_TYPE(T)) ? 1 : 0 \
+ : ((x) >> BITS_PER_TYPE(T)) ? 1 : 0 \
+ : 0)
-:86: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'T' - possible side-effects?
#86: FILE: include/drm/drm_util.h:92:
+#define overflows_type(x, T) \
+ (is_type_unsigned(x) ? \
+ is_type_unsigned(T) ? \
+ (sizeof(x) > sizeof(T) && (x) >> BITS_PER_TYPE(T)) ? 1
: 0 \
+ : (sizeof(x) >= sizeof(T) && (x) >> (BITS_PER_TYPE(T) -
1)) ? 1 : 0 \
+ : is_type_unsigned(T) ? \
+ ((x) < 0) ? 1 : (sizeof(x) > sizeof(T) && (x) >>
BITS_PER_TYPE(T)) ? 1 : 0 \
+ : (sizeof(x) > sizeof(T)) ? \
+ ((x) < 0) ? (((x) * -1) >> BITS_PER_TYPE(T)) ? 1 : 0 \
+ : ((x) >> BITS_PER_TYPE(T)) ? 1 : 0 \
+ : 0)
total: 0 errors, 0 warnings, 2 checks, 100 lines checked
0ba9641f2367 drm/i915/gem: Typecheck page lookups
-:97: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'n' - possible side-effects?
#97: FILE: drivers/gpu/drm/i915/gem/i915_gem_object.h:374:
+#define i915_gem_object_page_iter_get_sg(obj, it, n, offset) ({ \
+ exactly_pgoff_t(n); \
+ __i915_gem_object_page_iter_get_sg(obj, it, n, offset); \
+})
-:113: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'n' - possible side-effects?
#113: FILE: drivers/gpu/drm/i915/gem/i915_gem_object.h:386:
+#define i915_gem_object_get_sg(obj, n, offset) ({ \
+ exactly_pgoff_t(n); \
+ __i915_gem_object_get_sg(obj, n, offset); \
+})
-:123: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#123: FILE: drivers/gpu/drm/i915/gem/i915_gem_object.h:393:
+__i915_gem_object_get_sg_dma(struct drm_i915_gem_object *obj, pgoff_t n,
+ unsigned int *offset)
-:129: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'n' - possible side-effects?
#129: FILE: drivers/gpu/drm/i915/gem/i915_gem_object.h:398:
+#define i915_gem_object_get_sg_dma(obj, n, offset) ({ \
+ exactly_pgoff_t(n); \
+ __i915_gem_object_get_sg_dma(obj, n, offset); \
+})
-:139: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'n' - possible side-effects?
#139: FILE: drivers/gpu/drm/i915/gem/i915_gem_object.h:406:
+#define i915_gem_object_get_page(obj, n) ({ \
+ exactly_pgoff_t(n); \
+ __i915_gem_object_get_page(obj, n); \
+})
-:149: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'n' - possible side-effects?
#149: FILE: drivers/gpu/drm/i915/gem/i915_gem_object.h:414:
+#define i915_gem_object_get_dirty_page(obj, n) ({ \
+ exactly_pgoff_t(n); \
+ __i915_gem_object_get_dirty_page(obj, n); \
+})
-:161: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'n' - possible side-effects?
#161: FILE: drivers/gpu/drm/i915/gem/i915_gem_object.h:423:
+#define i915_gem_object_get_dma_address_len(obj, n, len) ({ \
+ exactly_pgoff_t(n); \
+ __i915_gem_object_get_dma_address_len(obj, n, len); \
+})
-:171: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'n' - possible side-effects?
#171: FILE: drivers/gpu/drm/i915/gem/i915_gem_object.h:431:
+#define i915_gem_object_get_dma_address(obj, n) ({ \
+ exactly_pgoff_t(n); \
+ __i915_gem_object_get_dma_address(obj, n); \
+})
total: 0 errors, 0 warnings, 8 checks, 399 lines checked
d2f809cd1a45 drm/i915: Check for integer truncation on scatterlist creation
-:200: WARNING:NEW_TYPEDEFS: do not add new typedefs
#200: FILE: drivers/gpu/drm/i915/i915_scatterlist.h:224:
+typedef unsigned int __sg_size_t; /* see linux/scatterlist.h */
-:201: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in
parentheses
#201: FILE: drivers/gpu/drm/i915/i915_scatterlist.h:225:
+#define sg_alloc_table(sgt, nents, gfp) \
+ overflows_type(nents, __sg_size_t) ? -E2BIG : (sg_alloc_table)(sgt,
(__sg_size_t)(nents), gfp)
-:201: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'nents' - possible
side-effects?
#201: FILE: drivers/gpu/drm/i915/i915_scatterlist.h:225:
+#define
Re: [Intel-gfx] [PATCH] drm/i915/display: Add debug print for scaler filter
> -Original Message-
> From: Intel-gfx On Behalf Of Swati
> Sharma
> Sent: Wednesday, July 6, 2022 3:53 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH] drm/i915/display: Add debug print for scaler
> filter
>
> Add debug print statement to print scaler filter property value. Since
> property can be
> set as either default or integer scaler; its good if we can get debug print
> for the same
> in dmesg log.
Looks Good to me.
Reviewed-by: Uma Shankar
> Cc: Juha-Pekka Heikkila
> Signed-off-by: Swati Sharma
> ---
> drivers/gpu/drm/i915/display/intel_crtc_state_dump.c | 9 +
> drivers/gpu/drm/i915/display/intel_display_debugfs.c | 5 +++--
> 2 files changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
> b/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
> index 4ca6e9493ff2..e9212f69c360 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
> +++ b/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
> @@ -134,8 +134,8 @@ static void intel_dump_plane_state(const struct
> intel_plane_state *plane_state)
> plane->base.base.id, plane->base.name,
> fb->base.id, fb->width, fb->height, >format->format,
> fb->modifier, str_yes_no(plane_state->uapi.visible));
> - drm_dbg_kms(>drm, "\trotation: 0x%x, scaler: %d\n",
> - plane_state->hw.rotation, plane_state->scaler_id);
> + drm_dbg_kms(>drm, "\trotation: 0x%x, scaler: %d, scaling_filter:
> %d\n",
> + plane_state->hw.rotation, plane_state->scaler_id,
> +plane_state->hw.scaling_filter);
> if (plane_state->uapi.visible)
> drm_dbg_kms(>drm,
> "\tsrc: " DRM_RECT_FP_FMT " dst: " DRM_RECT_FMT
> "\n", @@ -262,10 +262,11 @@ void intel_crtc_state_dump(const struct
> intel_crtc_state *pipe_config,
>
> if (DISPLAY_VER(i915) >= 9)
> drm_dbg_kms(>drm,
> - "num_scalers: %d, scaler_users: 0x%x, scaler_id:
> %d\n",
> + "num_scalers: %d, scaler_users: 0x%x, scaler_id: %d,
> +scaling_filter: %d\n",
> crtc->num_scalers,
> pipe_config->scaler_state.scaler_users,
> - pipe_config->scaler_state.scaler_id);
> + pipe_config->scaler_state.scaler_id,
> + pipe_config->hw.scaling_filter);
>
> if (HAS_GMCH(i915))
> drm_dbg_kms(>drm,
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index 6c3954479047..225b6bfc783c 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -722,10 +722,11 @@ static void intel_scaler_info(struct seq_file *m, struct
> intel_crtc *crtc)
>
> /* Not all platformas have a scaler */
> if (num_scalers) {
> - seq_printf(m, "\tnum_scalers=%d, scaler_users=%x scaler_id=%d",
> + seq_printf(m, "\tnum_scalers=%d, scaler_users=%x scaler_id=%d
> +scaling_filter=%d",
> num_scalers,
> crtc_state->scaler_state.scaler_users,
> -crtc_state->scaler_state.scaler_id);
> +crtc_state->scaler_state.scaler_id,
> +crtc_state->hw.scaling_filter);
>
> for (i = 0; i < num_scalers; i++) {
> const struct intel_scaler *sc =
> --
> 2.25.1
