dri-devel September 2019

dri-devel@lists.freedesktop.org

315 participants
2278 discussions

[PATCH v2] drm: Bump encoder limit from 32 to 64
by Lyude Paul 09 Sep '19

09 Sep '19

Assuming that GPUs would never have even close to 32 separate video encoders is quite honestly a pretty reasonable assumption. Unfortunately we do not live in a reasonable world, as it looks like it is actually possible to find devices that will create more drm_encoder objects then this. Case in point: the ThinkPad P71's discrete GPU, which exposes 1 eDP port and 5 DP ports. On the P71, nouveau attempts to create one encoder for the eDP port, and two encoders for each DP++/USB-C port along with 4 MST encoders for each DP port. This comes out to 35 different encoders. Unfortunately, this can't really be optimized to make less encoders either. So, what if we bumped the limit to 64? Unfortunately this has one very awkward drawback: we already expose 32-bit bitmasks for encoders to userspace in drm_encoder->possible_clones. Yikes. While cloning is still (rarely) used in certain modern video hardware, it's mostly used in situations where memory bandwidth is so limited that it's not possible to scan out from 2 CRTCs at once. So, let's try to compromise here: allow encoders with indexes <32 to have non-zero values in drm_encoder->possible_clones, and don't allow encoders with higher indexes to set drm_encoder->possible_clones to a non-zero value. This allows us to avoid breaking UAPI and keep things working sanely for hardware which still uses cloning, while still being able to bump up the encoder limit. This also fixes driver probing for nouveau on the ThinkPad P71. Changes since v1: * Move index+possible_clones check out of drm_encoder_init() and into drm_encoder_register_all(), since encoder->possible_clones can get changed any time before registration - Daniel Vetter * Update the commit message a bit to accurately reflect modern day usage of hardware cloning, which as Daniel Stone pointed out is apparently a thing Signed-off-by: Lyude Paul <lyude(a)redhat.com> Cc: nouveau(a)lists.freedesktop.org --- drivers/gpu/drm/drm_atomic.c | 2 +- drivers/gpu/drm/drm_encoder.c | 12 ++++++++++-- include/drm/drm_crtc.h | 2 +- include/drm/drm_encoder.h | 20 +++++++++++++++----- 4 files changed, 27 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 419381abbdd1..27ce988ef0cc 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -392,7 +392,7 @@ static void drm_atomic_crtc_print_state(struct drm_printer *p, drm_printf(p, "\tcolor_mgmt_changed=%d\n", state->color_mgmt_changed); drm_printf(p, "\tplane_mask=%x\n", state->plane_mask); drm_printf(p, "\tconnector_mask=%x\n", state->connector_mask); - drm_printf(p, "\tencoder_mask=%x\n", state->encoder_mask); + drm_printf(p, "\tencoder_mask=%llx\n", state->encoder_mask); drm_printf(p, "\tmode: " DRM_MODE_FMT "\n", DRM_MODE_ARG(&state->mode)); if (crtc->funcs->atomic_print_state) diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c index 7fb47b7b8b44..9d443b45ebba 100644 --- a/drivers/gpu/drm/drm_encoder.c +++ b/drivers/gpu/drm/drm_encoder.c @@ -71,6 +71,14 @@ int drm_encoder_register_all(struct drm_device *dev) int ret = 0; drm_for_each_encoder(encoder, dev) { + /* + * Since possible_clones has been exposed to userspace as a + * 32bit bitmask, we don't allow creating encoders with an + * index >=32 which are capable of cloning + */ + if (WARN_ON(encoder->index >= 32 && encoder->possible_clones)) + return -EINVAL; + if (encoder->funcs->late_register) ret = encoder->funcs->late_register(encoder); if (ret) @@ -112,8 +120,8 @@ int drm_encoder_init(struct drm_device *dev, { int ret; - /* encoder index is used with 32bit bitmasks */ - if (WARN_ON(dev->mode_config.num_encoder >= 32)) + /* encoder index is used with 64bit bitmasks */ + if (WARN_ON(dev->mode_config.num_encoder >= 64)) return -EINVAL; ret = drm_mode_object_add(dev, &encoder->base, DRM_MODE_OBJECT_ENCODER); diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index 7d14c11bdc0a..fd0b2438c3d5 100644 --- a/include/drm/drm_crtc.h +++ b/include/drm/drm_crtc.h @@ -210,7 +210,7 @@ struct drm_crtc_state { * @encoder_mask: Bitmask of drm_encoder_mask(encoder) of encoders * attached to this CRTC. */ - u32 encoder_mask; + u64 encoder_mask; /** * @adjusted_mode: diff --git a/include/drm/drm_encoder.h b/include/drm/drm_encoder.h index 70cfca03d812..3f9cb65694e1 100644 --- a/include/drm/drm_encoder.h +++ b/include/drm/drm_encoder.h @@ -159,7 +159,15 @@ struct drm_encoder { * encoders can be used in a cloned configuration, they both should have * each another bits set. * - * In reality almost every driver gets this wrong. + * In reality almost every driver gets this wrong, and most modern + * display hardware does not have support for cloning. As well, while we + * expose this mask to userspace as 32bits long, we do sure purely to + * avoid breaking pre-existing UAPI since the limitation on the number + * of encoders has been increased from 32 bits to 64 bits. In order to + * maintain functionality for drivers which do actually support cloning, + * we only allow cloning with encoders that have an index <32. Encoders + * with indexes higher than 32 are not allowed to specify a non-zero + * value here. * * Note that since encoder objects can't be hotplugged the assigned indices * are stable and hence known before registering all objects. @@ -198,13 +206,15 @@ static inline unsigned int drm_encoder_index(const struct drm_encoder *encoder) } /** - * drm_encoder_mask - find the mask of a registered ENCODER + * drm_encoder_mask - find the mask of a registered encoder * @encoder: encoder to find mask for * - * Given a registered encoder, return the mask bit of that encoder for an - * encoder's possible_clones field. + * Returns: + * A bit mask with the nth bit set, where n is the index of the encoder. Take + * care when using this, as the DRM UAPI only allows for 32 bit encoder masks + * while internally encoder masks are 64 bits. */ -static inline u32 drm_encoder_mask(const struct drm_encoder *encoder) +static inline u64 drm_encoder_mask(const struct drm_encoder *encoder) { return 1 << drm_encoder_index(encoder); } -- 2.21.0

2 2

[Bug 110659] pageflipping seems to cause jittering on mouse input when running Hitman 2 in Wine/DXVK with amdgpu.dc=1
by bugzilla-daemon＠freedesktop.org 09 Sep '19

09 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=110659 tempel.julian(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |NOTOURBUG Status|NEW |RESOLVED --- Comment #80 from tempel.julian(a)gmail.com --- Oh my. I've tried the oldest Proton build offered by Steam, which is based on Wine 3.7, and indeed it doesn't show the issue (neither in Oblivion with wined3d OGL nor Hitman 2 DXVK Vulkan). I tried with the older Proton 3.16 version before, which unfortunately is the one that started showing the issue. I don't know why I didn't try 3.7 in the first place. I'm sorry for the time you have invested into this issue. :( Though it would appear to me that the old non-atomic DC is very resilient toward such issues. To be sure, I also tested with untouched Arch 5.2.13 kernel: Without that Wine commit, it is totally free of that stutter issue as well. Pierre-Eric, I reverted that commit c6b6935bb433dbbd30f5ba122a7c45ad3a2d6eed, and indeed, it introduced this issue. Should I create a Wine bug ticket for this? Closing now. Big thanks @ Michel and Nicholas for their great support. AMD's kernel and Linux windowing support is simply outstanding, a dam good reason to stay with team (former) red. :) -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 110659] pageflipping seems to cause jittering on mouse input when running Hitman 2 in Wine/DXVK with amdgpu.dc=1
by bugzilla-daemon＠freedesktop.org 09 Sep '19

09 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=110659 --- Comment #79 from Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer(a)amd.com> --- (In reply to Michel Dänzer from comment #76) > (In reply to tempel.julian from comment #75) > > Is it possible that Wine or the affected programs in Wine are the clients > > that are at fault for this? > > Certainly. It looks like the intention is to prevent the monitors from > entering power saving mode. Maybe the code from this wine patch https://www.winehq.org/pipermail/wine-devel/2018-July/129014.html ("winex11.drv: Wake up the display on user input") is causing this? (adding a breakpoint in wine for the XResetScreenSaver function should confirm) -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 110659] pageflipping seems to cause jittering on mouse input when running Hitman 2 in Wine/DXVK with amdgpu.dc=1
by bugzilla-daemon＠freedesktop.org 09 Sep '19

09 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=110659 --- Comment #78 from Michel Dänzer <michel(a)daenzer.net> --- (In reply to tempel.julian from comment #77) > I turned DPMS off in Xorg config which leaves the issue unchanged. Is this > to be expected? Yeah, this isn't directly related to X's DPMS functionality. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[PATCH AUTOSEL 4.19 001/167] drm/i915: Re-apply "Perform link quality check, unconditionally during long pulse"
by Sasha Levin 09 Sep '19

09 Sep '19

From: Jan-Marek Glogowski <glogow(a)fbihome.de> [ Upstream commit 3cf71bc9904d7ee4a25a822c5dcb54c7804ea388 ] This re-applies the workaround for "some DP sinks, [which] are a little nuts" from commit 1a36147bb939 ("drm/i915: Perform link quality check unconditionally during long pulse"). It makes the secondary AOC E2460P monitor connected via DP to an acer Veriton N4640G usable again. This hunk was dropped in commit c85d200e8321 ("drm/i915: Move SST DP link retraining into the ->post_hotplug() hook") Fixes: c85d200e8321 ("drm/i915: Move SST DP link retraining into the ->post_hotplug() hook") [Cleaned up commit message, added stable cc] Signed-off-by: Lyude Paul <lyude(a)redhat.com> Signed-off-by: Jan-Marek Glogowski <glogow(a)fbihome.de> Cc: stable(a)vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20180825191035.3945-1-lyude@r… Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/i915/intel_dp.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index f92079e19de8d..20cd4c8acecc3 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -4739,6 +4739,22 @@ intel_dp_long_pulse(struct intel_connector *connector, */ status = connector_status_disconnected; goto out; + } else { + /* + * If display is now connected check links status, + * there has been known issues of link loss triggering + * long pulse. + * + * Some sinks (eg. ASUS PB287Q) seem to perform some + * weird HPD ping pong during modesets. So we can apparently + * end up with HPD going low during a modeset, and then + * going back up soon after. And once that happens we must + * retrain the link to get a picture. That's in case no + * userspace component reacted to intermittent HPD dip. + */ + struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base; + + intel_dp_retrain_link(encoder, ctx); } /* -- 2.20.1

8 40

[Bug 110659] pageflipping seems to cause jittering on mouse input when running Hitman 2 in Wine/DXVK with amdgpu.dc=1
by bugzilla-daemon＠freedesktop.org 09 Sep '19

09 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=110659 --- Comment #77 from tempel.julian(a)gmail.com --- (In reply to Michel Dänzer from comment #76) > Certainly. It looks like the intention is to prevent the monitors from > entering power saving mode. I turned DPMS off in Xorg config which leaves the issue unchanged. Is this to be expected? I'll open a ticket for the issue on the Wine tracker, but I'd still be happy to try out any patch for Xorg or kernel. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 110659] pageflipping seems to cause jittering on mouse input when running Hitman 2 in Wine/DXVK with amdgpu.dc=1
by bugzilla-daemon＠freedesktop.org 09 Sep '19

09 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=110659 --- Comment #76 from Michel Dänzer <michel(a)daenzer.net> --- (In reply to tempel.julian from comment #75) > Is it possible that Wine or the affected programs in Wine are the clients > that are at fault for this? Certainly. It looks like the intention is to prevent the monitors from entering power saving mode. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[PATCH] gpu/drm: fix a -Wstringop-truncation warning
by Qian Cai 09 Sep '19

09 Sep '19

In file included from ./include/linux/bitmap.h:9, from ./include/linux/cpumask.h:12, from ./arch/x86/include/asm/cpumask.h:5, from ./arch/x86/include/asm/msr.h:11, from ./arch/x86/include/asm/processor.h:21, from ./arch/x86/include/asm/cpufeature.h:5, from ./arch/x86/include/asm/thread_info.h:53, from ./include/linux/thread_info.h:38, from ./arch/x86/include/asm/preempt.h:7, from ./include/linux/preempt.h:78, from ./include/linux/rcupdate.h:27, from ./include/linux/rculist.h:11, from ./include/linux/pid.h:5, from ./include/linux/sched.h:14, from ./include/linux/uaccess.h:5, from drivers/gpu/drm/drm_property.c:24: In function 'strncpy', inlined from 'drm_property_create' at drivers/gpu/drm/drm_property.c:130:2: ./include/linux/string.h:305:9: warning: '__builtin_strncpy' specified bound 32 equals destination size [-Wstringop-truncation] return __builtin_strncpy(p, q, size); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Fix it by using strscpy() which will always return a valid string, and doesn't unnecessarily force the tail of the destination buffer to be zeroed. Signed-off-by: Qian Cai <cai(a)lca.pw> --- drivers/gpu/drm/drm_property.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c index 892ce636ef72..66ec2cc7a559 100644 --- a/drivers/gpu/drm/drm_property.c +++ b/drivers/gpu/drm/drm_property.c @@ -127,8 +127,7 @@ struct drm_property *drm_property_create(struct drm_device *dev, property->num_values = num_values; INIT_LIST_HEAD(&property->enum_list); - strncpy(property->name, name, DRM_PROP_NAME_LEN); - property->name[DRM_PROP_NAME_LEN-1] = '\0'; + strscpy(property->name, name, DRM_PROP_NAME_LEN); list_add_tail(&property->head, &dev->mode_config.property_list); -- 1.8.3.1

1 2

[Bug 109303] [CI][SHARDS] igt@i915_query@query-topology-known-pci-ids - skip - Test requirement: IS_HASWELL(devid) || IS_BROADWELL(devid) || IS_SKYLAKE(devid) || IS_KABYLAKE(devid) || IS_COFFEELAKE(devid), SKIP
by bugzilla-daemon＠freedesktop.org 09 Sep '19

09 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=109303 Bug ID: 109303 Summary: [CI][SHARDS] igt@i915_query@query-topology-known-pci-ids - skip - Test requirement: IS_HASWELL(devid) || IS_BROADWELL(devid) || IS_SKYLAKE(devid) || IS_KABYLAKE(devid) || IS_COFFEELAKE(devid), SKIP Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: IGT Assignee: dri-devel(a)lists.freedesktop.org Reporter: martin.peres(a)free.fr https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shard-iclb2/igt@i915_q… Test requirement: IS_HASWELL(devid) || IS_BROADWELL(devid) || IS_SKYLAKE(devid) || IS_KABYLAKE(devid) || IS_COFFEELAKE(devid) Subtest query-topology-known-pci-ids: SKIP (0.000s) I doubt that this would only be supported on these platforms and not on CNL and ICL. -- You are receiving this mail because: You are the assignee for the bug.

1 6

Re: Xorg indefinitely hangs in kernelspace
by Hillf Danton 09 Sep '19

09 Sep '19

On Mon, 9 Sep 2019 from Gerd Hoffmann <kraxel(a)redhat.com> > > Hmm, I think the patch is wrong. Hmm...it should have added change only in the error path, leaving locks for drivers to release if job is done with no error returned. > As far I know it is the qxl drivers's > job to call ttm_eu_backoff_reservation(). Like other drivers, qxl is currently doing the right. > Doing that automatically in > ttm will most likely break other ttm users. > You are right. They are responsible for doing backoff if error happens while validating buffers afterwards. --- a/drivers/gpu/drm/ttm/ttm_execbuf_util.c +++ b/drivers/gpu/drm/ttm/ttm_execbuf_util.c @@ -111,8 +111,10 @@ int ttm_eu_reserve_buffers(struct ww_acq list_for_each_entry(entry, list, head) { struct ttm_buffer_object *bo = entry->bo; + bool lockon; ret = __ttm_bo_reserve(bo, intr, (ticket == NULL), ticket); + lockon = !ret; if (!ret && unlikely(atomic_read(&bo->cpu_writers) > 0)) { reservation_object_unlock(bo->resv); @@ -151,6 +153,7 @@ int ttm_eu_reserve_buffers(struct ww_acq ret = 0; } } + lockon = !ret; if (!ret && entry->num_shared) ret = reservation_object_reserve_shared(bo->resv, @@ -163,6 +166,8 @@ int ttm_eu_reserve_buffers(struct ww_acq ww_acquire_done(ticket); ww_acquire_fini(ticket); } + if (lockon) + ttm_eu_backoff_reservation_reverse(list, entry); return ret; } --

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2019