[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for linux-next: manual merge of the drm-misc tree with Linus' tree
== Series Details ==
Series: linux-next: manual merge of the drm-misc tree with Linus' tree
URL : https://patchwork.freedesktop.org/series/60886/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
75ba999b2c56 linux-next: manual merge of the drm-misc tree with Linus' tree
-:15: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 8122de54602e ("dt-bindings:
Convert vendor prefixes to json-schema")'
#15:
8122de54602e ("dt-bindings: Convert vendor prefixes to json-schema")
-:19: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit b4a2c0055a4f ("dt-bindings: Add
vendor prefix for VXT Ltd")'
#19:
b4a2c0055a4f ("dt-bindings: Add vendor prefix for VXT Ltd")
-:20: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#20:
b1b0d36bdb15 ("dt-bindings: drm/panel: simple: Add binding for TFC
S9700RTWV43TR-01B")
-:20: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit b1b0d36bdb15 ("dt-bindings:
drm/panel: simple: Add binding for TFC S9700RTWV43TR-01B")'
#20:
b1b0d36bdb15 ("dt-bindings: drm/panel: simple: Add binding for TFC
S9700RTWV43TR-01B")
-:21: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit fbd8b69ab616 ("dt-bindings: Add
vendor prefix for Evervision Electronics")'
#21:
fbd8b69ab616 ("dt-bindings: Add vendor prefix for Evervision Electronics")
-:62: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s)
total: 5 errors, 1 warnings, 0 checks, 24 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] linux-next: manual merge of the drm-misc tree with Linus' tree
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
Documentation/devicetree/bindings/vendor-prefixes.txt
between commit:
8122de54602e ("dt-bindings: Convert vendor prefixes to json-schema")
from Linus' tree and commits:
b4a2c0055a4f ("dt-bindings: Add vendor prefix for VXT Ltd")
b1b0d36bdb15 ("dt-bindings: drm/panel: simple: Add binding for TFC
S9700RTWV43TR-01B")
fbd8b69ab616 ("dt-bindings: Add vendor prefix for Evervision Electronics")
from the drm-misc tree.
I fixed it up (I deleted the file and added the patch below) and can
carry the fix as necessary. This is now fixed as far as linux-next is
concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging. You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
From: Stephen Rothwell
Date: Tue, 21 May 2019 10:48:36 +1000
Subject: [PATCH] dt-bindings: fix up for vendor prefixes file conversion
Signed-off-by: Stephen Rothwell
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml
b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 83ca4816a78b..749e3c3843d0 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -287,6 +287,8 @@ patternProperties:
description: Everest Semiconductor Co. Ltd.
"^everspin,.*":
description: Everspin Technologies, Inc.
+ "^evervision,.*":
+description: Evervision Electronics Co. Ltd.
"^exar,.*":
description: Exar Corporation
"^excito,.*":
@@ -851,6 +853,8 @@ patternProperties:
description: Shenzhen Techstar Electronics Co., Ltd.
"^terasic,.*":
description: Terasic Inc.
+ "^tfc,.*":
+description: Three Five Corp
"^thine,.*":
description: THine Electronics, Inc.
"^ti,.*":
@@ -925,6 +929,8 @@ patternProperties:
description: Voipac Technologies s.r.o.
"^vot,.*":
description: Vision Optical Technology Co., Ltd.
+ "^vxt,.*"
+description: VXT Ltd
"^wd,.*":
description: Western Digital Corp.
"^wetek,.*":
--
2.20.1
pgp7qo208H1ot.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] linux-next: manual merge of the drm-misc tree with the amdgpu tree
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
between commit:
56965ce261af ("drm/amdgpu: cancel late_init_work before gpu reset")
from the amdgpu tree and commit:
1d721ed679db ("drm/amdgpu: Avoid HW reset if guilty job already signaled.")
from the drm-misc tree.
I fixed it up (I think - see below) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index c9024f92e203,b9371ec5e04f..
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@@ -3614,28 -3538,27 +3595,28 @@@ int amdgpu_device_gpu_recover(struct am
dev_info(adev->dev, "GPU reset begin!\n");
+ cancel_delayed_work_sync(>late_init_work);
+ hive = amdgpu_get_xgmi_hive(adev, false);
/*
-* In case of XGMI hive disallow concurrent resets to be triggered
-* by different nodes. No point also since the one node already
executing
-* reset will also reset all the other nodes in the hive.
+* Here we trylock to avoid chain of resets executing from
+* either trigger by jobs on different adevs in XGMI hive or jobs on
+* different schedulers for same device while this TO handler is
running.
+* We always reset all schedulers for device and all devices for XGMI
+* hive so that should take care of them too.
*/
- hive = amdgpu_get_xgmi_hive(adev, 0);
- if (hive && adev->gmc.xgmi.num_physical_nodes > 1 &&
- !mutex_trylock(>reset_lock))
+
+ if (hive && !mutex_trylock(>reset_lock)) {
+ DRM_INFO("Bailing on TDR for s_job:%llx, hive: %llx as another
already in progress",
+job->base.id, hive->hive_id);
return 0;
+ }
/* Start with adev pre asic reset first for soft reset check.*/
- amdgpu_device_lock_adev(adev);
- r = amdgpu_device_pre_asic_reset(adev,
-job,
-_full_reset);
- if (r) {
- /*TODO Should we stop ?*/
- DRM_ERROR("GPU pre asic reset failed with err, %d for drm dev,
%s ",
- r, adev->ddev->unique);
- adev->asic_reset_res = r;
+ if (!amdgpu_device_lock_adev(adev, !hive)) {
+ DRM_INFO("Bailing on TDR for s_job:%llx, as another already in
progress",
+job->base.id);
+ return 0;
}
/* Build list of devices to reset */
pgpd7OqMqJbiJ.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Revert "ICL HACK: Disable ACPI idle driver"
On Mon, May 20, 2019 at 01:42:35PM +, Saarinen, Jani wrote:
> HI,
>
> > -Original Message-
> > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> > Of
> > Aditya Swarup
> > Sent: lauantai 18. toukokuuta 2019 1.00
> > To: Gupta, Anshuman
> > Cc: Vetter, Daniel ;
> > intel-gfx@lists.freedesktop.org;
> > Syrjala, Ville ; Peres, Martin
> >
> > Subject: Re: [Intel-gfx] [PATCH] Revert "ICL HACK: Disable ACPI idle driver"
> >
> > The patch looks fine to me.
> > On Thu, May 16, 2019 at 10:41:56PM +0530, Anshuman Gupta wrote:
> > > This reverts commit 99b69db57544ec7ed427607f1a2a1858a7d43b61
> > > Core-for-CI:ICL_only Disable ACPI idle driver.
> > >
> > > This hack has been provided considering the Bug assessment that ACPI
> > > idle driver page fault causes below bug.
> > > FDO https://bugs.freedesktop.org/show_bug.cgi?id=108840
> > > But this bug is still reproducible after disabling ACPI idle driver.
> > >
> > > It looks "rcu_preempt self-detected stall on CPU" causes to hung
> > > kworker and followed by panic resulted this bug.
> > >
> > > Hence it make sense to revert this patch.
> > >
> > > Cc: martin.pe...@intel.com
> > > Cc: daniel.vet...@intel.com
> > > Cc: ville.syrj...@intel.com
> >
> > Reviewed-by: Aditya Swarup
> Are we now ok to merge this or? Chris, Ville?
We shouldn't merge this. Instead we just need to go there and remove
from topic/core-for-CI and force push with dim to rebuild drm-tip.
If this is the wish from CI perspective, let's do it.
>
> >
> > > Signed-off-by: Anshuman Gupta
> > > ---
> > > drivers/acpi/processor_driver.c | 18 +-
> > > 1 file changed, 1 insertion(+), 17 deletions(-)
> > >
> > > diff --git a/drivers/acpi/processor_driver.c
> > > b/drivers/acpi/processor_driver.c index ee842a2f..9d6aff2 100644
> > > --- a/drivers/acpi/processor_driver.c
> > > +++ b/drivers/acpi/processor_driver.c
> > > @@ -35,12 +35,6 @@
> > >
> > > #include
> > >
> > > -/* Only for Core-for-CI so don't want ia64 to fail compilation.*/
> > > -#ifdef CONFIG_X86 -#include -#include
> > > -#endif
> > > -
> > > #include "internal.h"
> > >
> > > #define ACPI_PROCESSOR_NOTIFY_PERFORMANCE 0x80 @@ -64,13 +58,6 @@
> > > static const struct acpi_device_id processor_device_ids[] = { };
> > > MODULE_DEVICE_TABLE(acpi, processor_device_ids);
> > >
> > > -#define ICPU(model) { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, }
> > > -static const struct x86_cpu_id intel_cpu_ids[] = {
> > > - ICPU(INTEL_FAM6_ICELAKE_MOBILE),/* ICL */
> > > - {}
> > > -};
> > > -MODULE_DEVICE_TABLE(x86cpu, intel_cpu_ids);
> > > -
> > > static struct device_driver acpi_processor_driver = {
> > > .name = "processor",
> > > .bus = _subsys,
> > > @@ -239,7 +226,6 @@ static inline void acpi_pss_perf_exit(struct
> > > acpi_processor *pr, static int __acpi_processor_start(struct
> > > acpi_device *device) {
> > > struct acpi_processor *pr = acpi_driver_data(device);
> > > - const struct x86_cpu_id *id;
> > > acpi_status status;
> > > int result = 0;
> > >
> > > @@ -253,9 +239,7 @@ static int __acpi_processor_start(struct acpi_device
> > *device)
> > > if (result && !IS_ENABLED(CONFIG_ACPI_CPU_FREQ_PSS))
> > > dev_dbg(>dev, "CPPC data invalid or not present\n");
> > >
> > > - id = x86_match_cpu(intel_cpu_ids);
> > > - if (!id && (!cpuidle_get_driver() || cpuidle_get_driver() ==
> > > - _idle_driver))
> > > + if (!cpuidle_get_driver() || cpuidle_get_driver() ==
> > > +_idle_driver)
> > > acpi_processor_power_init(pr);
> > >
> > > result = acpi_pss_perf_init(pr, device);
> > > --
> > > 2.7.4
> > >
> > > ___
> > > 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
> ___
> 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] drm: Allow modeset on unregisted connectors unconditionally
On Mon, May 20, 2019 at 08:41:09PM +0300, Imre Deak wrote:
> We allowed modesetting an unregistered connector only in the case the
> mode is getting disabled on the connector.
>
> The reason for this check was the lack of proper refcounting for the
> backing memory objects. That problem has been solved meanwhile so there
> is no reason any more to reject the modesetting in general. The check
> for that also makes driver internal modesets more cumbersome where we
> need to add exemptions for the cases where we do need to allow the
> modeset even for unregistered connectors. One such case is the
> restoration of the mode during resume.
>
> Simplify things by removing the unneeded check. I can't see how
> modesetting an unregistered connector can cause any problem and the race
> (described in the code comment) can anyway result in such a modeset (if
> the connector is unregistered right after the check).
>
> Cc: Lyude Paul
> Cc: Daniel Vetter
> Cc: Ville Syrjälä
> Signed-off-by: Imre Deak
Lyude, could you test this change against the DDX fail scenario that the
check was added for originally (based on our IRC discussion)?
Thanks,
Imre
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 29 ++---
> 1 file changed, 2 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 2e0cb4246cbd..e94e69483498 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -319,33 +319,6 @@ update_connector_routing(struct drm_atomic_state *state,
> return 0;
> }
>
> - crtc_state = drm_atomic_get_new_crtc_state(state,
> -new_connector_state->crtc);
> - /*
> - * For compatibility with legacy users, we want to make sure that
> - * we allow DPMS On->Off modesets on unregistered connectors. Modesets
> - * which would result in anything else must be considered invalid, to
> - * avoid turning on new displays on dead connectors.
> - *
> - * Since the connector can be unregistered at any point during an
> - * atomic check or commit, this is racy. But that's OK: all we care
> - * about is ensuring that userspace can't do anything but shut off the
> - * display on a connector that was destroyed after it's been notified,
> - * not before.
> - *
> - * Additionally, we also want to ignore connector registration when
> - * we're trying to restore an atomic state during system resume since
> - * there's a chance the connector may have been destroyed during the
> - * process, but it's better to ignore that then cause
> - * drm_atomic_helper_resume() to fail.
> - */
> - if (!state->duplicated && drm_connector_is_unregistered(connector) &&
> - crtc_state->active) {
> - DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] is not registered\n",
> - connector->base.id, connector->name);
> - return -EINVAL;
> - }
> -
> funcs = connector->helper_private;
>
> if (funcs->atomic_best_encoder)
> @@ -390,6 +363,8 @@ update_connector_routing(struct drm_atomic_state *state,
>
> set_best_encoder(state, new_connector_state, new_encoder);
>
> + crtc_state = drm_atomic_get_new_crtc_state(state,
> +new_connector_state->crtc);
> crtc_state->connectors_changed = true;
>
> DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] using [ENCODER:%d:%s] on
> [CRTC:%d:%s]\n",
> --
> 2.17.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] [igt-dev] [PATCH V2 i-g-t] lib: Drop __kms_addfb() wrapper
Hi Simon,
Thank you very much for your review. I'll fix the issue in the next version.
On Mon, May 20, 2019 at 3:22 AM Ser, Simon wrote:
>
> Hi Rodrigo,
>
> On Sun, 2019-05-19 at 20:00 -0300, Rodrigo Siqueira wrote:
> > The function __kms_addfb() and drmModeAddFB2WithModifiers() have a
> > similar code. Due to this similarity, this commit replaces all the
> > occurrences of __kms_addfb() by drmModeAddFB2WithModifiers() and adds
> > the required adaptations.
> >
> > V1: Arkadiusz Hiler
> > - Fix array initialization
> > - Drop __kms_addfb()
> >
> > Signed-off-by: Rodrigo Siqueira
> > ---
> > lib/igt_fb.c| 14 +-
> > lib/ioctl_wrappers.c| 33 -
> > lib/ioctl_wrappers.h| 11 ---
> > tests/kms_available_modes_crc.c | 14 +-
> > tests/kms_draw_crc.c| 10 ++
> > tests/prime_vgem.c | 14 --
> > 6 files changed, 32 insertions(+), 64 deletions(-)
> >
> > diff --git a/lib/igt_fb.c b/lib/igt_fb.c
> > index d4929019..bac3b21c 100644
> > --- a/lib/igt_fb.c
> > +++ b/lib/igt_fb.c
> > @@ -1235,6 +1235,9 @@ igt_create_fb_with_bo_size(int fd, int width, int
> > height,
> > struct igt_fb *fb, uint64_t bo_size,
> > unsigned bo_stride)
> > {
> > + uint32_t handles[4] = {};
> > + uint64_t modifiers[4] = {};
> > +
> > /* FIXME allow the caller to pass these in */
> > enum igt_color_encoding color_encoding = IGT_COLOR_YCBCR_BT709;
> > enum igt_color_range color_range = IGT_COLOR_YCBCR_LIMITED_RANGE;
> > @@ -1262,11 +1265,12 @@ igt_create_fb_with_bo_size(int fd, int width, int
> > height,
> > if (fb->modifier || igt_has_fb_modifiers(fd))
> > flags = LOCAL_DRM_MODE_FB_MODIFIERS;
> >
> > - do_or_die(__kms_addfb(fb->fd, fb->gem_handle,
> > - fb->width, fb->height,
> > - fb->drm_format, fb->modifier,
> > - fb->strides, fb->offsets, fb->num_planes, flags,
> > - >fb_id));
> > + memset(handles, fb->gem_handle, fb->num_planes);
> > + memset(modifiers, modifier, fb->num_planes);
>
> memset is only able to fill bytes. This won't work for larger values.
>
> > + do_or_die(drmModeAddFB2WithModifiers(fb->fd, fb->width, fb->height,
> > + fb->drm_format, handles,
> > + fb->strides, fb->offsets,
> > + modifiers, >fb_id, flags));
> >
> > return fb->fb_id;
> > }
> > diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
> > index 280fdd62..0f00971d 100644
> > --- a/lib/ioctl_wrappers.c
> > +++ b/lib/ioctl_wrappers.c
> > @@ -1453,36 +1453,3 @@ void igt_require_fb_modifiers(int fd)
> > {
> > igt_require(igt_has_fb_modifiers(fd));
> > }
> > -
> > -int __kms_addfb(int fd, uint32_t handle,
> > - uint32_t width, uint32_t height,
> > - uint32_t pixel_format, uint64_t modifier,
> > - uint32_t strides[4], uint32_t offsets[4],
> > - int num_planes, uint32_t flags, uint32_t *buf_id)
> > -{
> > - struct drm_mode_fb_cmd2 f;
> > - int ret, i;
> > -
> > - if (flags & DRM_MODE_FB_MODIFIERS)
> > - igt_require_fb_modifiers(fd);
> > -
> > - memset(, 0, sizeof(f));
> > -
> > - f.width = width;
> > - f.height = height;
> > - f.pixel_format = pixel_format;
> > - f.flags = flags;
> > -
> > - for (i = 0; i < num_planes; i++) {
> > - f.handles[i] = handle;
> > - f.modifier[i] = modifier;
> > - f.pitches[i] = strides[i];
> > - f.offsets[i] = offsets[i];
> > - }
> > -
> > - ret = igt_ioctl(fd, DRM_IOCTL_MODE_ADDFB2, );
> > -
> > - *buf_id = f.fb_id;
> > -
> > - return ret < 0 ? -errno : ret;
> > -}
> > diff --git a/lib/ioctl_wrappers.h b/lib/ioctl_wrappers.h
> > index 03211c97..4afc3e09 100644
> > --- a/lib/ioctl_wrappers.h
> > +++ b/lib/ioctl_wrappers.h
> > @@ -209,17 +209,6 @@ struct local_drm_mode_fb_cmd2 {
> > bool igt_has_fb_modifiers(int fd);
> > void igt_require_fb_modifiers(int fd);
> >
> > -/**
> > - * __kms_addfb:
> > - *
> > - * Creates a framebuffer object.
> > - */
> > -int __kms_addfb(int fd, uint32_t handle,
> > - uint32_t width, uint32_t height,
> > - uint32_t pixel_format, uint64_t modifier,
> > - uint32_t strides[4], uint32_t offsets[4],
> > - int num_planes, uint32_t flags, uint32_t *buf_id);
> > -
> > /**
> > * to_user_pointer:
> > *
> > diff --git a/tests/kms_available_modes_crc.c
> > b/tests/kms_available_modes_crc.c
> > index 50b5522a..9e5f1fd5 100644
> > --- a/tests/kms_available_modes_crc.c
> > +++ b/tests/kms_available_modes_crc.c
> > @@ -172,9 +172,10 @@ static bool setup_fb(data_t *data, igt_output_t
> > *output,
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Fix the interpretation of MAX_PRE-EMPHASIS_REACHED bit inorder to pass Link Layer compliance test number 400.3.1.15
== Series Details == Series: drm/i915: Fix the interpretation of MAX_PRE-EMPHASIS_REACHED bit inorder to pass Link Layer compliance test number 400.3.1.15 URL : https://patchwork.freedesktop.org/series/60880/ State : warning == Summary == $ dim checkpatch origin/drm-tip bc6664a25925 drm/i915: Fix the interpretation of MAX_PRE-EMPHASIS_REACHED bit inorder to pass Link Layer compliance test number 400.3.1.15 -:7: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #7: According to DP 1.4 standard, if the source supports four pre-emphasis levels, then the source shall set the bit MAX_PRE-EMPHASIS_REACHED = 1 only when trasmitter programmed PRE-EMPHASIS_SET field (bits 4:3) to 11b (Level 3). Pre-emphasis level 3 is the maximum pre-emphasis level that the source supports. total: 0 errors, 1 warnings, 0 checks, 34 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Fix the interpretation of MAX_PRE-EMPHASIS_REACHED bit inorder to pass Link Layer compliance test number 400.3.1.15
According to DP 1.4 standard, if the source supports four pre-emphasis levels,
then the source shall set the bit MAX_PRE-EMPHASIS_REACHED = 1 only when
trasmitter programmed PRE-EMPHASIS_SET field (bits 4:3) to 11b (Level 3).
Pre-emphasis level 3 is the maximum pre-emphasis level that the source supports.
Currently the MAX_PRE-EMPHASIS_REACHED bit is interpreted as the Max
Pre-Emphasis level for certain Swing Level. This interpretation fails Link
Layer compliance test 400.3.1.15 step 17 according to the following Fail
condition: TRAINING_LANEx_SET.MAX_PRE-EMPHASIS_REACHED = 1 (check all active
lanes) and the Source DUT supports pre-emphasis level 3 (9.5db).
Cc: Clint Taylor
Cc: Manasi Navare
Signed-off-by: Khaled Almahallawy
---
drivers/gpu/drm/i915/intel_ddi.c | 20
drivers/gpu/drm/i915/intel_dp.c | 2 +-
2 files changed, 1 insertion(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 0af47f343faa..6540c979c098 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2239,26 +2239,6 @@ u8 intel_ddi_dp_voltage_max(struct intel_encoder
*encoder)
DP_TRAIN_VOLTAGE_SWING_MASK;
}
-/*
- * We assume that the full set of pre-emphasis values can be
- * used on all DDI platforms. Should that change we need to
- * rethink this code.
- */
-u8 intel_ddi_dp_pre_emphasis_max(struct intel_encoder *encoder, u8
voltage_swing)
-{
- switch (voltage_swing & DP_TRAIN_VOLTAGE_SWING_MASK) {
- case DP_TRAIN_VOLTAGE_SWING_LEVEL_0:
- return DP_TRAIN_PRE_EMPH_LEVEL_3;
- case DP_TRAIN_VOLTAGE_SWING_LEVEL_1:
- return DP_TRAIN_PRE_EMPH_LEVEL_2;
- case DP_TRAIN_VOLTAGE_SWING_LEVEL_2:
- return DP_TRAIN_PRE_EMPH_LEVEL_1;
- case DP_TRAIN_VOLTAGE_SWING_LEVEL_3:
- default:
- return DP_TRAIN_PRE_EMPH_LEVEL_0;
- }
-}
-
static void cnl_ddi_vswing_program(struct intel_encoder *encoder,
int level, enum intel_output_type type)
{
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 77ba4da6b981..f94759e45862 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3541,7 +3541,7 @@ intel_dp_pre_emphasis_max(struct intel_dp *intel_dp, u8
voltage_swing)
enum port port = encoder->port;
if (HAS_DDI(dev_priv)) {
- return intel_ddi_dp_pre_emphasis_max(encoder, voltage_swing);
+ return DP_TRAIN_PRE_EMPH_LEVEL_3;
} else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
switch (voltage_swing & DP_TRAIN_VOLTAGE_SWING_MASK) {
case DP_TRAIN_VOLTAGE_SWING_LEVEL_0:
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/4] mm: Check if mmu notifier callbacks are allowed to fail
== Series Details == Series: series starting with [1/4] mm: Check if mmu notifier callbacks are allowed to fail URL : https://patchwork.freedesktop.org/series/60874/ State : failure == Summary == CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh DESCEND objtool CHK include/generated/compile.h CC kernel/sched/core.o kernel/sched/core.c: In function ‘schedule_debug’: kernel/sched/core.c:3277:33: error: ‘struct task_struct’ has no member named ‘non_blocking_count’; did you mean ‘non_block_count’? prev->comm, prev->pid, prev->non_blocking_count); ^~ non_block_count scripts/Makefile.build:278: recipe for target 'kernel/sched/core.o' failed make[2]: *** [kernel/sched/core.o] Error 1 scripts/Makefile.build:489: recipe for target 'kernel/sched' failed make[1]: *** [kernel/sched] Error 2 Makefile:1071: recipe for target 'kernel' failed make: *** [kernel] Error 2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 18/33] fbdev: make unregister/unlink functions not fail
Hi Daniel,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.2-rc1 next-20190520]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Daniel-Vetter/fbcon-notifier-begone/20190521-021841
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
sparse warnings: (new ones prefixed by >>)
>> drivers/staging/fbtft/fbtft-core.c:894:38: sparse: sparse: incorrect type in
>> return expression (different base types) @@expected int @@got vint @@
>> drivers/staging/fbtft/fbtft-core.c:894:38: sparse:expected int
>> drivers/staging/fbtft/fbtft-core.c:894:38: sparse:got void
--
>> drivers/media/pci/ivtv/ivtvfb.c:1261:43: sparse: sparse: incorrect type in
>> conditional (non-scalar type)
>> drivers/media/pci/ivtv/ivtvfb.c:1261:43: sparse:got void
--
>> drivers/video/fbdev/neofb.c:2130:43: sparse: sparse: incorrect type in
>> conditional (non-scalar type)
>> drivers/video/fbdev/neofb.c:2130:43: sparse:got void
--
>> drivers/video/fbdev/savage/savagefb_driver.c:2341:43: sparse: sparse:
>> incorrect type in conditional (non-scalar type)
>> drivers/video/fbdev/savage/savagefb_driver.c:2341:43: sparse:got void
vim +894 drivers/staging/fbtft/fbtft-core.c
c296d5f9 Thomas Petazzoni 2014-12-31 877
c296d5f9 Thomas Petazzoni 2014-12-31 878 /**
c296d5f9 Thomas Petazzoni 2014-12-31 879 * fbtft_unregister_framebuffer -
releases a tft frame buffer device
c296d5f9 Thomas Petazzoni 2014-12-31 880 * @fb_info: frame buffer info
structure
c296d5f9 Thomas Petazzoni 2014-12-31 881 *
c296d5f9 Thomas Petazzoni 2014-12-31 882 * Frees SPI driverdata if needed
c296d5f9 Thomas Petazzoni 2014-12-31 883 * Frees gpios.
c296d5f9 Thomas Petazzoni 2014-12-31 884 * Unregisters frame buffer device.
c296d5f9 Thomas Petazzoni 2014-12-31 885 *
c296d5f9 Thomas Petazzoni 2014-12-31 886 */
c296d5f9 Thomas Petazzoni 2014-12-31 887 int
fbtft_unregister_framebuffer(struct fb_info *fb_info)
c296d5f9 Thomas Petazzoni 2014-12-31 888 {
c296d5f9 Thomas Petazzoni 2014-12-31 889 struct fbtft_par *par =
fb_info->par;
c296d5f9 Thomas Petazzoni 2014-12-31 890
c296d5f9 Thomas Petazzoni 2014-12-31 891 if
(par->fbtftops.unregister_backlight)
c296d5f9 Thomas Petazzoni 2014-12-31 892
par->fbtftops.unregister_backlight(par);
c296d5f9 Thomas Petazzoni 2014-12-31 893 fbtft_sysfs_exit(par);
11107ffe Aya Mahfouz 2015-02-27 @894 return
unregister_framebuffer(fb_info);
c296d5f9 Thomas Petazzoni 2014-12-31 895 }
c296d5f9 Thomas Petazzoni 2014-12-31 896
EXPORT_SYMBOL(fbtft_unregister_framebuffer);
c296d5f9 Thomas Petazzoni 2014-12-31 897
:: The code at line 894 was first introduced by commit
:: 11107ffe2cd1c1dc5948713fc08a1372185be0d5 staging: fbtft: remove unused
variable
:: TO: Aya Mahfouz
:: CC: Greg Kroah-Hartman
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] mm, notifier: Add a lockdep map for invalidate_range_start
This is a similar idea to the fs_reclaim fake lockdep lock. It's
fairly easy to provoke a specific notifier to be run on a specific
range: Just prep it, and then munmap() it.
A bit harder, but still doable, is to provoke the mmu notifiers for
all the various callchains that might lead to them. But both at the
same time is really hard to reliable hit, especially when you want to
exercise paths like direct reclaim or compaction, where it's not
easy to control what exactly will be unmapped.
By introducing a lockdep map to tie them all together we allow lockdep
to see a lot more dependencies, without having to actually hit them
in a single challchain while testing.
Aside: Since I typed this to test i915 mmu notifiers I've only rolled
this out for the invaliate_range_start callback. If there's
interest, we should probably roll this out to all of them. But my
undestanding of core mm is seriously lacking, and I'm not clear on
whether we need a lockdep map for each callback, or whether some can
be shared.
v2: Use lock_map_acquire/release() like fs_reclaim, to avoid confusion
with this being a real mutex (Chris Wilson).
v3: Rebase on top of Glisse's arg rework.
Cc: Chris Wilson
Cc: Andrew Morton
Cc: David Rientjes
Cc: "Jérôme Glisse"
Cc: Michal Hocko
Cc: "Christian König"
Cc: Greg Kroah-Hartman
Cc: Daniel Vetter
Cc: Mike Rapoport
Cc: linux...@kvack.org
Signed-off-by: Daniel Vetter
---
include/linux/mmu_notifier.h | 6 ++
mm/mmu_notifier.c| 7 +++
2 files changed, 13 insertions(+)
diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
index b6c004bd9f6a..9dd38c32fc53 100644
--- a/include/linux/mmu_notifier.h
+++ b/include/linux/mmu_notifier.h
@@ -42,6 +42,10 @@ enum mmu_notifier_event {
#ifdef CONFIG_MMU_NOTIFIER
+#ifdef CONFIG_LOCKDEP
+extern struct lockdep_map __mmu_notifier_invalidate_range_start_map;
+#endif
+
/*
* The mmu notifier_mm structure is allocated and installed in
* mm->mmu_notifier_mm inside the mm_take_all_locks() protected
@@ -310,10 +314,12 @@ static inline void mmu_notifier_change_pte(struct
mm_struct *mm,
static inline void
mmu_notifier_invalidate_range_start(struct mmu_notifier_range *range)
{
+ lock_map_acquire(&__mmu_notifier_invalidate_range_start_map);
if (mm_has_notifiers(range->mm)) {
range->flags |= MMU_NOTIFIER_RANGE_BLOCKABLE;
__mmu_notifier_invalidate_range_start(range);
}
+ lock_map_release(&__mmu_notifier_invalidate_range_start_map);
}
static inline int
diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
index a09e737711d5..33bdaddfb9b1 100644
--- a/mm/mmu_notifier.c
+++ b/mm/mmu_notifier.c
@@ -23,6 +23,13 @@
/* global SRCU for all MMs */
DEFINE_STATIC_SRCU(srcu);
+#ifdef CONFIG_LOCKDEP
+struct lockdep_map __mmu_notifier_invalidate_range_start_map = {
+ .name = "mmu_notifier_invalidate_range_start"
+};
+EXPORT_SYMBOL_GPL(__mmu_notifier_invalidate_range_start_map);
+#endif
+
/*
* This function allows mmu_notifier::release callback to delay a call to
* a function that will free appropriate resources. The function must be
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] kernel.h: Add non_block_start/end()
In some special cases we must not block, but there's not a
spinlock, preempt-off, irqs-off or similar critical section already
that arms the might_sleep() debug checks. Add a non_block_start/end()
pair to annotate these.
This will be used in the oom paths of mmu-notifiers, where blocking is
not allowed to make sure there's forward progress. Quoting Michal:
"The notifier is called from quite a restricted context - oom_reaper -
which shouldn't depend on any locks or sleepable conditionals. The code
should be swift as well but we mostly do care about it to make a forward
progress. Checking for sleepable context is the best thing we could come
up with that would describe these demands at least partially."
Peter also asked whether we want to catch spinlocks on top, but Michal
said those are less of a problem because spinlocks can't have an
indirect dependency upon the page allocator and hence close the loop
with the oom reaper.
Suggested by Michal Hocko.
v2:
- Improve commit message (Michal)
- Also check in schedule, not just might_sleep (Peter)
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Andrew Morton
Cc: Michal Hocko
Cc: David Rientjes
Cc: "Christian König"
Cc: Daniel Vetter
Cc: "Jérôme Glisse"
Cc: linux...@kvack.org
Cc: Masahiro Yamada
Cc: Wei Wang
Cc: Andy Shevchenko
Cc: Thomas Gleixner
Cc: Jann Horn
Cc: Feng Tang
Cc: Kees Cook
Cc: Randy Dunlap
Cc: linux-ker...@vger.kernel.org
Acked-by: Christian König
Signed-off-by: Daniel Vetter
---
include/linux/kernel.h | 10 +-
include/linux/sched.h | 4
kernel/sched/core.c| 19 ++-
3 files changed, 27 insertions(+), 6 deletions(-)
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 74b1ee9027f5..b5f2c2ff0eab 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -214,7 +214,9 @@ extern void __cant_sleep(const char *file, int line, int
preempt_offset);
* might_sleep - annotation for functions that can sleep
*
* this macro will print a stack trace if it is executed in an atomic
- * context (spinlock, irq-handler, ...).
+ * context (spinlock, irq-handler, ...). Additional sections where blocking is
+ * not allowed can be annotated with non_block_start() and non_block_end()
+ * pairs.
*
* This is a useful debugging help to be able to catch problems early and not
* be bitten later when the calling function happens to sleep when it is not
@@ -230,6 +232,10 @@ extern void __cant_sleep(const char *file, int line, int
preempt_offset);
# define cant_sleep() \
do { __cant_sleep(__FILE__, __LINE__, 0); } while (0)
# define sched_annotate_sleep()(current->task_state_change = 0)
+# define non_block_start() \
+ do { current->non_block_count++; } while (0)
+# define non_block_end() \
+ do { WARN_ON(current->non_block_count-- == 0); } while (0)
#else
static inline void ___might_sleep(const char *file, int line,
int preempt_offset) { }
@@ -238,6 +244,8 @@ extern void __cant_sleep(const char *file, int line, int
preempt_offset);
# define might_sleep() do { might_resched(); } while (0)
# define cant_sleep() do { } while (0)
# define sched_annotate_sleep() do { } while (0)
+# define non_block_start() do { } while (0)
+# define non_block_end() do { } while (0)
#endif
#define might_sleep_if(cond) do { if (cond) might_sleep(); } while (0)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 11837410690f..7f5b293e72df 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -908,6 +908,10 @@ struct task_struct {
struct mutex_waiter *blocked_on;
#endif
+#ifdef CONFIG_DEBUG_ATOMIC_SLEEP
+ int non_block_count;
+#endif
+
#ifdef CONFIG_TRACE_IRQFLAGS
unsigned intirq_events;
unsigned long hardirq_enable_ip;
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 102dfcf0a29a..dd08d423947d 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3264,13 +3264,22 @@ static noinline void __schedule_bug(struct task_struct
*prev)
/*
* Various schedule()-time debugging checks and statistics:
*/
-static inline void schedule_debug(struct task_struct *prev)
+static inline void schedule_debug(struct task_struct *prev, bool preempt)
{
#ifdef CONFIG_SCHED_STACK_END_CHECK
if (task_stack_end_corrupted(prev))
panic("corrupted stack end detected inside scheduler\n");
#endif
+#ifdef CONFIG_DEBUG_ATOMIC_SLEEP
+ if (!preempt && prev->state && prev->non_block_count) {
+ printk(KERN_ERR "BUG: scheduling in a non-blocking section:
%s/%d/%i\n",
+ prev->comm, prev->pid, prev->non_blocking_count);
+ dump_stack();
+ add_taint(TAINT_WARN, LOCKDEP_STILL_OK);
+ }
+#endif
+
if (unlikely(in_atomic_preempt_off())) {
__schedule_bug(prev);
[Intel-gfx] [PATCH 1/4] mm: Check if mmu notifier callbacks are allowed to fail
Just a bit of paranoia, since if we start pushing this deep into
callchains it's hard to spot all places where an mmu notifier
implementation might fail when it's not allowed to.
Inspired by some confusion we had discussing i915 mmu notifiers and
whether we could use the newly-introduced return value to handle some
corner cases. Until we realized that these are only for when a task
has been killed by the oom reaper.
An alternative approach would be to split the callback into two
versions, one with the int return value, and the other with void
return value like in older kernels. But that's a lot more churn for
fairly little gain I think.
Summary from the m-l discussion on why we want something at warning
level: This allows automated tooling in CI to catch bugs without
humans having to look at everything. If we just upgrade the existing
pr_info to a pr_warn, then we'll have false positives. And as-is, no
one will ever spot the problem since it's lost in the massive amounts
of overall dmesg noise.
v2: Drop the full WARN_ON backtrace in favour of just a pr_warn for
the problematic case (Michal Hocko).
v3: Rebase on top of Glisse's arg rework.
v4: More rebase on top of Glisse reworking everything.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "Christian König"
Cc: David Rientjes
Cc: Daniel Vetter
Cc: "Jérôme Glisse"
Cc: linux...@kvack.org
Cc: Paolo Bonzini
Reviewed-by: Christian König
Signed-off-by: Daniel Vetter
---
mm/mmu_notifier.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
index ee36068077b6..c05e406a7cd7 100644
--- a/mm/mmu_notifier.c
+++ b/mm/mmu_notifier.c
@@ -181,6 +181,9 @@ int __mmu_notifier_invalidate_range_start(struct
mmu_notifier_range *range)
pr_info("%pS callback failed with %d in
%sblockable context.\n",
mn->ops->invalidate_range_start, _ret,
!mmu_notifier_range_blockable(range) ?
"non-" : "");
+ if (!mmu_notifier_range_blockable(range))
+ pr_warn("%pS callback failure not
allowed\n",
+
mn->ops->invalidate_range_start);
ret = _ret;
}
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] mm, notifier: Catch sleeping/blocking for !blockable
We need to make sure implementations don't cheat and don't have a
possible schedule/blocking point deeply burried where review can't
catch it.
I'm not sure whether this is the best way to make sure all the
might_sleep() callsites trigger, and it's a bit ugly in the code flow.
But it gets the job done.
Inspired by an i915 patch series which did exactly that, because the
rules haven't been entirely clear to us.
v2: Use the shiny new non_block_start/end annotations instead of
abusing preempt_disable/enable.
v3: Rebase on top of Glisse's arg rework.
v4: Rebase on top of more Glisse rework.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: David Rientjes
Cc: "Christian König"
Cc: Daniel Vetter
Cc: "Jérôme Glisse"
Cc: linux...@kvack.org
Reviewed-by: Christian König
Signed-off-by: Daniel Vetter
---
mm/mmu_notifier.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
index c05e406a7cd7..a09e737711d5 100644
--- a/mm/mmu_notifier.c
+++ b/mm/mmu_notifier.c
@@ -176,7 +176,13 @@ int __mmu_notifier_invalidate_range_start(struct
mmu_notifier_range *range)
id = srcu_read_lock();
hlist_for_each_entry_rcu(mn, >mm->mmu_notifier_mm->list, hlist) {
if (mn->ops->invalidate_range_start) {
- int _ret = mn->ops->invalidate_range_start(mn, range);
+ int _ret;
+
+ if (!mmu_notifier_range_blockable(range))
+ non_block_start();
+ _ret = mn->ops->invalidate_range_start(mn, range);
+ if (!mmu_notifier_range_blockable(range))
+ non_block_end();
if (_ret) {
pr_info("%pS callback failed with %d in
%sblockable context.\n",
mn->ops->invalidate_range_start, _ret,
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: We don't need display's suspend/resume operations when !HAS_DISPLAY
On Sun, 2019-05-19 at 21:56 -0700, Rodrigo Vivi wrote:
> Suspend resume is broken if we try to enable/disable dc9 on
> cases with disabled displays.
>
Reviewed-by: José Roberto de Souza
> Cc: José Roberto de Souza
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_drv.c | 103 ++--
>
> 1 file changed, 71 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c
> b/drivers/gpu/drm/i915/i915_drv.c
> index 2c7a4318d13c..90693327065a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -2117,6 +2117,15 @@ get_suspend_mode(struct drm_i915_private
> *dev_priv, bool hibernate)
> return I915_DRM_SUSPEND_MEM;
> }
>
> +static void intel_display_suspend_late(struct drm_i915_private
> *dev_priv)
> +{
> + if (!HAS_DISPLAY(dev_priv))
> + return;
> +
> + if (INTEL_GEN(dev_priv) >= 11 || IS_GEN9_LP(dev_priv))
> + bxt_enable_dc9(dev_priv);
> +}
> +
> static int i915_drm_suspend_late(struct drm_device *dev, bool
> hibernation)
> {
> struct drm_i915_private *dev_priv = to_i915(dev);
> @@ -2132,10 +2141,10 @@ static int i915_drm_suspend_late(struct
> drm_device *dev, bool hibernation)
> intel_power_domains_suspend(dev_priv,
> get_suspend_mode(dev_priv,
> hibernation));
>
> + intel_display_suspend_late(dev_priv);
> +
> ret = 0;
> - if (INTEL_GEN(dev_priv) >= 11 || IS_GEN9_LP(dev_priv))
> - bxt_enable_dc9(dev_priv);
> - else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
> + if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
> hsw_enable_pc8(dev_priv);
> else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> ret = vlv_suspend_complete(dev_priv);
> @@ -2265,6 +2274,17 @@ static int i915_drm_resume(struct drm_device
> *dev)
> return 0;
> }
>
> +static void intel_display_resume_early(struct drm_i915_private
> *dev_priv)
> +{
> + if (!HAS_DISPLAY(dev_priv))
> + return;
> +
> + if (INTEL_GEN(dev_priv) >= 11 || IS_GEN9_LP(dev_priv)) {
> + gen9_sanitize_dc_state(dev_priv);
> + bxt_disable_dc9(dev_priv);
> + }
> +}
> +
> static int i915_drm_resume_early(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = to_i915(dev);
> @@ -2327,10 +2347,9 @@ static int i915_drm_resume_early(struct
> drm_device *dev)
>
> i915_check_and_clear_faults(dev_priv);
>
> - if (INTEL_GEN(dev_priv) >= 11 || IS_GEN9_LP(dev_priv)) {
> - gen9_sanitize_dc_state(dev_priv);
> - bxt_disable_dc9(dev_priv);
> - } else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
> + intel_display_resume_early(dev_priv);
> +
> + if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
> hsw_disable_pc8(dev_priv);
> }
>
> @@ -2868,6 +2887,20 @@ static int vlv_resume_prepare(struct
> drm_i915_private *dev_priv,
> return ret;
> }
>
> +static void intel_runtime_display_suspend(struct drm_i915_private
> *dev_priv)
> +{
> + if (!HAS_DISPLAY(dev_priv))
> + return;
> +
> + if (INTEL_GEN(dev_priv) >= 11) {
> + icl_display_core_uninit(dev_priv);
> + bxt_enable_dc9(dev_priv);
> + } else if (IS_GEN9_LP(dev_priv)) {
> + bxt_display_core_uninit(dev_priv);
> + bxt_enable_dc9(dev_priv);
> + }
> +}
> +
> static int intel_runtime_suspend(struct device *kdev)
> {
> struct pci_dev *pdev = to_pci_dev(kdev);
> @@ -2897,14 +2930,10 @@ static int intel_runtime_suspend(struct
> device *kdev)
>
> intel_uncore_suspend(_priv->uncore);
>
> + intel_runtime_display_suspend(dev_priv);
> +
> ret = 0;
> - if (INTEL_GEN(dev_priv) >= 11) {
> - icl_display_core_uninit(dev_priv);
> - bxt_enable_dc9(dev_priv);
> - } else if (IS_GEN9_LP(dev_priv)) {
> - bxt_display_core_uninit(dev_priv);
> - bxt_enable_dc9(dev_priv);
> - } else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
> + if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
> hsw_enable_pc8(dev_priv);
> } else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> {
> ret = vlv_suspend_complete(dev_priv);
> @@ -2966,6 +2995,31 @@ static int intel_runtime_suspend(struct device
> *kdev)
> return 0;
> }
>
> +static void intel_runtime_display_resume(struct drm_i915_private
> *dev_priv)
> +{
> + if (!HAS_DISPLAY(dev_priv))
> + return;
> +
> + if (INTEL_GEN(dev_priv) >= 11) {
> + bxt_disable_dc9(dev_priv);
> + icl_display_core_init(dev_priv, true);
> + if (dev_priv->csr.dmc_payload) {
> + if (dev_priv->csr.allowed_dc_mask &
> + DC_STATE_EN_UPTO_DC6)
> + skl_enable_dc6(dev_priv);
> +
Re: [Intel-gfx] [PATCH] drm: Allow modeset on unregisted connectors unconditionally
On Mon, May 20, 2019 at 10:59:35PM +0200, Daniel Vetter wrote: > On Mon, May 20, 2019 at 10:51 PM Imre Deak wrote: > > > > On Mon, May 20, 2019 at 10:15:20PM +0200, Daniel Vetter wrote: > > > On Mon, May 20, 2019 at 10:06 PM Imre Deak wrote: > > > > On Mon, May 20, 2019 at 09:23:00PM +0200, Daniel Vetter wrote: > > > > > On Mon, May 20, 2019 at 10:09:24PM +0300, Imre Deak wrote: > > > > > > On Mon, May 20, 2019 at 08:37:46PM +0200, Daniel Vetter wrote: > > > > > > > On Mon, May 20, 2019 at 08:41:09PM +0300, Imre Deak wrote: > > > > > > > > We allowed modesetting an unregistered connector only in the > > > > > > > > case the > > > > > > > > mode is getting disabled on the connector. > > > > > > > > > > > > > > > > The reason for this check was the lack of proper refcounting > > > > > > > > for the > > > > > > > > backing memory objects. That problem has been solved meanwhile > > > > > > > > so there > > > > > > > > is no reason any more to reject the modesetting in general. > > > > > > > > > > > > > > I'm not parsing this at all ... maybe references to the commits > > > > > > > that fix > > > > > > > this? Or do you mean the refcounting work for all the things > > > > > > > hanging of > > > > > > > connectors, including the entire mst tree? > > > > > > > > > > > > Yes the check was added to solve the issue related to the removal > > > > > > of MST > > > > > > connectors that could happen asynchronously wrt. a modeset > > > > > > referring to > > > > > > that MST connector. That could happen since the MST core doesn't > > > > > > hold > > > > > > any locks (for instance the connection_mutex) during removing an MST > > > > > > connector that would prevent doing a modeset at the same time. > > > > > > > > > > > > Adding the refcounting for such MST connectors (via the > > > > > > drm_connector_get()/drm_connector_put()) got rid of the above > > > > > > problem. > > > > > > > > > > We added the check way after that stuff landed. Before all the > > > > > connector > > > > > reworking connectors were forcefully disabled by the kernel. The idea > > > > > behind this check is to make sure that that userspace notices a > > > > > connector > > > > > is gone (only thing that's not allowed is enabling it, you can keep > > > > > pageflipping). I think we've always had behaviour like ever since mst > > > > > (all > > > > > userspace has some "oops mst connector probably gone" failure catching > > > > > around modesets). > > > > > > > > Right, pageflipping works. > > > > > > > > > So no idea what all blows up if we stop catching userspace this way. > > > > > > > > > > Now very much possible I'm getting all this wrong again or missing > > > > > something, this stuff is often way over my head. But I'm really vary > > > > > of > > > > > breaking userspace here. E.g. just the drm_connector_get/put lifetime > > > > > changes results in some userspace breaking if you unplug/replug fast > > > > > enough, because then it doesn't notice the connector change anymore. I > > > > > couldn't figure out a way to paper over that regression without > > > > > reintroduce the rather broken and oops-prone old connector lifetime > > > > > management. > > > > > > > > Yes, but what is the the actual description of the failing scenario? I > > > > can't see how anything can go wrong without this check. The resume time > > > > restoration modeset may have to act in the same way on an old connector. > > > > > > That's what the !state->duplicated thing is meant to check for btw. > > > > > > > I don't understand how userspace would not notice the connector change. > > > > It will get a hotplug uevent in response to which it would have to do a > > > > detect which returns to it the updated information about the new MST > > > > connector tree. > > > > > > uevent handling can take positively forever, at which point the new > > > connector could already be plugged in, and then userspace makes a mess > > > aliasing the two since the path property matches. Just needs a wobbly > > > cable. This is the issue with the "fixed" lifetime management, and I'm > > > wary of breaking more stuff. > > > > Yea, processing can be delayed arbitrarily, the corresponding > > GETRESOURCES/GETCONNECTOR should still return to the userspace the > > correct information to do right thing, even if the path property > > matches: the connector ID for the old and new connector will be > > different and the GETCONNECTOR for the old ID will return properly that > > this old connector is already disconnected (see intel_dp_mst_detect()). > > So I don't see how userspace could mess up things. Obviously if user > > space is buggy, then well, it is just buggy and then that user space bug > > would need to be fixed instead of papering over such problems in the > > kernel. > > Uh that's not how this "kernel change caused a regression" thing > works. Dave just dropped a rant about this and i915 recently ... I still don't see what would depend on the current behavior instead
Re: [Intel-gfx] [PATCH] drm: Allow modeset on unregisted connectors unconditionally
On Mon, May 20, 2019 at 10:51 PM Imre Deak wrote: > > On Mon, May 20, 2019 at 10:15:20PM +0200, Daniel Vetter wrote: > > On Mon, May 20, 2019 at 10:06 PM Imre Deak wrote: > > > On Mon, May 20, 2019 at 09:23:00PM +0200, Daniel Vetter wrote: > > > > On Mon, May 20, 2019 at 10:09:24PM +0300, Imre Deak wrote: > > > > > On Mon, May 20, 2019 at 08:37:46PM +0200, Daniel Vetter wrote: > > > > > > On Mon, May 20, 2019 at 08:41:09PM +0300, Imre Deak wrote: > > > > > > > We allowed modesetting an unregistered connector only in the case > > > > > > > the > > > > > > > mode is getting disabled on the connector. > > > > > > > > > > > > > > The reason for this check was the lack of proper refcounting for > > > > > > > the > > > > > > > backing memory objects. That problem has been solved meanwhile so > > > > > > > there > > > > > > > is no reason any more to reject the modesetting in general. > > > > > > > > > > > > I'm not parsing this at all ... maybe references to the commits > > > > > > that fix > > > > > > this? Or do you mean the refcounting work for all the things > > > > > > hanging of > > > > > > connectors, including the entire mst tree? > > > > > > > > > > Yes the check was added to solve the issue related to the removal of > > > > > MST > > > > > connectors that could happen asynchronously wrt. a modeset referring > > > > > to > > > > > that MST connector. That could happen since the MST core doesn't hold > > > > > any locks (for instance the connection_mutex) during removing an MST > > > > > connector that would prevent doing a modeset at the same time. > > > > > > > > > > Adding the refcounting for such MST connectors (via the > > > > > drm_connector_get()/drm_connector_put()) got rid of the above problem. > > > > > > > > We added the check way after that stuff landed. Before all the connector > > > > reworking connectors were forcefully disabled by the kernel. The idea > > > > behind this check is to make sure that that userspace notices a > > > > connector > > > > is gone (only thing that's not allowed is enabling it, you can keep > > > > pageflipping). I think we've always had behaviour like ever since mst > > > > (all > > > > userspace has some "oops mst connector probably gone" failure catching > > > > around modesets). > > > > > > Right, pageflipping works. > > > > > > > So no idea what all blows up if we stop catching userspace this way. > > > > > > > > Now very much possible I'm getting all this wrong again or missing > > > > something, this stuff is often way over my head. But I'm really vary of > > > > breaking userspace here. E.g. just the drm_connector_get/put lifetime > > > > changes results in some userspace breaking if you unplug/replug fast > > > > enough, because then it doesn't notice the connector change anymore. I > > > > couldn't figure out a way to paper over that regression without > > > > reintroduce the rather broken and oops-prone old connector lifetime > > > > management. > > > > > > Yes, but what is the the actual description of the failing scenario? I > > > can't see how anything can go wrong without this check. The resume time > > > restoration modeset may have to act in the same way on an old connector. > > > > That's what the !state->duplicated thing is meant to check for btw. > > > > > I don't understand how userspace would not notice the connector change. > > > It will get a hotplug uevent in response to which it would have to do a > > > detect which returns to it the updated information about the new MST > > > connector tree. > > > > uevent handling can take positively forever, at which point the new > > connector could already be plugged in, and then userspace makes a mess > > aliasing the two since the path property matches. Just needs a wobbly > > cable. This is the issue with the "fixed" lifetime management, and I'm > > wary of breaking more stuff. > > Yea, processing can be delayed arbitrarily, the corresponding > GETRESOURCES/GETCONNECTOR should still return to the userspace the > correct information to do right thing, even if the path property > matches: the connector ID for the old and new connector will be > different and the GETCONNECTOR for the old ID will return properly that > this old connector is already disconnected (see intel_dp_mst_detect()). > So I don't see how userspace could mess up things. Obviously if user > space is buggy, then well, it is just buggy and then that user space bug > would need to be fixed instead of papering over such problems in the > kernel. Uh that's not how this "kernel change caused a regression" thing works. Dave just dropped a rant about this and i915 recently ... > > Other way round: What do we gain if userspace is allowed to turn on a > > connector again which doesn't exist and will not ever show any pixels? > > I'm not seeing a benefit here in allowing that. And history says we > > change something around mst handling, it'll break something somewhere. > > Let's then describe the actual reason for this check,
Re: [Intel-gfx] [PATCH] drm: Allow modeset on unregisted connectors unconditionally
On Mon, May 20, 2019 at 10:15:20PM +0200, Daniel Vetter wrote: > On Mon, May 20, 2019 at 10:06 PM Imre Deak wrote: > > On Mon, May 20, 2019 at 09:23:00PM +0200, Daniel Vetter wrote: > > > On Mon, May 20, 2019 at 10:09:24PM +0300, Imre Deak wrote: > > > > On Mon, May 20, 2019 at 08:37:46PM +0200, Daniel Vetter wrote: > > > > > On Mon, May 20, 2019 at 08:41:09PM +0300, Imre Deak wrote: > > > > > > We allowed modesetting an unregistered connector only in the case > > > > > > the > > > > > > mode is getting disabled on the connector. > > > > > > > > > > > > The reason for this check was the lack of proper refcounting for the > > > > > > backing memory objects. That problem has been solved meanwhile so > > > > > > there > > > > > > is no reason any more to reject the modesetting in general. > > > > > > > > > > I'm not parsing this at all ... maybe references to the commits that > > > > > fix > > > > > this? Or do you mean the refcounting work for all the things hanging > > > > > of > > > > > connectors, including the entire mst tree? > > > > > > > > Yes the check was added to solve the issue related to the removal of MST > > > > connectors that could happen asynchronously wrt. a modeset referring to > > > > that MST connector. That could happen since the MST core doesn't hold > > > > any locks (for instance the connection_mutex) during removing an MST > > > > connector that would prevent doing a modeset at the same time. > > > > > > > > Adding the refcounting for such MST connectors (via the > > > > drm_connector_get()/drm_connector_put()) got rid of the above problem. > > > > > > We added the check way after that stuff landed. Before all the connector > > > reworking connectors were forcefully disabled by the kernel. The idea > > > behind this check is to make sure that that userspace notices a connector > > > is gone (only thing that's not allowed is enabling it, you can keep > > > pageflipping). I think we've always had behaviour like ever since mst (all > > > userspace has some "oops mst connector probably gone" failure catching > > > around modesets). > > > > Right, pageflipping works. > > > > > So no idea what all blows up if we stop catching userspace this way. > > > > > > Now very much possible I'm getting all this wrong again or missing > > > something, this stuff is often way over my head. But I'm really vary of > > > breaking userspace here. E.g. just the drm_connector_get/put lifetime > > > changes results in some userspace breaking if you unplug/replug fast > > > enough, because then it doesn't notice the connector change anymore. I > > > couldn't figure out a way to paper over that regression without > > > reintroduce the rather broken and oops-prone old connector lifetime > > > management. > > > > Yes, but what is the the actual description of the failing scenario? I > > can't see how anything can go wrong without this check. The resume time > > restoration modeset may have to act in the same way on an old connector. > > That's what the !state->duplicated thing is meant to check for btw. > > > I don't understand how userspace would not notice the connector change. > > It will get a hotplug uevent in response to which it would have to do a > > detect which returns to it the updated information about the new MST > > connector tree. > > uevent handling can take positively forever, at which point the new > connector could already be plugged in, and then userspace makes a mess > aliasing the two since the path property matches. Just needs a wobbly > cable. This is the issue with the "fixed" lifetime management, and I'm > wary of breaking more stuff. Yea, processing can be delayed arbitrarily, the corresponding GETRESOURCES/GETCONNECTOR should still return to the userspace the correct information to do right thing, even if the path property matches: the connector ID for the old and new connector will be different and the GETCONNECTOR for the old ID will return properly that this old connector is already disconnected (see intel_dp_mst_detect()). So I don't see how userspace could mess up things. Obviously if user space is buggy, then well, it is just buggy and then that user space bug would need to be fixed instead of papering over such problems in the kernel. > Other way round: What do we gain if userspace is allowed to turn on a > connector again which doesn't exist and will not ever show any pixels? > I'm not seeing a benefit here in allowing that. And history says we > change something around mst handling, it'll break something somewhere. Let's then describe the actual reason for this check, that description is missing. We should remove this check to simplify things if there isn't an actual need for it. Userspace can do already a modeset on connectors in general that are not in a connected state. So this special casing - for MST connectors only - is a bad idea if there is no reason for special casing it. If it's there to paper over some user space bug that user space bug should be
Re: [Intel-gfx] [PATCH] drm: Allow modeset on unregisted connectors unconditionally
On Mon, May 20, 2019 at 10:06 PM Imre Deak wrote: > On Mon, May 20, 2019 at 09:23:00PM +0200, Daniel Vetter wrote: > > On Mon, May 20, 2019 at 10:09:24PM +0300, Imre Deak wrote: > > > On Mon, May 20, 2019 at 08:37:46PM +0200, Daniel Vetter wrote: > > > > On Mon, May 20, 2019 at 08:41:09PM +0300, Imre Deak wrote: > > > > > We allowed modesetting an unregistered connector only in the case the > > > > > mode is getting disabled on the connector. > > > > > > > > > > The reason for this check was the lack of proper refcounting for the > > > > > backing memory objects. That problem has been solved meanwhile so > > > > > there > > > > > is no reason any more to reject the modesetting in general. > > > > > > > > I'm not parsing this at all ... maybe references to the commits that fix > > > > this? Or do you mean the refcounting work for all the things hanging of > > > > connectors, including the entire mst tree? > > > > > > Yes the check was added to solve the issue related to the removal of MST > > > connectors that could happen asynchronously wrt. a modeset referring to > > > that MST connector. That could happen since the MST core doesn't hold > > > any locks (for instance the connection_mutex) during removing an MST > > > connector that would prevent doing a modeset at the same time. > > > > > > Adding the refcounting for such MST connectors (via the > > > drm_connector_get()/drm_connector_put()) got rid of the above problem. > > > > We added the check way after that stuff landed. Before all the connector > > reworking connectors were forcefully disabled by the kernel. The idea > > behind this check is to make sure that that userspace notices a connector > > is gone (only thing that's not allowed is enabling it, you can keep > > pageflipping). I think we've always had behaviour like ever since mst (all > > userspace has some "oops mst connector probably gone" failure catching > > around modesets). > > Right, pageflipping works. > > > So no idea what all blows up if we stop catching userspace this way. > > > > Now very much possible I'm getting all this wrong again or missing > > something, this stuff is often way over my head. But I'm really vary of > > breaking userspace here. E.g. just the drm_connector_get/put lifetime > > changes results in some userspace breaking if you unplug/replug fast > > enough, because then it doesn't notice the connector change anymore. I > > couldn't figure out a way to paper over that regression without > > reintroduce the rather broken and oops-prone old connector lifetime > > management. > > Yes, but what is the the actual description of the failing scenario? I > can't see how anything can go wrong without this check. The resume time > restoration modeset may have to act in the same way on an old connector. That's what the !state->duplicated thing is meant to check for btw. > I don't understand how userspace would not notice the connector change. > It will get a hotplug uevent in response to which it would have to do a > detect which returns to it the updated information about the new MST > connector tree. uevent handling can take positively forever, at which point the new connector could already be plugged in, and then userspace makes a mess aliasing the two since the path property matches. Just needs a wobbly cable. This is the issue with the "fixed" lifetime management, and I'm wary of breaking more stuff. Other way round: What do we gain if userspace is allowed to turn on a connector again which doesn't exist and will not ever show any pixels? I'm not seeing a benefit here in allowing that. And history says we change something around mst handling, it'll break something somewhere. -Daniel > > > > > > The check > > > > > for that also makes driver internal modesets more cumbersome where we > > > > > need to add exemptions for the cases where we do need to allow the > > > > > modeset even for unregistered connectors. One such case is the > > > > > restoration of the mode during resume. > > > > > > > > Yeah this one actually makes sense to me. We could still keep this check > > > > here, but for the atomic ioctl only when called from userspace. But iirc > > > > Lyude also said she has some plans here, so no idea whether that all > > > > fits. > > > > > > > > > Simplify things by removing the unneeded check. I can't see how > > > > > modesetting an unregistered connector can cause any problem and the > > > > > race > > > > > (described in the code comment) can anyway result in such a modeset > > > > > (if > > > > > the connector is unregistered right after the check). > > > > > > > > Not saying we don't need this, but there's fairly enormous amounts of > > > > history behind all this stuff, and lots of discussions. Would be good to > > > > at least reference those, so we have a good story for when this then all > > > > goes wrong again. > > > > > > I still don't see why this check is needed. There is no justification > > > for it - besides the original reason for it
Re: [Intel-gfx] [PATCH] drm: Allow modeset on unregisted connectors unconditionally
On Mon, May 20, 2019 at 09:23:00PM +0200, Daniel Vetter wrote: > On Mon, May 20, 2019 at 10:09:24PM +0300, Imre Deak wrote: > > On Mon, May 20, 2019 at 08:37:46PM +0200, Daniel Vetter wrote: > > > On Mon, May 20, 2019 at 08:41:09PM +0300, Imre Deak wrote: > > > > We allowed modesetting an unregistered connector only in the case the > > > > mode is getting disabled on the connector. > > > > > > > > The reason for this check was the lack of proper refcounting for the > > > > backing memory objects. That problem has been solved meanwhile so there > > > > is no reason any more to reject the modesetting in general. > > > > > > I'm not parsing this at all ... maybe references to the commits that fix > > > this? Or do you mean the refcounting work for all the things hanging of > > > connectors, including the entire mst tree? > > > > Yes the check was added to solve the issue related to the removal of MST > > connectors that could happen asynchronously wrt. a modeset referring to > > that MST connector. That could happen since the MST core doesn't hold > > any locks (for instance the connection_mutex) during removing an MST > > connector that would prevent doing a modeset at the same time. > > > > Adding the refcounting for such MST connectors (via the > > drm_connector_get()/drm_connector_put()) got rid of the above problem. > > We added the check way after that stuff landed. Before all the connector > reworking connectors were forcefully disabled by the kernel. The idea > behind this check is to make sure that that userspace notices a connector > is gone (only thing that's not allowed is enabling it, you can keep > pageflipping). I think we've always had behaviour like ever since mst (all > userspace has some "oops mst connector probably gone" failure catching > around modesets). Right, pageflipping works. > So no idea what all blows up if we stop catching userspace this way. > > Now very much possible I'm getting all this wrong again or missing > something, this stuff is often way over my head. But I'm really vary of > breaking userspace here. E.g. just the drm_connector_get/put lifetime > changes results in some userspace breaking if you unplug/replug fast > enough, because then it doesn't notice the connector change anymore. I > couldn't figure out a way to paper over that regression without > reintroduce the rather broken and oops-prone old connector lifetime > management. Yes, but what is the the actual description of the failing scenario? I can't see how anything can go wrong without this check. The resume time restoration modeset may have to act in the same way on an old connector. I don't understand how userspace would not notice the connector change. It will get a hotplug uevent in response to which it would have to do a detect which returns to it the updated information about the new MST connector tree. > > > > The check > > > > for that also makes driver internal modesets more cumbersome where we > > > > need to add exemptions for the cases where we do need to allow the > > > > modeset even for unregistered connectors. One such case is the > > > > restoration of the mode during resume. > > > > > > Yeah this one actually makes sense to me. We could still keep this check > > > here, but for the atomic ioctl only when called from userspace. But iirc > > > Lyude also said she has some plans here, so no idea whether that all fits. > > > > > > > Simplify things by removing the unneeded check. I can't see how > > > > modesetting an unregistered connector can cause any problem and the race > > > > (described in the code comment) can anyway result in such a modeset (if > > > > the connector is unregistered right after the check). > > > > > > Not saying we don't need this, but there's fairly enormous amounts of > > > history behind all this stuff, and lots of discussions. Would be good to > > > at least reference those, so we have a good story for when this then all > > > goes wrong again. > > > > I still don't see why this check is needed. There is no justification > > for it - besides the original reason for it as discussed above about the > > refcounting problem, which is solved now - so I think we should remove > > it, instead of just making it a special case for the user space modeset. > > > > As I wrote a user space modeset can end up anyway doing a modeset on an > > unregistered connector when the unregistering - by MST core - happens just > > right after the check. > > Yup. Always been like that. > -Daniel > > > > > > -Daniel > > > > > > > > > > > Cc: Lyude Paul > > > > Cc: Daniel Vetter > > > > Cc: Ville Syrjälä > > > > Signed-off-by: Imre Deak > > > > --- > > > > drivers/gpu/drm/drm_atomic_helper.c | 29 ++--- > > > > 1 file changed, 2 insertions(+), 27 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c > > > > b/drivers/gpu/drm/drm_atomic_helper.c > > > > index 2e0cb4246cbd..e94e69483498 100644 > > > > ---
Re: [Intel-gfx] [PATCH 31/33] fbcon: Call con2fb_map functions directly
Hi Daniel,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.2-rc1 next-20190520]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Daniel-Vetter/fbcon-notifier-begone/20190521-021841
config: alpha-allyesconfig (attached as .config)
compiler: alpha-linux-gcc (GCC) 8.1.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=8.1.0 make.cross ARCH=alpha
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
drivers/video/fbdev/core/fbcon.c: In function 'fbcon_set_con2fb_map_ioctl':
>> drivers/video/fbdev/core/fbcon.c:3323:6: error: implicit declaration of
>> function 'copy_from_user'; did you mean 'sg_copy_from_buffer'?
>> [-Werror=implicit-function-declaration]
if (copy_from_user(, argp, sizeof(con2fb)))
^~
sg_copy_from_buffer
drivers/video/fbdev/core/fbcon.c: In function 'fbcon_get_con2fb_map_ioctl':
drivers/video/fbdev/core/fbcon.c:3356:9: error: implicit declaration of
function 'copy_to_user'; did you mean 'cpu_to_mem'?
[-Werror=implicit-function-declaration]
return copy_to_user(argp, , sizeof(con2fb)) ? -EFAULT : 0;
^~~~
cpu_to_mem
cc1: some warnings being treated as errors
vim +3323 drivers/video/fbdev/core/fbcon.c
3317
3318 int fbcon_set_con2fb_map_ioctl(void __user *argp)
3319 {
3320 struct fb_con2fbmap con2fb;
3321 int ret;
3322
> 3323 if (copy_from_user(, argp, sizeof(con2fb)))
3324 return -EFAULT;
3325 if (con2fb.console < 1 || con2fb.console > MAX_NR_CONSOLES)
3326 return -EINVAL;
3327 if (con2fb.framebuffer >= FB_MAX)
3328 return -EINVAL;
3329 if (!registered_fb[con2fb.framebuffer])
3330 request_module("fb%d", con2fb.framebuffer);
3331 if (!registered_fb[con2fb.framebuffer]) {
3332 return -EINVAL;
}
3334
3335 console_lock();
3336 ret = set_con2fb_map(con2fb.console - 1,
3337 con2fb.framebuffer, 1);
3338 console_unlock();
3339
3340 return ret;
3341 }
3342
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 31/33] fbcon: Call con2fb_map functions directly
Hi Daniel,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.2-rc1 next-20190520]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Daniel-Vetter/fbcon-notifier-begone/20190521-021841
config: sparc64-allyesconfig (attached as .config)
compiler: sparc64-linux-gcc (GCC) 8.1.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=8.1.0 make.cross ARCH=sparc64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
drivers/video/fbdev/core/fbcon.c: In function 'fbcon_set_con2fb_map_ioctl':
>> drivers/video/fbdev/core/fbcon.c:3323:6: error: implicit declaration of
>> function 'copy_from_user'; did you mean 'copy_creds'?
>> [-Werror=implicit-function-declaration]
if (copy_from_user(, argp, sizeof(con2fb)))
^~
copy_creds
drivers/video/fbdev/core/fbcon.c: In function 'fbcon_get_con2fb_map_ioctl':
>> drivers/video/fbdev/core/fbcon.c:3356:9: error: implicit declaration of
>> function 'copy_to_user'; did you mean 'cpu_to_mem'?
>> [-Werror=implicit-function-declaration]
return copy_to_user(argp, , sizeof(con2fb)) ? -EFAULT : 0;
^~~~
cpu_to_mem
cc1: some warnings being treated as errors
vim +3323 drivers/video/fbdev/core/fbcon.c
3317
3318 int fbcon_set_con2fb_map_ioctl(void __user *argp)
3319 {
3320 struct fb_con2fbmap con2fb;
3321 int ret;
3322
> 3323 if (copy_from_user(, argp, sizeof(con2fb)))
3324 return -EFAULT;
3325 if (con2fb.console < 1 || con2fb.console > MAX_NR_CONSOLES)
3326 return -EINVAL;
3327 if (con2fb.framebuffer >= FB_MAX)
3328 return -EINVAL;
3329 if (!registered_fb[con2fb.framebuffer])
3330 request_module("fb%d", con2fb.framebuffer);
3331 if (!registered_fb[con2fb.framebuffer]) {
3332 return -EINVAL;
}
3334
3335 console_lock();
3336 ret = set_con2fb_map(con2fb.console - 1,
3337 con2fb.framebuffer, 1);
3338 console_unlock();
3339
3340 return ret;
3341 }
3342
3343 int fbcon_get_con2fb_map_ioctl(void __user *argp)
3344 {
3345 struct fb_con2fbmap con2fb;
3346
3347 if (copy_from_user(, argp, sizeof(con2fb)))
3348 return -EFAULT;
3349 if (con2fb.console < 1 || con2fb.console > MAX_NR_CONSOLES)
3350 return -EINVAL;
3351
3352 console_lock();
3353 con2fb.framebuffer = con2fb_map[con2fb.console - 1];
3354 console_unlock();
3355
> 3356 return copy_to_user(argp, , sizeof(con2fb)) ? -EFAULT :
> 0;
3357 }
3358
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 18/33] fbdev: make unregister/unlink functions not fail
Hi Daniel,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.2-rc1 next-20190520]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Daniel-Vetter/fbcon-notifier-begone/20190521-021841
config: x86_64-randconfig-x003-201920 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
drivers/video/fbdev/savage/savagefb_driver.c: In function 'savagefb_remove':
>> drivers/video/fbdev/savage/savagefb_driver.c:2341:7: error: void value not
>> ignored as it ought to be
if (unregister_framebuffer(info))
^~
vim +2341 drivers/video/fbdev/savage/savagefb_driver.c
^1da177e drivers/video/savage/savagefb_driver.c Linus Torvalds 2005-04-16
2328
48c68c4f drivers/video/savage/savagefb_driver.c Greg Kroah-Hartman 2012-12-21
2329 static void savagefb_remove(struct pci_dev *dev)
^1da177e drivers/video/savage/savagefb_driver.c Linus Torvalds 2005-04-16
2330 {
b8901b09 drivers/video/savage/savagefb_driver.c Antonino A. Daplas 2006-01-09
2331 struct fb_info *info = pci_get_drvdata(dev);
^1da177e drivers/video/savage/savagefb_driver.c Linus Torvalds 2005-04-16
2332
^1da177e drivers/video/savage/savagefb_driver.c Linus Torvalds 2005-04-16
2333 DBG("savagefb_remove");
^1da177e drivers/video/savage/savagefb_driver.c Linus Torvalds 2005-04-16
2334
^1da177e drivers/video/savage/savagefb_driver.c Linus Torvalds 2005-04-16
2335 if (info) {
^1da177e drivers/video/savage/savagefb_driver.c Linus Torvalds 2005-04-16
2336 /*
^1da177e drivers/video/savage/savagefb_driver.c Linus Torvalds 2005-04-16
2337 * If unregister_framebuffer fails, then
^1da177e drivers/video/savage/savagefb_driver.c Linus Torvalds 2005-04-16
2338 * we will be leaving hooks that could cause
^1da177e drivers/video/savage/savagefb_driver.c Linus Torvalds 2005-04-16
2339 * oopsen laying around.
^1da177e drivers/video/savage/savagefb_driver.c Linus Torvalds 2005-04-16
2340 */
^1da177e drivers/video/savage/savagefb_driver.c Linus Torvalds 2005-04-16
@2341 if (unregister_framebuffer(info))
^1da177e drivers/video/savage/savagefb_driver.c Linus Torvalds 2005-04-16
2342 printk(KERN_WARNING "savagefb: danger danger! "
^1da177e drivers/video/savage/savagefb_driver.c Linus Torvalds 2005-04-16
2343"Oopsen imminent!\n");
^1da177e drivers/video/savage/savagefb_driver.c Linus Torvalds 2005-04-16
2344
:: The code at line 2341 was first introduced by commit
:: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Linux-2.6.12-rc2
:: TO: Linus Torvalds
:: CC: Linus Torvalds
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 21/33] fbdev: directly call fbcon_suspended/resumed
Hi Daniel,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.2-rc1 next-20190520]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Daniel-Vetter/fbcon-notifier-begone/20190521-021841
config: x86_64-randconfig-x006-201920 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
drivers/video/fbdev/core/fbmem.c: In function 'fb_set_suspend':
>> drivers/video/fbdev/core/fbmem.c:1908:3: error: too many arguments to
>> function 'fbcon_suspended'
fbcon_suspended(info);
^~~
In file included from drivers/video/fbdev/core/fbmem.c:35:0:
include/linux/fbcon.h:18:20: note: declared here
static inline void fbcon_suspended(void) {}
^~~
>> drivers/video/fbdev/core/fbmem.c:1912:3: error: too many arguments to
>> function 'fbcon_resumed'
fbcon_resumed(info);
^
In file included from drivers/video/fbdev/core/fbmem.c:35:0:
include/linux/fbcon.h:19:20: note: declared here
static inline void fbcon_resumed(void) {}
^
vim +/fbcon_suspended +1908 drivers/video/fbdev/core/fbmem.c
1893
1894 /**
1895 * fb_set_suspend - low level driver signals suspend
1896 * @info: framebuffer affected
1897 * @state: 0 = resuming, !=0 = suspending
1898 *
1899 * This is meant to be used by low level drivers to
1900 * signal suspend/resume to the core & clients.
1901 * It must be called with the console semaphore held
1902 */
1903 void fb_set_suspend(struct fb_info *info, int state)
1904 {
1905 WARN_CONSOLE_UNLOCKED();
1906
1907 if (state) {
> 1908 fbcon_suspended(info);
1909 info->state = FBINFO_STATE_SUSPENDED;
1910 } else {
1911 info->state = FBINFO_STATE_RUNNING;
> 1912 fbcon_resumed(info);
1913 }
1914 }
1915 EXPORT_SYMBOL(fb_set_suspend);
1916
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Allow modeset on unregisted connectors unconditionally
On Mon, May 20, 2019 at 10:09:24PM +0300, Imre Deak wrote: > On Mon, May 20, 2019 at 08:37:46PM +0200, Daniel Vetter wrote: > > On Mon, May 20, 2019 at 08:41:09PM +0300, Imre Deak wrote: > > > We allowed modesetting an unregistered connector only in the case the > > > mode is getting disabled on the connector. > > > > > > The reason for this check was the lack of proper refcounting for the > > > backing memory objects. That problem has been solved meanwhile so there > > > is no reason any more to reject the modesetting in general. > > > > I'm not parsing this at all ... maybe references to the commits that fix > > this? Or do you mean the refcounting work for all the things hanging of > > connectors, including the entire mst tree? > > Yes the check was added to solve the issue related to the removal of MST > connectors that could happen asynchronously wrt. a modeset referring to > that MST connector. That could happen since the MST core doesn't hold > any locks (for instance the connection_mutex) during removing an MST > connector that would prevent doing a modeset at the same time. > > Adding the refcounting for such MST connectors (via the > drm_connector_get()/drm_connector_put()) got rid of the above problem. We added the check way after that stuff landed. Before all the connector reworking connectors were forcefully disabled by the kernel. The idea behind this check is to make sure that that userspace notices a connector is gone (only thing that's not allowed is enabling it, you can keep pageflipping). I think we've always had behaviour like ever since mst (all userspace has some "oops mst connector probably gone" failure catching around modesets). So no idea what all blows up if we stop catching userspace this way. Now very much possible I'm getting all this wrong again or missing something, this stuff is often way over my head. But I'm really vary of breaking userspace here. E.g. just the drm_connector_get/put lifetime changes results in some userspace breaking if you unplug/replug fast enough, because then it doesn't notice the connector change anymore. I couldn't figure out a way to paper over that regression without reintroduce the rather broken and oops-prone old connector lifetime management. > > > The check > > > for that also makes driver internal modesets more cumbersome where we > > > need to add exemptions for the cases where we do need to allow the > > > modeset even for unregistered connectors. One such case is the > > > restoration of the mode during resume. > > > > Yeah this one actually makes sense to me. We could still keep this check > > here, but for the atomic ioctl only when called from userspace. But iirc > > Lyude also said she has some plans here, so no idea whether that all fits. > > > > > Simplify things by removing the unneeded check. I can't see how > > > modesetting an unregistered connector can cause any problem and the race > > > (described in the code comment) can anyway result in such a modeset (if > > > the connector is unregistered right after the check). > > > > Not saying we don't need this, but there's fairly enormous amounts of > > history behind all this stuff, and lots of discussions. Would be good to > > at least reference those, so we have a good story for when this then all > > goes wrong again. > > I still don't see why this check is needed. There is no justification > for it - besides the original reason for it as discussed above about the > refcounting problem, which is solved now - so I think we should remove > it, instead of just making it a special case for the user space modeset. > > As I wrote a user space modeset can end up anyway doing a modeset on an > unregistered connector when the unregistering - by MST core - happens just > right after the check. Yup. Always been like that. -Daniel > > > -Daniel > > > > > > > > Cc: Lyude Paul > > > Cc: Daniel Vetter > > > Cc: Ville Syrjälä > > > Signed-off-by: Imre Deak > > > --- > > > drivers/gpu/drm/drm_atomic_helper.c | 29 ++--- > > > 1 file changed, 2 insertions(+), 27 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c > > > b/drivers/gpu/drm/drm_atomic_helper.c > > > index 2e0cb4246cbd..e94e69483498 100644 > > > --- a/drivers/gpu/drm/drm_atomic_helper.c > > > +++ b/drivers/gpu/drm/drm_atomic_helper.c > > > @@ -319,33 +319,6 @@ update_connector_routing(struct drm_atomic_state > > > *state, > > > return 0; > > > } > > > > > > - crtc_state = drm_atomic_get_new_crtc_state(state, > > > -new_connector_state->crtc); > > > - /* > > > - * For compatibility with legacy users, we want to make sure that > > > - * we allow DPMS On->Off modesets on unregistered connectors. Modesets > > > - * which would result in anything else must be considered invalid, to > > > - * avoid turning on new displays on dead connectors. > > > - * > > > - * Since the connector can be unregistered at
[Intel-gfx] XDC 2019: Registration & Call for Proposals now open!
Hello! Registration & Call for Proposals are now open for XDC 2019, which will take place at the Concordia University Conference Centre in Montréal, Canada on October 2-4, 2019. Thanks to LWN.net, this year we have a brand new website using the Indico platform, a fully open source event management tool! https://xdc2019.x.org If you plan on attending, please make sure to register as early as possible as space is limited! As usual, the conference is free of charge and open to the general public. Please note, as we are now based on Indico, we will no longer use the wiki for registration. You will therefore need to register via the XDC website. However, as XDC is sharing the same Indico infrastructure as LPC, if you previously registered on the LPC website (linuxplumbersconference.org), then you already have an active account and can use the same username & password to login! https://xdc2019.x.org/event/5/registrations/2/ In addition to registration, the CfP is now open for talks, workshops and demos at XDC 2019. While any serious proposal will be gratefully considered, topics of interest to X.Org and freedesktop.org developers are encouraged. The program focus is on new development, ongoing challenges and anything else that will spark discussions among attendees in the hallway track. We are open to talks across all layers of the graphics stack, from the kernel to desktop environments / graphical applications and about how to make things better for the developers who build them. Head to the CfP page to learn more: https://xdc2019.x.org/event/5/abstracts/ The deadline for submissions Sunday, 7 July 2019. We are looking forward to seeing you (and sharing a poutine!) in beautiful Montréal! If you have any questions, please send me an email to mark.fil...@collabora.com, adding on CC the X.org board (board at foundation.x.org). And don't forget, you can follow us on Twitter for all the latest updates and to stay connected: https://twitter.com/xdc2019 Best, Mark ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 0/5] cgroup support for GPU devices
Leon Romanovsky writes: First group (programmers) is using special API [1] through libibverbs [2] without any notion of cgroups or any limitations. Second group (sysadmins) is less interested in application specifics and for them "device memory" means "memory" and not "rdma, nic specific, internal memory". I'd suggest otherwise, based on historic precedent -- sysadmins are typically very opinionated about operation of the memory subsystem (hence the endless discussions about swap, caching behaviour, etc). Especially in this case, these types of memory operate fundamentally differently and have significantly different performance and availability characteristics. That's not something that can be trivially abstracted over without non-trivial drawbacks. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Allow modeset on unregisted connectors unconditionally
On Mon, May 20, 2019 at 08:37:46PM +0200, Daniel Vetter wrote:
> On Mon, May 20, 2019 at 08:41:09PM +0300, Imre Deak wrote:
> > We allowed modesetting an unregistered connector only in the case the
> > mode is getting disabled on the connector.
> >
> > The reason for this check was the lack of proper refcounting for the
> > backing memory objects. That problem has been solved meanwhile so there
> > is no reason any more to reject the modesetting in general.
>
> I'm not parsing this at all ... maybe references to the commits that fix
> this? Or do you mean the refcounting work for all the things hanging of
> connectors, including the entire mst tree?
Yes the check was added to solve the issue related to the removal of MST
connectors that could happen asynchronously wrt. a modeset referring to
that MST connector. That could happen since the MST core doesn't hold
any locks (for instance the connection_mutex) during removing an MST
connector that would prevent doing a modeset at the same time.
Adding the refcounting for such MST connectors (via the
drm_connector_get()/drm_connector_put()) got rid of the above problem.
>
> > The check
> > for that also makes driver internal modesets more cumbersome where we
> > need to add exemptions for the cases where we do need to allow the
> > modeset even for unregistered connectors. One such case is the
> > restoration of the mode during resume.
>
> Yeah this one actually makes sense to me. We could still keep this check
> here, but for the atomic ioctl only when called from userspace. But iirc
> Lyude also said she has some plans here, so no idea whether that all fits.
>
> > Simplify things by removing the unneeded check. I can't see how
> > modesetting an unregistered connector can cause any problem and the race
> > (described in the code comment) can anyway result in such a modeset (if
> > the connector is unregistered right after the check).
>
> Not saying we don't need this, but there's fairly enormous amounts of
> history behind all this stuff, and lots of discussions. Would be good to
> at least reference those, so we have a good story for when this then all
> goes wrong again.
I still don't see why this check is needed. There is no justification
for it - besides the original reason for it as discussed above about the
refcounting problem, which is solved now - so I think we should remove
it, instead of just making it a special case for the user space modeset.
As I wrote a user space modeset can end up anyway doing a modeset on an
unregistered connector when the unregistering - by MST core - happens just
right after the check.
> -Daniel
>
> >
> > Cc: Lyude Paul
> > Cc: Daniel Vetter
> > Cc: Ville Syrjälä
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/drm_atomic_helper.c | 29 ++---
> > 1 file changed, 2 insertions(+), 27 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 2e0cb4246cbd..e94e69483498 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -319,33 +319,6 @@ update_connector_routing(struct drm_atomic_state
> > *state,
> > return 0;
> > }
> >
> > - crtc_state = drm_atomic_get_new_crtc_state(state,
> > - new_connector_state->crtc);
> > - /*
> > -* For compatibility with legacy users, we want to make sure that
> > -* we allow DPMS On->Off modesets on unregistered connectors. Modesets
> > -* which would result in anything else must be considered invalid, to
> > -* avoid turning on new displays on dead connectors.
> > -*
> > -* Since the connector can be unregistered at any point during an
> > -* atomic check or commit, this is racy. But that's OK: all we care
> > -* about is ensuring that userspace can't do anything but shut off the
> > -* display on a connector that was destroyed after it's been notified,
> > -* not before.
> > -*
> > -* Additionally, we also want to ignore connector registration when
> > -* we're trying to restore an atomic state during system resume since
> > -* there's a chance the connector may have been destroyed during the
> > -* process, but it's better to ignore that then cause
> > -* drm_atomic_helper_resume() to fail.
> > -*/
> > - if (!state->duplicated && drm_connector_is_unregistered(connector) &&
> > - crtc_state->active) {
> > - DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] is not registered\n",
> > -connector->base.id, connector->name);
> > - return -EINVAL;
> > - }
> > -
> > funcs = connector->helper_private;
> >
> > if (funcs->atomic_best_encoder)
> > @@ -390,6 +363,8 @@ update_connector_routing(struct drm_atomic_state *state,
> >
> > set_best_encoder(state, new_connector_state, new_encoder);
> >
> > + crtc_state =
Re: [Intel-gfx] [PATCH 18/33] fbdev: make unregister/unlink functions not fail
Hi Daniel,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.2-rc1 next-20190520]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Daniel-Vetter/fbcon-notifier-begone/20190521-021841
config: x86_64-randconfig-x004-201920 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
drivers/video/fbdev/neofb.c: In function 'neofb_remove':
>> drivers/video/fbdev/neofb.c:2130:7: error: void value not ignored as it
>> ought to be
if (unregister_framebuffer(info))
^~
vim +2130 drivers/video/fbdev/neofb.c
^1da177e drivers/video/neofb.c Linus Torvalds 2005-04-16 2117
48c68c4f drivers/video/neofb.c Greg Kroah-Hartman 2012-12-21 2118 static void
neofb_remove(struct pci_dev *dev)
^1da177e drivers/video/neofb.c Linus Torvalds 2005-04-16 2119 {
^1da177e drivers/video/neofb.c Linus Torvalds 2005-04-16 2120 struct
fb_info *info = pci_get_drvdata(dev);
^1da177e drivers/video/neofb.c Linus Torvalds 2005-04-16 2121
^1da177e drivers/video/neofb.c Linus Torvalds 2005-04-16 2122
DBG("neofb_remove");
^1da177e drivers/video/neofb.c Linus Torvalds 2005-04-16 2123
^1da177e drivers/video/neofb.c Linus Torvalds 2005-04-16 2124 if
(info) {
^1da177e drivers/video/neofb.c Linus Torvalds 2005-04-16 2125
/*
^1da177e drivers/video/neofb.c Linus Torvalds 2005-04-16 2126
* If unregister_framebuffer fails, then
^1da177e drivers/video/neofb.c Linus Torvalds 2005-04-16 2127
* we will be leaving hooks that could cause
^1da177e drivers/video/neofb.c Linus Torvalds 2005-04-16 2128
* oopsen laying around.
^1da177e drivers/video/neofb.c Linus Torvalds 2005-04-16 2129
*/
^1da177e drivers/video/neofb.c Linus Torvalds 2005-04-16 @2130
if (unregister_framebuffer(info))
^1da177e drivers/video/neofb.c Linus Torvalds 2005-04-16 2131
printk(KERN_WARNING
^1da177e drivers/video/neofb.c Linus Torvalds 2005-04-16 2132
"neofb: danger danger! Oopsen imminent!\n");
^1da177e drivers/video/neofb.c Linus Torvalds 2005-04-16 2133
^1da177e drivers/video/neofb.c Linus Torvalds 2005-04-16 2134
neo_unmap_video(info);
^1da177e drivers/video/neofb.c Linus Torvalds 2005-04-16 2135
fb_destroy_modedb(info->monspecs.modedb);
^1da177e drivers/video/neofb.c Linus Torvalds 2005-04-16 2136
neo_unmap_mmio(info);
^1da177e drivers/video/neofb.c Linus Torvalds 2005-04-16 2137
neo_free_fb_info(info);
^1da177e drivers/video/neofb.c Linus Torvalds 2005-04-16 2138 }
^1da177e drivers/video/neofb.c Linus Torvalds 2005-04-16 2139 }
^1da177e drivers/video/neofb.c Linus Torvalds 2005-04-16 2140
:: The code at line 2130 was first introduced by commit
:: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Linux-2.6.12-rc2
:: TO: Linus Torvalds
:: CC: Linus Torvalds
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Allow modeset on unregisted connectors unconditionally
On Mon, May 20, 2019 at 08:41:09PM +0300, Imre Deak wrote:
> We allowed modesetting an unregistered connector only in the case the
> mode is getting disabled on the connector.
>
> The reason for this check was the lack of proper refcounting for the
> backing memory objects. That problem has been solved meanwhile so there
> is no reason any more to reject the modesetting in general.
I'm not parsing this at all ... maybe references to the commits that fix
this? Or do you mean the refcounting work for all the things hanging of
connectors, including the entire mst tree?
> The check
> for that also makes driver internal modesets more cumbersome where we
> need to add exemptions for the cases where we do need to allow the
> modeset even for unregistered connectors. One such case is the
> restoration of the mode during resume.
Yeah this one actually makes sense to me. We could still keep this check
here, but for the atomic ioctl only when called from userspace. But iirc
Lyude also said she has some plans here, so no idea whether that all fits.
> Simplify things by removing the unneeded check. I can't see how
> modesetting an unregistered connector can cause any problem and the race
> (described in the code comment) can anyway result in such a modeset (if
> the connector is unregistered right after the check).
Not saying we don't need this, but there's fairly enormous amounts of
history behind all this stuff, and lots of discussions. Would be good to
at least reference those, so we have a good story for when this then all
goes wrong again.
-Daniel
>
> Cc: Lyude Paul
> Cc: Daniel Vetter
> Cc: Ville Syrjälä
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 29 ++---
> 1 file changed, 2 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 2e0cb4246cbd..e94e69483498 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -319,33 +319,6 @@ update_connector_routing(struct drm_atomic_state *state,
> return 0;
> }
>
> - crtc_state = drm_atomic_get_new_crtc_state(state,
> -new_connector_state->crtc);
> - /*
> - * For compatibility with legacy users, we want to make sure that
> - * we allow DPMS On->Off modesets on unregistered connectors. Modesets
> - * which would result in anything else must be considered invalid, to
> - * avoid turning on new displays on dead connectors.
> - *
> - * Since the connector can be unregistered at any point during an
> - * atomic check or commit, this is racy. But that's OK: all we care
> - * about is ensuring that userspace can't do anything but shut off the
> - * display on a connector that was destroyed after it's been notified,
> - * not before.
> - *
> - * Additionally, we also want to ignore connector registration when
> - * we're trying to restore an atomic state during system resume since
> - * there's a chance the connector may have been destroyed during the
> - * process, but it's better to ignore that then cause
> - * drm_atomic_helper_resume() to fail.
> - */
> - if (!state->duplicated && drm_connector_is_unregistered(connector) &&
> - crtc_state->active) {
> - DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] is not registered\n",
> - connector->base.id, connector->name);
> - return -EINVAL;
> - }
> -
> funcs = connector->helper_private;
>
> if (funcs->atomic_best_encoder)
> @@ -390,6 +363,8 @@ update_connector_routing(struct drm_atomic_state *state,
>
> set_best_encoder(state, new_connector_state, new_encoder);
>
> + crtc_state = drm_atomic_get_new_crtc_state(state,
> +new_connector_state->crtc);
> crtc_state->connectors_changed = true;
>
> DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] using [ENCODER:%d:%s] on
> [CRTC:%d:%s]\n",
> --
> 2.17.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 27/33] fbdev: remove FBINFO_MISC_USEREVENT around fb_blank
Hi Daniel.
On Mon, May 20, 2019 at 07:29:52PM +0200, Daniel Vetter wrote:
> On Mon, May 20, 2019 at 7:20 PM Sam Ravnborg wrote:
> >
> > Hi Daniel.
> >
> > > With the recursion broken in the previous patch we can drop the
> > > FBINFO_MISC_USEREVENT flag around calls to fb_blank - recursion
> > > prevention was it's only job.
> > >
> > When grepping for FBINFO_MISC_USEREVENT I get a few hits not addressed
> > in the patch below:
> >
> > drivers/video/fbdev/core/fbcon.c: if (!(info->flags &
> > FBINFO_MISC_USEREVENT))
> > drivers/video/fbdev/core/fbmem.c: if (!ret && (flags
> > & FBINFO_MISC_USEREVENT)) {
> > drivers/video/fbdev/core/fbmem.c: info->flags
> > &= ~FBINFO_MISC_USEREVENT;
> > drivers/video/fbdev/core/fbmem.c: info->flags |=
> > FBINFO_MISC_USEREVENT;
> > drivers/video/fbdev/core/fbmem.c: info->flags &=
> > ~FBINFO_MISC_USEREVENT;
> > drivers/video/fbdev/core/fbmem.c: info->flags |=
> > FBINFO_MISC_USEREVENT;
> > drivers/video/fbdev/core/fbmem.c: info->flags &=
> > ~FBINFO_MISC_USEREVENT;
> > drivers/video/fbdev/core/fbsysfs.c: fb_info->flags |=
> > FBINFO_MISC_USEREVENT;
> > drivers/video/fbdev/core/fbsysfs.c: fb_info->flags &=
> > ~FBINFO_MISC_USEREVENT;
> > drivers/video/fbdev/core/fbsysfs.c: fb_info->flags |=
> > FBINFO_MISC_USEREVENT;
> > drivers/video/fbdev/core/fbsysfs.c: fb_info->flags &=
> > ~FBINFO_MISC_USEREVENT;
> > drivers/video/fbdev/ps3fb.c:info->flags |=
> > FBINFO_MISC_USEREVENT;
> > drivers/video/fbdev/ps3fb.c:info->flags &=
> > ~FBINFO_MISC_USEREVENT;
> > drivers/video/fbdev/sh_mobile_lcdcfb.c: * FBINFO_MISC_USEREVENT flag is
> > set. Since we do not want to fake a
> > include/linux/fb.h:#define FBINFO_MISC_USEREVENT 0x1 /* event
> > request
> >
> > The use in ps3fb looks like a candidate for removal and this file is not
> > touch in this patch series, so I guess I did not miss it.
> >
> > As I did not apply the full series maybe some of the other users was
> > already taken care of.
>
> It's also used to break recursion around fb_set_par and fb_set_pan.
> Untangling that one would be possible, but also requires untangling
> some locking, so a lot more work. If you chase all the call paths then
> you'll noticed that the users still left have no overlap with the ones
> I'm removing here.
Now you spell it out it is obvious. I guess I never read more than fb_
and missed that we are dealing with different calls.
Thanks for the quick feedback, and sorry for the noise.
Sam
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm: Allow modeset on unregisted connectors unconditionally
We allowed modesetting an unregistered connector only in the case the
mode is getting disabled on the connector.
The reason for this check was the lack of proper refcounting for the
backing memory objects. That problem has been solved meanwhile so there
is no reason any more to reject the modesetting in general. The check
for that also makes driver internal modesets more cumbersome where we
need to add exemptions for the cases where we do need to allow the
modeset even for unregistered connectors. One such case is the
restoration of the mode during resume.
Simplify things by removing the unneeded check. I can't see how
modesetting an unregistered connector can cause any problem and the race
(described in the code comment) can anyway result in such a modeset (if
the connector is unregistered right after the check).
Cc: Lyude Paul
Cc: Daniel Vetter
Cc: Ville Syrjälä
Signed-off-by: Imre Deak
---
drivers/gpu/drm/drm_atomic_helper.c | 29 ++---
1 file changed, 2 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 2e0cb4246cbd..e94e69483498 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -319,33 +319,6 @@ update_connector_routing(struct drm_atomic_state *state,
return 0;
}
- crtc_state = drm_atomic_get_new_crtc_state(state,
- new_connector_state->crtc);
- /*
-* For compatibility with legacy users, we want to make sure that
-* we allow DPMS On->Off modesets on unregistered connectors. Modesets
-* which would result in anything else must be considered invalid, to
-* avoid turning on new displays on dead connectors.
-*
-* Since the connector can be unregistered at any point during an
-* atomic check or commit, this is racy. But that's OK: all we care
-* about is ensuring that userspace can't do anything but shut off the
-* display on a connector that was destroyed after it's been notified,
-* not before.
-*
-* Additionally, we also want to ignore connector registration when
-* we're trying to restore an atomic state during system resume since
-* there's a chance the connector may have been destroyed during the
-* process, but it's better to ignore that then cause
-* drm_atomic_helper_resume() to fail.
-*/
- if (!state->duplicated && drm_connector_is_unregistered(connector) &&
- crtc_state->active) {
- DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] is not registered\n",
-connector->base.id, connector->name);
- return -EINVAL;
- }
-
funcs = connector->helper_private;
if (funcs->atomic_best_encoder)
@@ -390,6 +363,8 @@ update_connector_routing(struct drm_atomic_state *state,
set_best_encoder(state, new_connector_state, new_encoder);
+ crtc_state = drm_atomic_get_new_crtc_state(state,
+ new_connector_state->crtc);
crtc_state->connectors_changed = true;
DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] using [ENCODER:%d:%s] on
[CRTC:%d:%s]\n",
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 27/33] fbdev: remove FBINFO_MISC_USEREVENT around fb_blank
On Mon, May 20, 2019 at 7:20 PM Sam Ravnborg wrote:
>
> Hi Daniel.
>
> > With the recursion broken in the previous patch we can drop the
> > FBINFO_MISC_USEREVENT flag around calls to fb_blank - recursion
> > prevention was it's only job.
> >
> When grepping for FBINFO_MISC_USEREVENT I get a few hits not addressed
> in the patch below:
>
> drivers/video/fbdev/core/fbcon.c: if (!(info->flags &
> FBINFO_MISC_USEREVENT))
> drivers/video/fbdev/core/fbmem.c: if (!ret && (flags &
> FBINFO_MISC_USEREVENT)) {
> drivers/video/fbdev/core/fbmem.c: info->flags
> &= ~FBINFO_MISC_USEREVENT;
> drivers/video/fbdev/core/fbmem.c: info->flags |=
> FBINFO_MISC_USEREVENT;
> drivers/video/fbdev/core/fbmem.c: info->flags &=
> ~FBINFO_MISC_USEREVENT;
> drivers/video/fbdev/core/fbmem.c: info->flags |=
> FBINFO_MISC_USEREVENT;
> drivers/video/fbdev/core/fbmem.c: info->flags &=
> ~FBINFO_MISC_USEREVENT;
> drivers/video/fbdev/core/fbsysfs.c: fb_info->flags |=
> FBINFO_MISC_USEREVENT;
> drivers/video/fbdev/core/fbsysfs.c: fb_info->flags &=
> ~FBINFO_MISC_USEREVENT;
> drivers/video/fbdev/core/fbsysfs.c: fb_info->flags |=
> FBINFO_MISC_USEREVENT;
> drivers/video/fbdev/core/fbsysfs.c: fb_info->flags &=
> ~FBINFO_MISC_USEREVENT;
> drivers/video/fbdev/ps3fb.c:info->flags |=
> FBINFO_MISC_USEREVENT;
> drivers/video/fbdev/ps3fb.c:info->flags &=
> ~FBINFO_MISC_USEREVENT;
> drivers/video/fbdev/sh_mobile_lcdcfb.c: * FBINFO_MISC_USEREVENT flag is set.
> Since we do not want to fake a
> include/linux/fb.h:#define FBINFO_MISC_USEREVENT 0x1 /* event
> request
>
> The use in ps3fb looks like a candidate for removal and this file is not
> touch in this patch series, so I guess I did not miss it.
>
> As I did not apply the full series maybe some of the other users was
> already taken care of.
It's also used to break recursion around fb_set_par and fb_set_pan.
Untangling that one would be possible, but also requires untangling
some locking, so a lot more work. If you chase all the call paths then
you'll noticed that the users still left have no overlap with the ones
I'm removing here.
-Daniel
>
>
> Sam
>
> > Signed-off-by: Daniel Vetter
> > Cc: Daniel Vetter
> > Cc: Bartlomiej Zolnierkiewicz
> > Cc: Hans de Goede
> > Cc: Yisheng Xie
> > Cc: "Michał Mirosław"
> > Cc: Peter Rosin
> > Cc: Mikulas Patocka
> > Cc: Rob Clark
> > ---
> > drivers/video/fbdev/core/fbcon.c | 5 ++---
> > drivers/video/fbdev/core/fbmem.c | 3 ---
> > drivers/video/fbdev/core/fbsysfs.c | 2 --
> > 3 files changed, 2 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/core/fbcon.c
> > b/drivers/video/fbdev/core/fbcon.c
> > index f85d794a3bee..c1a7476e980f 100644
> > --- a/drivers/video/fbdev/core/fbcon.c
> > +++ b/drivers/video/fbdev/core/fbcon.c
> > @@ -2382,9 +2382,8 @@ static int fbcon_blank(struct vc_data *vc, int blank,
> > int mode_switch)
> > fbcon_cursor(vc, blank ? CM_ERASE : CM_DRAW);
> > ops->cursor_flash = (!blank);
> >
> > - if (!(info->flags & FBINFO_MISC_USEREVENT))
> > - if (fb_blank(info, blank))
> > - fbcon_generic_blank(vc, info, blank);
> > + if (fb_blank(info, blank))
> > + fbcon_generic_blank(vc, info, blank);
> > }
> >
> > if (!blank)
> > diff --git a/drivers/video/fbdev/core/fbmem.c
> > b/drivers/video/fbdev/core/fbmem.c
> > index 7f95c7e80155..65a075ccac4a 100644
> > --- a/drivers/video/fbdev/core/fbmem.c
> > +++ b/drivers/video/fbdev/core/fbmem.c
> > @@ -1194,10 +1194,7 @@ static long do_fb_ioctl(struct fb_info *info,
> > unsigned int cmd,
> > case FBIOBLANK:
> > console_lock();
> > lock_fb_info(info);
> > - info->flags |= FBINFO_MISC_USEREVENT;
> > ret = fb_blank(info, arg);
> > - info->flags &= ~FBINFO_MISC_USEREVENT;
> > -
> > /* might again call into fb_blank */
> > fbcon_fb_blanked(info, arg);
> > unlock_fb_info(info);
> > diff --git a/drivers/video/fbdev/core/fbsysfs.c
> > b/drivers/video/fbdev/core/fbsysfs.c
> > index 252d4f52d2a5..882b471d619e 100644
> > --- a/drivers/video/fbdev/core/fbsysfs.c
> > +++ b/drivers/video/fbdev/core/fbsysfs.c
> > @@ -310,9 +310,7 @@ static ssize_t store_blank(struct device *device,
> >
> > arg = simple_strtoul(buf, , 0);
> > console_lock();
> > - fb_info->flags |= FBINFO_MISC_USEREVENT;
> > err = fb_blank(fb_info, arg);
> > - fb_info->flags &= ~FBINFO_MISC_USEREVENT;
> > /* might again call into fb_blank */
> > fbcon_fb_blanked(fb_info, arg);
> > console_unlock();
> > --
> > 2.20.1
> >
>
Re: [Intel-gfx] [PATCH 10/33] fbcon: call fbcon_fb_(un)registered directly
On Mon, May 20, 2019 at 7:08 PM Sam Ravnborg wrote:
>
> Hi Daniel.
>
> While browsing this nice patch series I stumbled upon a detail.
>
> On Mon, May 20, 2019 at 10:21:53AM +0200, Daniel Vetter wrote:
> > With
> >
> > commit 6104c37094e729f3d4ce65797002112735d49cd1
> > Author: Daniel Vetter
> > Date: Tue Aug 1 17:32:07 2017 +0200
> >
> > fbcon: Make fbcon a built-time depency for fbdev
> >
> > we have a static dependency between fbcon and fbdev, and we can
> > replace the indirection through the notifier chain with a function
> > call.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Bartlomiej Zolnierkiewicz
> > Cc: Daniel Vetter
> > Cc: Hans de Goede
> > Cc: Greg Kroah-Hartman
> > Cc: "Noralf Trønnes"
> > Cc: Yisheng Xie
> > Cc: Peter Rosin
> > Cc: "Michał Mirosław"
> > Cc: Thomas Zimmermann
> > Cc: Mikulas Patocka
> > Cc: linux-fb...@vger.kernel.org
> > ---
> > diff --git a/include/linux/fb.h b/include/linux/fb.h
> > index f52ef0ad6781..701abaf79c87 100644
> > --- a/include/linux/fb.h
> > +++ b/include/linux/fb.h
> > @@ -136,10 +136,6 @@ struct fb_cursor_user {
> > #define FB_EVENT_RESUME 0x03
> > /* An entry from the modelist was removed */
> > #define FB_EVENT_MODE_DELETE0x04
> > -/* A driver registered itself */
> > -#define FB_EVENT_FB_REGISTERED 0x05
> > -/* A driver unregistered itself */
> > -#define FB_EVENT_FB_UNREGISTERED0x06
> > /* CONSOLE-SPECIFIC: get console to framebuffer mapping */
> > #define FB_EVENT_GET_CONSOLE_MAP0x07
> > /* CONSOLE-SPECIFIC: set console to framebuffer mapping */
>
> This breaks build of arch/arm/mach-pxa/am200epd.c thats uses
> FB_EVENT_FB_*REGISTERED:
>
>
>if (event == FB_EVENT_FB_REGISTERED)
> return am200_share_video_mem(info);
> else if (event == FB_EVENT_FB_UNREGISTERED)
> return am200_unshare_video_mem(info);
>
>
> Found while grepping for "FB_EVENT" so this is not a build
> error I triggered.
Oh this is glorious :-/
Thanks a lot for spotting this, I guess I need to hack around on
metronomefb a bit ...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 27/33] fbdev: remove FBINFO_MISC_USEREVENT around fb_blank
Hi Daniel.
> With the recursion broken in the previous patch we can drop the
> FBINFO_MISC_USEREVENT flag around calls to fb_blank - recursion
> prevention was it's only job.
>
When grepping for FBINFO_MISC_USEREVENT I get a few hits not addressed
in the patch below:
drivers/video/fbdev/core/fbcon.c: if (!(info->flags &
FBINFO_MISC_USEREVENT))
drivers/video/fbdev/core/fbmem.c: if (!ret && (flags &
FBINFO_MISC_USEREVENT)) {
drivers/video/fbdev/core/fbmem.c: info->flags &=
~FBINFO_MISC_USEREVENT;
drivers/video/fbdev/core/fbmem.c: info->flags |=
FBINFO_MISC_USEREVENT;
drivers/video/fbdev/core/fbmem.c: info->flags &=
~FBINFO_MISC_USEREVENT;
drivers/video/fbdev/core/fbmem.c: info->flags |=
FBINFO_MISC_USEREVENT;
drivers/video/fbdev/core/fbmem.c: info->flags &=
~FBINFO_MISC_USEREVENT;
drivers/video/fbdev/core/fbsysfs.c: fb_info->flags |= FBINFO_MISC_USEREVENT;
drivers/video/fbdev/core/fbsysfs.c: fb_info->flags &=
~FBINFO_MISC_USEREVENT;
drivers/video/fbdev/core/fbsysfs.c: fb_info->flags |= FBINFO_MISC_USEREVENT;
drivers/video/fbdev/core/fbsysfs.c: fb_info->flags &=
~FBINFO_MISC_USEREVENT;
drivers/video/fbdev/ps3fb.c:info->flags |=
FBINFO_MISC_USEREVENT;
drivers/video/fbdev/ps3fb.c:info->flags &=
~FBINFO_MISC_USEREVENT;
drivers/video/fbdev/sh_mobile_lcdcfb.c: * FBINFO_MISC_USEREVENT flag is set.
Since we do not want to fake a
include/linux/fb.h:#define FBINFO_MISC_USEREVENT 0x1 /* event
request
The use in ps3fb looks like a candidate for removal and this file is not
touch in this patch series, so I guess I did not miss it.
As I did not apply the full series maybe some of the other users was
already taken care of.
Sam
> Signed-off-by: Daniel Vetter
> Cc: Daniel Vetter
> Cc: Bartlomiej Zolnierkiewicz
> Cc: Hans de Goede
> Cc: Yisheng Xie
> Cc: "Michał Mirosław"
> Cc: Peter Rosin
> Cc: Mikulas Patocka
> Cc: Rob Clark
> ---
> drivers/video/fbdev/core/fbcon.c | 5 ++---
> drivers/video/fbdev/core/fbmem.c | 3 ---
> drivers/video/fbdev/core/fbsysfs.c | 2 --
> 3 files changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbcon.c
> b/drivers/video/fbdev/core/fbcon.c
> index f85d794a3bee..c1a7476e980f 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -2382,9 +2382,8 @@ static int fbcon_blank(struct vc_data *vc, int blank,
> int mode_switch)
> fbcon_cursor(vc, blank ? CM_ERASE : CM_DRAW);
> ops->cursor_flash = (!blank);
>
> - if (!(info->flags & FBINFO_MISC_USEREVENT))
> - if (fb_blank(info, blank))
> - fbcon_generic_blank(vc, info, blank);
> + if (fb_blank(info, blank))
> + fbcon_generic_blank(vc, info, blank);
> }
>
> if (!blank)
> diff --git a/drivers/video/fbdev/core/fbmem.c
> b/drivers/video/fbdev/core/fbmem.c
> index 7f95c7e80155..65a075ccac4a 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -1194,10 +1194,7 @@ static long do_fb_ioctl(struct fb_info *info, unsigned
> int cmd,
> case FBIOBLANK:
> console_lock();
> lock_fb_info(info);
> - info->flags |= FBINFO_MISC_USEREVENT;
> ret = fb_blank(info, arg);
> - info->flags &= ~FBINFO_MISC_USEREVENT;
> -
> /* might again call into fb_blank */
> fbcon_fb_blanked(info, arg);
> unlock_fb_info(info);
> diff --git a/drivers/video/fbdev/core/fbsysfs.c
> b/drivers/video/fbdev/core/fbsysfs.c
> index 252d4f52d2a5..882b471d619e 100644
> --- a/drivers/video/fbdev/core/fbsysfs.c
> +++ b/drivers/video/fbdev/core/fbsysfs.c
> @@ -310,9 +310,7 @@ static ssize_t store_blank(struct device *device,
>
> arg = simple_strtoul(buf, , 0);
> console_lock();
> - fb_info->flags |= FBINFO_MISC_USEREVENT;
> err = fb_blank(fb_info, arg);
> - fb_info->flags &= ~FBINFO_MISC_USEREVENT;
> /* might again call into fb_blank */
> fbcon_fb_blanked(fb_info, arg);
> console_unlock();
> --
> 2.20.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/33] fbcon: call fbcon_fb_(un)registered directly
Hi Daniel.
While browsing this nice patch series I stumbled upon a detail.
On Mon, May 20, 2019 at 10:21:53AM +0200, Daniel Vetter wrote:
> With
>
> commit 6104c37094e729f3d4ce65797002112735d49cd1
> Author: Daniel Vetter
> Date: Tue Aug 1 17:32:07 2017 +0200
>
> fbcon: Make fbcon a built-time depency for fbdev
>
> we have a static dependency between fbcon and fbdev, and we can
> replace the indirection through the notifier chain with a function
> call.
>
> Signed-off-by: Daniel Vetter
> Cc: Bartlomiej Zolnierkiewicz
> Cc: Daniel Vetter
> Cc: Hans de Goede
> Cc: Greg Kroah-Hartman
> Cc: "Noralf Trønnes"
> Cc: Yisheng Xie
> Cc: Peter Rosin
> Cc: "Michał Mirosław"
> Cc: Thomas Zimmermann
> Cc: Mikulas Patocka
> Cc: linux-fb...@vger.kernel.org
> ---
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index f52ef0ad6781..701abaf79c87 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -136,10 +136,6 @@ struct fb_cursor_user {
> #define FB_EVENT_RESUME 0x03
> /* An entry from the modelist was removed */
> #define FB_EVENT_MODE_DELETE0x04
> -/* A driver registered itself */
> -#define FB_EVENT_FB_REGISTERED 0x05
> -/* A driver unregistered itself */
> -#define FB_EVENT_FB_UNREGISTERED0x06
> /* CONSOLE-SPECIFIC: get console to framebuffer mapping */
> #define FB_EVENT_GET_CONSOLE_MAP0x07
> /* CONSOLE-SPECIFIC: set console to framebuffer mapping */
This breaks build of arch/arm/mach-pxa/am200epd.c thats uses
FB_EVENT_FB_*REGISTERED:
if (event == FB_EVENT_FB_REGISTERED)
return am200_share_video_mem(info);
else if (event == FB_EVENT_FB_UNREGISTERED)
return am200_unshare_video_mem(info);
Found while grepping for "FB_EVENT" so this is not a build
error I triggered.
Sam
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 09/11] drm: uevent for connector status change
Le lundi 20 mai 2019 à 18:11 +0200, Daniel Vetter a écrit : > On Fri, May 17, 2019 at 01:08:24PM +0300, Pekka Paalanen wrote: > > On Thu, 16 May 2019 14:24:55 +0200 > > Daniel Vetter wrote: > > > > > On Thu, May 16, 2019 at 11:22:11AM +0300, Pekka Paalanen wrote: > > > > On Wed, 15 May 2019 10:24:49 +0200 > > > > Daniel Vetter wrote: > > > > > > > > > On Wed, May 15, 2019 at 10:37:31AM +0300, Pekka Paalanen wrote: > > > > > > On Tue, 14 May 2019 16:34:01 +0200 > > > > > > Daniel Vetter wrote: > > > > > > > > > > > > > On Tue, May 14, 2019 at 3:36 PM Pekka Paalanen > > > > > > > wrote: > > > > > > > > On Tue, 14 May 2019 13:02:09 +0200 > > > > > > > > Daniel Vetter wrote: > > > > > > > > > > > > > > > > > On Tue, May 14, 2019 at 10:18 AM Ser, Simon > > > > > > > > > wrote: > > > > > > > > > > On Tue, 2019-05-14 at 11:02 +0300, Pekka Paalanen wrote: > > > > > > > > > > > > > > > > > > > > > > ... > > > > > > > > > > > > > > > > > Hi Daniel, > > > > > > > > > > > > > > > > > > > > > > just to clarify the first case, specific to one very > > > > > > > > > > > particular > > > > > > > > > > > property: > > > > > > > > > > > > > > > > > > > > > > With HDCP, there is a property that may change > > > > > > > > > > > dynamically at runtime > > > > > > > > > > > (the undesired/desired/enabled tristate). Userspace must > > > > > > > > > > > be notified > > > > > > > > > > > when it changes, I do not want userspace have to poll > > > > > > > > > > > that property > > > > > > > > > > > with a timer. > > > > > > > > > > > > > > > > > > > > > > When that property alone changes, and userspace is > > > > > > > > > > > prepared to handle > > > > > > > > > > > that property changing alone, it must not trigger a > > > > > > > > > > > reprobe of the > > > > > > > > > > > connector. There is no reason to reprobe at that point > > > > > > > > > > > AFAIU. > > > > > > > > > > > > > > > > > > > > > > How do you ensure that userspace can avoid triggering a > > > > > > > > > > > reprobe with the > > > > > > > > > > > epoch approach or with any alternate uevent design? > > > > > > > > > > > > > > > > > > > > > > We need an event to userspace that indicates that > > > > > > > > > > > re-reading the > > > > > > > > > > > properties is enough and reprobe of the connector is not > > > > > > > > > > > necessary. > > > > > > > > > > > This is complementary to indicating to userspace that > > > > > > > > > > > only some > > > > > > > > > > > connectors need to be reprobed instead of everything. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Can't you use the PROPERTY hint? If PROPERTY is the HDCP > > > > > > > > > > one, skip the > > > > > > > > > > reprobing. Would that work? > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > yes, that would work, if it was acceptable to DRM upstream. The > > > > > > > > replies > > > > > > > > to Paul seemed to be going south so fast that I thought we > > > > > > > > wouldn't get > > > > > > > > any new uevent fields in favour of "epoch counters". > > > > > > > > > > > > > > > > > Yes that's the idea, depending upon which property you get > > > > > > > > > you know > > > > > > > > > it's a sink change (needs full reprobe) or something else > > > > > > > > > like hdcp > > > > > > > > > state machinery update. > > > > > > > > > > > > > > > > Right. > > > > > > > > > > > > > > > > > Wrt avoiding the full reprobe for sink changes: I think we > > > > > > > > > should > > > > > > > > > indeed decouple that from the per-connector event for sink > > > > > > > > > changes. > > > > > > > > > That along is a good win already, since you know for which > > > > > > > > > connector > > > > > > > > > you need to call drmGetConnector (which forces the reprobe). > > > > > > > > > It would > > > > > > > > > be nice to only call drmGetConnectorCurrent (avoids the > > > > > > > > > reprobe), but > > > > > > > > > historically speaking every time we tried to rely on this we > > > > > > > > > ended up > > > > > > > > > regretting things. > > > > > > > > > > > > > > > > What changed? This sounds very much what Paul suggested. > > > > > > > > Looking at it > > > > > > > > from userspace side: > > > > > > > > > > > > > > This sounds solid, some refinements below: > > > > > > > > > > > > > > > HOTPLUG=1 CONNECTOR=xx PROPERTY=yy > > > > > > > > > > > > > > > > - If yy is "Content Protection", no need to > > > > > > > > drmModeGetConnector(), just > > > > > > > > re-get the connector properties. > > > > > > > > > > > > > > > > - Kernel probably shouldn't bother sending this for properties > > > > > > > > where > > > > > > > > re-probe could be necessary, and send the below instead. > > > > > > > > > > > > > > I think we should assert that the kernel can get the new property > > > > > > > values using drmModeGetConnectorCurrent for this case, i.e. the > > > >
Re: [Intel-gfx] [PATCH v7 09/11] drm: uevent for connector status change
On Fri, May 17, 2019 at 01:08:24PM +0300, Pekka Paalanen wrote: > On Thu, 16 May 2019 14:24:55 +0200 > Daniel Vetter wrote: > > > On Thu, May 16, 2019 at 11:22:11AM +0300, Pekka Paalanen wrote: > > > On Wed, 15 May 2019 10:24:49 +0200 > > > Daniel Vetter wrote: > > > > > > > On Wed, May 15, 2019 at 10:37:31AM +0300, Pekka Paalanen wrote: > > > > > On Tue, 14 May 2019 16:34:01 +0200 > > > > > Daniel Vetter wrote: > > > > > > > > > > > On Tue, May 14, 2019 at 3:36 PM Pekka Paalanen > > > > > > wrote: > > > > > > > > > > > > > > On Tue, 14 May 2019 13:02:09 +0200 > > > > > > > Daniel Vetter wrote: > > > > > > > > > > > > > > > On Tue, May 14, 2019 at 10:18 AM Ser, Simon > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Tue, 2019-05-14 at 11:02 +0300, Pekka Paalanen wrote: > > > > > > > > > > ... > > > > > > > > > > > > > > > Hi Daniel, > > > > > > > > > > > > > > > > > > > > just to clarify the first case, specific to one very > > > > > > > > > > particular > > > > > > > > > > property: > > > > > > > > > > > > > > > > > > > > With HDCP, there is a property that may change dynamically > > > > > > > > > > at runtime > > > > > > > > > > (the undesired/desired/enabled tristate). Userspace must be > > > > > > > > > > notified > > > > > > > > > > when it changes, I do not want userspace have to poll that > > > > > > > > > > property > > > > > > > > > > with a timer. > > > > > > > > > > > > > > > > > > > > When that property alone changes, and userspace is prepared > > > > > > > > > > to handle > > > > > > > > > > that property changing alone, it must not trigger a reprobe > > > > > > > > > > of the > > > > > > > > > > connector. There is no reason to reprobe at that point > > > > > > > > > > AFAIU. > > > > > > > > > > > > > > > > > > > > How do you ensure that userspace can avoid triggering a > > > > > > > > > > reprobe with the > > > > > > > > > > epoch approach or with any alternate uevent design? > > > > > > > > > > > > > > > > > > > > We need an event to userspace that indicates that > > > > > > > > > > re-reading the > > > > > > > > > > properties is enough and reprobe of the connector is not > > > > > > > > > > necessary. > > > > > > > > > > This is complementary to indicating to userspace that only > > > > > > > > > > some > > > > > > > > > > connectors need to be reprobed instead of everything. > > > > > > > > > > > > > > > > > > Can't you use the PROPERTY hint? If PROPERTY is the HDCP one, > > > > > > > > > skip the > > > > > > > > > reprobing. Would that work? > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > yes, that would work, if it was acceptable to DRM upstream. The > > > > > > > replies > > > > > > > to Paul seemed to be going south so fast that I thought we > > > > > > > wouldn't get > > > > > > > any new uevent fields in favour of "epoch counters". > > > > > > > > > > > > > > > Yes that's the idea, depending upon which property you get you > > > > > > > > know > > > > > > > > it's a sink change (needs full reprobe) or something else like > > > > > > > > hdcp > > > > > > > > state machinery update. > > > > > > > > > > > > > > Right. > > > > > > > > > > > > > > > Wrt avoiding the full reprobe for sink changes: I think we > > > > > > > > should > > > > > > > > indeed decouple that from the per-connector event for sink > > > > > > > > changes. > > > > > > > > That along is a good win already, since you know for which > > > > > > > > connector > > > > > > > > you need to call drmGetConnector (which forces the reprobe). It > > > > > > > > would > > > > > > > > be nice to only call drmGetConnectorCurrent (avoids the > > > > > > > > reprobe), but > > > > > > > > historically speaking every time we tried to rely on this we > > > > > > > > ended up > > > > > > > > regretting things. > > > > > > > > > > > > > > What changed? This sounds very much what Paul suggested. Looking > > > > > > > at it > > > > > > > from userspace side: > > > > > > > > > > > > This sounds solid, some refinements below: > > > > > > > > > > > > > HOTPLUG=1 CONNECTOR=xx PROPERTY=yy > > > > > > > > > > > > > > - If yy is "Content Protection", no need to > > > > > > > drmModeGetConnector(), just > > > > > > > re-get the connector properties. > > > > > > > > > > > > > > - Kernel probably shouldn't bother sending this for properties > > > > > > > where > > > > > > > re-probe could be necessary, and send the below instead. > > > > > > > > > > > > > > > > > > I think we should assert that the kernel can get the new property > > > > > > values using drmModeGetConnectorCurrent for this case, i.e. the > > > > > > kernel > > > > > > does not expect a full reprobe. I.e. upgrade your idea from "should" > > > > > > to "must" > > > > > > > > > > Hi Daniel, > > > > > > > > > > ok, that's good. > > > > > > > > > > > Furthermore different property can indicate different kind of > > > >
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v4,1/2] drm/i915/selftests: Verify context workarounds (rev2)
== Series Details ==
Series: series starting with [v4,1/2] drm/i915/selftests: Verify context
workarounds (rev2)
URL : https://patchwork.freedesktop.org/series/60857/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6101 -> Patchwork_13047
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13047/
Known issues
Here are the changes found in Patchwork_13047 that come from known issues:
### IGT changes ###
Possible fixes
* igt@gem_exec_create@basic:
- {fi-icl-y}: [INCOMPLETE][1] ([fdo#107713]) -> [PASS][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6101/fi-icl-y/igt@gem_exec_cre...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13047/fi-icl-y/igt@gem_exec_cre...@basic.html
* igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq: [FAIL][3] ([fdo#108511]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6101/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13047/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live_objects:
- fi-pnv-d510:[INCOMPLETE][5] -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6101/fi-pnv-d510/igt@i915_selftest@live_objects.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13047/fi-pnv-d510/igt@i915_selftest@live_objects.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511
Participating hosts (51 -> 43)
--
Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-apl-guc fi-elk-e7500 fi-byt-clapper
Build changes
-
* Linux: CI_DRM_6101 -> Patchwork_13047
CI_DRM_6101: 64e63de5aac6ad2d47714d9e39c9ea7625a3242d @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4997: eff5d0db3248734845b78fcc2e2772dd4012e5af @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_13047: 27620709957bbfee5c2d2cda095efc44426b8c60 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
27620709957b drm/i915/icl: Add WaDisableBankHangMode
312d9436cd7a drm/i915/selftests: Verify context workarounds
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13047/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 8/8] drm/i915: Bump gen7+ fb size limits to 16kx16k
On Thu, May 16, 2019 at 06:33:21PM +0200, Maarten Lankhorst wrote:
> Op 09-05-2019 om 14:21 schreef Ville Syrjala:
> > From: Ville Syrjälä
> >
> > With gtt remapping in place we can use arbitrarily large
> > framebuffers. Let's bump the limits to 16kx16k on gen7+.
> > The limit was chosen to match the maximum 2D surface size
> > of the 3D engine.
> >
> > With the remapping we could easily go higher than that for the
> > display engine. However the modesetting ddx will blindly assume
> > it can handle whatever is reported via kms. The oversized
> > buffer dimensions are not caught by glamor nor Mesa until
> > finally an assert will trip when genxml attempts to pack the
> > SURFACE_STATE. So we pick a safe limit to avoid the X server
> > from crashing (or potentially misbehaving if the genxml asserts
> > are compiled out).
> >
> > Reviewed-by: Daniel Vetter
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110187
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 18 --
> > 1 file changed, 12 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index a2e4ef938d53..a495fd2dcaa3 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -15783,16 +15783,22 @@ int intel_modeset_init(struct drm_device *dev)
> > }
> > }
> >
> > - /* maximum framebuffer dimensions */
> > - if (IS_GEN(dev_priv, 2)) {
> > - dev->mode_config.max_width = 2048;
> > - dev->mode_config.max_height = 2048;
> > + /*
> > +* Maximum framebuffer dimensions, chosen to match
> > +* the maximum render engine surface size on gen4+.
> > +*/
> > + if (INTEL_GEN(dev_priv) >= 7) {
> > + dev->mode_config.max_width = 16384;
> > + dev->mode_config.max_height = 16384;
> > + } else if (INTEL_GEN(dev_priv) >= 4) {
> > + dev->mode_config.max_width = 8192;
> > + dev->mode_config.max_height = 8192;
> > } else if (IS_GEN(dev_priv, 3)) {
> > dev->mode_config.max_width = 4096;
> > dev->mode_config.max_height = 4096;
> > } else {
> > - dev->mode_config.max_width = 8192;
> > - dev->mode_config.max_height = 8192;
> > + dev->mode_config.max_width = 2048;
> > + dev->mode_config.max_height = 2048;
> > }
> >
> > if (IS_I845G(dev_priv) || IS_I865G(dev_priv)) {
>
> Should be good enough, lets not go too crazy. :)
>
> For whole series:
>
> Reviewed-by: Maarten Lankhorst
Yay! Everything rb'd so series pushed to dinq.
Thanks for the reviews everyone.
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3] drm/i915: add i2c symlink under hdmi connector
Currently, the i2c adapter is available only under DP connectors.
Add i2c symlink under hdmi connector pointing to i2c adapter in order to
make this behaviour consistent.
The initial motivation was to make igt i2c subtest
patch [1] work on all connectors.
[1]: https://patchwork.freedesktop.org/series/60357/
v2:
- Moved symlink remove to unregister (Ville)
- Clarified commit message (Jani)
- Changed WARN to DRM_ERROR (Jani)
- Minor codestyle changes proposed by Jani
v3: added blank line
Cc: Arkadiusz Hiler
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Jani Nikula
Signed-off-by: Oleg Vasilev
---
drivers/gpu/drm/i915/intel_hdmi.c | 41 ++-
1 file changed, 40 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 2a4086cf2692..a51d1408db7f 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -2658,6 +2658,36 @@ static void chv_hdmi_pre_enable(struct intel_encoder
*encoder,
chv_phy_release_cl2_override(encoder);
}
+static struct i2c_adapter *
+intel_hdmi_get_i2c_adapter(struct drm_connector *connector)
+{
+ struct drm_i915_private *dev_priv = to_i915(connector->dev);
+ struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
+
+ return intel_gmbus_get_adapter(dev_priv, intel_hdmi->ddc_bus);
+}
+
+static void intel_hdmi_create_i2c_symlink(struct drm_connector *connector)
+{
+ struct i2c_adapter *adapter = intel_hdmi_get_i2c_adapter(connector);
+ struct kobject *i2c_kobj = >dev.kobj;
+ struct kobject *connector_kobj = >kdev->kobj;
+ int ret;
+
+ ret = sysfs_create_link(connector_kobj, i2c_kobj, i2c_kobj->name);
+ if (ret)
+ DRM_ERROR("Failed to create i2c symlink (%d)\n", ret);
+}
+
+static void intel_hdmi_remove_i2c_symlink(struct drm_connector *connector)
+{
+ struct i2c_adapter *adapter = intel_hdmi_get_i2c_adapter(connector);
+ struct kobject *i2c_kobj = >dev.kobj;
+ struct kobject *connector_kobj = >kdev->kobj;
+
+ sysfs_remove_link(connector_kobj, i2c_kobj->name);
+}
+
static int
intel_hdmi_connector_register(struct drm_connector *connector)
{
@@ -2669,6 +2699,8 @@ intel_hdmi_connector_register(struct drm_connector
*connector)
i915_debugfs_connector_add(connector);
+ intel_hdmi_create_i2c_symlink(connector);
+
return ret;
}
@@ -2680,6 +2712,13 @@ static void intel_hdmi_destroy(struct drm_connector
*connector)
intel_connector_destroy(connector);
}
+static void intel_hdmi_connector_unregister(struct drm_connector *connector)
+{
+ intel_hdmi_remove_i2c_symlink(connector);
+
+ intel_connector_unregister(connector);
+}
+
static const struct drm_connector_funcs intel_hdmi_connector_funcs = {
.detect = intel_hdmi_detect,
.force = intel_hdmi_force,
@@ -2687,7 +2726,7 @@ static const struct drm_connector_funcs
intel_hdmi_connector_funcs = {
.atomic_get_property = intel_digital_connector_atomic_get_property,
.atomic_set_property = intel_digital_connector_atomic_set_property,
.late_register = intel_hdmi_connector_register,
- .early_unregister = intel_connector_unregister,
+ .early_unregister = intel_hdmi_connector_unregister,
.destroy = intel_hdmi_destroy,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
.atomic_duplicate_state = intel_digital_connector_duplicate_state,
--
2.21.0
___
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: added i2c symlink to hdmi connector (rev2)
== Series Details ==
Series: drm/i915: added i2c symlink to hdmi connector (rev2)
URL : https://patchwork.freedesktop.org/series/60794/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6101 -> Patchwork_13046
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13046/
Known issues
Here are the changes found in Patchwork_13046 that come from known issues:
### IGT changes ###
Possible fixes
* igt@gem_exec_create@basic:
- {fi-icl-y}: [INCOMPLETE][1] ([fdo#107713]) -> [PASS][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6101/fi-icl-y/igt@gem_exec_cre...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13046/fi-icl-y/igt@gem_exec_cre...@basic.html
* igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq: [FAIL][3] ([fdo#108511]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6101/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13046/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live_contexts:
- fi-bdw-gvtdvm: [DMESG-FAIL][5] ([fdo#110235]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6101/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13046/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html
* igt@i915_selftest@live_objects:
- fi-pnv-d510:[INCOMPLETE][7] -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6101/fi-pnv-d510/igt@i915_selftest@live_objects.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13046/fi-pnv-d510/igt@i915_selftest@live_objects.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511
[fdo#110235]: https://bugs.freedesktop.org/show_bug.cgi?id=110235
Participating hosts (51 -> 45)
--
Missing(6): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-byt-clapper
Build changes
-
* Linux: CI_DRM_6101 -> Patchwork_13046
CI_DRM_6101: 64e63de5aac6ad2d47714d9e39c9ea7625a3242d @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4997: eff5d0db3248734845b78fcc2e2772dd4012e5af @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_13046: 7cf050cd9642149101bf1f68a1b674d7fdefb1e4 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
7cf050cd9642 drm/i915: add i2c symlink under hdmi connector
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13046/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915/selftests: Verify context workarounds
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/selftests: Verify context
workarounds
URL : https://patchwork.freedesktop.org/series/60855/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6101 -> Patchwork_13045
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13045/
Known issues
Here are the changes found in Patchwork_13045 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_contexts:
- fi-skl-gvtdvm: [PASS][1] -> [DMESG-FAIL][2] ([fdo#110235])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6101/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13045/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html
Possible fixes
* igt@gem_exec_create@basic:
- {fi-icl-y}: [INCOMPLETE][3] ([fdo#107713]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6101/fi-icl-y/igt@gem_exec_cre...@basic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13045/fi-icl-y/igt@gem_exec_cre...@basic.html
* igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq: [FAIL][5] ([fdo#108511]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6101/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13045/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live_contexts:
- fi-bdw-gvtdvm: [DMESG-FAIL][7] ([fdo#110235]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6101/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13045/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html
* igt@i915_selftest@live_objects:
- fi-pnv-d510:[INCOMPLETE][9] -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6101/fi-pnv-d510/igt@i915_selftest@live_objects.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13045/fi-pnv-d510/igt@i915_selftest@live_objects.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511
[fdo#110235]: https://bugs.freedesktop.org/show_bug.cgi?id=110235
Participating hosts (51 -> 45)
--
Missing(6): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-byt-clapper
Build changes
-
* Linux: CI_DRM_6101 -> Patchwork_13045
CI_DRM_6101: 64e63de5aac6ad2d47714d9e39c9ea7625a3242d @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4997: eff5d0db3248734845b78fcc2e2772dd4012e5af @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_13045: edfe8289b6cf1cb456c2b4af72f3d38a54ed9a33 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
edfe8289b6cf drm/i915/icl: Add WaDisableBankHangMode
1c4ae4182178 drm/i915/selftests: Verify context workarounds
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13045/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 23/27] gem_wsim: Consolidate engine assignments into helpers
From: Tvrtko Ursulin
This will allow applying the discovered engine configuration from a single
place.
v2:
* Consolidate enum to ci conversion.
Signed-off-by: Tvrtko Ursulin
---
benchmarks/gem_wsim.c | 163 --
1 file changed, 94 insertions(+), 69 deletions(-)
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
index fe70e7719d88..02c3e9d655d8 100644
--- a/benchmarks/gem_wsim.c
+++ b/benchmarks/gem_wsim.c
@@ -365,6 +365,66 @@ static int str_to_engine(const char *str)
return -1;
}
+static unsigned int num_engines_in_class(enum intel_engine_id class)
+{
+ igt_assert(class == VCS);
+
+ return 2;
+}
+
+static void
+fill_engines_class(struct i915_engine_class_instance *ci,
+ enum intel_engine_id class)
+{
+ igt_assert(class == VCS);
+
+ ci[0].engine_class = I915_ENGINE_CLASS_VIDEO;
+ ci[0].engine_instance = 0;
+
+ ci[1].engine_class = I915_ENGINE_CLASS_VIDEO;
+ ci[1].engine_instance = 1;
+}
+
+static void
+fill_engines_id_class(enum intel_engine_id *list,
+ enum intel_engine_id class)
+{
+ igt_assert(class == VCS);
+
+ list[0] = VCS1;
+ list[1] = VCS2;
+}
+
+static struct i915_engine_class_instance
+get_engine(enum intel_engine_id engine)
+{
+ struct i915_engine_class_instance ci;
+
+ switch (engine) {
+ case RCS:
+ ci.engine_class = I915_ENGINE_CLASS_RENDER;
+ ci.engine_instance = 0;
+ break;
+ case BCS:
+ ci.engine_class = I915_ENGINE_CLASS_COPY;
+ ci.engine_instance = 0;
+ break;
+ case VCS1:
+ case VCS2:
+ ci.engine_class = I915_ENGINE_CLASS_VIDEO;
+ ci.engine_instance = engine - VCS1;
+ break;
+ case VECS:
+ ci.engine_class = I915_ENGINE_CLASS_VIDEO_ENHANCE;
+ ci.engine_instance = 0;
+ break;
+ default:
+ igt_assert(0);
+ };
+
+ return ci;
+}
+
static int parse_engine_map(struct w_step *step, const char *_str)
{
char *token, *tctx = NULL, *tstart = (char *)_str;
@@ -386,18 +446,16 @@ static int parse_engine_map(struct w_step *step, const
char *_str)
engine != RCS)
return -1; /* TODO */
- add = engine == VCS ? 2 : 1;
+ add = engine == VCS ? num_engines_in_class(VCS) : 1;
step->engine_map_count += add;
step->engine_map = realloc(step->engine_map,
step->engine_map_count *
sizeof(step->engine_map[0]));
- if (engine != VCS) {
- step->engine_map[step->engine_map_count - 1] = engine;
- } else {
- step->engine_map[step->engine_map_count - 2] = VCS1;
- step->engine_map[step->engine_map_count - 1] = VCS2;
- }
+ if (engine != VCS)
+ step->engine_map[step->engine_map_count - add] = engine;
+ else
+
fill_engines_id_class(>engine_map[step->engine_map_count - add], VCS);
}
return 0;
@@ -1148,20 +1206,11 @@ static unsigned int
find_engine(struct i915_engine_class_instance *ci, unsigned int count,
enum intel_engine_id engine)
{
- static struct i915_engine_class_instance map[] = {
- [RCS] = { I915_ENGINE_CLASS_RENDER, 0 },
- [BCS] = { I915_ENGINE_CLASS_COPY, 0 },
- [VCS1] = { I915_ENGINE_CLASS_VIDEO, 0 },
- [VCS2] = { I915_ENGINE_CLASS_VIDEO, 1 },
- [VECS] = { I915_ENGINE_CLASS_VIDEO_ENHANCE, 0 },
- };
+ struct i915_engine_class_instance e = get_engine(engine);
unsigned int i;
- igt_assert(engine < ARRAY_SIZE(map));
- igt_assert(engine == RCS || map[engine].engine_class);
-
for (i = 0; i < count; i++, ci++) {
- if (!memcmp([engine], ci, sizeof(*ci)))
+ if (!memcmp(, ci, sizeof(*ci)))
return i;
}
@@ -1465,19 +1514,9 @@ prepare_workload(unsigned int id, struct workload *wrk,
unsigned int flags)
load_balance.num_siblings =
ctx->engine_map_count;
- for (j = 0; j < ctx->engine_map_count; j++) {
- if (ctx->engine_map[j] == RCS) {
-
load_balance.engines[j].engine_class =
-
I915_ENGINE_CLASS_RENDER;
-
load_balance.engines[j].engine_instance =
- 0; /* FIXME */
- } else {
-
[Intel-gfx] [PATCH i-g-t 24/27] gem_wsim: Discover engines
From: Tvrtko Ursulin
Instead of hardcoding the VCS balancing engines, discover, both with the
new engines query, or with the legacy get_param in the fallback case, so
class based addressing always works.
v2:
* Simplify has_engine_query check. (Andi)
* Fix assert on uninitialized variable. (Andi)
Signed-off-by: Tvrtko Ursulin
---
benchmarks/gem_wsim.c | 173 --
1 file changed, 166 insertions(+), 7 deletions(-)
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
index 02c3e9d655d8..64d19ed469b0 100644
--- a/benchmarks/gem_wsim.c
+++ b/benchmarks/gem_wsim.c
@@ -365,34 +365,191 @@ static int str_to_engine(const char *str)
return -1;
}
+static bool __engines_queried;
+static unsigned int __num_engines;
+static struct i915_engine_class_instance *__engines;
+
+static int
+__i915_query(int i915, struct drm_i915_query *q)
+{
+ if (igt_ioctl(i915, DRM_IOCTL_I915_QUERY, q))
+ return -errno;
+ return 0;
+}
+
+static int
+__i915_query_items(int i915, struct drm_i915_query_item *items, uint32_t
n_items)
+{
+ struct drm_i915_query q = {
+ .num_items = n_items,
+ .items_ptr = to_user_pointer(items),
+ };
+ return __i915_query(i915, );
+}
+
+static void
+i915_query_items(int i915, struct drm_i915_query_item *items, uint32_t n_items)
+{
+ igt_assert_eq(__i915_query_items(i915, items, n_items), 0);
+}
+
+static bool has_engine_query(int i915)
+{
+ struct drm_i915_query_item item = {
+ .query_id = DRM_I915_QUERY_ENGINE_INFO,
+ };
+
+ return __i915_query_items(i915, , 1) == 0 && item.length > 0;
+}
+
+static void query_engines(void)
+{
+ struct i915_engine_class_instance *engines;
+ unsigned int num;
+
+ if (__engines_queried)
+ return;
+
+ __engines_queried = true;
+
+ if (!has_engine_query(fd)) {
+ unsigned int num_bsd = gem_has_bsd(fd) + gem_has_bsd2(fd);
+ unsigned int i = 0;
+
+ igt_assert(num_bsd);
+
+ num = 1 + num_bsd;
+
+ if (gem_has_blt(fd))
+ num++;
+
+ if (gem_has_vebox(fd))
+ num++;
+
+ engines = calloc(num,
+sizeof(struct i915_engine_class_instance));
+ igt_assert(engines);
+
+ engines[i].engine_class = I915_ENGINE_CLASS_RENDER;
+ engines[i].engine_instance = 0;
+ i++;
+
+ if (gem_has_blt(fd)) {
+ engines[i].engine_class = I915_ENGINE_CLASS_COPY;
+ engines[i].engine_instance = 0;
+ i++;
+ }
+
+ if (gem_has_bsd(fd)) {
+ engines[i].engine_class = I915_ENGINE_CLASS_VIDEO;
+ engines[i].engine_instance = 0;
+ i++;
+ }
+
+ if (gem_has_bsd2(fd)) {
+ engines[i].engine_class = I915_ENGINE_CLASS_VIDEO;
+ engines[i].engine_instance = 1;
+ i++;
+ }
+
+ if (gem_has_vebox(fd)) {
+ engines[i].engine_class =
+ I915_ENGINE_CLASS_VIDEO_ENHANCE;
+ engines[i].engine_instance = 0;
+ i++;
+ }
+ } else {
+ struct drm_i915_query_engine_info *engine_info;
+ struct drm_i915_query_item item = {
+ .query_id = DRM_I915_QUERY_ENGINE_INFO,
+ };
+ const unsigned int sz = 4096;
+ unsigned int i;
+
+ engine_info = malloc(sz);
+ igt_assert(engine_info);
+ memset(engine_info, 0, sz);
+
+ item.data_ptr = to_user_pointer(engine_info);
+ item.length = sz;
+
+ i915_query_items(fd, , 1);
+ igt_assert(item.length > 0);
+ igt_assert(item.length <= sz);
+
+ num = engine_info->num_engines;
+
+ engines = calloc(num,
+sizeof(struct i915_engine_class_instance));
+ igt_assert(engines);
+
+ for (i = 0; i < num; i++) {
+ struct drm_i915_engine_info *engine =
+ (struct drm_i915_engine_info
*)_info->engines[i];
+
+ engines[i] = engine->engine;
+ }
+ }
+
+ __engines = engines;
+ __num_engines = num;
+}
+
static unsigned int num_engines_in_class(enum intel_engine_id class)
{
+ unsigned int i, count = 0;
+
igt_assert(class == VCS);
- return 2;
+ query_engines();
+
+ for (i = 0; i < __num_engines; i++) {
+ if (__engines[i].engine_class == I915_ENGINE_CLASS_VIDEO)
+
[Intel-gfx] [PATCH i-g-t 27/27] gem_wsim: Allow random seed control
From: Tvrtko Ursulin
New command line option to allow controling the initial pseudo random
generator seed in order to allow repeatable runs.
Signed-off-by: Tvrtko Ursulin
Suggested-by: Chris Wilson
Suggested-by: Simon Ser
---
benchmarks/gem_wsim.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
index c43bbbc8c94d..e2ffb93a94d5 100644
--- a/benchmarks/gem_wsim.c
+++ b/benchmarks/gem_wsim.c
@@ -2946,6 +2946,7 @@ static void print_help(void)
" -t Nop calibration tolerance percentage.\n"
" Use when there is a difficulty obtaining calibration with
the\n"
" default settings.\n"
+" -I Initial randomness seed.\n"
" -p Context priority to use for the following workload on the\n"
" command line.\n"
" -w Filename or a workload descriptor.\n"
@@ -3119,11 +3120,9 @@ int main(int argc, char **argv)
init_clocks();
master_prng = time(NULL);
- srand(master_prng);
- master_prng = rand();
while ((c = getopt(argc, argv,
- "hqv2RsSHxGdc:n:r:w:W:a:t:b:p:")) != -1) {
+ "hqv2RsSHxGdc:n:r:w:W:a:t:b:p:I:")) != -1) {
switch (c) {
case 'W':
if (master_workload >= 0) {
@@ -3210,6 +3209,9 @@ int main(int argc, char **argv)
return 1;
}
break;
+ case 'I':
+ master_prng = strtol(optarg, NULL, 0);
+ break;
case 'h':
print_help();
return 0;
@@ -3294,6 +3296,7 @@ int main(int argc, char **argv)
clients = nr_w_args;
if (verbose > 1) {
+ printf("Random seed is %u.\n", master_prng);
printf("Using %lu nop calibration for %uus delay.\n",
nop_calibration, nop_calibration_us);
printf("%u client%s.\n", clients, clients > 1 ? "s" : "");
@@ -3312,6 +3315,9 @@ int main(int argc, char **argv)
}
}
+ srand(master_prng);
+ master_prng = rand();
+
if (master_workload >= 0 && clients == 1)
master_workload = -1;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 26/27] gem_wsim: Fix prng usage
From: Tvrtko Ursulin
Back when gem_wsim used forking it was safe to use the common storage
prng, but after converting to threads it no longer is.
Fix by storing and using a new per workload seed for batch buffer
duration randomness.
Signed-off-by: Tvrtko Ursulin
---
benchmarks/gem_wsim.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
index 0ccb271575f7..c43bbbc8c94d 100644
--- a/benchmarks/gem_wsim.c
+++ b/benchmarks/gem_wsim.c
@@ -193,6 +193,7 @@ struct workload
unsigned int flags;
bool print_stats;
+ uint32_t bb_prng;
uint32_t prng;
struct timespec repeat_start;
@@ -240,6 +241,8 @@ struct workload
static const unsigned int nop_calibration_us = 1000;
static unsigned long nop_calibration;
+static unsigned int master_prng;
+
static unsigned int context_vcs_rr;
static int verbose = 1;
@@ -1067,14 +1070,14 @@ clone_workload(struct workload *_wrk)
#define PAGE_SIZE (4096)
#endif
-static unsigned int get_duration(struct w_step *w)
+static unsigned int get_duration(struct workload *wrk, struct w_step *w)
{
struct duration *dur = >duration;
if (dur->min == dur->max)
return dur->min;
else
- return dur->min + hars_petruska_f54_1_random_unsafe() %
+ return dur->min + hars_petruska_f54_1_random(>bb_prng) %
(dur->max + 1 - dur->min);
}
@@ -1448,6 +1451,7 @@ prepare_workload(unsigned int id, struct workload *wrk,
unsigned int flags)
wrk->id = id;
wrk->prng = rand();
+ wrk->bb_prng = (wrk->flags & SYNCEDCLIENTS) ? master_prng : rand();
wrk->run = true;
ctx_vcs = 0;
@@ -2607,7 +2611,7 @@ do_eb(struct workload *wrk, struct w_step *w, enum
intel_engine_id engine,
w->eb.batch_start_offset =
w->unbound_duration ?
0 :
- ALIGN(w->bb_sz - get_bb_sz(get_duration(w)),
+ ALIGN(w->bb_sz - get_bb_sz(get_duration(wrk, w)),
2 * sizeof(uint32_t));
for (i = 0; i < w->fence_deps.nr; i++) {
@@ -2676,9 +2680,6 @@ static void *run_workload(void *data)
clock_gettime(CLOCK_MONOTONIC, _start);
- hars_petruska_f54_1_random_seed((wrk->flags & SYNCEDCLIENTS) ?
- 0 : wrk->id);
-
init_status_page(wrk, INIT_ALL);
for (count = 0; wrk->run && (wrk->background || count < wrk->repeat);
count++) {
@@ -3117,6 +3118,10 @@ int main(int argc, char **argv)
init_clocks();
+ master_prng = time(NULL);
+ srand(master_prng);
+ master_prng = rand();
+
while ((c = getopt(argc, argv,
"hqv2RsSHxGdc:n:r:w:W:a:t:b:p:")) != -1) {
switch (c) {
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 20/27] gem_wsim: Per context SSEU control
From: Tvrtko Ursulin
A new workload command ('S') is added which allows per context slice
(re-)configuration.
v2:
* Only query device SSEU on first use. (Chris)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
benchmarks/gem_wsim.c | 83 --
benchmarks/wsim/README | 23 +++-
2 files changed, 94 insertions(+), 12 deletions(-)
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
index 8dd887a5afd8..ede505e537fd 100644
--- a/benchmarks/gem_wsim.c
+++ b/benchmarks/gem_wsim.c
@@ -87,6 +87,7 @@ enum w_type
LOAD_BALANCE,
BOND,
TERMINATE,
+ SSEU
};
struct deps
@@ -136,6 +137,7 @@ struct w_step
uint64_t bond_mask;
enum intel_engine_id bond_master;
};
+ int sseu;
};
/* Implementation details */
@@ -171,6 +173,7 @@ struct ctx {
bool targets_instance;
bool wants_balance;
unsigned int static_vcs;
+ uint64_t sseu;
};
struct workload
@@ -241,6 +244,9 @@ static unsigned int context_vcs_rr;
static int verbose = 1;
static int fd;
+static struct drm_i915_gem_context_param_sseu device_sseu = {
+ .slice_mask = -1 /* Force read on first use. */
+};
#define SWAPVCS(1<<0)
#define SEQNO (1<<1)
@@ -482,6 +488,27 @@ parse_workload(struct w_arg *arg, unsigned int flags,
struct workload *app_w)
int_field(SYNC, target,
tmp >= 0 || ((int)nr_steps + tmp) < 0,
"Invalid sync target at step %u!\n");
+ } else if (!strcmp(field, "S")) {
+ unsigned int nr = 0;
+ while ((field = strtok_r(fstart, ".", ))) {
+ tmp = atoi(field);
+ check_arg(tmp <= 0 && nr == 0,
+ "Invalid context at step
%u!\n",
+ nr_steps);
+ check_arg(nr > 1,
+ "Invalid SSEU format at step
%u!\n",
+ nr_steps);
+
+ if (nr == 0)
+ step.context = tmp;
+ else if (nr == 1)
+ step.sseu = tmp;
+
+ nr++;
+ }
+
+ step.type = SSEU;
+ goto add_step;
} else if (!strcmp(field, "t")) {
int_field(THROTTLE, throttle,
tmp < 0,
@@ -1141,24 +1168,38 @@ find_engine(struct i915_engine_class_instance *ci,
unsigned int count,
return 0;
}
-static void
-set_ctx_sseu(uint32_t ctx)
+static struct drm_i915_gem_context_param_sseu get_device_sseu(void)
{
- struct drm_i915_gem_context_param_sseu sseu = { };
struct drm_i915_gem_context_param param = { };
- sseu.class = I915_ENGINE_CLASS_RENDER;
- sseu.instance = 0;
+ if (device_sseu.slice_mask == -1) {
+ param.param = I915_CONTEXT_PARAM_SSEU;
+ param.value = (uintptr_t)_sseu;
+
+ gem_context_get_param(fd, );
+ }
+
+ return device_sseu;
+}
+
+static uint64_t
+set_ctx_sseu(uint32_t ctx, uint64_t slice_mask)
+{
+ struct drm_i915_gem_context_param_sseu sseu = get_device_sseu();
+ struct drm_i915_gem_context_param param = { };
+
+ if (slice_mask == -1)
+ slice_mask = device_sseu.slice_mask;
+
+ sseu.slice_mask = slice_mask;
param.ctx_id = ctx;
param.param = I915_CONTEXT_PARAM_SSEU;
param.value = (uintptr_t)
- gem_context_get_param(fd, );
-
- sseu.slice_mask = 1;
-
gem_context_set_param(fd, );
+
+ return slice_mask;
}
static int
@@ -1352,6 +1393,7 @@ prepare_workload(unsigned int id, struct workload *wrk,
unsigned int flags)
igt_assert(ctx_id);
ctx->id = ctx_id;
+ ctx->sseu = device_sseu.slice_mask;
if (flags & GLOBAL_BALANCE) {
ctx->static_vcs = context_vcs_rr;
@@ -1512,8 +1554,10 @@ prepare_workload(unsigned int id, struct workload *wrk,
unsigned int flags)
gem_context_set_param(fd, );
}
- if (wrk->sseu)
- set_ctx_sseu(arg.ctx_id);
+ if (wrk->sseu) {
+ /* Set to slice 0 only, one slice. */
+ ctx->sseu = set_ctx_sseu(ctx_id, 1);
+ }
if (share_vm)
[Intel-gfx] [PATCH i-g-t 25/27] gem_wsim: Support Icelake parts
From: Tvrtko Ursulin
On Icelake second vcs engine is vcs2 instead of vcs1 so add some logical
to physical instance remapping based on engine discovery to support it.
v2:
* Rebase.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
benchmarks/gem_wsim.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
index 64d19ed469b0..0ccb271575f7 100644
--- a/benchmarks/gem_wsim.c
+++ b/benchmarks/gem_wsim.c
@@ -552,6 +552,26 @@ fill_engines_id_class(enum intel_engine_id *list,
}
}
+static unsigned int
+find_physical_instance(enum intel_engine_id class, unsigned int logical)
+{
+ unsigned int i, j = 0;
+
+ igt_assert(class == VCS);
+
+ for (i = 0; i < __num_engines; i++) {
+ if (__engines[i].engine_class != I915_ENGINE_CLASS_VIDEO)
+ continue;
+
+ /* Map logical to physical instances. */
+ if (logical == j++)
+ return __engines[i].engine_instance;
+ }
+
+ igt_assert(0);
+ return 0;
+}
+
static struct i915_engine_class_instance
get_engine(enum intel_engine_id engine)
{
@@ -571,7 +591,7 @@ get_engine(enum intel_engine_id engine)
case VCS1:
case VCS2:
ci.engine_class = I915_ENGINE_CLASS_VIDEO;
- ci.engine_instance = engine - VCS1;
+ ci.engine_instance = find_physical_instance(VCS, engine - VCS1);
break;
case VECS:
ci.engine_class = I915_ENGINE_CLASS_VIDEO_ENHANCE;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 21/27] gem_wsim: Allow RCS virtual engine with SSEU control
From: Tvrtko Ursulin
To allow exercising the SSEU configuration in combination with Virtual
Engine, allow RCS to be specified in the engine map and use appropriate
index based addressing when applying SSEU configuration to it.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
benchmarks/gem_wsim.c | 51 ++-
1 file changed, 36 insertions(+), 15 deletions(-)
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
index ede505e537fd..fe70e7719d88 100644
--- a/benchmarks/gem_wsim.c
+++ b/benchmarks/gem_wsim.c
@@ -382,7 +382,8 @@ static int parse_engine_map(struct w_step *step, const char
*_str)
if ((int)engine < 0)
return -1;
- if (engine != VCS && engine != VCS1 && engine != VCS2)
+ if (engine != VCS && engine != VCS1 && engine != VCS2 &&
+ engine != RCS)
return -1; /* TODO */
add = engine == VCS ? 2 : 1;
@@ -1183,7 +1184,7 @@ static struct drm_i915_gem_context_param_sseu
get_device_sseu(void)
}
static uint64_t
-set_ctx_sseu(uint32_t ctx, uint64_t slice_mask)
+set_ctx_sseu(struct ctx *ctx, uint64_t slice_mask)
{
struct drm_i915_gem_context_param_sseu sseu = get_device_sseu();
struct drm_i915_gem_context_param param = { };
@@ -1191,10 +1192,17 @@ set_ctx_sseu(uint32_t ctx, uint64_t slice_mask)
if (slice_mask == -1)
slice_mask = device_sseu.slice_mask;
+ if (ctx->engine_map && ctx->wants_balance) {
+ sseu.flags = I915_CONTEXT_SSEU_FLAG_ENGINE_INDEX;
+ sseu.engine.engine_class = I915_ENGINE_CLASS_INVALID;
+ sseu.engine.engine_instance = 0;
+ }
+
sseu.slice_mask = slice_mask;
- param.ctx_id = ctx;
+ param.ctx_id = ctx->id;
param.param = I915_CONTEXT_PARAM_SSEU;
+ param.size = sizeof(sseu);
param.value = (uintptr_t)
gem_context_set_param(fd, );
@@ -1458,10 +1466,17 @@ prepare_workload(unsigned int id, struct workload *wrk,
unsigned int flags)
ctx->engine_map_count;
for (j = 0; j < ctx->engine_map_count; j++) {
- load_balance.engines[j].engine_class =
- I915_ENGINE_CLASS_VIDEO; /*
FIXME */
- load_balance.engines[j].engine_instance
=
- ctx->engine_map[j] - VCS1; /*
FIXME */
+ if (ctx->engine_map[j] == RCS) {
+
load_balance.engines[j].engine_class =
+
I915_ENGINE_CLASS_RENDER;
+
load_balance.engines[j].engine_instance =
+ 0; /* FIXME */
+ } else {
+
load_balance.engines[j].engine_class =
+
I915_ENGINE_CLASS_VIDEO; /* FIXME */
+
load_balance.engines[j].engine_instance =
+ ctx->engine_map[j] -
VCS1; /* FIXME */
+ }
}
} else {
set_engines.extensions = 0;
@@ -1474,10 +1489,16 @@ prepare_workload(unsigned int id, struct workload *wrk,
unsigned int flags)
I915_ENGINE_CLASS_INVALID_NONE;
for (j = 1; j <= ctx->engine_map_count; j++) {
- set_engines.engines[j].engine_class =
- I915_ENGINE_CLASS_VIDEO; /* FIXME */
- set_engines.engines[j].engine_instance =
- ctx->engine_map[j - 1] - VCS1; /* FIXME
*/
+ if (ctx->engine_map[j - 1] == RCS) {
+ set_engines.engines[j].engine_class =
+ I915_ENGINE_CLASS_RENDER;
+ set_engines.engines[j].engine_instance
= 0; /* FIXME */
+ } else {
+ set_engines.engines[j].engine_class =
+ I915_ENGINE_CLASS_VIDEO; /*
FIXME */
+ set_engines.engines[j].engine_instance =
+ ctx->engine_map[j - 1] - VCS1;
/* FIXME */
+ }
}
for (j = 0; j < ctx->bond_count; j++) {
@@ -1556,7 +1577,7 @@ prepare_workload(unsigned
[Intel-gfx] [PATCH i-g-t 17/27] gem_wsim: Some more example workloads
From: Tvrtko Ursulin A few additional workloads useful for experimenting with scheduling. Signed-off-by: Tvrtko Ursulin Acked-by: Chris Wilson --- benchmarks/wsim/frame-split-60fps.wsim | 16 benchmarks/wsim/high-composited-game.wsim | 11 +++ benchmarks/wsim/media-1080p-player.wsim | 5 + benchmarks/wsim/medium-composited-game.wsim | 9 + 4 files changed, 41 insertions(+) create mode 100644 benchmarks/wsim/frame-split-60fps.wsim create mode 100644 benchmarks/wsim/high-composited-game.wsim create mode 100644 benchmarks/wsim/media-1080p-player.wsim create mode 100644 benchmarks/wsim/medium-composited-game.wsim diff --git a/benchmarks/wsim/frame-split-60fps.wsim b/benchmarks/wsim/frame-split-60fps.wsim new file mode 100644 index ..20fdcf8c8b4a --- /dev/null +++ b/benchmarks/wsim/frame-split-60fps.wsim @@ -0,0 +1,16 @@ +X.1.0 +M.1.VCS1 +B.1 +X.2.0 +M.2.VCS2 +B.2 +b.2.VCS2.VCS1 +f +1.DEFAULT.4000-6000.f-1.0 +2.DEFAULT.4000-6000.s-1.0 +a.-3 +3.RCS.2000-4000.-3/-2.0 +3.VECS.2000.-1.0 +4.BCS.1000.-1.0 +s.-2 +p.16667 diff --git a/benchmarks/wsim/high-composited-game.wsim b/benchmarks/wsim/high-composited-game.wsim new file mode 100644 index ..a90a2b2be95b --- /dev/null +++ b/benchmarks/wsim/high-composited-game.wsim @@ -0,0 +1,11 @@ +1.RCS.500.0.0 +1.RCS.2000.0.0 +1.RCS.2000.0.0 +1.RCS.2000.0.0 +1.RCS.2000.0.0 +1.RCS.2000.0.0 +1.RCS.2000.0.0 +P.2.1 +2.BCS.1000.-2.0 +2.RCS.2000.-1.1 +p.16667 diff --git a/benchmarks/wsim/media-1080p-player.wsim b/benchmarks/wsim/media-1080p-player.wsim new file mode 100644 index ..bcbb0cfd2ad3 --- /dev/null +++ b/benchmarks/wsim/media-1080p-player.wsim @@ -0,0 +1,5 @@ +1.VCS.5000-1.0.0 +2.RCS.1000-2000.-1.0 +P.3.1 +3.BCS.1000.-2.0 +p.16667 diff --git a/benchmarks/wsim/medium-composited-game.wsim b/benchmarks/wsim/medium-composited-game.wsim new file mode 100644 index ..580883516168 --- /dev/null +++ b/benchmarks/wsim/medium-composited-game.wsim @@ -0,0 +1,9 @@ +1.RCS.1000-2000.0.0 +1.RCS.1000-2000.0.0 +1.RCS.1000-2000.0.0 +1.RCS.1000-2000.0.0 +1.RCS.1000-2000.0.0 +P.2.1 +2.BCS.1000.-2.0 +2.RCS.2000.-1.1 +p.16667 -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 18/27] gem_wsim: Infinite batch support
From: Tvrtko Ursulin
For simulating frame split workloads it is useful to express a batch which
ends at the same time as the parallel submission on the respective bonded
engine. For this we add support for infinite batch durations and the batch
terminate command ('T'). Syntax looks like this:
1.RCS.*.0.0
T.-1
First step starts an infinite batch, and second command terminates the
infinite batch with the usual relative workload step addressing.
v2: (Chris)
* Relax the recursive batch with 4096 nops between BB_START.
* Check for at least gen8.
* Simplify relocation entry building.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson # v1
---
benchmarks/gem_wsim.c | 124 ++---
benchmarks/wsim/README | 9 +-
benchmarks/wsim/frame-split-60fps.wsim | 6 +-
3 files changed, 104 insertions(+), 35 deletions(-)
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
index 6fb6c8cef2c7..47a1ddaf8792 100644
--- a/benchmarks/gem_wsim.c
+++ b/benchmarks/gem_wsim.c
@@ -86,6 +86,7 @@ enum w_type
ENGINE_MAP,
LOAD_BALANCE,
BOND,
+ TERMINATE,
};
struct deps
@@ -113,6 +114,7 @@ struct w_step
unsigned int context;
unsigned int engine;
struct duration duration;
+ bool unbound_duration;
struct deps data_deps;
struct deps fence_deps;
int emit_fence;
@@ -143,7 +145,7 @@ struct w_step
struct drm_i915_gem_execbuffer2 eb;
struct drm_i915_gem_exec_object2 *obj;
- struct drm_i915_gem_relocation_entry reloc[4];
+ struct drm_i915_gem_relocation_entry reloc[5];
unsigned long bb_sz;
uint32_t bb_handle;
uint32_t *seqno_value;
@@ -153,6 +155,7 @@ struct w_step
uint32_t *rt1_address;
uint32_t *latch_value;
uint32_t *latch_address;
+ uint32_t *recursive_bb_start;
};
DECLARE_EWMA(uint64_t, rt, 4, 2)
@@ -517,6 +520,10 @@ parse_workload(struct w_arg *arg, unsigned int flags,
struct workload *app_w)
step.type = ENGINE_MAP;
goto add_step;
+ } else if (!strcmp(field, "T")) {
+ int_field(TERMINATE, target,
+ tmp >= 0 || ((int)nr_steps + tmp) < 0,
+ "Invalid terminate target at step
%u!\n");
} else if (!strcmp(field, "X")) {
unsigned int nr = 0;
while ((field = strtok_r(fstart, ".", ))) {
@@ -632,23 +639,31 @@ parse_workload(struct w_arg *arg, unsigned int flags,
struct workload *app_w)
fstart = NULL;
- tmpl = strtol(field, , 10);
- check_arg(tmpl <= 0 || tmpl == LONG_MIN ||
- tmpl == LONG_MAX,
- "Invalid duration at step %u!\n", nr_steps);
- step.duration.min = tmpl;
-
- if (sep && *sep == '-') {
- tmpl = strtol(sep + 1, NULL, 10);
- check_arg(tmpl <= 0 ||
- tmpl <= step.duration.min ||
- tmpl == LONG_MIN ||
- tmpl == LONG_MAX,
- "Invalid duration range at step
%u!\n",
+ if (field[0] == '*') {
+ check_arg(intel_gen(intel_get_drm_devid(fd)) <
8,
+ "Infinite batch at step %u needs
Gen8+!\n",
nr_steps);
- step.duration.max = tmpl;
+ step.unbound_duration = true;
} else {
- step.duration.max = step.duration.min;
+ tmpl = strtol(field, , 10);
+ check_arg(tmpl <= 0 || tmpl == LONG_MIN ||
+ tmpl == LONG_MAX,
+ "Invalid duration at step %u!\n",
+ nr_steps);
+ step.duration.min = tmpl;
+
+ if (sep && *sep == '-') {
+ tmpl = strtol(sep + 1, NULL, 10);
+ check_arg(tmpl <= 0 ||
+ tmpl <= step.duration.min ||
+ tmpl == LONG_MIN ||
+ tmpl == LONG_MAX,
+ "Invalid duration range at step
%u!\n",
+ nr_steps);
+
[Intel-gfx] [PATCH i-g-t 22/27] tests/i915_query: Engine discovery tests
From: Tvrtko Ursulin
Test the new engine discovery query.
Signed-off-by: Tvrtko Ursulin
---
tests/i915/i915_query.c | 247
1 file changed, 247 insertions(+)
diff --git a/tests/i915/i915_query.c b/tests/i915/i915_query.c
index 7d0c0e3a061c..ecbec3ae141d 100644
--- a/tests/i915/i915_query.c
+++ b/tests/i915/i915_query.c
@@ -483,6 +483,241 @@ test_query_topology_known_pci_ids(int fd, int devid)
free(topo_info);
}
+static bool query_engine_info_supported(int fd)
+{
+ struct drm_i915_query_item item = {
+ .query_id = DRM_I915_QUERY_ENGINE_INFO,
+ };
+
+ return __i915_query_items(fd, , 1) == 0 && item.length > 0;
+}
+
+static void engines_invalid(int fd)
+{
+ struct drm_i915_query_engine_info *engines;
+ struct drm_i915_query_item item;
+ unsigned int len;
+
+ /* Flags is MBZ. */
+ memset(, 0, sizeof(item));
+ item.query_id = DRM_I915_QUERY_ENGINE_INFO;
+ item.flags = 1;
+ i915_query_items(fd, , 1);
+ igt_assert_eq(item.length, -EINVAL);
+
+ /* Length not zero and not greater or equal required size. */
+ memset(, 0, sizeof(item));
+ item.query_id = DRM_I915_QUERY_ENGINE_INFO;
+ item.length = 1;
+ i915_query_items(fd, , 1);
+ igt_assert_eq(item.length, -EINVAL);
+
+ /* Query correct length. */
+ memset(, 0, sizeof(item));
+ item.query_id = DRM_I915_QUERY_ENGINE_INFO;
+ i915_query_items(fd, , 1);
+ igt_assert(item.length >= 0);
+ len = item.length;
+
+ engines = malloc(len);
+ igt_assert(engines);
+
+ /* Ivalid pointer. */
+ memset(, 0, sizeof(item));
+ item.query_id = DRM_I915_QUERY_ENGINE_INFO;
+ item.length = len;
+ i915_query_items(fd, , 1);
+ igt_assert_eq(item.length, -EFAULT);
+
+ /* All fields in engines query are MBZ and only filled by the kernel. */
+
+ memset(engines, 0, len);
+ engines->num_engines = 1;
+ memset(, 0, sizeof(item));
+ item.query_id = DRM_I915_QUERY_ENGINE_INFO;
+ item.length = len;
+ item.data_ptr = to_user_pointer(engines);
+ i915_query_items(fd, , 1);
+ igt_assert_eq(item.length, -EINVAL);
+
+ memset(engines, 0, len);
+ engines->rsvd[0] = 1;
+ memset(, 0, sizeof(item));
+ item.query_id = DRM_I915_QUERY_ENGINE_INFO;
+ item.length = len;
+ item.data_ptr = to_user_pointer(engines);
+ i915_query_items(fd, , 1);
+ igt_assert_eq(item.length, -EINVAL);
+
+ memset(engines, 0, len);
+ engines->rsvd[1] = 1;
+ memset(, 0, sizeof(item));
+ item.query_id = DRM_I915_QUERY_ENGINE_INFO;
+ item.length = len;
+ item.data_ptr = to_user_pointer(engines);
+ i915_query_items(fd, , 1);
+ igt_assert_eq(item.length, -EINVAL);
+
+ memset(engines, 0, len);
+ engines->rsvd[2] = 1;
+ memset(, 0, sizeof(item));
+ item.query_id = DRM_I915_QUERY_ENGINE_INFO;
+ item.length = len;
+ item.data_ptr = to_user_pointer(engines);
+ i915_query_items(fd, , 1);
+ igt_assert_eq(item.length, -EINVAL);
+
+ free(engines);
+
+ igt_assert(len <= 4096);
+ engines = mmap(0, 4096, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON,
+ -1, 0);
+ igt_assert(engines != MAP_FAILED);
+
+ /* PROT_NONE is similar to unmapped area. */
+ memset(engines, 0, len);
+ igt_assert_eq(mprotect(engines, len, PROT_NONE), 0);
+ memset(, 0, sizeof(item));
+ item.query_id = DRM_I915_QUERY_ENGINE_INFO;
+ item.length = len;
+ item.data_ptr = to_user_pointer(engines);
+ i915_query_items(fd, , 1);
+ igt_assert_eq(item.length, -EFAULT);
+ igt_assert_eq(mprotect(engines, len, PROT_WRITE), 0);
+
+ /* Read-only so kernel cannot fill the data back. */
+ memset(engines, 0, len);
+ igt_assert_eq(mprotect(engines, len, PROT_READ), 0);
+ memset(, 0, sizeof(item));
+ item.query_id = DRM_I915_QUERY_ENGINE_INFO;
+ item.length = len;
+ item.data_ptr = to_user_pointer(engines);
+ i915_query_items(fd, , 1);
+ igt_assert_eq(item.length, -EFAULT);
+
+ munmap(engines, 4096);
+}
+
+static bool
+has_engine(struct drm_i915_query_engine_info *engines,
+ unsigned class, unsigned instance)
+{
+ unsigned int i;
+
+ for (i = 0; i < engines->num_engines; i++) {
+ struct drm_i915_engine_info *engine =
+ (struct drm_i915_engine_info *)>engines[i];
+
+ if (engine->engine.engine_class == class &&
+ engine->engine.engine_instance == instance)
+ return true;
+ }
+
+ return false;
+}
+
+static void engines(int fd)
+{
+ struct drm_i915_query_engine_info *engines;
+ struct drm_i915_query_item item;
+ unsigned int len, i;
+
+ engines =
[Intel-gfx] [PATCH i-g-t 15/27] gem_wsim: Engine map load balance command
From: Tvrtko Ursulin
A new workload command for enabling a load balanced context map (aka
Virtual Engine). Example usage:
B.1
This turns on load balancing for context one, assuming it has already been
configured with an engine map. Only DEFAULT engine specifier can be used
with load balanced engine maps.
v2:
* Lift restriction to only use load balancer when enabled in context map.
(Chris)
Signed-off-by: Tvrtko Ursulin
---
benchmarks/gem_wsim.c | 66 +-
benchmarks/wsim/README | 15 ++
2 files changed, 74 insertions(+), 7 deletions(-)
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
index 66832f74e34a..d645611cf8c2 100644
--- a/benchmarks/gem_wsim.c
+++ b/benchmarks/gem_wsim.c
@@ -83,7 +83,8 @@ enum w_type
SW_FENCE_SIGNAL,
CTX_PRIORITY,
PREEMPTION,
- ENGINE_MAP
+ ENGINE_MAP,
+ LOAD_BALANCE,
};
struct deps
@@ -121,6 +122,7 @@ struct w_step
unsigned int engine_map_count;
enum intel_engine_id *engine_map;
};
+ bool load_balance;
};
/* Implementation details */
@@ -507,6 +509,25 @@ parse_workload(struct w_arg *arg, unsigned int flags,
struct workload *app_w)
step.type = PREEMPTION;
goto add_step;
+ } else if (!strcmp(field, "B")) {
+ unsigned int nr = 0;
+ while ((field = strtok_r(fstart, ".", ))) {
+ tmp = atoi(field);
+ check_arg(nr == 0 && tmp <= 0,
+ "Invalid context at step
%u!\n",
+ nr_steps);
+ check_arg(nr > 0,
+ "Invalid load balance format
at step %u!\n",
+ nr_steps);
+
+ step.context = tmp;
+ step.load_balance = true;
+
+ nr++;
+ }
+
+ step.type = LOAD_BALANCE;
+ goto add_step;
}
if (!field) {
@@ -841,7 +862,7 @@ find_engine_in_map(struct ctx *ctx, enum intel_engine_id
engine)
return i + 1;
}
- igt_assert(0);
+ igt_assert(ctx->wants_balance);
return 0;
}
@@ -1073,12 +1094,19 @@ prepare_workload(unsigned int id, struct workload *wrk,
unsigned int flags)
wrk->ctx_list[j].engine_map = w->engine_map;
wrk->ctx_list[j].engine_map_count =
w->engine_map_count;
+ } else if (w->type == LOAD_BALANCE) {
+ if (!wrk->ctx_list[j].engine_map) {
+ wsim_err("Load balancing needs an
engine map!\n");
+ return 1;
+ }
+ wrk->ctx_list[j].wants_balance =
+ w->load_balance;
}
}
wrk->ctx_list[j].targets_instance = targets;
if (flags & I915)
- wrk->ctx_list[j].wants_balance = balance;
+ wrk->ctx_list[j].wants_balance |= balance;
}
/*
@@ -1092,7 +1120,9 @@ prepare_workload(unsigned int id, struct workload *wrk,
unsigned int flags)
if (w->type != BATCH)
continue;
- if (wrk->ctx_list[j].engine_map && w->engine == VCS) {
+ if (wrk->ctx_list[j].engine_map &&
+ !wrk->ctx_list[j].wants_balance &&
+ (w->engine == VCS || w->engine == DEFAULT)) {
wsim_err("Batches targetting engine maps must
use explicit engines!\n");
return -1;
}
@@ -1140,7 +1170,8 @@ prepare_workload(unsigned int id, struct workload *wrk,
unsigned int flags)
break;
}
- if (!ctx->engine_map && !ctx->targets_instance)
+ if ((!ctx->engine_map && !ctx->targets_instance) ||
+ (ctx->engine_map && ctx->wants_balance))
args.flags |=
I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE;
@@ -1201,6 +1232,8 @@ prepare_workload(unsigned int id, struct workload *wrk,
unsigned int flags)
if (ctx->engine_map) {
[Intel-gfx] [PATCH i-g-t 19/27] gem_wsim: Command line switch for specifying low slice count workloads
From: Tvrtko Ursulin
A new command line switch ('-s') is added which toggles the low slice
count mode for workloads following on the command line.
This enables easy benchmarking of the effect of running the existing media
workloads in parallel against another client. For example:
./gem_wsim -n ... -v -r 600 -W master.wsim -s -w media_nn480.wsim
Adding or removing the '-s' switch before the second workload enables
analyzing the cost of dynamic SSEU switching impacted to the first
(master) workload.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
benchmarks/gem_wsim.c | 44 +++
1 file changed, 40 insertions(+), 4 deletions(-)
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
index 47a1ddaf8792..8dd887a5afd8 100644
--- a/benchmarks/gem_wsim.c
+++ b/benchmarks/gem_wsim.c
@@ -100,6 +100,7 @@ struct w_arg {
char *filename;
char *desc;
int prio;
+ bool sseu;
};
struct bond {
@@ -179,6 +180,7 @@ struct workload
unsigned int nr_steps;
struct w_step *steps;
int prio;
+ bool sseu;
pthread_t thread;
bool run;
@@ -251,6 +253,7 @@ static int fd;
#define GLOBAL_BALANCE (1<<8)
#define DEPSYNC(1<<9)
#define I915 (1<<10)
+#define SSEU (1<<11)
#define SEQNO_IDX(engine) ((engine) * 16)
#define SEQNO_OFFSET(engine) (SEQNO_IDX(engine) * sizeof(uint32_t))
@@ -726,6 +729,7 @@ add_step:
wrk->nr_steps = nr_steps;
wrk->steps = steps;
wrk->prio = arg->prio;
+ wrk->sseu = arg->sseu;
free(desc);
@@ -771,6 +775,7 @@ clone_workload(struct workload *_wrk)
memset(wrk, 0, sizeof(*wrk));
wrk->prio = _wrk->prio;
+ wrk->sseu = _wrk->sseu;
wrk->nr_steps = _wrk->nr_steps;
wrk->steps = calloc(wrk->nr_steps, sizeof(struct w_step));
igt_assert(wrk->steps);
@@ -1136,6 +1141,26 @@ find_engine(struct i915_engine_class_instance *ci,
unsigned int count,
return 0;
}
+static void
+set_ctx_sseu(uint32_t ctx)
+{
+ struct drm_i915_gem_context_param_sseu sseu = { };
+ struct drm_i915_gem_context_param param = { };
+
+ sseu.class = I915_ENGINE_CLASS_RENDER;
+ sseu.instance = 0;
+
+ param.ctx_id = ctx;
+ param.param = I915_CONTEXT_PARAM_SSEU;
+ param.value = (uintptr_t)
+
+ gem_context_get_param(fd, );
+
+ sseu.slice_mask = 1;
+
+ gem_context_set_param(fd, );
+}
+
static int
prepare_workload(unsigned int id, struct workload *wrk, unsigned int flags)
{
@@ -1487,6 +1512,9 @@ prepare_workload(unsigned int id, struct workload *wrk,
unsigned int flags)
gem_context_set_param(fd, );
}
+ if (wrk->sseu)
+ set_ctx_sseu(arg.ctx_id);
+
if (share_vm)
vm_destroy(fd, share_vm);
}
@@ -2661,6 +2689,8 @@ static void print_help(void)
" -R Round-robin initial VCS assignment per client.\n"
" -H Send heartbeat on synchronisation points with seqno based\n"
" balancers. Gives better engine busyness view in some
cases.\n"
+" -s Turn on small SSEU config for the next workload on the\n"
+" command line. Subsequent -s switches it off.\n"
" -S Synchronize the sequence of random batch durations
between\n"
" clients.\n"
" -G Global load balancing - a single load balancer will be
shared\n"
@@ -2703,11 +2733,12 @@ static char *load_workload_descriptor(char *filename)
}
static struct w_arg *
-add_workload_arg(struct w_arg *w_args, unsigned int nr_args, char *w_arg, int
prio)
+add_workload_arg(struct w_arg *w_args, unsigned int nr_args, char *w_arg,
+int prio, bool sseu)
{
w_args = realloc(w_args, sizeof(*w_args) * nr_args);
igt_assert(w_args);
- w_args[nr_args - 1] = (struct w_arg) { w_arg, NULL, prio };
+ w_args[nr_args - 1] = (struct w_arg) { w_arg, NULL, prio, sseu };
return w_args;
}
@@ -2800,7 +2831,8 @@ int main(int argc, char **argv)
init_clocks();
- while ((c = getopt(argc, argv, "hqv2RSHxGdc:n:r:w:W:a:t:b:p:")) != -1) {
+ while ((c = getopt(argc, argv,
+ "hqv2RsSHxGdc:n:r:w:W:a:t:b:p:")) != -1) {
switch (c) {
case 'W':
if (master_workload >= 0) {
@@ -2810,7 +2842,8 @@ int main(int argc, char **argv)
master_workload = nr_w_args;
/* Fall through */
case 'w':
- w_args = add_workload_arg(w_args, ++nr_w_args, optarg,
prio);
+ w_args = add_workload_arg(w_args, ++nr_w_args, optarg,
+ prio, flags & SSEU);
break;
case 'p':
[Intel-gfx] [PATCH i-g-t 13/27] gem_wsim: Save some lines by changing to implicit NULL checking
From: Tvrtko Ursulin
We can improve the parsing loop readability a bit more by avoiding some
line breaks caused by explicit NULL checks.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
benchmarks/gem_wsim.c | 39 +++
1 file changed, 15 insertions(+), 24 deletions(-)
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
index e5b12e37490e..baa389c3f0e7 100644
--- a/benchmarks/gem_wsim.c
+++ b/benchmarks/gem_wsim.c
@@ -391,7 +391,7 @@ parse_workload(struct w_arg *arg, unsigned int flags,
struct workload *app_w)
igt_assert(desc);
- while ((_token = strtok_r(tstart, ",", )) != NULL) {
+ while ((_token = strtok_r(tstart, ",", ))) {
tstart = NULL;
token = strdup(_token);
igt_assert(token);
@@ -399,12 +399,11 @@ parse_workload(struct w_arg *arg, unsigned int flags,
struct workload *app_w)
valid = 0;
memset(, 0, sizeof(step));
- if ((field = strtok_r(fstart, ".", )) != NULL) {
+ if ((field = strtok_r(fstart, ".", ))) {
fstart = NULL;
if (!strcmp(field, "d")) {
- if ((field = strtok_r(fstart, ".", )) !=
- NULL) {
+ if ((field = strtok_r(fstart, ".", ))) {
tmp = atoi(field);
check_arg(tmp <= 0,
"Invalid delay at step %u!\n",
@@ -414,8 +413,7 @@ parse_workload(struct w_arg *arg, unsigned int flags,
struct workload *app_w)
goto add_step;
}
} else if (!strcmp(field, "p")) {
- if ((field = strtok_r(fstart, ".", )) !=
- NULL) {
+ if ((field = strtok_r(fstart, ".", ))) {
tmp = atoi(field);
check_arg(tmp <= 0,
"Invalid period at step
%u!\n",
@@ -426,8 +424,7 @@ parse_workload(struct w_arg *arg, unsigned int flags,
struct workload *app_w)
}
} else if (!strcmp(field, "P")) {
unsigned int nr = 0;
- while ((field = strtok_r(fstart, ".", )) !=
- NULL) {
+ while ((field = strtok_r(fstart, ".", ))) {
tmp = atoi(field);
check_arg(nr == 0 && tmp <= 0,
"Invalid context at step
%u!\n",
@@ -447,8 +444,7 @@ parse_workload(struct w_arg *arg, unsigned int flags,
struct workload *app_w)
step.type = CTX_PRIORITY;
goto add_step;
} else if (!strcmp(field, "s")) {
- if ((field = strtok_r(fstart, ".", )) !=
- NULL) {
+ if ((field = strtok_r(fstart, ".", ))) {
tmp = atoi(field);
check_arg(tmp >= 0 ||
((int)nr_steps + tmp) < 0,
@@ -459,8 +455,7 @@ parse_workload(struct w_arg *arg, unsigned int flags,
struct workload *app_w)
goto add_step;
}
} else if (!strcmp(field, "t")) {
- if ((field = strtok_r(fstart, ".", )) !=
- NULL) {
+ if ((field = strtok_r(fstart, ".", ))) {
tmp = atoi(field);
check_arg(tmp < 0,
"Invalid throttle at step
%u!\n",
@@ -470,8 +465,7 @@ parse_workload(struct w_arg *arg, unsigned int flags,
struct workload *app_w)
goto add_step;
}
} else if (!strcmp(field, "q")) {
- if ((field = strtok_r(fstart, ".", )) !=
- NULL) {
+ if ((field = strtok_r(fstart, ".", ))) {
tmp = atoi(field);
check_arg(tmp < 0,
"Invalid qd throttle at step
%u!\n",
@@ -481,8 +475,7 @@ parse_workload(struct w_arg *arg, unsigned int flags,
struct workload *app_w)
goto add_step;
[Intel-gfx] [PATCH i-g-t 12/27] gem_wsim: Engine map support
From: Tvrtko Ursulin
Support new i915 uAPI for configuring contexts with engine maps.
Please refer to the README file for more detailed explanation.
v2:
* Allow defining engine maps by class.
Signed-off-by: Tvrtko Ursulin
---
benchmarks/gem_wsim.c | 211 +++--
benchmarks/wsim/README | 25 -
2 files changed, 204 insertions(+), 32 deletions(-)
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
index 60b7d32e22d4..e5b12e37490e 100644
--- a/benchmarks/gem_wsim.c
+++ b/benchmarks/gem_wsim.c
@@ -57,6 +57,7 @@
#include "ewma.h"
enum intel_engine_id {
+ DEFAULT,
RCS,
BCS,
VCS,
@@ -81,7 +82,8 @@ enum w_type
SW_FENCE,
SW_FENCE_SIGNAL,
CTX_PRIORITY,
- PREEMPTION
+ PREEMPTION,
+ ENGINE_MAP
};
struct deps
@@ -115,6 +117,10 @@ struct w_step
int throttle;
int fence_signal;
int priority;
+ struct {
+ unsigned int engine_map_count;
+ enum intel_engine_id *engine_map;
+ };
};
/* Implementation details */
@@ -142,6 +148,8 @@ DECLARE_EWMA(uint64_t, rt, 4, 2)
struct ctx {
uint32_t id;
int priority;
+ unsigned int engine_map_count;
+ enum intel_engine_id *engine_map;
bool targets_instance;
bool wants_balance;
unsigned int static_vcs;
@@ -200,10 +208,10 @@ struct workload
int fd;
bool first;
unsigned int num_engines;
- unsigned int engine_map[5];
+ unsigned int engine_map[NUM_ENGINES];
uint64_t t_prev;
- uint64_t prev[5];
- double busy[5];
+ uint64_t prev[NUM_ENGINES];
+ double busy[NUM_ENGINES];
} busy_balancer;
};
@@ -234,6 +242,7 @@ static int fd;
#define REG(x) (volatile uint32_t *)((volatile char *)igt_global_mmio + x)
static const char *ring_str_map[NUM_ENGINES] = {
+ [DEFAULT] = "DEFAULT",
[RCS] = "RCS",
[BCS] = "BCS",
[VCS] = "VCS",
@@ -330,6 +339,43 @@ static int str_to_engine(const char *str)
return -1;
}
+static int parse_engine_map(struct w_step *step, const char *_str)
+{
+ char *token, *tctx = NULL, *tstart = (char *)_str;
+
+ while ((token = strtok_r(tstart, "|", ))) {
+ enum intel_engine_id engine;
+ unsigned int add;
+
+ tstart = NULL;
+
+ if (!strcmp(token, "DEFAULT"))
+ return -1;
+
+ engine = str_to_engine(token);
+ if ((int)engine < 0)
+ return -1;
+
+ if (engine != VCS && engine != VCS1 && engine != VCS2)
+ return -1; /* TODO */
+
+ add = engine == VCS ? 2 : 1;
+ step->engine_map_count += add;
+ step->engine_map = realloc(step->engine_map,
+ step->engine_map_count *
+ sizeof(step->engine_map[0]));
+
+ if (engine != VCS) {
+ step->engine_map[step->engine_map_count - 1] = engine;
+ } else {
+ step->engine_map[step->engine_map_count - 2] = VCS1;
+ step->engine_map[step->engine_map_count - 1] = VCS2;
+ }
+ }
+
+ return 0;
+}
+
static struct workload *
parse_workload(struct w_arg *arg, unsigned int flags, struct workload *app_w)
{
@@ -448,6 +494,33 @@ parse_workload(struct w_arg *arg, unsigned int flags,
struct workload *app_w)
} else if (!strcmp(field, "f")) {
step.type = SW_FENCE;
goto add_step;
+ } else if (!strcmp(field, "M")) {
+ unsigned int nr = 0;
+ while ((field = strtok_r(fstart, ".", )) !=
+ NULL) {
+ tmp = atoi(field);
+ check_arg(nr == 0 && tmp <= 0,
+ "Invalid context at step
%u!\n",
+ nr_steps);
+ check_arg(nr > 1,
+ "Invalid engine map format at
step %u!\n",
+ nr_steps);
+
+ if (nr == 0) {
+ step.context = tmp;
+ } else {
+ tmp = parse_engine_map(,
+ field);
+ check_arg(tmp <
[Intel-gfx] [PATCH i-g-t 16/27] gem_wsim: Engine bond command
From: Tvrtko Ursulin
Engine bonds are an i915 uAPI applicable to load balanced contexts with
engine map. They allow expression rules of engine selection between two
contexts when submissions are also tied with submit fences.
Please refer to the README for a more detailed description.
v2:
* Use list of symbolic engine names instead of the mask. (Chris)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
benchmarks/gem_wsim.c | 159 +++--
benchmarks/wsim/README | 50 +
2 files changed, 202 insertions(+), 7 deletions(-)
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
index d645611cf8c2..6fb6c8cef2c7 100644
--- a/benchmarks/gem_wsim.c
+++ b/benchmarks/gem_wsim.c
@@ -85,6 +85,7 @@ enum w_type
PREEMPTION,
ENGINE_MAP,
LOAD_BALANCE,
+ BOND,
};
struct deps
@@ -100,6 +101,11 @@ struct w_arg {
int prio;
};
+struct bond {
+ uint64_t mask;
+ enum intel_engine_id master;
+};
+
struct w_step
{
/* Workload step metadata */
@@ -123,6 +129,10 @@ struct w_step
enum intel_engine_id *engine_map;
};
bool load_balance;
+ struct {
+ uint64_t bond_mask;
+ enum intel_engine_id bond_master;
+ };
};
/* Implementation details */
@@ -152,6 +162,8 @@ struct ctx {
int priority;
unsigned int engine_map_count;
enum intel_engine_id *engine_map;
+ unsigned int bond_count;
+ struct bond *bonds;
bool targets_instance;
bool wants_balance;
unsigned int static_vcs;
@@ -378,6 +390,26 @@ static int parse_engine_map(struct w_step *step, const
char *_str)
return 0;
}
+static uint64_t engine_list_mask(const char *_str)
+{
+ uint64_t mask = 0;
+
+ char *token, *tctx = NULL, *tstart = (char *)_str;
+
+ while ((token = strtok_r(tstart, "|", ))) {
+ enum intel_engine_id engine = str_to_engine(token);
+
+ if ((int)engine < 0 || engine == DEFAULT || engine == VCS)
+ return 0;
+
+ mask |= 1 << engine;
+
+ tstart = NULL;
+ }
+
+ return mask;
+}
+
#define int_field(_STEP_, _FIELD_, _COND_, _ERR_) \
if ((field = strtok_r(fstart, ".", ))) { \
tmp = atoi(field); \
@@ -528,6 +560,39 @@ parse_workload(struct w_arg *arg, unsigned int flags,
struct workload *app_w)
step.type = LOAD_BALANCE;
goto add_step;
+ } else if (!strcmp(field, "b")) {
+ unsigned int nr = 0;
+ while ((field = strtok_r(fstart, ".", ))) {
+ check_arg(nr > 2,
+ "Invalid bond format at step
%u!\n",
+ nr_steps);
+
+ if (nr == 0) {
+ tmp = atoi(field);
+ step.context = tmp;
+ check_arg(tmp <= 0,
+ "Invalid context at
step %u!\n",
+ nr_steps);
+ } else if (nr == 1) {
+ step.bond_mask =
engine_list_mask(field);
+ check_arg(step.bond_mask == 0,
+ "Invalid siblings list
at step %u!\n",
+ nr_steps);
+ } else if (nr == 2) {
+ tmp = str_to_engine(field);
+ check_arg(tmp <= 0 ||
+ tmp == VCS ||
+ tmp == DEFAULT,
+ "Invalid master
engine at step %u!\n",
+ nr_steps);
+ step.bond_master = tmp;
+ }
+
+ nr++;
+ }
+
+ step.type = BOND;
+ goto add_step;
}
if (!field) {
@@ -1011,6 +1076,31 @@ static void vm_destroy(int i915, uint32_t vm_id)
igt_assert_eq(__vm_destroy(i915, vm_id), 0);
}
+static unsigned int
+find_engine(struct i915_engine_class_instance *ci, unsigned int count,
+ enum intel_engine_id
[Intel-gfx] [PATCH i-g-t 14/27] gem_wsim: Compact int command parsing with a macro
From: Tvrtko Ursulin
Parsing an integer workload descriptor field is a common pattern which we
can extract to a helper macro and by doing so further improve the
readability of the main parsing loop.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
benchmarks/gem_wsim.c | 80 ++-
1 file changed, 25 insertions(+), 55 deletions(-)
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
index baa389c3f0e7..66832f74e34a 100644
--- a/benchmarks/gem_wsim.c
+++ b/benchmarks/gem_wsim.c
@@ -376,6 +376,15 @@ static int parse_engine_map(struct w_step *step, const
char *_str)
return 0;
}
+#define int_field(_STEP_, _FIELD_, _COND_, _ERR_) \
+ if ((field = strtok_r(fstart, ".", ))) { \
+ tmp = atoi(field); \
+ check_arg(_COND_, _ERR_, nr_steps); \
+ step.type = _STEP_; \
+ step._FIELD_ = tmp; \
+ goto add_step; \
+ } \
+
static struct workload *
parse_workload(struct w_arg *arg, unsigned int flags, struct workload *app_w)
{
@@ -403,25 +412,11 @@ parse_workload(struct w_arg *arg, unsigned int flags,
struct workload *app_w)
fstart = NULL;
if (!strcmp(field, "d")) {
- if ((field = strtok_r(fstart, ".", ))) {
- tmp = atoi(field);
- check_arg(tmp <= 0,
- "Invalid delay at step %u!\n",
- nr_steps);
- step.type = DELAY;
- step.delay = tmp;
- goto add_step;
- }
+ int_field(DELAY, delay, tmp <= 0,
+ "Invalid delay at step %u!\n");
} else if (!strcmp(field, "p")) {
- if ((field = strtok_r(fstart, ".", ))) {
- tmp = atoi(field);
- check_arg(tmp <= 0,
- "Invalid period at step
%u!\n",
- nr_steps);
- step.type = PERIOD;
- step.period = tmp;
- goto add_step;
- }
+ int_field(PERIOD, period, tmp <= 0,
+ "Invalid period at step %u!\n");
} else if (!strcmp(field, "P")) {
unsigned int nr = 0;
while ((field = strtok_r(fstart, ".", ))) {
@@ -444,46 +439,21 @@ parse_workload(struct w_arg *arg, unsigned int flags,
struct workload *app_w)
step.type = CTX_PRIORITY;
goto add_step;
} else if (!strcmp(field, "s")) {
- if ((field = strtok_r(fstart, ".", ))) {
- tmp = atoi(field);
- check_arg(tmp >= 0 ||
- ((int)nr_steps + tmp) < 0,
- "Invalid sync target at step
%u!\n",
- nr_steps);
- step.type = SYNC;
- step.target = tmp;
- goto add_step;
- }
+ int_field(SYNC, target,
+ tmp >= 0 || ((int)nr_steps + tmp) < 0,
+ "Invalid sync target at step %u!\n");
} else if (!strcmp(field, "t")) {
- if ((field = strtok_r(fstart, ".", ))) {
- tmp = atoi(field);
- check_arg(tmp < 0,
- "Invalid throttle at step
%u!\n",
- nr_steps);
- step.type = THROTTLE;
- step.throttle = tmp;
- goto add_step;
- }
+ int_field(THROTTLE, throttle,
+ tmp < 0,
+ "Invalid throttle at step %u!\n");
} else if (!strcmp(field, "q")) {
- if ((field = strtok_r(fstart, ".", ))) {
- tmp = atoi(field);
-
[Intel-gfx] [PATCH i-g-t 08/27] gem_wsim: Factor out common error handling
From: Tvrtko Ursulin
There is a repeated pattern with error handling which can be moved to a
macro to for better readability in the command parsing loop.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
benchmarks/gem_wsim.c | 244 +++---
1 file changed, 88 insertions(+), 156 deletions(-)
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
index b91dbdec2cce..fceb850d0ca0 100644
--- a/benchmarks/gem_wsim.c
+++ b/benchmarks/gem_wsim.c
@@ -289,6 +289,27 @@ parse_dependencies(unsigned int nr_steps, struct w_step
*w, char *_desc)
return 0;
}
+static void __attribute__((format(printf, 1, 2)))
+wsim_err(const char *fmt, ...)
+{
+ va_list ap;
+
+ if (!verbose)
+ return;
+
+ va_start(ap, fmt);
+ vfprintf(stderr, fmt, ap);
+ va_end(ap);
+}
+
+#define check_arg(cond, fmt, ...) \
+{ \
+ if (cond) { \
+ wsim_err(fmt, __VA_ARGS__); \
+ return NULL; \
+ } \
+}
+
static struct workload *
parse_workload(struct w_arg *arg, unsigned int flags, struct workload *app_w)
{
@@ -319,14 +340,9 @@ parse_workload(struct w_arg *arg, unsigned int flags,
struct workload *app_w)
if ((field = strtok_r(fstart, ".", )) !=
NULL) {
tmp = atoi(field);
- if (tmp <= 0) {
- if (verbose)
- fprintf(stderr,
- "Invalid delay
at step %u!\n",
- nr_steps);
- return NULL;
- }
-
+ check_arg(tmp <= 0,
+ "Invalid delay at step %u!\n",
+ nr_steps);
step.type = DELAY;
step.delay = tmp;
goto add_step;
@@ -335,14 +351,9 @@ parse_workload(struct w_arg *arg, unsigned int flags,
struct workload *app_w)
if ((field = strtok_r(fstart, ".", )) !=
NULL) {
tmp = atoi(field);
- if (tmp <= 0) {
- if (verbose)
- fprintf(stderr,
- "Invalid period
at step %u!\n",
- nr_steps);
- return NULL;
- }
-
+ check_arg(tmp <= 0,
+ "Invalid period at step
%u!\n",
+ nr_steps);
step.type = PERIOD;
step.period = tmp;
goto add_step;
@@ -352,25 +363,17 @@ parse_workload(struct w_arg *arg, unsigned int flags,
struct workload *app_w)
while ((field = strtok_r(fstart, ".", )) !=
NULL) {
tmp = atoi(field);
- if (tmp <= 0 && nr == 0) {
- if (verbose)
- fprintf(stderr,
- "Invalid
context at step %u!\n",
- nr_steps);
- return NULL;
- }
-
- if (nr == 0) {
+ check_arg(nr == 0 && tmp <= 0,
+ "Invalid context at step
%u!\n",
+ nr_steps);
+ check_arg(nr > 1,
+ "Invalid priority format at
step %u!\n",
+ nr_steps);
+
+ if (nr == 0)
step.context = tmp;
- } else if (nr == 1) {
+ else
step.priority = tmp;
- } else {
-
[Intel-gfx] [PATCH i-g-t 05/27] trace.pl: Virtual engine preemption support
From: Tvrtko Ursulin
Use the 'completed?' tracepoint field to detect more robustly when a
request has been preempted and remove it from the engine database if so.
Otherwise the script can hit a scenario where the same global seqno will
be mentioned multiple times (on an engine seqno) which aborts processing.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
scripts/trace.pl | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/scripts/trace.pl b/scripts/trace.pl
index 1f4953b02ef6..77587f24197a 100755
--- a/scripts/trace.pl
+++ b/scripts/trace.pl
@@ -488,16 +488,21 @@ while (<>) {
$ringmap{$rings{$ring}} = $ring;
$db{$key} = \%req;
} elsif ($tp_name eq 'i915:i915_request_out:') {
- my $nkey;
+ if ($tp{'completed?'}) {
+ my $nkey;
- die unless exists $db{$key};
- die unless exists $db{$key}->{'start'};
- die if exists $db{$key}->{'end'};
+ die unless exists $db{$key};
+ die unless exists $db{$key}->{'start'};
+ die if exists $db{$key}->{'end'};
- $nkey = notify_key($ctx, $seqno);
+ $nkey = notify_key($ctx, $seqno);
- $db{$key}->{'end'} = $time;
- $db{$key}->{'notify'} = $notify{$nkey} if exists $notify{$nkey};
+ $db{$key}->{'end'} = $time;
+ $db{$key}->{'notify'} = $notify{$nkey}
+ if exists $notify{$nkey};
+ } else {
+ delete $db{$key};
+ }
} elsif ($tp_name eq 'dma_fence:dma_fence_signaled:') {
my $nkey;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 11/27] gem_wsim: Extract str to engine lookup
From: Tvrtko Ursulin
v2:
* Remove redundant check. (Chris)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
benchmarks/gem_wsim.c | 34 +-
1 file changed, 21 insertions(+), 13 deletions(-)
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
index 464314c05697..60b7d32e22d4 100644
--- a/benchmarks/gem_wsim.c
+++ b/benchmarks/gem_wsim.c
@@ -318,6 +318,18 @@ wsim_err(const char *fmt, ...)
} \
}
+static int str_to_engine(const char *str)
+{
+ unsigned int i;
+
+ for (i = 0; i < ARRAY_SIZE(ring_str_map); i++) {
+ if (!strcasecmp(str, ring_str_map[i]))
+ return i;
+ }
+
+ return -1;
+}
+
static struct workload *
parse_workload(struct w_arg *arg, unsigned int flags, struct workload *app_w)
{
@@ -480,22 +492,18 @@ parse_workload(struct w_arg *arg, unsigned int flags,
struct workload *app_w)
}
if ((field = strtok_r(fstart, ".", )) != NULL) {
- unsigned int old_valid = valid;
-
fstart = NULL;
- for (i = 0; i < ARRAY_SIZE(ring_str_map); i++) {
- if (!strcasecmp(field, ring_str_map[i])) {
- step.engine = i;
- if (step.engine == BCS)
- bcs_used = true;
- valid++;
- break;
- }
- }
-
- check_arg(old_valid == valid,
+ i = str_to_engine(field);
+ check_arg(i < 0,
"Invalid engine id at step %u!\n", nr_steps);
+
+ valid++;
+
+ step.engine = i;
+
+ if (step.engine == BCS)
+ bcs_used = true;
}
if ((field = strtok_r(fstart, ".", )) != NULL) {
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 10/27] gem_wsim: Submit fence support
From: Tvrtko Ursulin
Add support for submit fences in a way similar to how normal input fences
are handled. Eg:
1.RCS.500-1000.0.0
1.VCS1.3000.s-1.0
1.VCS2.3000.s-2.0
Submit fences are signalled when the originating request enters the
submission backend.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
benchmarks/gem_wsim.c | 20
benchmarks/wsim/README | 17 +
2 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
index 6c9eb1e20efc..464314c05697 100644
--- a/benchmarks/gem_wsim.c
+++ b/benchmarks/gem_wsim.c
@@ -87,6 +87,7 @@ enum w_type
struct deps
{
int nr;
+ bool submit_fence;
int *list;
};
@@ -253,17 +254,23 @@ parse_dependencies(unsigned int nr_steps, struct w_step
*w, char *_desc)
w->data_deps.list == w->fence_deps.list);
while ((token = strtok_r(tstart, "/", )) != NULL) {
+ bool submit_fence = false;
char *str = token;
struct deps *deps;
int dep;
tstart = NULL;
- if (strlen(token) > 1 && token[0] == 'f') {
+ if (str[0] == '-' || (str[0] >= '0' && str[0] <= '9')) {
+ deps = >data_deps;
+ } else {
+ if (str[0] == 's')
+ submit_fence = true;
+ else if (str[0] != 'f')
+ return -1;
+
deps = >fence_deps;
str++;
- } else {
- deps = >data_deps;
}
dep = atoi(str);
@@ -281,6 +288,7 @@ parse_dependencies(unsigned int nr_steps, struct w_step *w,
char *_desc)
sizeof(*deps->list) * deps->nr);
igt_assert(deps->list);
deps->list[deps->nr - 1] = dep;
+ deps->submit_fence = submit_fence;
}
}
@@ -1944,7 +1952,11 @@ do_eb(struct workload *wrk, struct w_step *w, enum
intel_engine_id engine,
igt_assert(tgt >= 0 && tgt < w->idx);
igt_assert(wrk->steps[tgt].emit_fence > 0);
- w->eb.flags |= I915_EXEC_FENCE_IN;
+ if (w->fence_deps.submit_fence)
+ w->eb.flags |= I915_EXEC_FENCE_SUBMIT;
+ else
+ w->eb.flags |= I915_EXEC_FENCE_IN;
+
w->eb.rsvd2 = wrk->steps[tgt].emit_fence;
}
diff --git a/benchmarks/wsim/README b/benchmarks/wsim/README
index 205cd6c93afb..4786f116b4ac 100644
--- a/benchmarks/wsim/README
+++ b/benchmarks/wsim/README
@@ -114,6 +114,23 @@ runnable. When the second RCS batch completes the
standalone fence is signaled
which allows the two VCS batches to be executed. Finally we wait until the both
VCS batches have completed before starting the (optional) next iteration.
+Submit fences
+-
+
+Submit fences are a type of input fence which are signalled when the
originating
+batch buffer is submitted to the GPU. (In contrary to normal sync fences, which
+are signalled when completed.)
+
+Submit fences have the identical syntax as the sync fences with the lower-case
+'s' being used to select them. Eg:
+
+ 1.RCS.500-1000.0.0
+ 1.VCS1.3000.s-1.0
+ 1.VCS2.3000.s-2.0
+
+Here VCS1 and VCS2 batches will only be submitted for executing once the RCS
+batch enters the GPU.
+
Context priority
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 09/27] gem_wsim: More wsim_err
From: Tvrtko Ursulin
A few more opportunities to compact the code by using the error logging
helper.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
benchmarks/gem_wsim.c | 54 ---
1 file changed, 15 insertions(+), 39 deletions(-)
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
index fceb850d0ca0..6c9eb1e20efc 100644
--- a/benchmarks/gem_wsim.c
+++ b/benchmarks/gem_wsim.c
@@ -2419,9 +2419,7 @@ int main(int argc, char **argv)
switch (c) {
case 'W':
if (master_workload >= 0) {
- if (verbose)
- fprintf(stderr,
- "Only one master workload can
be given!\n");
+ wsim_err("Only one master workload can be
given!\n");
return 1;
}
master_workload = nr_w_args;
@@ -2434,9 +2432,7 @@ int main(int argc, char **argv)
break;
case 'a':
if (append_workload_arg) {
- if (verbose)
- fprintf(stderr,
- "Only one append workload can
be given!\n");
+ wsim_err("Only one append workload can be
given!\n");
return 1;
}
append_workload_arg = optarg;
@@ -2497,10 +2493,8 @@ int main(int argc, char **argv)
}
if (!balancer) {
- if (verbose)
- fprintf(stderr,
- "Unknown balancing mode
'%s'!\n",
- optarg);
+ wsim_err("Unknown balancing mode '%s'!\n",
+optarg);
return 1;
}
break;
@@ -2513,14 +2507,12 @@ int main(int argc, char **argv)
}
if ((flags & HEARTBEAT) && !(flags & SEQNO)) {
- if (verbose)
- fprintf(stderr, "Heartbeat needs a seqno based
balancer!\n");
+ wsim_err("Heartbeat needs a seqno based balancer!\n");
return 1;
}
if ((flags & VCS2REMAP) && (flags & I915)) {
- if (verbose)
- fprintf(stderr, "VCS remapping not supported with i915
balancing!\n");
+ wsim_err("VCS remapping not supported with i915 balancing!\n");
return 1;
}
@@ -2537,31 +2529,24 @@ int main(int argc, char **argv)
}
if (!nr_w_args) {
- if (verbose)
- fprintf(stderr, "No workload descriptor(s)!\n");
+ wsim_err("No workload descriptor(s)!\n");
return 1;
}
if (nr_w_args > 1 && clients > 1) {
- if (verbose)
- fprintf(stderr,
- "Cloned clients cannot be combined with
multiple workloads!\n");
+ wsim_err("Cloned clients cannot be combined with multiple
workloads!\n");
return 1;
}
if ((flags & GLOBAL_BALANCE) && !balancer) {
- if (verbose)
- fprintf(stderr,
- "Balancer not specified in global balancing
mode!\n");
+ wsim_err("Balancer not specified in global balancing mode!\n");
return 1;
}
if (append_workload_arg) {
append_workload_arg =
load_workload_descriptor(append_workload_arg);
if (!append_workload_arg) {
- if (verbose)
- fprintf(stderr,
- "Failed to load append workload
descriptor!\n");
+ wsim_err("Failed to load append workload
descriptor!\n");
return 1;
}
}
@@ -2570,9 +2555,7 @@ int main(int argc, char **argv)
struct w_arg arg = { NULL, append_workload_arg, 0 };
app_w = parse_workload(, flags, NULL);
if (!app_w) {
- if (verbose)
- fprintf(stderr,
- "Failed to parse append workload!\n");
+ wsim_err("Failed to parse append workload!\n");
return 1;
}
}
@@ -2584,18 +2567,13 @@ int main(int argc, char **argv)
w_args[i].desc = load_workload_descriptor(w_args[i].filename);
if (!w_args[i].desc) {
- if (verbose)
-
[Intel-gfx] [PATCH i-g-t 02/27] trace.pl: Ignore signaling on non i915 fences
From: Tvrtko Ursulin
gem_wsim uses the sw_fence timeline and confuses the script.
v2:
* Check the correct timeline as well. (Chris)
Signed-off-by: Tvrtko Ursulin
---
scripts/trace.pl | 3 +++
1 file changed, 3 insertions(+)
diff --git a/scripts/trace.pl b/scripts/trace.pl
index 8c896cfde6b0..ac141a514055 100755
--- a/scripts/trace.pl
+++ b/scripts/trace.pl
@@ -443,6 +443,9 @@ while (<>) {
} elsif ($tp_name eq 'dma_fence:dma_fence_signaled:') {
my $nkey;
+ next unless $tp{'driver'} eq 'i915' and
+ $tp{'timeline'} eq 'signaled';
+
$nkey = notify_key($tp{'context'}, $tp{'seqno'});
die if exists $notify{$nkey};
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 06/27] wsim/media-bench: i915 balancing
From: Tvrtko Ursulin
Support i915 virtual engine from gem_wsim (-b i915) and media-bench.pl
v2:
* Add vm_destroy. (Chris)
* Remove unneeded braces. (Chris)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
benchmarks/gem_wsim.c | 302 +++--
scripts/media-bench.pl | 9 +-
2 files changed, 265 insertions(+), 46 deletions(-)
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
index 48568ce4066e..afb53f4114d2 100644
--- a/benchmarks/gem_wsim.c
+++ b/benchmarks/gem_wsim.c
@@ -142,6 +142,14 @@ struct w_step
DECLARE_EWMA(uint64_t, rt, 4, 2)
+struct ctx {
+ uint32_t id;
+ int priority;
+ bool targets_instance;
+ bool wants_balance;
+ unsigned int static_vcs;
+};
+
struct workload
{
unsigned int id;
@@ -163,11 +171,7 @@ struct workload
struct timespec repeat_start;
unsigned int nr_ctxs;
- struct {
- uint32_t id;
- int priority;
- unsigned int static_vcs;
- } *ctx_list;
+ struct ctx *ctx_list;
int sync_timeline;
uint32_t sync_seqno;
@@ -224,6 +228,7 @@ static int fd;
#define HEARTBEAT (1<<7)
#define GLOBAL_BALANCE (1<<8)
#define DEPSYNC(1<<9)
+#define I915 (1<<10)
#define SEQNO_IDX(engine) ((engine) * 16)
#define SEQNO_OFFSET(engine) (SEQNO_IDX(engine) * sizeof(uint32_t))
@@ -841,7 +846,10 @@ eb_set_engine(struct drm_i915_gem_execbuffer2 *eb,
if (engine == VCS2 && (flags & VCS2REMAP))
engine = BCS;
- eb->flags = eb_engine_map[engine];
+ if ((flags & I915) && engine == VCS)
+ eb->flags = 0;
+ else
+ eb->flags = eb_engine_map[engine];
}
static void
@@ -867,6 +875,23 @@ get_status_objects(struct workload *wrk)
return wrk->status_object;
}
+static struct ctx *
+__get_ctx(struct workload *wrk, struct w_step *w)
+{
+ return >ctx_list[w->context * 2];
+}
+
+static uint32_t
+get_ctxid(struct workload *wrk, struct w_step *w)
+{
+ struct ctx *ctx = __get_ctx(wrk, w);
+
+ if (ctx->targets_instance && ctx->wants_balance && w->engine == VCS)
+ return wrk->ctx_list[w->context * 2 + 1].id;
+ else
+ return wrk->ctx_list[w->context * 2].id;
+}
+
static void
alloc_step_batch(struct workload *wrk, struct w_step *w, unsigned int flags)
{
@@ -919,7 +944,7 @@ alloc_step_batch(struct workload *wrk, struct w_step *w,
unsigned int flags)
w->eb.buffers_ptr = to_user_pointer(w->obj);
w->eb.buffer_count = j + 1;
- w->eb.rsvd1 = wrk->ctx_list[w->context].id;
+ w->eb.rsvd1 = get_ctxid(wrk, w);
if (flags & SWAPVCS && engine == VCS1)
engine = VCS2;
@@ -932,17 +957,48 @@ alloc_step_batch(struct workload *wrk, struct w_step *w,
unsigned int flags)
printf("%x|", w->obj[i].handle);
printf(" %10lu flags=%llx bb=%x[%u] ctx[%u]=%u\n",
w->bb_sz, w->eb.flags, w->bb_handle, j, w->context,
- wrk->ctx_list[w->context].id);
+ get_ctxid(wrk, w));
#endif
}
+static void __ctx_set_prio(uint32_t ctx_id, unsigned int prio)
+{
+ struct drm_i915_gem_context_param param = {
+ .ctx_id = ctx_id,
+ .param = I915_CONTEXT_PARAM_PRIORITY,
+ .value = prio,
+ };
+
+ if (prio)
+ gem_context_set_param(fd, );
+}
+
+static int __vm_destroy(int i915, uint32_t vm_id)
+{
+ struct drm_i915_gem_vm_control ctl = { .vm_id = vm_id };
+ int err = 0;
+
+ if (igt_ioctl(i915, DRM_IOCTL_I915_GEM_VM_DESTROY, )) {
+ err = -errno;
+ igt_assume(err);
+ }
+
+ errno = 0;
+ return err;
+}
+
+static void vm_destroy(int i915, uint32_t vm_id)
+{
+ igt_assert_eq(__vm_destroy(i915, vm_id), 0);
+}
+
static void
prepare_workload(unsigned int id, struct workload *wrk, unsigned int flags)
{
unsigned int ctx_vcs;
int max_ctx = -1;
struct w_step *w;
- int i;
+ int i, j;
wrk->id = id;
wrk->prng = rand();
@@ -975,45 +1031,187 @@ prepare_workload(unsigned int id, struct workload *wrk,
unsigned int flags)
}
}
+ /*
+* Pre-scan workload steps to allocate context list storage.
+*/
for (i = 0, w = wrk->steps; i < wrk->nr_steps; i++, w++) {
- if ((int)w->context > max_ctx) {
- int delta = w->context + 1 - wrk->nr_ctxs;
+ int ctx = w->context * 2 + 1; /* Odd slots are special. */
+ int delta;
+
+ if (ctx <= max_ctx)
+ continue;
+
+ delta = ctx + 1 - wrk->nr_ctxs;
- wrk->nr_ctxs += delta;
- wrk->ctx_list = realloc(wrk->ctx_list,
- wrk->nr_ctxs *
-
[Intel-gfx] [PATCH i-g-t 07/27] gem_wsim: Use IGT uapi headers
From: Tvrtko Ursulin
We are moving towards bumping the uAPI headers more often instead of using
too much local struct/ioctl/param definitions since the latter are more
challenging for rebase and maintenance.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
benchmarks/gem_wsim.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
index afb53f4114d2..b91dbdec2cce 100644
--- a/benchmarks/gem_wsim.c
+++ b/benchmarks/gem_wsim.c
@@ -41,7 +41,6 @@
#include
#include
-
#include "intel_chipset.h"
#include "intel_reg.h"
#include "drm.h"
@@ -57,9 +56,6 @@
#include "ewma.h"
-#define LOCAL_I915_EXEC_FENCE_IN (1<<16)
-#define LOCAL_I915_EXEC_FENCE_OUT (1<<17)
-
enum intel_engine_id {
RCS,
BCS,
@@ -863,7 +859,7 @@ eb_update_flags(struct w_step *w, enum intel_engine_id
engine,
igt_assert(w->emit_fence <= 0);
if (w->emit_fence)
- w->eb.flags |= LOCAL_I915_EXEC_FENCE_OUT;
+ w->eb.flags |= I915_EXEC_FENCE_OUT;
}
static struct drm_i915_gem_exec_object2 *
@@ -2016,16 +2012,16 @@ do_eb(struct workload *wrk, struct w_step *w, enum
intel_engine_id engine,
igt_assert(tgt >= 0 && tgt < w->idx);
igt_assert(wrk->steps[tgt].emit_fence > 0);
- w->eb.flags |= LOCAL_I915_EXEC_FENCE_IN;
+ w->eb.flags |= I915_EXEC_FENCE_IN;
w->eb.rsvd2 = wrk->steps[tgt].emit_fence;
}
- if (w->eb.flags & LOCAL_I915_EXEC_FENCE_OUT)
+ if (w->eb.flags & I915_EXEC_FENCE_OUT)
gem_execbuf_wr(fd, >eb);
else
gem_execbuf(fd, >eb);
- if (w->eb.flags & LOCAL_I915_EXEC_FENCE_OUT) {
+ if (w->eb.flags & I915_EXEC_FENCE_OUT) {
w->emit_fence = w->eb.rsvd2 >> 32;
igt_assert(w->emit_fence > 0);
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 04/27] trace.pl: Virtual engine support
From: Tvrtko Ursulin
Add virtual/queue timelines to both stdout and HTML output.
A new timeline is created for each queue/virtual engine to display
associated requests in queued and runnable states. Once requests are
submitted to a real engine for executing they show up on the physical
engine timeline.
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
Reviewed-by: Chris Wilson
---
scripts/trace.pl | 238 +--
1 file changed, 208 insertions(+), 30 deletions(-)
diff --git a/scripts/trace.pl b/scripts/trace.pl
index ac141a514055..1f4953b02ef6 100755
--- a/scripts/trace.pl
+++ b/scripts/trace.pl
@@ -27,11 +27,16 @@ use warnings;
use 5.010;
my $gid = 0;
-my (%db, %queue, %submit, %notify, %rings, %ctxdb, %ringmap, %reqwait,
+my (%db, %vdb, %queue, %submit, %notify, %rings, %ctxdb, %ringmap, %reqwait,
%ctxtimelines);
+my (%cids, %ctxmap);
+my $cid = 0;
+my %queues;
my @freqs;
-my $max_items = 3000;
+use constant VENG => '255:254';
+
+my $max_requests = 1000;
my $width_us = 32000;
my $correct_durations = 0;
my %ignore_ring;
@@ -181,21 +186,21 @@ sub arg_trace
return @_;
}
-sub arg_max_items
+sub arg_max_requests
{
my $val;
return unless scalar(@_);
- if ($_[0] eq '--max-items' or $_[0] eq '-m') {
+ if ($_[0] eq '--max-requests' or $_[0] eq '-m') {
shift @_;
$val = shift @_;
- } elsif ($_[0] =~ /--max-items=(\d+)/) {
+ } elsif ($_[0] =~ /--max-requests=(\d+)/) {
shift @_;
$val = $1;
}
- $max_items = int($val) if defined $val;
+ $max_requests = int($val) if defined $val;
return @_;
}
@@ -292,7 +297,7 @@ while (@args) {
@args = arg_avg_delay_stats(@args);
@args = arg_gpu_timeline(@args);
@args = arg_trace(@args);
- @args = arg_max_items(@args);
+ @args = arg_max_requests(@args);
@args = arg_zoom_width(@args);
@args = arg_split_requests(@args);
@args = arg_ignore_ring(@args);
@@ -331,6 +336,13 @@ sub sanitize_ctx
}
}
+sub is_veng
+{
+ my ($class, $instance) = split ':', shift;
+
+ return $instance eq '254';
+}
+
# Main input loop - parse lines and build the internal representation of the
# trace using a hash of requests and some auxilliary data structures.
my $prev_freq = 0;
@@ -373,6 +385,7 @@ while (<>) {
$ctx = $tp{'ctx'};
$orig_ctx = $ctx;
$ctx = sanitize_ctx($ctx, $ring);
+ $ring = VENG if is_veng($ring);
$key = db_key($ring, $ctx, $seqno);
}
}
@@ -381,6 +394,7 @@ while (<>) {
my %rw;
next if exists $reqwait{$key};
+ die if $ring eq VENG and not exists $queues{$ctx};
$rw{'key'} = $key;
$rw{'ring'} = $ring;
@@ -389,9 +403,19 @@ while (<>) {
$rw{'start'} = $time;
$reqwait{$key} = \%rw;
} elsif ($tp_name eq 'i915:i915_request_wait_end:') {
- next unless exists $reqwait{$key};
+ die if $ring eq VENG and not exists $queues{$ctx};
- $reqwait{$key}->{'end'} = $time;
+ if (exists $reqwait{$key}) {
+ $reqwait{$key}->{'end'} = $time;
+ } else { # Virtual engine
+ my $vkey = db_key(VENG, $ctx, $seqno);
+
+ die unless exists $reqwait{$vkey};
+
+ # If the wait started on the virtual engine, attribute
+ # it to it completely.
+ $reqwait{$vkey}->{'end'} = $time;
+ }
} elsif ($tp_name eq 'i915:i915_request_add:') {
if (exists $queue{$key}) {
$ctxdb{$orig_ctx}++;
@@ -402,19 +426,52 @@ while (<>) {
}
$queue{$key} = $time;
+ if ($ring eq VENG and not exists $queues{$ctx}) {
+ $queues{$ctx} = 1 ;
+ $cids{$ctx} = $cid++;
+ $ctxmap{$cids{$ctx}} = $ctx;
+ }
} elsif ($tp_name eq 'i915:i915_request_submit:') {
die if exists $submit{$key};
die unless exists $queue{$key};
+ die if $ring eq VENG and not exists $queues{$ctx};
$submit{$key} = $time;
} elsif ($tp_name eq 'i915:i915_request_in:') {
+ my ($q, $s);
my %req;
# preemption
delete $db{$key} if exists $db{$key};
- die unless exists $queue{$key};
- die unless exists $submit{$key};
+ unless (exists $queue{$key}) {
+ # Virtual engine
+ my $vkey = db_key(VENG, $ctx, $seqno);
+ my %req;
+
+
[Intel-gfx] [PATCH i-g-t 03/27] headers: bump
From: Tvrtko Ursulin
Catch up to drm-tip headers.
Signed-off-by: Tvrtko Ursulin
---
include/drm-uapi/amdgpu_drm.h | 52 +++-
include/drm-uapi/drm.h | 36 ++
include/drm-uapi/drm_mode.h| 4 +-
include/drm-uapi/i915_drm.h| 209 -
include/drm-uapi/lima_drm.h| 169 ++
include/drm-uapi/msm_drm.h | 14 +++
include/drm-uapi/nouveau_drm.h | 51
include/drm-uapi/v3d_drm.h | 28 +
8 files changed, 557 insertions(+), 6 deletions(-)
create mode 100644 include/drm-uapi/lima_drm.h
diff --git a/include/drm-uapi/amdgpu_drm.h b/include/drm-uapi/amdgpu_drm.h
index be84e43c1e19..4788730dbe78 100644
--- a/include/drm-uapi/amdgpu_drm.h
+++ b/include/drm-uapi/amdgpu_drm.h
@@ -210,6 +210,9 @@ union drm_amdgpu_bo_list {
#define AMDGPU_CTX_QUERY2_FLAGS_VRAMLOST (1<<1)
/* indicate some job from this context once cause gpu hang */
#define AMDGPU_CTX_QUERY2_FLAGS_GUILTY (1<<2)
+/* indicate some errors are detected by RAS */
+#define AMDGPU_CTX_QUERY2_FLAGS_RAS_CE (1<<3)
+#define AMDGPU_CTX_QUERY2_FLAGS_RAS_UE (1<<4)
/* Context priority level */
#define AMDGPU_CTX_PRIORITY_UNSET -2048
@@ -272,13 +275,14 @@ union drm_amdgpu_vm {
/* sched ioctl */
#define AMDGPU_SCHED_OP_PROCESS_PRIORITY_OVERRIDE 1
+#define AMDGPU_SCHED_OP_CONTEXT_PRIORITY_OVERRIDE 2
struct drm_amdgpu_sched_in {
/* AMDGPU_SCHED_OP_* */
__u32 op;
__u32 fd;
__s32 priority;
- __u32 flags;
+ __u32 ctx_id;
};
union drm_amdgpu_sched {
@@ -523,6 +527,9 @@ struct drm_amdgpu_gem_va {
#define AMDGPU_CHUNK_ID_SYNCOBJ_IN 0x04
#define AMDGPU_CHUNK_ID_SYNCOBJ_OUT 0x05
#define AMDGPU_CHUNK_ID_BO_HANDLES 0x06
+#define AMDGPU_CHUNK_ID_SCHEDULED_DEPENDENCIES 0x07
+#define AMDGPU_CHUNK_ID_SYNCOBJ_TIMELINE_WAIT0x08
+#define AMDGPU_CHUNK_ID_SYNCOBJ_TIMELINE_SIGNAL 0x09
struct drm_amdgpu_cs_chunk {
__u32 chunk_id;
@@ -565,6 +572,11 @@ union drm_amdgpu_cs {
* caches (L2/vL1/sL1/I$). */
#define AMDGPU_IB_FLAG_TC_WB_NOT_INVALIDATE (1 << 3)
+/* Set GDS_COMPUTE_MAX_WAVE_ID = DEFAULT before PACKET3_INDIRECT_BUFFER.
+ * This will reset wave ID counters for the IB.
+ */
+#define AMDGPU_IB_FLAG_RESET_GDS_MAX_WAVE_ID (1 << 4)
+
struct drm_amdgpu_cs_chunk_ib {
__u32 _pad;
/** AMDGPU_IB_FLAG_* */
@@ -598,6 +610,12 @@ struct drm_amdgpu_cs_chunk_sem {
__u32 handle;
};
+struct drm_amdgpu_cs_chunk_syncobj {
+ __u32 handle;
+ __u32 flags;
+ __u64 point;
+};
+
#define AMDGPU_FENCE_TO_HANDLE_GET_SYNCOBJ 0
#define AMDGPU_FENCE_TO_HANDLE_GET_SYNCOBJ_FD 1
#define AMDGPU_FENCE_TO_HANDLE_GET_SYNC_FILE_FD2
@@ -673,6 +691,7 @@ struct drm_amdgpu_cs_chunk_data {
#define AMDGPU_INFO_FW_GFX_RLC_RESTORE_LIST_SRM_MEM 0x11
/* Subquery id: Query DMCU firmware version */
#define AMDGPU_INFO_FW_DMCU 0x12
+ #define AMDGPU_INFO_FW_TA 0x13
/* number of bytes moved for TTM migration */
#define AMDGPU_INFO_NUM_BYTES_MOVED0x0f
/* the used VRAM size */
@@ -726,6 +745,37 @@ struct drm_amdgpu_cs_chunk_data {
/* Number of VRAM page faults on CPU access. */
#define AMDGPU_INFO_NUM_VRAM_CPU_PAGE_FAULTS 0x1E
#define AMDGPU_INFO_VRAM_LOST_COUNTER 0x1F
+/* query ras mask of enabled features*/
+#define AMDGPU_INFO_RAS_ENABLED_FEATURES 0x20
+
+/* RAS MASK: UMC (VRAM) */
+#define AMDGPU_INFO_RAS_ENABLED_UMC(1 << 0)
+/* RAS MASK: SDMA */
+#define AMDGPU_INFO_RAS_ENABLED_SDMA (1 << 1)
+/* RAS MASK: GFX */
+#define AMDGPU_INFO_RAS_ENABLED_GFX(1 << 2)
+/* RAS MASK: MMHUB */
+#define AMDGPU_INFO_RAS_ENABLED_MMHUB (1 << 3)
+/* RAS MASK: ATHUB */
+#define AMDGPU_INFO_RAS_ENABLED_ATHUB (1 << 4)
+/* RAS MASK: PCIE */
+#define AMDGPU_INFO_RAS_ENABLED_PCIE (1 << 5)
+/* RAS MASK: HDP */
+#define AMDGPU_INFO_RAS_ENABLED_HDP(1 << 6)
+/* RAS MASK: XGMI */
+#define AMDGPU_INFO_RAS_ENABLED_XGMI (1 << 7)
+/* RAS MASK: DF */
+#define AMDGPU_INFO_RAS_ENABLED_DF (1 << 8)
+/* RAS MASK: SMN */
+#define AMDGPU_INFO_RAS_ENABLED_SMN(1 << 9)
+/* RAS MASK: SEM */
+#define AMDGPU_INFO_RAS_ENABLED_SEM(1 << 10)
+/* RAS MASK: MP0 */
+#define AMDGPU_INFO_RAS_ENABLED_MP0(1 << 11)
+/* RAS MASK: MP1 */
+#define AMDGPU_INFO_RAS_ENABLED_MP1(1 << 12)
+/* RAS MASK: FUSE */
+#define AMDGPU_INFO_RAS_ENABLED_FUSE (1 << 13)
#define AMDGPU_INFO_MMR_SE_INDEX_SHIFT 0
#define AMDGPU_INFO_MMR_SE_INDEX_MASK 0xff
diff --git a/include/drm-uapi/drm.h b/include/drm-uapi/drm.h
index 85c685a2075e..c893f3b4a895 100644
--- a/include/drm-uapi/drm.h
+++ b/include/drm-uapi/drm.h
@@ -729,8 +729,18 @@ struct drm_syncobj_handle {
[Intel-gfx] [PATCH i-g-t 00/27] Media scalability tooling
From: Tvrtko Ursulin Review feedback and some other fixes: * prng seed fix and control via command line parameter. * trace.pl dma_fence_signal_notify fix. * Further consolidation in gem_wsim "un-hardcoding" patches. Tvrtko Ursulin (27): scripts/trace.pl: Fix after intel_engine_notify removal trace.pl: Ignore signaling on non i915 fences headers: bump trace.pl: Virtual engine support trace.pl: Virtual engine preemption support wsim/media-bench: i915 balancing gem_wsim: Use IGT uapi headers gem_wsim: Factor out common error handling gem_wsim: More wsim_err gem_wsim: Submit fence support gem_wsim: Extract str to engine lookup gem_wsim: Engine map support gem_wsim: Save some lines by changing to implicit NULL checking gem_wsim: Compact int command parsing with a macro gem_wsim: Engine map load balance command gem_wsim: Engine bond command gem_wsim: Some more example workloads gem_wsim: Infinite batch support gem_wsim: Command line switch for specifying low slice count workloads gem_wsim: Per context SSEU control gem_wsim: Allow RCS virtual engine with SSEU control tests/i915_query: Engine discovery tests gem_wsim: Consolidate engine assignments into helpers gem_wsim: Discover engines gem_wsim: Support Icelake parts gem_wsim: Fix prng usage gem_wsim: Allow random seed control benchmarks/gem_wsim.c | 1530 ++- benchmarks/wsim/README | 139 +- benchmarks/wsim/frame-split-60fps.wsim | 18 + benchmarks/wsim/high-composited-game.wsim | 11 + benchmarks/wsim/media-1080p-player.wsim |5 + benchmarks/wsim/medium-composited-game.wsim |9 + include/drm-uapi/amdgpu_drm.h | 52 +- include/drm-uapi/drm.h | 36 + include/drm-uapi/drm_mode.h |4 +- include/drm-uapi/i915_drm.h | 209 ++- include/drm-uapi/lima_drm.h | 169 ++ include/drm-uapi/msm_drm.h | 14 + include/drm-uapi/nouveau_drm.h | 51 + include/drm-uapi/v3d_drm.h | 28 + scripts/media-bench.pl |9 +- scripts/trace.pl| 321 +++- tests/i915/i915_query.c | 247 +++ 17 files changed, 2426 insertions(+), 426 deletions(-) create mode 100644 benchmarks/wsim/frame-split-60fps.wsim create mode 100644 benchmarks/wsim/high-composited-game.wsim create mode 100644 benchmarks/wsim/media-1080p-player.wsim create mode 100644 benchmarks/wsim/medium-composited-game.wsim create mode 100644 include/drm-uapi/lima_drm.h -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 01/27] scripts/trace.pl: Fix after intel_engine_notify removal
From: Tvrtko Ursulin
After the removal of engine global seqnos and the corresponding
intel_engine_notify tracepoints the script needs to be adjusted to cope
with the new state of things.
To keep working it switches over using the dma_fence:dma_fence_signaled:
tracepoint and keeps one extra internal map to connect the ctx-seqno pairs
with engines.
It also needs to key the completion events on the full engine/ctx/seqno
tokens, and adjust correspondingly the timeline sorting logic.
v2:
* Do not use late notifications (received after context complete) when
splitting up coalesced requests. They are now much more likely and can
not be used.
v3:
* Pull a hunk which moved forward during rebases back here.
v4:
* Drop ctxengines approach since it cannot handle requests moving across
engines. ctx/seqno pair is unique anyway so enough.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson # v3
---
scripts/trace.pl | 69 +++-
1 file changed, 33 insertions(+), 36 deletions(-)
diff --git a/scripts/trace.pl b/scripts/trace.pl
index 18f9f3b18396..8c896cfde6b0 100755
--- a/scripts/trace.pl
+++ b/scripts/trace.pl
@@ -27,7 +27,8 @@ use warnings;
use 5.010;
my $gid = 0;
-my (%db, %queue, %submit, %notify, %rings, %ctxdb, %ringmap, %reqwait,
%ctxtimelines);
+my (%db, %queue, %submit, %notify, %rings, %ctxdb, %ringmap, %reqwait,
+%ctxtimelines);
my @freqs;
my $max_items = 3000;
@@ -66,7 +67,7 @@ Notes:
i915:i915_request_submit, \
i915:i915_request_in, \
i915:i915_request_out, \
- i915:intel_engine_notify, \
+ dma_fence:dma_fence_signaled, \
i915:i915_request_wait_begin, \
i915:i915_request_wait_end \
[command-to-be-profiled]
@@ -161,7 +162,7 @@ sub arg_trace
'i915:i915_request_submit',
'i915:i915_request_in',
'i915:i915_request_out',
- 'i915:intel_engine_notify',
+ 'dma_fence:dma_fence_signaled',
'i915:i915_request_wait_begin',
'i915:i915_request_wait_end' );
@@ -312,11 +313,11 @@ sub db_key
return $ring . '/' . $ctx . '/' . $seqno;
}
-sub global_key
+sub notify_key
{
- my ($ring, $seqno) = @_;
+ my ($ctx, $seqno) = @_;
- return $ring . '/' . $seqno;
+ return $ctx . '/' . $seqno;
}
sub sanitize_ctx
@@ -429,18 +430,23 @@ while (<>) {
$ringmap{$rings{$ring}} = $ring;
$db{$key} = \%req;
} elsif ($tp_name eq 'i915:i915_request_out:') {
- my $gkey = global_key($ring, $tp{'global'});
+ my $nkey;
die unless exists $db{$key};
die unless exists $db{$key}->{'start'};
die if exists $db{$key}->{'end'};
+ $nkey = notify_key($ctx, $seqno);
+
$db{$key}->{'end'} = $time;
- $db{$key}->{'notify'} = $notify{$gkey} if exists $notify{$gkey};
- } elsif ($tp_name eq 'i915:intel_engine_notify:') {
- my $gkey = global_key($ring, $seqno);
+ $db{$key}->{'notify'} = $notify{$nkey} if exists $notify{$nkey};
+ } elsif ($tp_name eq 'dma_fence:dma_fence_signaled:') {
+ my $nkey;
+
+ $nkey = notify_key($tp{'context'}, $tp{'seqno'});
- $notify{$gkey} = $time unless exists $notify{$gkey};
+ die if exists $notify{$nkey};
+ $notify{$nkey} = $time unless exists $notify{$nkey};
} elsif ($tp_name eq 'i915:intel_gpu_freq_change:') {
push @freqs, [$prev_freq_ts, $time, $prev_freq] if $prev_freq;
$prev_freq_ts = $time;
@@ -452,15 +458,15 @@ while (<>) {
# find the largest seqno to be used for timeline sorting purposes.
my $max_seqno = 0;
foreach my $key (keys %db) {
- my $gkey = global_key($db{$key}->{'ring'}, $db{$key}->{'global'});
+ my $nkey = notify_key($db{$key}->{'ctx'}, $db{$key}->{'seqno'});
die unless exists $db{$key}->{'start'};
$max_seqno = $db{$key}->{'seqno'} if $db{$key}->{'seqno'} > $max_seqno;
# Notify arrived after context complete?
- $db{$key}->{'notify'} = $notify{$gkey} if not exists
$db{$key}->{'notify'}
- and exists $notify{$gkey};
+ $db{$key}->{'notify'} = $notify{$nkey} if not exists
$db{$key}->{'notify'}
+ and exists $notify{$nkey};
# No notify but we have end?
$db{$key}->{'notify'} = $db{$key}->{'end'} if exists $db{$key}->{'end'}
and
@@ -478,14 +484,13 @@ my $key_count = scalar(keys %db);
my %engine_timelines;
-sub sortEngine {
- my
[Intel-gfx] [PATCH v4 1/2] drm/i915/selftests: Verify context workarounds
From: Tvrtko Ursulin
Test context workarounds have been correctly applied in newly created
contexts.
To accomplish this the existing engine_wa_list_verify helper is extended
to take in a context from which reading of the workaround list will be
done.
Context workaround verification is done from the existing subtests, which
have been renamed to reflect they are no longer only about GT and engine
workarounds.
v2:
* Test after resets and refactor to use intel_context more. (Chris)
v3:
* Use ce->engine->i915 instead of ce->gem_context->i915. (Chris)
* gem_engine_iter.idx is engine->id + 1. (Chris)
v4:
* Make local function static.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 112 ++
.../gpu/drm/i915/gt/selftest_workarounds.c| 54 ++---
2 files changed, 98 insertions(+), 68 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 43e290306551..d692b83583fa 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -196,10 +196,9 @@ ignore_wa_write_or(struct i915_wa_list *wal, i915_reg_t
reg, u32 mask, u32 val)
#define WA_SET_FIELD_MASKED(addr, mask, value) \
wa_write_masked_or(wal, (addr), (mask), _MASKED_FIELD((mask), (value)))
-static void gen8_ctx_workarounds_init(struct intel_engine_cs *engine)
+static void gen8_ctx_workarounds_init(struct intel_engine_cs *engine,
+ struct i915_wa_list *wal)
{
- struct i915_wa_list *wal = >ctx_wa_list;
-
WA_SET_BIT_MASKED(INSTPM, INSTPM_FORCE_ORDERING);
/* WaDisableAsyncFlipPerfMode:bdw,chv */
@@ -245,12 +244,12 @@ static void gen8_ctx_workarounds_init(struct
intel_engine_cs *engine)
GEN6_WIZ_HASHING_16x4);
}
-static void bdw_ctx_workarounds_init(struct intel_engine_cs *engine)
+static void bdw_ctx_workarounds_init(struct intel_engine_cs *engine,
+struct i915_wa_list *wal)
{
struct drm_i915_private *i915 = engine->i915;
- struct i915_wa_list *wal = >ctx_wa_list;
- gen8_ctx_workarounds_init(engine);
+ gen8_ctx_workarounds_init(engine, wal);
/* WaDisableThreadStallDopClockGating:bdw (pre-production) */
WA_SET_BIT_MASKED(GEN8_ROW_CHICKEN, STALL_DOP_GATING_DISABLE);
@@ -273,11 +272,10 @@ static void bdw_ctx_workarounds_init(struct
intel_engine_cs *engine)
(IS_BDW_GT3(i915) ? HDC_FENCE_DEST_SLM_DISABLE : 0));
}
-static void chv_ctx_workarounds_init(struct intel_engine_cs *engine)
+static void chv_ctx_workarounds_init(struct intel_engine_cs *engine,
+struct i915_wa_list *wal)
{
- struct i915_wa_list *wal = >ctx_wa_list;
-
- gen8_ctx_workarounds_init(engine);
+ gen8_ctx_workarounds_init(engine, wal);
/* WaDisableThreadStallDopClockGating:chv */
WA_SET_BIT_MASKED(GEN8_ROW_CHICKEN, STALL_DOP_GATING_DISABLE);
@@ -286,10 +284,10 @@ static void chv_ctx_workarounds_init(struct
intel_engine_cs *engine)
WA_SET_BIT_MASKED(HIZ_CHICKEN, CHV_HZ_8X8_MODE_IN_1X);
}
-static void gen9_ctx_workarounds_init(struct intel_engine_cs *engine)
+static void gen9_ctx_workarounds_init(struct intel_engine_cs *engine,
+ struct i915_wa_list *wal)
{
struct drm_i915_private *i915 = engine->i915;
- struct i915_wa_list *wal = >ctx_wa_list;
if (HAS_LLC(i915)) {
/* WaCompressedResourceSamplerPbeMediaNewHashMode:skl,kbl
@@ -384,10 +382,10 @@ static void gen9_ctx_workarounds_init(struct
intel_engine_cs *engine)
WA_SET_BIT_MASKED(GEN9_WM_CHICKEN3, GEN9_FACTOR_IN_CLR_VAL_HIZ);
}
-static void skl_tune_iz_hashing(struct intel_engine_cs *engine)
+static void skl_tune_iz_hashing(struct intel_engine_cs *engine,
+ struct i915_wa_list *wal)
{
struct drm_i915_private *i915 = engine->i915;
- struct i915_wa_list *wal = >ctx_wa_list;
u8 vals[3] = { 0, 0, 0 };
unsigned int i;
@@ -424,17 +422,17 @@ static void skl_tune_iz_hashing(struct intel_engine_cs
*engine)
GEN9_IZ_HASHING(0, vals[0]));
}
-static void skl_ctx_workarounds_init(struct intel_engine_cs *engine)
+static void skl_ctx_workarounds_init(struct intel_engine_cs *engine,
+struct i915_wa_list *wal)
{
- gen9_ctx_workarounds_init(engine);
- skl_tune_iz_hashing(engine);
+ gen9_ctx_workarounds_init(engine, wal);
+ skl_tune_iz_hashing(engine, wal);
}
-static void bxt_ctx_workarounds_init(struct intel_engine_cs *engine)
+static void bxt_ctx_workarounds_init(struct intel_engine_cs *engine,
+struct i915_wa_list *wal)
{
- struct i915_wa_list *wal = >ctx_wa_list;
-
-
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: added i2c symlink to hdmi connector (rev2)
== Series Details == Series: drm/i915: added i2c symlink to hdmi connector (rev2) URL : https://patchwork.freedesktop.org/series/60794/ State : warning == Summary == $ dim checkpatch origin/drm-tip 7cf050cd9642 drm/i915: add i2c symlink under hdmi connector -:44: WARNING:LINE_SPACING: Missing a blank line after declarations #44: FILE: drivers/gpu/drm/i915/intel_hdmi.c:2656: + struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector); + return intel_gmbus_get_adapter(dev_priv, intel_hdmi->ddc_bus); total: 0 errors, 1 warnings, 0 checks, 64 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/2] drm/i915/selftests: Verify context workarounds
== Series Details == Series: series starting with [v2,1/2] drm/i915/selftests: Verify context workarounds URL : https://patchwork.freedesktop.org/series/60855/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915/selftests: Verify context workarounds +drivers/gpu/drm/i915/gt/intel_workarounds.c:572:6: warning: symbol '__intel_engine_init_ctx_wa' was not declared. Should it be static? Commit: drm/i915/icl: Add WaDisableBankHangMode Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Revert "ICL HACK: Disable ACPI idle driver"
HI,
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Aditya Swarup
> Sent: lauantai 18. toukokuuta 2019 1.00
> To: Gupta, Anshuman
> Cc: Vetter, Daniel ; intel-gfx@lists.freedesktop.org;
> Syrjala, Ville ; Peres, Martin
>
> Subject: Re: [Intel-gfx] [PATCH] Revert "ICL HACK: Disable ACPI idle driver"
>
> The patch looks fine to me.
> On Thu, May 16, 2019 at 10:41:56PM +0530, Anshuman Gupta wrote:
> > This reverts commit 99b69db57544ec7ed427607f1a2a1858a7d43b61
> > Core-for-CI:ICL_only Disable ACPI idle driver.
> >
> > This hack has been provided considering the Bug assessment that ACPI
> > idle driver page fault causes below bug.
> > FDO https://bugs.freedesktop.org/show_bug.cgi?id=108840
> > But this bug is still reproducible after disabling ACPI idle driver.
> >
> > It looks "rcu_preempt self-detected stall on CPU" causes to hung
> > kworker and followed by panic resulted this bug.
> >
> > Hence it make sense to revert this patch.
> >
> > Cc: martin.pe...@intel.com
> > Cc: daniel.vet...@intel.com
> > Cc: ville.syrj...@intel.com
>
> Reviewed-by: Aditya Swarup
Are we now ok to merge this or? Chris, Ville?
>
> > Signed-off-by: Anshuman Gupta
> > ---
> > drivers/acpi/processor_driver.c | 18 +-
> > 1 file changed, 1 insertion(+), 17 deletions(-)
> >
> > diff --git a/drivers/acpi/processor_driver.c
> > b/drivers/acpi/processor_driver.c index ee842a2f..9d6aff2 100644
> > --- a/drivers/acpi/processor_driver.c
> > +++ b/drivers/acpi/processor_driver.c
> > @@ -35,12 +35,6 @@
> >
> > #include
> >
> > -/* Only for Core-for-CI so don't want ia64 to fail compilation.*/
> > -#ifdef CONFIG_X86 -#include -#include
> > -#endif
> > -
> > #include "internal.h"
> >
> > #define ACPI_PROCESSOR_NOTIFY_PERFORMANCE 0x80 @@ -64,13 +58,6 @@
> > static const struct acpi_device_id processor_device_ids[] = { };
> > MODULE_DEVICE_TABLE(acpi, processor_device_ids);
> >
> > -#define ICPU(model){ X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, }
> > -static const struct x86_cpu_id intel_cpu_ids[] = {
> > - ICPU(INTEL_FAM6_ICELAKE_MOBILE),/* ICL */
> > - {}
> > -};
> > -MODULE_DEVICE_TABLE(x86cpu, intel_cpu_ids);
> > -
> > static struct device_driver acpi_processor_driver = {
> > .name = "processor",
> > .bus = _subsys,
> > @@ -239,7 +226,6 @@ static inline void acpi_pss_perf_exit(struct
> > acpi_processor *pr, static int __acpi_processor_start(struct
> > acpi_device *device) {
> > struct acpi_processor *pr = acpi_driver_data(device);
> > - const struct x86_cpu_id *id;
> > acpi_status status;
> > int result = 0;
> >
> > @@ -253,9 +239,7 @@ static int __acpi_processor_start(struct acpi_device
> *device)
> > if (result && !IS_ENABLED(CONFIG_ACPI_CPU_FREQ_PSS))
> > dev_dbg(>dev, "CPPC data invalid or not present\n");
> >
> > - id = x86_match_cpu(intel_cpu_ids);
> > - if (!id && (!cpuidle_get_driver() || cpuidle_get_driver() ==
> > - _idle_driver))
> > + if (!cpuidle_get_driver() || cpuidle_get_driver() ==
> > +_idle_driver)
> > acpi_processor_power_init(pr);
> >
> > result = acpi_pss_perf_init(pr, device);
> > --
> > 2.7.4
> >
> > ___
> > 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
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/33] drm/i915: Restore control over ppgtt for context creation ABI
== Series Details == Series: series starting with [01/33] drm/i915: Restore control over ppgtt for context creation ABI URL : https://patchwork.freedesktop.org/series/60842/ State : failure == Summary == Applying: drm/i915: Restore control over ppgtt for context creation ABI Applying: drm/i915: Allow a context to define its set of engines Applying: drm/i915: Extend I915_CONTEXT_PARAM_SSEU to support local ctx->engine[] Applying: drm/i915: Re-expose SINGLE_TIMELINE flags for context creation Applying: drm/i915: Allow userspace to clone contexts on creation Applying: drm/i915: Load balancing across a virtual engine Applying: drm/i915: Apply an execution_mask to the virtual_engine Applying: drm/i915: Extend execution fence to support a callback Applying: drm/i915/execlists: Virtual engine bonding Applying: drm/i915: Allow specification of parallel execbuf Applying: drm/i915: Split GEM object type definition to its own header Applying: drm/i915: Pull GEM ioctls interface to its own file Applying: drm/i915: Move object->pages API to i915_gem_object.[ch] Applying: drm/i915: Move shmem object setup to its own file Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_gem.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/i915_gem.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/i915_gem.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch' to see the failed patch Patch failed at 0014 drm/i915: Move shmem object setup to its own file 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 18/33] drm/i915: Move more GEM objects under gem/
Chris Wilson writes: > Continuing the theme of separating out the GEM clutter. > > Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] linux-next: Fixes tag needs some work in the drm-intel tree
Hi all,
In commit
0d90ccb70211 ("drm/i915: Delay semaphore submission until the start of the
signaler")
Fixes tag
Fixes: e88619646971 ("drm/i915: Use HW semaphores for inter-engine synchroni
has these problem(s):
- Subject has leading but no trailing parentheses
- Subject has leading but no trailing quotes
Please don't split Fixes tags across more than one line.
--
Cheers,
Stephen Rothwell
pgpBEqVa_2TQ6.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/huc: Don't try to check HuC status if it's not loaded
On Mon, 20 May 2019 12:44:43 +0200, Chris Wilson
wrote:
Quoting Michal Wajdeczko (2019-05-20 11:24:37)
On Mon, 20 May 2019 11:35:26 +0200, Chris Wilson
wrote:
> Quoting Michal Wajdeczko (2019-05-19 22:50:43)
>> If we never attempted to load HuC firmware, or we already wedged
>> or reset GuC/HuC, then there is no reason to wake up the device
>> to check one bit in the register that will be for sure cleared.
>>
>> v2: check if HuC was enabled; subtle change in ABI
>> reuse hus_is_load helper
>>
>> Suggested-by: Chris Wilson
>> Signed-off-by: Michal Wajdeczko
>> Cc: Chris Wilson
>> Cc: Tony Ye
>> ---
>> drivers/gpu/drm/i915/intel_huc.c | 20
>> drivers/gpu/drm/i915/intel_huc.h | 5 +
>> 2 files changed, 17 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_huc.c
>> b/drivers/gpu/drm/i915/intel_huc.c
>> index 1ff1fb015e58..bfdebec1cfc8 100644
>> --- a/drivers/gpu/drm/i915/intel_huc.c
>> +++ b/drivers/gpu/drm/i915/intel_huc.c
>> @@ -113,7 +113,7 @@ int intel_huc_auth(struct intel_huc *huc)
>> u32 status;
>> int ret;
>>
>> - if (huc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
>> + if (!intel_huc_is_loaded(huc))
>> return -ENOEXEC;
>>
>> ret = intel_guc_auth_huc(guc,
>> @@ -150,21 +150,25 @@ int intel_huc_auth(struct intel_huc *huc)
>> * This function reads status register to verify if HuC
>> * firmware was successfully loaded.
>> *
>> - * Returns: 1 if HuC firmware is loaded and verified,
>> - * 0 if HuC firmware is not loaded and -ENODEV if HuC
>> - * is not present on this platform.
>> + * Returns: 1 if HuC firmware is loaded and verified, 0 if HuC
>> firmware is not
>> + * enabled, -ENOPKG if HuC firmware is not loaded and -ENODEV if HuC
>> is not
>> + * present on this platform.
>> */
>> int intel_huc_check_status(struct intel_huc *huc)
>> {
>> struct drm_i915_private *dev_priv = huc_to_i915(huc);
>> intel_wakeref_t wakeref;
>> - bool status = false;
>> + bool verified = false;
>>
>> if (!HAS_HUC(dev_priv))
>> return -ENODEV;
>>
>> - with_intel_runtime_pm(dev_priv, wakeref)
>> - status = I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED;
>> + if (!USES_HUC(dev_priv))
>> + return 0;
>
> Hmm, EOPNOTSUPP here for the user disabled case?
I'm not sure that user disabled case shall be reported as error,
since it perfectly fits into legacy ABI 0="not loaded".
The only small change is that now 0="not loaded (not enabled by user)"
The only requirement for the intel-media driver seems to "HUC_STATUS >
0".
That's our only user, so I think we have the liberty to redefine <=0 as
befits error reporting.
>
> Then
>
> if (!intel_huc_is_loaded(huc))
> return -ENOPKG;
>
> bool verified = false;
> with_intel_runtime_pm(dev_priv, wakeref)
> verified = I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED;
> return verified.
>
> That keeps it a bit flatter with the special casing separate and the
0/1
> result as given by the register status. Then if negative, we know one
of
> the preconditions for using HuC is not available, and if 0 something
went
> wrong in mmio setup.
>
> Does that make sense?
IMHO, if something went wrong it is better to report it as error rather
then weak 0 status. Compare:
I disagree, <0 is the weak case. 0 is the HW reports something went
wrong (and only that). 1 is the HW reports all went well.
But I was assuming that we're defining ABI here, not simply exposing
unified
register value. Since we want 1 to report all ok, and we can fail for many
reasons (no hw, no fw blob, wrong fw, bad signature, ...) we should at
least
try to match all these failures into error code (today just ENOPKG, but
later
we can extend into ENOEXEC=bad fw, ENOSPC=can't fit into WOPCM, ...).
On other hand, at least for me, user decision to disable HuC should not
be treated the same way as other real failures, so 0 seems like perfect
match.
Then we'll have: 1 = enabled, 0 = disabled, <0 = problem
If we have more ways we can report the HW went wrong, sure expand that
into extra error codes, but I don't see that. And if it's in the regs,
why are not exporting them via reg_read_ioctl?
+---+---+---+---+
no hardware -ENODEV -ENODEV -ENODEV
fw disabled0 0-ENOTSUP
fw not loaded 0-ENOPKG -ENOPKG
fw not verified* 0-ENOPKG0
fw verified* 1 1 1
+---+---+---+---+
*) registry access
Note that in your case, fw verification problem can be reported both
as -ENOPKG or as 0 (former when verification fails at load time, latter
as result of runtime reg read). Very likely we will never see 0 at all,
since probably that can't change once fw was verified at load time.
I see more distinction for ENODEV/ENOTSUP/ENOPKG/0/1. I am not getting
your point that we have conflation here, as to me
[Intel-gfx] [PATCH v2 02/25] trace.pl: Ignore signaling on non i915 fences
From: Tvrtko Ursulin
gem_wsim uses the sw_fence timeline and confuses the script.
v2:
* Check the correct timeline as well. (Chris)
Signed-off-by: Tvrtko Ursulin
---
scripts/trace.pl | 2 ++
1 file changed, 2 insertions(+)
diff --git a/scripts/trace.pl b/scripts/trace.pl
index b7bbabc79f68..5f70cd23979b 100755
--- a/scripts/trace.pl
+++ b/scripts/trace.pl
@@ -439,6 +439,8 @@ while (<>) {
} elsif ($tp_name eq 'dma_fence:dma_fence_signaled:') {
my $gkey;
+ next unless $tp{'driver'} eq 'i915' and
+ $tp{'timeline'} eq 'signaled';
die unless exists $ctxengines{$tp{'context'}};
$gkey = db_key($ctxengines{$tp{'context'}}, $tp{'context'},
$tp{'seqno'});
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dp: Support for DP YCbCr4:2:0 outputs (rev3)
== Series Details == Series: drm/i915/dp: Support for DP YCbCr4:2:0 outputs (rev3) URL : https://patchwork.freedesktop.org/series/60404/ State : success == Summary == CI Bug Log - changes from CI_DRM_6097_full -> Patchwork_13043_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_13043_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_tiled_swapping@non-threaded: - shard-kbl: [PASS][1] -> [FAIL][2] ([fdo#108686]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6097/shard-kbl6/igt@gem_tiled_swapp...@non-threaded.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13043/shard-kbl4/igt@gem_tiled_swapp...@non-threaded.html * igt@i915_pm_rc6_residency@rc6-accuracy: - shard-kbl: [PASS][3] -> [SKIP][4] ([fdo#109271]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6097/shard-kbl4/igt@i915_pm_rc6_reside...@rc6-accuracy.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13043/shard-kbl7/igt@i915_pm_rc6_reside...@rc6-accuracy.html * igt@i915_pm_rpm@legacy-planes: - shard-skl: [PASS][5] -> [INCOMPLETE][6] ([fdo#107807]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6097/shard-skl1/igt@i915_pm_...@legacy-planes.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13043/shard-skl8/igt@i915_pm_...@legacy-planes.html * igt@i915_suspend@sysfs-reader: - shard-apl: [PASS][7] -> [DMESG-WARN][8] ([fdo#108566]) +6 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6097/shard-apl3/igt@i915_susp...@sysfs-reader.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13043/shard-apl8/igt@i915_susp...@sysfs-reader.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-skl: [PASS][9] -> [FAIL][10] ([fdo#105363]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6097/shard-skl4/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13043/shard-skl7/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-pwrite: - shard-iclb: [PASS][11] -> [FAIL][12] ([fdo#103167]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6097/shard-iclb6/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-pwrite.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13043/shard-iclb1/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-pwrite.html * igt@kms_psr@psr2_sprite_mmap_gtt: - shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#109441]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6097/shard-iclb2/igt@kms_psr@psr2_sprite_mmap_gtt.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13043/shard-iclb3/igt@kms_psr@psr2_sprite_mmap_gtt.html * igt@kms_setmode@basic: - shard-apl: [PASS][15] -> [FAIL][16] ([fdo#99912]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6097/shard-apl6/igt@kms_setm...@basic.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13043/shard-apl4/igt@kms_setm...@basic.html Possible fixes * igt@gem_tiled_swapping@non-threaded: - shard-glk: [DMESG-WARN][17] ([fdo#108686]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6097/shard-glk7/igt@gem_tiled_swapp...@non-threaded.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13043/shard-glk1/igt@gem_tiled_swapp...@non-threaded.html - shard-hsw: [FAIL][19] ([fdo#108686]) -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6097/shard-hsw6/igt@gem_tiled_swapp...@non-threaded.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13043/shard-hsw8/igt@gem_tiled_swapp...@non-threaded.html * igt@i915_pm_rpm@debugfs-read: - shard-skl: [INCOMPLETE][21] ([fdo#107807]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6097/shard-skl3/igt@i915_pm_...@debugfs-read.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13043/shard-skl5/igt@i915_pm_...@debugfs-read.html * igt@i915_pm_rpm@gem-execbuf: - shard-skl: [INCOMPLETE][23] ([fdo#107803] / [fdo#107807]) -> [PASS][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6097/shard-skl4/igt@i915_pm_...@gem-execbuf.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13043/shard-skl8/igt@i915_pm_...@gem-execbuf.html * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic: - shard-hsw: [FAIL][25] ([fdo#105767]) -> [PASS][26] [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6097/shard-hsw1/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html [26]:
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 12/25] gem_wsim: Engine map support
On 20/05/2019 11:59, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-05-20 11:49:13)
On 17/05/2019 20:35, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-05-17 12:25:13)
+ /*
+* Ensure VCS is not allowed with engine map contexts.
+*/
+ for (j = 0; j < wrk->nr_ctxs; j += 2) {
+ for (i = 0, w = wrk->steps; i < wrk->nr_steps; i++, w++) {
+ if (w->context != (j / 2))
+ continue;
+
+ if (w->type != BATCH)
+ continue;
+
+ if (wrk->ctx_list[j].engine_map && w->engine == VCS) {
But wouldn't VCS still be meaning use the balancer and not a specific
engine???
I'm not understanding how you are using maps in the .wsim :(
Batch sent to VCS means any VCS if not a context with a map, but VCS
mentioned in the map now auto-expands to all present VCS instances.
VCS as engine specifier at execbuf time could be allowed if code would
then check if there is a load balancer built of vcs engines in this context.
But what use case you think is not covered?
We got legacy wsim files which implicitly create a map by doing:
1.VCS.1000.0.0 -> submit a batch to any vcs
And then after this series you can also do:
M.1.VCS
B.1
1.DEFAULT.1000.0.0
Which would have the same effect.
You would seem want:
M.1.VCS
B.1
1.VCS.1000.0.0
?
But I don't see what it gains?
I just have a picture of a map consisting of
[RCS] = rcs0,
[BCS] = 0,
[VCS] = (vcs0, vcs2),
Then the workload would be a single context, feeding batches to RCS and
VCS, which are then mapped to hardware and balanced as suitable. One
could go even further with RCS0, RCS1 for different logical state within
the same client context (different pipelines, same vm). That is how I
think I would decompose the media workloads given a fresh start on top
of the new api -- and then probably cursing the limits of that api.
Hm.. this is quite an appealing idea. I'll give it some thought to see
how difficult or easy it would be to implement it. I however ask for
dispensation to consider this follow up work since turning some
implementation details on their head could be a bit time consuming.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 1/2] drm/i915/selftests: Verify context workarounds
From: Tvrtko Ursulin
Test context workarounds have been correctly applied in newly created
contexts.
To accomplish this the existing engine_wa_list_verify helper is extended
to take in a context from which reading of the workaround list will be
done.
Context workaround verification is done from the existing subtests, which
have been renamed to reflect they are no longer only about GT and engine
workarounds.
v2:
* Test after resets and refactor to use intel_context more. (Chris)
v3:
* Use ce->engine->i915 instead of ce->gem_context->i915. (Chris)
* gem_engine_iter.idx is engine->id + 1. (Chris)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 111 ++
.../gpu/drm/i915/gt/selftest_workarounds.c| 54 ++---
2 files changed, 97 insertions(+), 68 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 43e290306551..a6a6477cf722 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -196,10 +196,9 @@ ignore_wa_write_or(struct i915_wa_list *wal, i915_reg_t
reg, u32 mask, u32 val)
#define WA_SET_FIELD_MASKED(addr, mask, value) \
wa_write_masked_or(wal, (addr), (mask), _MASKED_FIELD((mask), (value)))
-static void gen8_ctx_workarounds_init(struct intel_engine_cs *engine)
+static void gen8_ctx_workarounds_init(struct intel_engine_cs *engine,
+ struct i915_wa_list *wal)
{
- struct i915_wa_list *wal = >ctx_wa_list;
-
WA_SET_BIT_MASKED(INSTPM, INSTPM_FORCE_ORDERING);
/* WaDisableAsyncFlipPerfMode:bdw,chv */
@@ -245,12 +244,12 @@ static void gen8_ctx_workarounds_init(struct
intel_engine_cs *engine)
GEN6_WIZ_HASHING_16x4);
}
-static void bdw_ctx_workarounds_init(struct intel_engine_cs *engine)
+static void bdw_ctx_workarounds_init(struct intel_engine_cs *engine,
+struct i915_wa_list *wal)
{
struct drm_i915_private *i915 = engine->i915;
- struct i915_wa_list *wal = >ctx_wa_list;
- gen8_ctx_workarounds_init(engine);
+ gen8_ctx_workarounds_init(engine, wal);
/* WaDisableThreadStallDopClockGating:bdw (pre-production) */
WA_SET_BIT_MASKED(GEN8_ROW_CHICKEN, STALL_DOP_GATING_DISABLE);
@@ -273,11 +272,10 @@ static void bdw_ctx_workarounds_init(struct
intel_engine_cs *engine)
(IS_BDW_GT3(i915) ? HDC_FENCE_DEST_SLM_DISABLE : 0));
}
-static void chv_ctx_workarounds_init(struct intel_engine_cs *engine)
+static void chv_ctx_workarounds_init(struct intel_engine_cs *engine,
+struct i915_wa_list *wal)
{
- struct i915_wa_list *wal = >ctx_wa_list;
-
- gen8_ctx_workarounds_init(engine);
+ gen8_ctx_workarounds_init(engine, wal);
/* WaDisableThreadStallDopClockGating:chv */
WA_SET_BIT_MASKED(GEN8_ROW_CHICKEN, STALL_DOP_GATING_DISABLE);
@@ -286,10 +284,10 @@ static void chv_ctx_workarounds_init(struct
intel_engine_cs *engine)
WA_SET_BIT_MASKED(HIZ_CHICKEN, CHV_HZ_8X8_MODE_IN_1X);
}
-static void gen9_ctx_workarounds_init(struct intel_engine_cs *engine)
+static void gen9_ctx_workarounds_init(struct intel_engine_cs *engine,
+ struct i915_wa_list *wal)
{
struct drm_i915_private *i915 = engine->i915;
- struct i915_wa_list *wal = >ctx_wa_list;
if (HAS_LLC(i915)) {
/* WaCompressedResourceSamplerPbeMediaNewHashMode:skl,kbl
@@ -384,10 +382,10 @@ static void gen9_ctx_workarounds_init(struct
intel_engine_cs *engine)
WA_SET_BIT_MASKED(GEN9_WM_CHICKEN3, GEN9_FACTOR_IN_CLR_VAL_HIZ);
}
-static void skl_tune_iz_hashing(struct intel_engine_cs *engine)
+static void skl_tune_iz_hashing(struct intel_engine_cs *engine,
+ struct i915_wa_list *wal)
{
struct drm_i915_private *i915 = engine->i915;
- struct i915_wa_list *wal = >ctx_wa_list;
u8 vals[3] = { 0, 0, 0 };
unsigned int i;
@@ -424,17 +422,17 @@ static void skl_tune_iz_hashing(struct intel_engine_cs
*engine)
GEN9_IZ_HASHING(0, vals[0]));
}
-static void skl_ctx_workarounds_init(struct intel_engine_cs *engine)
+static void skl_ctx_workarounds_init(struct intel_engine_cs *engine,
+struct i915_wa_list *wal)
{
- gen9_ctx_workarounds_init(engine);
- skl_tune_iz_hashing(engine);
+ gen9_ctx_workarounds_init(engine, wal);
+ skl_tune_iz_hashing(engine, wal);
}
-static void bxt_ctx_workarounds_init(struct intel_engine_cs *engine)
+static void bxt_ctx_workarounds_init(struct intel_engine_cs *engine,
+struct i915_wa_list *wal)
{
- struct i915_wa_list *wal = >ctx_wa_list;
-
- gen9_ctx_workarounds_init(engine);
+
[Intel-gfx] [PATCH v3 2/2] drm/i915/icl: Add WaDisableBankHangMode
From: Tvrtko Ursulin
Disable GPU hang by default on unrecoverable ECC cache errors.
v2:
* Rebase.
v3:
* Use intel_uncore_read. (Chris)
Fixes: cc38cae7c4e9 ("drm/i915/icl: Introduce initial Icelake Workarounds")
Signed-off-by: Tvrtko Ursulin
Acked-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 ++
drivers/gpu/drm/i915/i915_reg.h | 3 +++
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index a6a6477cf722..7675699f8406 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -529,6 +529,12 @@ static void icl_ctx_workarounds_init(struct
intel_engine_cs *engine,
{
struct drm_i915_private *i915 = engine->i915;
+ /* WaDisableBankHangMode:icl */
+ wa_write(wal,
+GEN8_L3CNTLREG,
+intel_uncore_read(engine->uncore, GEN8_L3CNTLREG) |
+GEN8_ERRDETBCTRL);
+
/* Wa_1604370585:icl (pre-prod)
* Formerly known as WaPushConstantDereferenceHoldDisable
*/
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e97c47fca645..87e8780711d7 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7621,6 +7621,9 @@ enum {
#define GEN8_SBE_DISABLE_REPLAY_BUF_OPTIMIZATION (1 << 8)
#define GEN8_CSC2_SBE_VUE_CACHE_CONSERVATIVE (1 << 0)
+#define GEN8_L3CNTLREG _MMIO(0x7034)
+ #define GEN8_ERRDETBCTRL (1 << 9)
+
#define GEN11_COMMON_SLICE_CHICKEN3_MMIO(0x7304)
#define GEN11_BLEND_EMB_FIX_DISABLE_IN_RCC (1 << 11)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 12/25] gem_wsim: Engine map support
Quoting Tvrtko Ursulin (2019-05-20 11:49:13)
>
> On 17/05/2019 20:35, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-05-17 12:25:13)
> >> + /*
> >> +* Ensure VCS is not allowed with engine map contexts.
> >> +*/
> >> + for (j = 0; j < wrk->nr_ctxs; j += 2) {
> >> + for (i = 0, w = wrk->steps; i < wrk->nr_steps; i++, w++) {
> >> + if (w->context != (j / 2))
> >> + continue;
> >> +
> >> + if (w->type != BATCH)
> >> + continue;
> >> +
> >> + if (wrk->ctx_list[j].engine_map && w->engine ==
> >> VCS) {
> >
> > But wouldn't VCS still be meaning use the balancer and not a specific
> > engine???
> >
> > I'm not understanding how you are using maps in the .wsim :(
>
> Batch sent to VCS means any VCS if not a context with a map, but VCS
> mentioned in the map now auto-expands to all present VCS instances.
>
> VCS as engine specifier at execbuf time could be allowed if code would
> then check if there is a load balancer built of vcs engines in this context.
>
> But what use case you think is not covered?
>
> We got legacy wsim files which implicitly create a map by doing:
>
> 1.VCS.1000.0.0 -> submit a batch to any vcs
>
> And then after this series you can also do:
>
> M.1.VCS
> B.1
> 1.DEFAULT.1000.0.0
>
> Which would have the same effect.
>
> You would seem want:
>
> M.1.VCS
> B.1
> 1.VCS.1000.0.0
>
> ?
>
> But I don't see what it gains?
I just have a picture of a map consisting of
[RCS] = rcs0,
[BCS] = 0,
[VCS] = (vcs0, vcs2),
Then the workload would be a single context, feeding batches to RCS and
VCS, which are then mapped to hardware and balanced as suitable. One
could go even further with RCS0, RCS1 for different logical state within
the same client context (different pipelines, same vm). That is how I
think I would decompose the media workloads given a fresh start on top
of the new api -- and then probably cursing the limits of that api.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH] drm/i915: Tolerate file owned GEM contexts on hot unbind
On Friday, May 17, 2019 4:32:35 PM CEST Chris Wilson wrote: > Quoting Janusz Krzysztofik (2019-05-17 15:06:17) > > From: Janusz Krzysztofik > > > > During i915_driver_unload(), GEM contexts are verified restrictively > > inside i915_gem_fini() if they don't consume shared resources which > > should be cleaned up before the driver is released. If those checks > > don't result in kernel panic, one more check is performed at the end of > > i915_gem_fini() which issues a WARN_ON() if GEM contexts still exist. > > Just fix the underlying bug of this code being called too early. The > assumptions we made for unload are clearly invalid when applied to > unbind, and we need to split the phases. > -Chris Thanks Chris, I think I get it finally. Janusz ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 12/25] gem_wsim: Engine map support
On 17/05/2019 20:35, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-05-17 12:25:13)
From: Tvrtko Ursulin
Support new i915 uAPI for configuring contexts with engine maps.
Please refer to the README file for more detailed explanation.
v2:
* Allow defining engine maps by class.
Signed-off-by: Tvrtko Ursulin
---
benchmarks/gem_wsim.c | 211 +++--
benchmarks/wsim/README | 25 -
2 files changed, 204 insertions(+), 32 deletions(-)
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
index 60b7d32e22d4..e5b12e37490e 100644
--- a/benchmarks/gem_wsim.c
+++ b/benchmarks/gem_wsim.c
@@ -57,6 +57,7 @@
#include "ewma.h"
enum intel_engine_id {
+ DEFAULT,
RCS,
BCS,
VCS,
@@ -81,7 +82,8 @@ enum w_type
SW_FENCE,
SW_FENCE_SIGNAL,
CTX_PRIORITY,
- PREEMPTION
+ PREEMPTION,
+ ENGINE_MAP
};
struct deps
@@ -115,6 +117,10 @@ struct w_step
int throttle;
int fence_signal;
int priority;
+ struct {
+ unsigned int engine_map_count;
+ enum intel_engine_id *engine_map;
+ };
};
/* Implementation details */
@@ -142,6 +148,8 @@ DECLARE_EWMA(uint64_t, rt, 4, 2)
struct ctx {
uint32_t id;
int priority;
+ unsigned int engine_map_count;
+ enum intel_engine_id *engine_map;
bool targets_instance;
bool wants_balance;
unsigned int static_vcs;
@@ -200,10 +208,10 @@ struct workload
int fd;
bool first;
unsigned int num_engines;
- unsigned int engine_map[5];
+ unsigned int engine_map[NUM_ENGINES];
uint64_t t_prev;
- uint64_t prev[5];
- double busy[5];
+ uint64_t prev[NUM_ENGINES];
+ double busy[NUM_ENGINES];
} busy_balancer;
};
@@ -234,6 +242,7 @@ static int fd;
#define REG(x) (volatile uint32_t *)((volatile char *)igt_global_mmio + x)
static const char *ring_str_map[NUM_ENGINES] = {
+ [DEFAULT] = "DEFAULT",
[RCS] = "RCS",
[BCS] = "BCS",
[VCS] = "VCS",
@@ -330,6 +339,43 @@ static int str_to_engine(const char *str)
return -1;
}
+static int parse_engine_map(struct w_step *step, const char *_str)
+{
+ char *token, *tctx = NULL, *tstart = (char *)_str;
+
+ while ((token = strtok_r(tstart, "|", ))) {
+ enum intel_engine_id engine;
+ unsigned int add;
+
+ tstart = NULL;
+
+ if (!strcmp(token, "DEFAULT"))
+ return -1;
+
+ engine = str_to_engine(token);
+ if ((int)engine < 0)
+ return -1;
+
+ if (engine != VCS && engine != VCS1 && engine != VCS2)
+ return -1; /* TODO */
Still a little concerned that the map is VCS only. It just doesn't fit
my expectations of what the map will be.
I think I could update this now that load_balance takes a list.
+
+ add = engine == VCS ? 2 : 1;
Will we not every ask what happens if we had millions of engines at our
disposal. But that's a tommorrow problem, ok.
This is improved in a later patch. It felt easier to generalize at the
end in this instance instead of trying to rebase the whole series.
+ step->engine_map_count += add;
+ step->engine_map = realloc(step->engine_map,
+ step->engine_map_count *
+ sizeof(step->engine_map[0]));
+
+ if (engine != VCS) {
+ step->engine_map[step->engine_map_count - 1] = engine;
+ } else {
+ step->engine_map[step->engine_map_count - 2] = VCS1;
+ step->engine_map[step->engine_map_count - 1] = VCS2;
+ }
+ }
+
+ return 0;
+}
+
static struct workload *
parse_workload(struct w_arg *arg, unsigned int flags, struct workload *app_w)
{
@@ -448,6 +494,33 @@ parse_workload(struct w_arg *arg, unsigned int flags,
struct workload *app_w)
} else if (!strcmp(field, "f")) {
step.type = SW_FENCE;
goto add_step;
+ } else if (!strcmp(field, "M")) {
+ unsigned int nr = 0;
+ while ((field = strtok_r(fstart, ".", )) !=
+ NULL) {
+ tmp = atoi(field);
+ check_arg(nr == 0 && tmp <= 0,
+ "Invalid context at step
%u!\n",
+ nr_steps);
+
Re: [Intel-gfx] [PATCH v2] drm/i915/huc: Don't try to check HuC status if it's not loaded
Quoting Michal Wajdeczko (2019-05-20 11:24:37)
> On Mon, 20 May 2019 11:35:26 +0200, Chris Wilson
> wrote:
>
> > Quoting Michal Wajdeczko (2019-05-19 22:50:43)
> >> If we never attempted to load HuC firmware, or we already wedged
> >> or reset GuC/HuC, then there is no reason to wake up the device
> >> to check one bit in the register that will be for sure cleared.
> >>
> >> v2: check if HuC was enabled; subtle change in ABI
> >> reuse hus_is_load helper
> >>
> >> Suggested-by: Chris Wilson
> >> Signed-off-by: Michal Wajdeczko
> >> Cc: Chris Wilson
> >> Cc: Tony Ye
> >> ---
> >> drivers/gpu/drm/i915/intel_huc.c | 20
> >> drivers/gpu/drm/i915/intel_huc.h | 5 +
> >> 2 files changed, 17 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_huc.c
> >> b/drivers/gpu/drm/i915/intel_huc.c
> >> index 1ff1fb015e58..bfdebec1cfc8 100644
> >> --- a/drivers/gpu/drm/i915/intel_huc.c
> >> +++ b/drivers/gpu/drm/i915/intel_huc.c
> >> @@ -113,7 +113,7 @@ int intel_huc_auth(struct intel_huc *huc)
> >> u32 status;
> >> int ret;
> >>
> >> - if (huc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
> >> + if (!intel_huc_is_loaded(huc))
> >> return -ENOEXEC;
> >>
> >> ret = intel_guc_auth_huc(guc,
> >> @@ -150,21 +150,25 @@ int intel_huc_auth(struct intel_huc *huc)
> >> * This function reads status register to verify if HuC
> >> * firmware was successfully loaded.
> >> *
> >> - * Returns: 1 if HuC firmware is loaded and verified,
> >> - * 0 if HuC firmware is not loaded and -ENODEV if HuC
> >> - * is not present on this platform.
> >> + * Returns: 1 if HuC firmware is loaded and verified, 0 if HuC
> >> firmware is not
> >> + * enabled, -ENOPKG if HuC firmware is not loaded and -ENODEV if HuC
> >> is not
> >> + * present on this platform.
> >> */
> >> int intel_huc_check_status(struct intel_huc *huc)
> >> {
> >> struct drm_i915_private *dev_priv = huc_to_i915(huc);
> >> intel_wakeref_t wakeref;
> >> - bool status = false;
> >> + bool verified = false;
> >>
> >> if (!HAS_HUC(dev_priv))
> >> return -ENODEV;
> >>
> >> - with_intel_runtime_pm(dev_priv, wakeref)
> >> - status = I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED;
> >> + if (!USES_HUC(dev_priv))
> >> + return 0;
> >
> > Hmm, EOPNOTSUPP here for the user disabled case?
>
> I'm not sure that user disabled case shall be reported as error,
> since it perfectly fits into legacy ABI 0="not loaded".
> The only small change is that now 0="not loaded (not enabled by user)"
The only requirement for the intel-media driver seems to "HUC_STATUS > 0".
That's our only user, so I think we have the liberty to redefine <=0 as
befits error reporting.
>
> >
> > Then
> >
> > if (!intel_huc_is_loaded(huc))
> > return -ENOPKG;
> >
> > bool verified = false;
> > with_intel_runtime_pm(dev_priv, wakeref)
> > verified = I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED;
> > return verified.
> >
> > That keeps it a bit flatter with the special casing separate and the 0/1
> > result as given by the register status. Then if negative, we know one of
> > the preconditions for using HuC is not available, and if 0 something went
> > wrong in mmio setup.
> >
> > Does that make sense?
>
> IMHO, if something went wrong it is better to report it as error rather
> then weak 0 status. Compare:
I disagree, <0 is the weak case. 0 is the HW reports something went
wrong (and only that). 1 is the HW reports all went well.
If we have more ways we can report the HW went wrong, sure expand that
into extra error codes, but I don't see that. And if it's in the regs,
why are not exporting them via reg_read_ioctl?
> +---+---+---+---+
> no hardware -ENODEV -ENODEV -ENODEV
> fw disabled0 0-ENOTSUP
> fw not loaded 0-ENOPKG -ENOPKG
> fw not verified* 0-ENOPKG0
> fw verified* 1 1 1
> +---+---+---+---+
> *) registry access
>
> Note that in your case, fw verification problem can be reported both
> as -ENOPKG or as 0 (former when verification fails at load time, latter
> as result of runtime reg read). Very likely we will never see 0 at all,
> since probably that can't change once fw was verified at load time.
I see more distinction for ENODEV/ENOTSUP/ENOPKG/0/1. I am not getting
your point that we have conflation here, as to me it looks more
distinct, and it is clear when we report the value as given by the
register and when we give an interpreted value for a driver error.
> That might be viewed as undesired ABI change.
grep says it is fine, so I'm happy that no one else cares (as can be
seen by the lack of igt, no one has looked hard enough into how to
distinguish the API failures ;)
-Chris
___
Intel-gfx mailing list
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/selftests: Add live_context_workarounds
== Series Details == Series: series starting with [1/2] drm/i915/selftests: Add live_context_workarounds URL : https://patchwork.freedesktop.org/series/60846/ State : success == Summary == CI Bug Log - changes from CI_DRM_6097_full -> Patchwork_13042_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_13042_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_mmap_gtt@forked-big-copy: - shard-iclb: [PASS][1] -> [TIMEOUT][2] ([fdo#109673]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6097/shard-iclb3/igt@gem_mmap_...@forked-big-copy.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13042/shard-iclb1/igt@gem_mmap_...@forked-big-copy.html * igt@gem_tiled_swapping@non-threaded: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([fdo#108686]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6097/shard-apl4/igt@gem_tiled_swapp...@non-threaded.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13042/shard-apl1/igt@gem_tiled_swapp...@non-threaded.html * igt@i915_pm_rpm@modeset-stress-extra-wait: - shard-glk: [PASS][5] -> [SKIP][6] ([fdo#109271]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6097/shard-glk6/igt@i915_pm_...@modeset-stress-extra-wait.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13042/shard-glk3/igt@i915_pm_...@modeset-stress-extra-wait.html * igt@i915_suspend@debugfs-reader: - shard-apl: [PASS][7] -> [DMESG-WARN][8] ([fdo#108566]) +2 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6097/shard-apl1/igt@i915_susp...@debugfs-reader.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13042/shard-apl8/igt@i915_susp...@debugfs-reader.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-pwrite: - shard-iclb: [PASS][9] -> [FAIL][10] ([fdo#103167]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6097/shard-iclb7/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-shrfb-draw-pwrite.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13042/shard-iclb2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-shrfb-draw-pwrite.html * igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-shrfb-draw-mmap-cpu: - shard-skl: [PASS][11] -> [FAIL][12] ([fdo#103167]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6097/shard-skl2/igt@kms_frontbuffer_track...@psr-1p-offscren-pri-shrfb-draw-mmap-cpu.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13042/shard-skl10/igt@kms_frontbuffer_track...@psr-1p-offscren-pri-shrfb-draw-mmap-cpu.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes: - shard-glk: [PASS][13] -> [INCOMPLETE][14] ([fdo#103359] / [k.org#198133]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6097/shard-glk1/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13042/shard-glk3/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html * igt@kms_psr@psr2_dpms: - shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109441]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6097/shard-iclb2/igt@kms_psr@psr2_dpms.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13042/shard-iclb3/igt@kms_psr@psr2_dpms.html * igt@kms_vblank@pipe-a-ts-continuation-dpms-rpm: - shard-glk: [PASS][17] -> [SKIP][18] ([fdo#109271] / [fdo#109278]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6097/shard-glk6/igt@kms_vbl...@pipe-a-ts-continuation-dpms-rpm.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13042/shard-glk3/igt@kms_vbl...@pipe-a-ts-continuation-dpms-rpm.html Possible fixes * igt@gem_mmap_gtt@forked-medium-copy-odd: - shard-iclb: [INCOMPLETE][19] ([fdo#107713]) -> [PASS][20] +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6097/shard-iclb7/igt@gem_mmap_...@forked-medium-copy-odd.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13042/shard-iclb2/igt@gem_mmap_...@forked-medium-copy-odd.html * igt@gem_tiled_swapping@non-threaded: - shard-glk: [DMESG-WARN][21] ([fdo#108686]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6097/shard-glk7/igt@gem_tiled_swapp...@non-threaded.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13042/shard-glk5/igt@gem_tiled_swapp...@non-threaded.html * igt@i915_pm_rpm@debugfs-read: - shard-skl: [INCOMPLETE][23] ([fdo#107807]) -> [PASS][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6097/shard-skl3/igt@i915_pm_...@debugfs-read.html [24]:
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/icl: Add WaDisableBankHangMode
Quoting Tvrtko Ursulin (2019-05-20 11:18:16)
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 468928cd8fb3..1a730424eba7 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -528,6 +528,12 @@ static void icl_ctx_workarounds_init(struct
> intel_engine_cs *engine,
> struct i915_wa_list *wal)
> {
> struct drm_i915_private *i915 = engine->i915;
> + struct drm_i915_private *dev_priv = i915;
> +
> + /* WaDisableBankHangMode:icl */
> + wa_write(wal,
> +GEN8_L3CNTLREG,
> +I915_READ(GEN8_L3CNTLREG) | GEN8_ERRDETBCTRL);
Oh, we converted intel_workarounds to intel_uncore_read() already.
intel_uncore_read(engine->uncore, GEN8_L3CNTLREG) | GEN8_ERRDETBCTRL
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/selftests: Verify context workarounds
Quoting Tvrtko Ursulin (2019-05-20 11:18:15)
> @@ -1352,11 +1357,11 @@ static int engine_wa_list_verify(struct
> intel_engine_cs *engine,
> if (!wal->count)
> return 0;
>
> - vma = create_scratch(>i915->ggtt.vm, wal->count);
> + vma = create_scratch(>gem_context->i915->ggtt.vm, wal->count);
Use ce->engine->i915->ggtt.vm to save me a headache later.
> if (IS_ERR(vma))
> return PTR_ERR(vma);
>
> - rq = i915_request_create(engine->kernel_context);
> + rq = intel_context_create_request(ce);
> if (IS_ERR(rq)) {
> err = PTR_ERR(rq);
> goto err_vma;
> @@ -1003,28 +1010,36 @@ static int live_isolated_whitelist(void *arg)
> return err;
> }
>
> -static bool verify_gt_engine_wa(struct drm_i915_private *i915,
> - struct wa_lists *lists, const char *str)
> +static bool
> +verify_wa_lists(struct i915_gem_context *ctx, struct wa_lists *lists,
> + const char *str)
> {
> - struct intel_engine_cs *engine;
> - enum intel_engine_id id;
> + struct drm_i915_private *i915 = ctx->i915;
> + struct i915_gem_engines_iter it;
> + struct intel_context *ce;
> bool ok = true;
>
> ok &= wa_list_verify(>uncore, >gt_wa_list, str);
>
> - for_each_engine(engine, i915, id) {
> - ok &= engine_wa_list_verify(engine,
> - >engine[id].wa_list,
> + for_each_gem_engine(ce, i915_gem_context_lock_engines(ctx), it) {
And for my piece of mind,
GEM_BUG_ON(it.idx != ce->engine->id)
as I already forgot the relationship for the default engine map.
> + ok &= engine_wa_list_verify(ce,
> + >engine[it.idx].wa_list,
> + str) == 0;
> +
> + ok &= engine_wa_list_verify(ce,
> +
> >engine[it.idx].ctx_wa_list,
> str) == 0;
> }
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 02/25] trace.pl: Ignore signaling on non i915 fences
On 17/05/2019 20:20, Chris Wilson wrote: Quoting Tvrtko Ursulin (2019-05-17 12:25:03) From: Tvrtko Ursulin gem_wsim uses the sw_fence timeline and confuses the script. sw_sync How does this fare with clflush fences (which are .driver="i915") and all of the future .driver="i915" fences? Looks like we are still prone to hitting that die. (Should die pretty quick on !llc) Okay I have to use the timeline name as well, thanks! Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 15/25] gem_wsim: Engine map load balance command
On 17/05/2019 20:36, Chris Wilson wrote: Quoting Tvrtko Ursulin (2019-05-17 12:25:16) From: Tvrtko Ursulin A new workload command for enabling a load balanced context map (aka Virtual Engine). Example usage: B.1 This turns on load balancing for context one, assuming it has already been configured with an engine map. Only DEFAULT engine specifier can be used with load balanced engine maps. Why? Hm... don't think there is a real reason and I definitely don't remember what I was thinking back when I wrote this sentence. :) I'll try lifting the restriction and see what happens. 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/huc: Don't try to check HuC status if it's not loaded
On Mon, 20 May 2019 11:35:26 +0200, Chris Wilson
wrote:
Quoting Michal Wajdeczko (2019-05-19 22:50:43)
If we never attempted to load HuC firmware, or we already wedged
or reset GuC/HuC, then there is no reason to wake up the device
to check one bit in the register that will be for sure cleared.
v2: check if HuC was enabled; subtle change in ABI
reuse hus_is_load helper
Suggested-by: Chris Wilson
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Tony Ye
---
drivers/gpu/drm/i915/intel_huc.c | 20
drivers/gpu/drm/i915/intel_huc.h | 5 +
2 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_huc.c
b/drivers/gpu/drm/i915/intel_huc.c
index 1ff1fb015e58..bfdebec1cfc8 100644
--- a/drivers/gpu/drm/i915/intel_huc.c
+++ b/drivers/gpu/drm/i915/intel_huc.c
@@ -113,7 +113,7 @@ int intel_huc_auth(struct intel_huc *huc)
u32 status;
int ret;
- if (huc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
+ if (!intel_huc_is_loaded(huc))
return -ENOEXEC;
ret = intel_guc_auth_huc(guc,
@@ -150,21 +150,25 @@ int intel_huc_auth(struct intel_huc *huc)
* This function reads status register to verify if HuC
* firmware was successfully loaded.
*
- * Returns: 1 if HuC firmware is loaded and verified,
- * 0 if HuC firmware is not loaded and -ENODEV if HuC
- * is not present on this platform.
+ * Returns: 1 if HuC firmware is loaded and verified, 0 if HuC
firmware is not
+ * enabled, -ENOPKG if HuC firmware is not loaded and -ENODEV if HuC
is not
+ * present on this platform.
*/
int intel_huc_check_status(struct intel_huc *huc)
{
struct drm_i915_private *dev_priv = huc_to_i915(huc);
intel_wakeref_t wakeref;
- bool status = false;
+ bool verified = false;
if (!HAS_HUC(dev_priv))
return -ENODEV;
- with_intel_runtime_pm(dev_priv, wakeref)
- status = I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED;
+ if (!USES_HUC(dev_priv))
+ return 0;
Hmm, EOPNOTSUPP here for the user disabled case?
I'm not sure that user disabled case shall be reported as error,
since it perfectly fits into legacy ABI 0="not loaded".
The only small change is that now 0="not loaded (not enabled by user)"
Then
if (!intel_huc_is_loaded(huc))
return -ENOPKG;
bool verified = false;
with_intel_runtime_pm(dev_priv, wakeref)
verified = I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED;
return verified.
That keeps it a bit flatter with the special casing separate and the 0/1
result as given by the register status. Then if negative, we know one of
the preconditions for using HuC is not available, and if 0 something went
wrong in mmio setup.
Does that make sense?
IMHO, if something went wrong it is better to report it as error rather
then weak 0 status. Compare:
+---+---+---+---+
no hardware -ENODEV -ENODEV -ENODEV
fw disabled0 0-ENOTSUP
fw not loaded 0-ENOPKG -ENOPKG
fw not verified* 0-ENOPKG0
fw verified* 1 1 1
+---+---+---+---+
*) registry access
Note that in your case, fw verification problem can be reported both
as -ENOPKG or as 0 (former when verification fails at load time, latter
as result of runtime reg read). Very likely we will never see 0 at all,
since probably that can't change once fw was verified at load time.
That might be viewed as undesired ABI change.
- return status;
+ if (intel_huc_is_loaded(huc))
+ with_intel_runtime_pm(dev_priv, wakeref)
+ verified = I915_READ(HUC_STATUS2) &
HUC_FW_VERIFIED;
+
+ return verified ? 1 : -ENOPKG;
}
diff --git a/drivers/gpu/drm/i915/intel_huc.h
b/drivers/gpu/drm/i915/intel_huc.h
index a0c21ae02a99..cde3d303718d 100644
--- a/drivers/gpu/drm/i915/intel_huc.h
+++ b/drivers/gpu/drm/i915/intel_huc.h
@@ -44,6 +44,11 @@ void intel_huc_fini(struct intel_huc *huc);
int intel_huc_auth(struct intel_huc *huc);
int intel_huc_check_status(struct intel_huc *huc);
+static inline bool intel_huc_is_loaded(struct intel_huc *huc)
+{
+ return intel_uc_fw_is_loaded(>fw);
+}
+
static inline void intel_huc_fini_misc(struct intel_huc *huc)
{
intel_uc_fw_cleanup_fetch(>fw);
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: add i2c symlink under hdmi connector
Currently, the i2c adapter is available only under DP connectors.
Add i2c symlink under hdmi connector pointing to i2c adapter in order to
make this behaviour consistent.
The initial motivation was to make igt i2c subtest
patch [1] work on all connectors.
[1]: https://patchwork.freedesktop.org/series/60357/
v2:
- Moved symlink remove to unregister (Ville)
- Clarified commit message (Jani)
- Changed WARN to DRM_ERROR (Jani)
- Minor codestyle changes proposed by Jani
Cc: Arkadiusz Hiler
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Jani Nikula
Signed-off-by: Oleg Vasilev
---
drivers/gpu/drm/i915/intel_hdmi.c | 40 ++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 2a4086cf2692..fd383de531b4 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -2658,6 +2658,35 @@ static void chv_hdmi_pre_enable(struct intel_encoder
*encoder,
chv_phy_release_cl2_override(encoder);
}
+static struct i2c_adapter *
+intel_hdmi_get_i2c_adapter(struct drm_connector *connector)
+{
+ struct drm_i915_private *dev_priv = to_i915(connector->dev);
+ struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
+ return intel_gmbus_get_adapter(dev_priv, intel_hdmi->ddc_bus);
+}
+
+static void intel_hdmi_create_i2c_symlink(struct drm_connector *connector)
+{
+ struct i2c_adapter *adapter = intel_hdmi_get_i2c_adapter(connector);
+ struct kobject *i2c_kobj = >dev.kobj;
+ struct kobject *connector_kobj = >kdev->kobj;
+ int ret;
+
+ ret = sysfs_create_link(connector_kobj, i2c_kobj, i2c_kobj->name);
+ if (ret)
+ DRM_ERROR("Failed to create i2c symlink (%d)\n", ret);
+}
+
+static void intel_hdmi_remove_i2c_symlink(struct drm_connector *connector)
+{
+ struct i2c_adapter *adapter = intel_hdmi_get_i2c_adapter(connector);
+ struct kobject *i2c_kobj = >dev.kobj;
+ struct kobject *connector_kobj = >kdev->kobj;
+
+ sysfs_remove_link(connector_kobj, i2c_kobj->name);
+}
+
static int
intel_hdmi_connector_register(struct drm_connector *connector)
{
@@ -2669,6 +2698,8 @@ intel_hdmi_connector_register(struct drm_connector
*connector)
i915_debugfs_connector_add(connector);
+ intel_hdmi_create_i2c_symlink(connector);
+
return ret;
}
@@ -2680,6 +2711,13 @@ static void intel_hdmi_destroy(struct drm_connector
*connector)
intel_connector_destroy(connector);
}
+static void intel_hdmi_connector_unregister(struct drm_connector *connector)
+{
+ intel_hdmi_remove_i2c_symlink(connector);
+
+ intel_connector_unregister(connector);
+}
+
static const struct drm_connector_funcs intel_hdmi_connector_funcs = {
.detect = intel_hdmi_detect,
.force = intel_hdmi_force,
@@ -2687,7 +2725,7 @@ static const struct drm_connector_funcs
intel_hdmi_connector_funcs = {
.atomic_get_property = intel_digital_connector_atomic_get_property,
.atomic_set_property = intel_digital_connector_atomic_set_property,
.late_register = intel_hdmi_connector_register,
- .early_unregister = intel_connector_unregister,
+ .early_unregister = intel_hdmi_connector_unregister,
.destroy = intel_hdmi_destroy,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
.atomic_duplicate_state = intel_digital_connector_duplicate_state,
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/2] drm/i915/icl: Add WaDisableBankHangMode
From: Tvrtko Ursulin
Disable GPU hang by default on unrecoverable ECC cache errors.
v2:
* Rebase.
Fixes: cc38cae7c4e9 ("drm/i915/icl: Introduce initial Icelake Workarounds")
Signed-off-by: Tvrtko Ursulin
Acked-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 ++
drivers/gpu/drm/i915/i915_reg.h | 3 +++
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 468928cd8fb3..1a730424eba7 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -528,6 +528,12 @@ static void icl_ctx_workarounds_init(struct
intel_engine_cs *engine,
struct i915_wa_list *wal)
{
struct drm_i915_private *i915 = engine->i915;
+ struct drm_i915_private *dev_priv = i915;
+
+ /* WaDisableBankHangMode:icl */
+ wa_write(wal,
+GEN8_L3CNTLREG,
+I915_READ(GEN8_L3CNTLREG) | GEN8_ERRDETBCTRL);
/* Wa_1604370585:icl (pre-prod)
* Formerly known as WaPushConstantDereferenceHoldDisable
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e97c47fca645..87e8780711d7 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7621,6 +7621,9 @@ enum {
#define GEN8_SBE_DISABLE_REPLAY_BUF_OPTIMIZATION (1 << 8)
#define GEN8_CSC2_SBE_VUE_CACHE_CONSERVATIVE (1 << 0)
+#define GEN8_L3CNTLREG _MMIO(0x7034)
+ #define GEN8_ERRDETBCTRL (1 << 9)
+
#define GEN11_COMMON_SLICE_CHICKEN3_MMIO(0x7304)
#define GEN11_BLEND_EMB_FIX_DISABLE_IN_RCC (1 << 11)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/2] drm/i915/selftests: Verify context workarounds
From: Tvrtko Ursulin
Test context workarounds have been correctly applied in newly created
contexts.
To accomplish this the existing engine_wa_list_verify helper is extended
to take in a context from which reading of the workaround list will be
done.
Context workaround verification is done from the existing subtests, which
have been renamed to reflect they are no longer only about GT and engine
workarounds.
v2:
* Test after resets and refactor to use intel_context more. (Chris)
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 111 ++
.../gpu/drm/i915/gt/selftest_workarounds.c| 54 ++---
2 files changed, 96 insertions(+), 69 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 43e290306551..468928cd8fb3 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -196,10 +196,9 @@ ignore_wa_write_or(struct i915_wa_list *wal, i915_reg_t
reg, u32 mask, u32 val)
#define WA_SET_FIELD_MASKED(addr, mask, value) \
wa_write_masked_or(wal, (addr), (mask), _MASKED_FIELD((mask), (value)))
-static void gen8_ctx_workarounds_init(struct intel_engine_cs *engine)
+static void gen8_ctx_workarounds_init(struct intel_engine_cs *engine,
+ struct i915_wa_list *wal)
{
- struct i915_wa_list *wal = >ctx_wa_list;
-
WA_SET_BIT_MASKED(INSTPM, INSTPM_FORCE_ORDERING);
/* WaDisableAsyncFlipPerfMode:bdw,chv */
@@ -245,12 +244,12 @@ static void gen8_ctx_workarounds_init(struct
intel_engine_cs *engine)
GEN6_WIZ_HASHING_16x4);
}
-static void bdw_ctx_workarounds_init(struct intel_engine_cs *engine)
+static void bdw_ctx_workarounds_init(struct intel_engine_cs *engine,
+struct i915_wa_list *wal)
{
struct drm_i915_private *i915 = engine->i915;
- struct i915_wa_list *wal = >ctx_wa_list;
- gen8_ctx_workarounds_init(engine);
+ gen8_ctx_workarounds_init(engine, wal);
/* WaDisableThreadStallDopClockGating:bdw (pre-production) */
WA_SET_BIT_MASKED(GEN8_ROW_CHICKEN, STALL_DOP_GATING_DISABLE);
@@ -273,11 +272,10 @@ static void bdw_ctx_workarounds_init(struct
intel_engine_cs *engine)
(IS_BDW_GT3(i915) ? HDC_FENCE_DEST_SLM_DISABLE : 0));
}
-static void chv_ctx_workarounds_init(struct intel_engine_cs *engine)
+static void chv_ctx_workarounds_init(struct intel_engine_cs *engine,
+struct i915_wa_list *wal)
{
- struct i915_wa_list *wal = >ctx_wa_list;
-
- gen8_ctx_workarounds_init(engine);
+ gen8_ctx_workarounds_init(engine, wal);
/* WaDisableThreadStallDopClockGating:chv */
WA_SET_BIT_MASKED(GEN8_ROW_CHICKEN, STALL_DOP_GATING_DISABLE);
@@ -286,10 +284,10 @@ static void chv_ctx_workarounds_init(struct
intel_engine_cs *engine)
WA_SET_BIT_MASKED(HIZ_CHICKEN, CHV_HZ_8X8_MODE_IN_1X);
}
-static void gen9_ctx_workarounds_init(struct intel_engine_cs *engine)
+static void gen9_ctx_workarounds_init(struct intel_engine_cs *engine,
+ struct i915_wa_list *wal)
{
struct drm_i915_private *i915 = engine->i915;
- struct i915_wa_list *wal = >ctx_wa_list;
if (HAS_LLC(i915)) {
/* WaCompressedResourceSamplerPbeMediaNewHashMode:skl,kbl
@@ -384,10 +382,10 @@ static void gen9_ctx_workarounds_init(struct
intel_engine_cs *engine)
WA_SET_BIT_MASKED(GEN9_WM_CHICKEN3, GEN9_FACTOR_IN_CLR_VAL_HIZ);
}
-static void skl_tune_iz_hashing(struct intel_engine_cs *engine)
+static void skl_tune_iz_hashing(struct intel_engine_cs *engine,
+ struct i915_wa_list *wal)
{
struct drm_i915_private *i915 = engine->i915;
- struct i915_wa_list *wal = >ctx_wa_list;
u8 vals[3] = { 0, 0, 0 };
unsigned int i;
@@ -424,17 +422,17 @@ static void skl_tune_iz_hashing(struct intel_engine_cs
*engine)
GEN9_IZ_HASHING(0, vals[0]));
}
-static void skl_ctx_workarounds_init(struct intel_engine_cs *engine)
+static void skl_ctx_workarounds_init(struct intel_engine_cs *engine,
+struct i915_wa_list *wal)
{
- gen9_ctx_workarounds_init(engine);
- skl_tune_iz_hashing(engine);
+ gen9_ctx_workarounds_init(engine, wal);
+ skl_tune_iz_hashing(engine, wal);
}
-static void bxt_ctx_workarounds_init(struct intel_engine_cs *engine)
+static void bxt_ctx_workarounds_init(struct intel_engine_cs *engine,
+struct i915_wa_list *wal)
{
- struct i915_wa_list *wal = >ctx_wa_list;
-
- gen9_ctx_workarounds_init(engine);
+ gen9_ctx_workarounds_init(engine, wal);
/* WaDisableThreadStallDopClockGating:bxt */
WA_SET_BIT_MASKED(GEN8_ROW_CHICKEN,
@@
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dp: Support for DP YCbCr4:2:0 outputs (rev3)
== Series Details == Series: drm/i915/dp: Support for DP YCbCr4:2:0 outputs (rev3) URL : https://patchwork.freedesktop.org/series/60404/ State : success == Summary == CI Bug Log - changes from CI_DRM_6097 -> Patchwork_13043 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13043/ Known issues Here are the changes found in Patchwork_13043 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live_evict: - fi-bsw-kefka: [PASS][1] -> [DMESG-WARN][2] ([fdo#107709]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6097/fi-bsw-kefka/igt@i915_selftest@live_evict.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13043/fi-bsw-kefka/igt@i915_selftest@live_evict.html Possible fixes * igt@amdgpu/amd_basic@userptr: - fi-kbl-8809g: [DMESG-WARN][3] ([fdo#108965]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6097/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13043/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html * igt@i915_selftest@live_hangcheck: - fi-skl-iommu: [INCOMPLETE][5] ([fdo#108602] / [fdo#108744]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6097/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13043/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html [fdo#107709]: https://bugs.freedesktop.org/show_bug.cgi?id=107709 [fdo#108602]: https://bugs.freedesktop.org/show_bug.cgi?id=108602 [fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744 [fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965 Participating hosts (52 -> 43) -- Missing(9): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-gdg-551 fi-icl-u3 fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_6097 -> Patchwork_13043 CI_DRM_6097: 3f2d6a47d9eec66594887b1e9718bc1a29aa6a77 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4996: 6fe5d254ec1b9b47d61408e1b49a7339876bf1e7 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_13043: ca72ed97fa79b9f574de1648f4af67fdeeae527e @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == ca72ed97fa79 drm/i915/dp: Support DP ports YUV 4:2:0 output to GEN11 449160fa821a drm/i915/dp: Change a link bandwidth computation for DP 9ff908a8307c drm/i915/dp: Add a support of YCBCR 4:2:0 to DP MSA 8bf66293c89e drm/i915/dp: Program VSC Header and DB for Pixel Encoding/Colorimetry Format 625bd28077ee drm: Rename struct edp_vsc_psr to struct dp_sdp 97a47b0e52bf drm/i915/dp: Add a config function for YCBCR420 outputs == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13043/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: We don't need display's suspend/resume operations when !HAS_DISPLAY
== Series Details == Series: drm/i915: We don't need display's suspend/resume operations when !HAS_DISPLAY URL : https://patchwork.freedesktop.org/series/60839/ State : success == Summary == CI Bug Log - changes from CI_DRM_6097_full -> Patchwork_13040_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_13040_full that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_rpm@debugfs-forcewake-user: - shard-skl: [PASS][1] -> [INCOMPLETE][2] ([fdo#107807]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6097/shard-skl2/igt@i915_pm_...@debugfs-forcewake-user.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13040/shard-skl5/igt@i915_pm_...@debugfs-forcewake-user.html * igt@kms_flip@flip-vs-suspend-interruptible: - shard-skl: [PASS][3] -> [INCOMPLETE][4] ([fdo#109507]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6097/shard-skl8/igt@kms_f...@flip-vs-suspend-interruptible.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13040/shard-skl10/igt@kms_f...@flip-vs-suspend-interruptible.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-mmap-gtt: - shard-iclb: [PASS][5] -> [FAIL][6] ([fdo#103167]) +5 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6097/shard-iclb8/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-mmap-gtt.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13040/shard-iclb7/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-mmap-gtt.html * igt@kms_lease@setcrtc_implicit_plane: - shard-snb: [PASS][7] -> [SKIP][8] ([fdo#109271]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6097/shard-snb5/igt@kms_lease@setcrtc_implicit_plane.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13040/shard-snb4/igt@kms_lease@setcrtc_implicit_plane.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes: - shard-apl: [PASS][9] -> [DMESG-WARN][10] ([fdo#108566]) +3 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6097/shard-apl6/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13040/shard-apl4/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html * igt@kms_plane_lowres@pipe-a-tiling-x: - shard-iclb: [PASS][11] -> [FAIL][12] ([fdo#103166]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6097/shard-iclb6/igt@kms_plane_low...@pipe-a-tiling-x.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13040/shard-iclb6/igt@kms_plane_low...@pipe-a-tiling-x.html * igt@kms_psr@psr2_dpms: - shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#109441]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6097/shard-iclb2/igt@kms_psr@psr2_dpms.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13040/shard-iclb4/igt@kms_psr@psr2_dpms.html * igt@perf_pmu@rc6: - shard-kbl: [PASS][15] -> [SKIP][16] ([fdo#109271]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6097/shard-kbl1/igt@perf_...@rc6.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13040/shard-kbl7/igt@perf_...@rc6.html Possible fixes * igt@gem_tiled_swapping@non-threaded: - shard-glk: [DMESG-WARN][17] ([fdo#108686]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6097/shard-glk7/igt@gem_tiled_swapp...@non-threaded.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13040/shard-glk6/igt@gem_tiled_swapp...@non-threaded.html * igt@i915_pm_rpm@debugfs-read: - shard-skl: [INCOMPLETE][19] ([fdo#107807]) -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6097/shard-skl3/igt@i915_pm_...@debugfs-read.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13040/shard-skl4/igt@i915_pm_...@debugfs-read.html * igt@i915_pm_rpm@gem-execbuf: - shard-skl: [INCOMPLETE][21] ([fdo#107803] / [fdo#107807]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6097/shard-skl4/igt@i915_pm_...@gem-execbuf.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13040/shard-skl5/igt@i915_pm_...@gem-execbuf.html * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic: - shard-hsw: [FAIL][23] ([fdo#105767]) -> [PASS][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6097/shard-hsw1/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13040/shard-hsw4/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html * igt@kms_flip@2x-flip-vs-expired-vblank: - shard-glk: [FAIL][25] ([fdo#102887]) ->
Re: [Intel-gfx] [PATCH v2] drm/i915/huc: Don't try to check HuC status if it's not loaded
Quoting Michal Wajdeczko (2019-05-19 22:50:43)
> If we never attempted to load HuC firmware, or we already wedged
> or reset GuC/HuC, then there is no reason to wake up the device
> to check one bit in the register that will be for sure cleared.
>
> v2: check if HuC was enabled; subtle change in ABI
> reuse hus_is_load helper
>
> Suggested-by: Chris Wilson
> Signed-off-by: Michal Wajdeczko
> Cc: Chris Wilson
> Cc: Tony Ye
> ---
> drivers/gpu/drm/i915/intel_huc.c | 20
> drivers/gpu/drm/i915/intel_huc.h | 5 +
> 2 files changed, 17 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_huc.c
> b/drivers/gpu/drm/i915/intel_huc.c
> index 1ff1fb015e58..bfdebec1cfc8 100644
> --- a/drivers/gpu/drm/i915/intel_huc.c
> +++ b/drivers/gpu/drm/i915/intel_huc.c
> @@ -113,7 +113,7 @@ int intel_huc_auth(struct intel_huc *huc)
> u32 status;
> int ret;
>
> - if (huc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
> + if (!intel_huc_is_loaded(huc))
> return -ENOEXEC;
>
> ret = intel_guc_auth_huc(guc,
> @@ -150,21 +150,25 @@ int intel_huc_auth(struct intel_huc *huc)
> * This function reads status register to verify if HuC
> * firmware was successfully loaded.
> *
> - * Returns: 1 if HuC firmware is loaded and verified,
> - * 0 if HuC firmware is not loaded and -ENODEV if HuC
> - * is not present on this platform.
> + * Returns: 1 if HuC firmware is loaded and verified, 0 if HuC firmware is
> not
> + * enabled, -ENOPKG if HuC firmware is not loaded and -ENODEV if HuC is not
> + * present on this platform.
> */
> int intel_huc_check_status(struct intel_huc *huc)
> {
> struct drm_i915_private *dev_priv = huc_to_i915(huc);
> intel_wakeref_t wakeref;
> - bool status = false;
> + bool verified = false;
>
> if (!HAS_HUC(dev_priv))
> return -ENODEV;
>
> - with_intel_runtime_pm(dev_priv, wakeref)
> - status = I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED;
> + if (!USES_HUC(dev_priv))
> + return 0;
Hmm, EOPNOTSUPP here for the user disabled case?
Then
if (!intel_huc_is_loaded(huc))
return -ENOPKG;
bool verified = false;
with_intel_runtime_pm(dev_priv, wakeref)
verified = I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED;
return verified.
That keeps it a bit flatter with the special casing separate and the 0/1
result as given by the register status. Then if negative, we know one of
the preconditions for using HuC is not available, and if 0 something went
wrong in mmio setup.
Does that make sense?
> - return status;
> + if (intel_huc_is_loaded(huc))
> + with_intel_runtime_pm(dev_priv, wakeref)
> + verified = I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED;
> +
> + return verified ? 1 : -ENOPKG;
> }
> diff --git a/drivers/gpu/drm/i915/intel_huc.h
> b/drivers/gpu/drm/i915/intel_huc.h
> index a0c21ae02a99..cde3d303718d 100644
> --- a/drivers/gpu/drm/i915/intel_huc.h
> +++ b/drivers/gpu/drm/i915/intel_huc.h
> @@ -44,6 +44,11 @@ void intel_huc_fini(struct intel_huc *huc);
> int intel_huc_auth(struct intel_huc *huc);
> int intel_huc_check_status(struct intel_huc *huc);
>
> +static inline bool intel_huc_is_loaded(struct intel_huc *huc)
> +{
> + return intel_uc_fw_is_loaded(>fw);
> +}
> +
> static inline void intel_huc_fini_misc(struct intel_huc *huc)
> {
> intel_uc_fw_cleanup_fetch(>fw);
> --
> 2.19.2
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
