v, dcb))
/* No callback queued, wake up any other
waiters */
dma_buf_poll_cb(NULL, &dcb->cb);
else
events &= ~EPOLLIN;
}
Other than that, looks good to me, can't say anything about the locking though.
Haven't been able to test this yet, hopefully later this week.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
From: Michel Dänzer
This makes sure we don't hit the
BUG_ON(dmabuf->cb_in.active || dmabuf->cb_out.active);
in dma_buf_release, which could be triggered by user space closing the
dma-buf file description while there are outstanding fence callbacks
from dma_buf_pol
s suggested by Michel, drop unused variables
>
> Signed-off-by: Christian König
> CC: sta...@vger.kernel.org
Working fine with https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880
Tested-by: Michel Dänzer
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
On 2021-07-23 10:04 a.m., Christian König wrote:
> Am 23.07.21 um 09:58 schrieb Michel Dänzer:
>> From: Michel Dänzer
>>
>> This makes sure we don't hit the
>>
>> BUG_ON(dmabuf->cb_in.active || dmabuf->cb_out.active);
>>
>> in dma_buf
On 2021-07-23 11:02 a.m., Daniel Vetter wrote:
> On Fri, Jul 23, 2021 at 10:19:49AM +0200, Michel Dänzer wrote:
>> On 2021-07-23 10:04 a.m., Christian König wrote:
>>> Am 23.07.21 um 09:58 schrieb Michel Dänzer:
>>>> From: Michel Dänzer
>>>
(new_plane_state->fence, vbltime);
> + }
vblank timestamps correspond to the end of vertical blank, the deadline should
be the start of vertical blank though.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
for a proof of concept of this for mutter. The boost will only affect the
compositor's own GPU work, not the client work (which means no effect at all
for fullscreen apps where the compositor can scan out the client buffers
directly).
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
On 2021-07-27 5:12 p.m., Rob Clark wrote:
> On Tue, Jul 27, 2021 at 7:50 AM Michel Dänzer wrote:
>>
>> On 2021-07-27 1:38 a.m., Rob Clark wrote:
>>> From: Rob Clark
>>>
>>> Based on discussion from a previous series[1] to add a "boost" mechanis
On 2021-07-28 1:36 p.m., Christian König wrote:
> Am 27.07.21 um 17:37 schrieb Rob Clark:
>> On Tue, Jul 27, 2021 at 8:19 AM Michel Dänzer wrote:
>>> On 2021-07-27 5:12 p.m., Rob Clark wrote:
>>>> On Tue, Jul 27, 2021 at 7:50 AM Michel Dänzer wrote:
>>>>
On 2021-07-28 3:13 p.m., Christian König wrote:
> Am 28.07.21 um 15:08 schrieb Michel Dänzer:
>> On 2021-07-28 1:36 p.m., Christian König wrote:
>>> Am 27.07.21 um 17:37 schrieb Rob Clark:
>>>> On Tue, Jul 27, 2021 at 8:19 AM Michel Dänzer wrote:
>>>>
On 2021-07-28 4:30 p.m., Christian König wrote:
> Am 28.07.21 um 15:57 schrieb Pekka Paalanen:
>> On Wed, 28 Jul 2021 15:31:41 +0200
>> Christian König wrote:
>>
>>> Am 28.07.21 um 15:24 schrieb Michel Dänzer:
>>>> On 2021-07-28 3:13 p.m., Christian König
On 2021-07-29 9:09 a.m., Daniel Vetter wrote:
> On Wed, Jul 28, 2021 at 08:34:13AM -0700, Rob Clark wrote:
>> On Wed, Jul 28, 2021 at 6:24 AM Michel Dänzer wrote:
>>> On 2021-07-28 3:13 p.m., Christian König wrote:
>>>> Am 28.07.21 um 15:08 schrieb Michel Dänzer
of the desktop
>> continues running normally without a glitch.
>
> But that is in contradict to what you told me before.
>
> See when the window should move but fails to draw it's new content what
> happens?
>
> Are the other windows which wou
the
> crtc_state->event correctly.
>
> - We probably also want some kind of (maybe per-crtc) recommended queue
> depth property so compositors know how many buffers to keep in flight.
> Not sure about that.
I'd say there would definitely need to
On 2021-08-02 9:59 a.m., Daniel Vetter wrote:
> On Fri, Jul 30, 2021 at 02:50:10PM +0200, Michel Dänzer wrote:
>> On 2021-07-30 12:25 p.m., Daniel Vetter wrote:
>>> On Thu, Jul 29, 2021 at 01:16:55AM -0700, Vivek Kasireddy wrote:
>>>> By separating the OUT_FENCE signa
On 2021-08-02 11:06 a.m., Daniel Vetter wrote:
> On Mon, Aug 02, 2021 at 10:49:37AM +0200, Michel Dänzer wrote:
>> On 2021-08-02 9:59 a.m., Daniel Vetter wrote:
>>> On Fri, Jul 30, 2021 at 02:50:10PM +0200, Michel Dänzer wrote:
>>>> On 2021-07-30 12:25 p.m., Daniel V
oblems so far but we did try the experiment you mentioned (i.e., adjusting
> the delays)
> and it works. However, this patch series is meant to fix the issue without
> having to tweak
> anything (delays) because we can't do this for every compositor out there.
Maybe there could
ly implies other
> stuff has changed as well and we'll just be chasing changes. I agree
> it would be best to just reject anything other than updating the
> scanout address.
FWIW, that means page flipping cannot be used in some cases which work fine by
changing the pitch, which can result in tearing:
https://gitlab.freedesktop.org/xorg/xserver/-/issues/839 (which says the i915
driver handles this as well).
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
and provide the existing synchronization semantics as needed?
Surely there are resource limits for the per-context queues, so the kernel
driver needs to do some kind of virtualization / multi-plexing anyway, or we'll
get sad user faces when there's no queue available for .
I'
> size (%u) for plane %d\n",
> + objs[i]->size, min_size, i);
> drm_gem_object_put(objs[i]);
> ret = -EINVAL;
> goto err_gem_object_put;
>
Reviewed-by: Michel Dänzer
gt; acceptable?
>>>>>
>>>>> That's just another flavour of your "increase queue depth without
>>>>> increasing the atomic queue depth" approach. I still think the underlying
>>>>> fundamental issue is a timing confusion, and the fact that adjusting the
>>>>> timings fixes things too kinda proves that. So we need to fix that in a
>>>>> clean way, not by shuffling things around semi-randomly until the specific
>>>>> config we tests works.
>>>> [Kasireddy, Vivek] This issue is not due to a timing or timestamp
>>>> mismatch. We
>>>> have carefully instrumented both the Host and Guest compositors and
>>>> measured
>>>> the latencies at each step. The relevant debug data only points to the
>>>> scheduling
>>>> policy -- of both Host and Guest compositors -- playing a role in Guest
>>>> rendering
>>>> at 30 FPS.
>>>
>>> Hm but that essentially means that the events your passing around have an
>>> even more ad-hoc implementation specific meaning: Essentially it's the
>>> kick-off for the guest's repaint loop? That sounds even worse for a kms
>>> uapi extension.
>> [Kasireddy, Vivek] The pageflip completion event/vblank event indeed serves
>> as the
>> kick-off for a compositor's (both Guest and Host) repaint loop. AFAICT,
>> Weston
>> works that way and even if we increase the queue depth to solve this
>> problem, I don't
>> think it'll help because the arrival of this event always indicates to a
>> compositor to
>> start its repaint cycle again and assume that the previous buffers are all
>> free.
>
> I thought this is how simple compositors work, and weston has since a
> while it's own timer, which is based on the timestamp it gets (at on
> drivers with vblank support), so that it starts the repaint loop a few ms
> before the next vblank. And not immediately when it receives the old page
> flip completion event.
As long as it's a fixed timer, there's still a risk that the guest compositor
repaint cycle runs too late for the host one (unless the guest cycle happens to
be scheduled significantly earlier than the host one).
Note that current mutter Git main (to become the 41 release this autumn) uses
dynamic scheduling of its repaint cycle based on how long the last 16 frames
took to draw and present. In theory, this could automatically schedule the
guest cycle early enough for the host one.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
From: Michel Dänzer
In contrast to schedule_delayed_work, this pushes back the work if it
was already scheduled before. Specific behaviour change:
Before:
amdgpu_device_delay_enable_gfx_off ran ~100 ms after the first time
GFXOFF was disabled and re-enabled, even if GFXOFF was disabled and
re
From: Michel Dänzer
In contrast to schedule_delayed_work, this pushes back the work if it
was already scheduled before. Specific behaviour change:
Before:
The scheduled work ran ~1 second after the first time ring_end_use was
called, even if the ring was used again during that second.
After
rames because
its CPU work for a frame update occasionally took up to 3 ms, instead of the
normal 2-300 microseconds. sysprof showed a lot of cycles spent in the
functions which enable/disable GFXOFF in the HW.
> so when this makes a difference it is actually a bug.
There was ce
32.reply and req32.request are
members of the same union.
> if (copy_to_user(argp, &req32, sizeof(req32)))
> return -EFAULT;
>
> - return 0;
> + return err;
> }
The other changes look correct.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
On 2021-08-12 1:33 p.m., Lazar, Lijo wrote:
> On 8/12/2021 1:41 PM, Michel Dänzer wrote:
>> On 2021-08-12 7:55 a.m., Koenig, Christian wrote:
>>> Hi James,
>>>
>>> Evan seems to have understood how this all works together.
>>>
>>> See while
5f1329c66a9d1e06b88d40b247b51313
With the Gerrit Change-Id removed,
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
From: Michel Dänzer
schedule_delayed_work does not push back the work if it was already
scheduled before, so amdgpu_device_delay_enable_gfx_off ran ~100 ms
after the first time GFXOFF was disabled and re-enabled, even if GFXOFF
was disabled and re-enabled again during those 100 ms.
This
On 2021-08-13 6:23 a.m., Lazar, Lijo wrote:
>
>
> On 8/12/2021 10:24 PM, Michel Dänzer wrote:
>> On 2021-08-12 1:33 p.m., Lazar, Lijo wrote:
>>> On 8/12/2021 1:41 PM, Michel Dänzer wrote:
>>>> On 2021-08-12 7:55 a.m., Koenig, Christian wrote:
>>&g
On 2021-08-13 1:50 p.m., Lazar, Lijo wrote:
>
>
> On 8/13/2021 3:59 PM, Michel Dänzer wrote:
>> From: Michel Dänzer
>>
>> schedule_delayed_work does not push back the work if it was already
>> scheduled before, so amdgpu_device_delay_enable_gfx_off ran ~100 ms
&
On 2021-08-13 4:14 p.m., Lazar, Lijo wrote:
> On 8/13/2021 7:04 PM, Michel Dänzer wrote:
>> On 2021-08-13 1:50 p.m., Lazar, Lijo wrote:
>>> On 8/13/2021 3:59 PM, Michel Dänzer wrote:
>>>> From: Michel Dänzer
>>>>
>>>> schedule_dela
t's read with
le32_to_cpu (with some exceptions which look like bugs), which would result in
0xADEDFECA like this.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
On 2021-08-13 5:07 p.m., Lazar, Lijo wrote:
>
>
> On 8/13/2021 8:10 PM, Michel Dänzer wrote:
>> On 2021-08-13 4:14 p.m., Lazar, Lijo wrote:
>>> On 8/13/2021 7:04 PM, Michel Dänzer wrote:
>>>> On 2021-08-13 1:50 p.m., Lazar, Lijo wrote:
>>>>> On
From: Michel Dänzer
schedule_delayed_work does not push back the work if it was already
scheduled before, so amdgpu_device_delay_enable_gfx_off ran ~100 ms
after the first time GFXOFF was disabled and re-enabled, even if GFXOFF
was disabled and re-enabled again during those 100 ms.
This
On 2021-08-16 9:38 a.m., Christian König wrote:
> Am 13.08.21 um 12:29 schrieb Michel Dänzer:
>> From: Michel Dänzer
>>
>> schedule_delayed_work does not push back the work if it was already
>> scheduled before, so amdgpu_device_delay_enable_gfx_off ran ~100 ms
>>
k when adev->gfx.gfx_off_req_count
transitions from 1 to 0, which means it no longer needs to lock the mutex.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
On 2021-08-16 6:13 a.m., Lazar, Lijo wrote:
> On 8/13/2021 9:30 PM, Michel Dänzer wrote:
>> On 2021-08-13 5:07 p.m., Lazar, Lijo wrote:
>>> On 8/13/2021 8:10 PM, Michel Dänzer wrote:
>>>> On 2021-08-13 4:14 p.m., Lazar, Lijo wrote:
>>>>> On 8/13/2021 7:
On 2021-08-16 2:06 p.m., Christian König wrote:
> Am 16.08.21 um 13:33 schrieb Lazar, Lijo:
>> On 8/16/2021 4:05 PM, Michel Dänzer wrote:
>>> From: Michel Dänzer
>>>
>>> schedule_delayed_work does not push back the work if it was already
>>> scheduled
From: Michel Dänzer
schedule_delayed_work does not push back the work if it was already
scheduled before, so amdgpu_device_delay_enable_gfx_off ran ~100 ms
after the first time GFXOFF was disabled and re-enabled, even if GFXOFF
was disabled and re-enabled again during those 100 ms.
This
On 2021-08-17 10:17 a.m., Lazar, Lijo wrote:
> On 8/17/2021 1:21 PM, Quan, Evan wrote:
>>> -Original Message-
>>> From: amd-gfx On Behalf Of
>>> Michel Dänzer
>>> Sent: Monday, August 16, 2021 6:35 PM
>>> To: Deucher, Alexander ; Koenig, Ch
On 2021-08-17 11:12 a.m., Lazar, Lijo wrote:
>
>
> On 8/17/2021 1:53 PM, Michel Dänzer wrote:
>> From: Michel Dänzer
>>
>> schedule_delayed_work does not push back the work if it was already
>> scheduled before, so amdgpu_device_delay_enable_gfx_off ran ~100
On 2021-08-17 11:37 a.m., Lazar, Lijo wrote:
>
>
> On 8/17/2021 2:56 PM, Michel Dänzer wrote:
>> On 2021-08-17 11:12 a.m., Lazar, Lijo wrote:
>>>
>>>
>>> On 8/17/2021 1:53 PM, Michel Dänzer wrote:
>>>> From: Michel Dänzer
>>>>
On 2021-08-17 12:37 p.m., Lazar, Lijo wrote:
>
>
> On 8/17/2021 3:29 PM, Michel Dänzer wrote:
>> On 2021-08-17 11:37 a.m., Lazar, Lijo wrote:
>>>
>>>
>>> On 8/17/2021 2:56 PM, Michel Dänzer wrote:
>>>> On 2021-08-17 11:12 a.m., Lazar, Lijo
fd = get_unused_fd_flags(O_CLOEXEC);
>> + if (fd < 0)
>> + return fd;
>> +
>> + if (arg.flags & DMA_BUF_SYNC_WRITE) {
>> + ret = dma_resv_get_singleton(dmabuf->resv, NULL, &fence);
>> + if (ret)
>
inear Modifier (DRM_FORMAT_MOD_LINEAR),
> [...]
No modifier support does not imply linear. It's generally signalled via
DRM_FORMAT_MOD_INVALID, which roughly means "tiling is determined by driver
specific mechanisms".
--
Earthling Michel Dänzer | https://re
P_NOWARN as well to avoid these splats.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
[ 9556.710241] clinfo: page allocation failure: order:9,
mode:0x194dc2(GFP_HIGHUSER|__GFP_RETRY_MAYFA
From: Michel Dänzer
Without __GFP_NOWARN, attempts at allocating huge pages can trigger
dmesg splats like below (which are essentially noise, since TTM falls
back to normal pages if it can't get a huge one).
[ 9556.710241] clinfo: page allocation failure: order:9,
mode:0x194dc2(GFP_HIG
select if CONFIG_DRM is
unfortunately needed I think.
Per above, not sure this is really true.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
_
On 2021-02-08 12:49 p.m., Michel Dänzer wrote:
On 2021-02-05 9:53 p.m., Daniel Vetter wrote:
On Fri, Feb 5, 2021 at 7:37 PM Kees Cook wrote:
On Fri, Feb 05, 2021 at 04:37:52PM +, Chris Wilson wrote:
Userspace has discovered the functionality offered by SYS_kcmp and has
started to depend
On 2021-02-08 2:34 p.m., Daniel Vetter wrote:
On Mon, Feb 8, 2021 at 12:49 PM Michel Dänzer wrote:
On 2021-02-05 9:53 p.m., Daniel Vetter wrote:
On Fri, Feb 5, 2021 at 7:37 PM Kees Cook wrote:
On Fri, Feb 05, 2021 at 04:37:52PM +, Chris Wilson wrote:
Userspace has discovered the
HUSER|__GFP_NORETRY|__GFP_ZERO|__
GFP_NOMEMALLOC),
nodemask=(null),cpuset=/,mems_allowed=0
Fixed in v5.11-rc7 by 2b1b3e544f65 "drm/ttm: Use __GFP_NOWARN for huge
pages in ttm_pool_alloc_page".
--
Earthling Michel Dänzer | htt
issue and mesa was using
SYS_kcmp to compare device node fds.
A far shorter and more portable solution is possible, so let me
prepare a Mesa patch.
Make sure to read my comments on
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6881 first. :)
--
Earthling Michel Dänzer
initialize
req.reply.tval_usec = req32.reply.tval_usec;
before calling drm_ioctl_kernel, since it's not aliased by any req.request.*
member, and drm_wait_vblank_ioctl doesn't always write to it.
--
Earthling Michel Dänzer | https://redhat.com
Libr
y uAPI.
Note that the dma-buf poll support could be useful to Wayland compositors for
the same purpose as Jason's new ioctl (only using client buffers which have
finished drawing for an output frame, to avoid missing a refresh cycle due to
client drawing), *if* i
On 2021-05-19 5:21 p.m., Jason Ekstrand wrote:
> On Wed, May 19, 2021 at 5:52 AM Michel Dänzer wrote:
>>
>> On 2021-05-19 12:06 a.m., Jason Ekstrand wrote:
>>> On Tue, May 18, 2021 at 4:17 PM Daniel Vetter wrote:
>>>>
>>>> On Tue, May
On 2021-05-20 9:55 a.m., Daniel Vetter wrote:
> On Wed, May 19, 2021 at 5:48 PM Michel Dänzer wrote:
>>
>> On 2021-05-19 5:21 p.m., Jason Ekstrand wrote:
>>> On Wed, May 19, 2021 at 5:52 AM Michel Dänzer wrote:
>>>>
>>>> On 2021-05-19 12:06 a.m.,
On 2021-05-20 4:18 p.m., Daniel Vetter wrote:
> On Thu, May 20, 2021 at 10:13:38AM +0200, Michel Dänzer wrote:
>> On 2021-05-20 9:55 a.m., Daniel Vetter wrote:
>>> On Wed, May 19, 2021 at 5:48 PM Michel Dänzer wrote:
>>>>
>>>> On 2021-05-19 5:21 p.m.,
sably slow (think single-digit frames
per second), and of course there's other userspace which goes "ooh,
dma-buf, let's map and read!".
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast |
explicitly
asked to be mapped into its address space).
The instability you're seeing likely isn't due to lack of memory
protection but due to any of a large number of other ways a GPU can end
up in a hanging state, and the drivers and wider ecosystem not being
very good at recoveri
On 2020-12-01 11:01 a.m., James Park wrote:
This will allow Mesa to port code to Windows more easily.
As discussed in
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6162#note_712779
, including drm.h makes no sense when building for Windows.
--
Earthling Michel Dänzer
On 2020-12-02 1:46 p.m., Daniel Vetter wrote:
On Wed, Dec 2, 2020 at 12:43 PM Michel Dänzer wrote:
On 2020-12-01 11:01 a.m., James Park wrote:
This will allow Mesa to port code to Windows more easily.
As discussed in
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6162
code should use platform-neutral abstractions for
these. This wasn't deemed necessary before, because nobody was trying to
build these drivers for non-UNIX OSes. But now you are.
--
Earthling Michel Dänzer | https://redhat.com
Libre software
ows (shortlog from
> b10733527bfd864605c33ab2e9a886eec317ec39..HEAD):
libdrm uses GitLab merge requests now:
https://gitlab.freedesktop.org/mesa/drm/-/merge_requests
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
>> again, this would maybe motivate the others to fix theirs too so we
>> could keep most/all of drivers/gpu/ free of W=1 warnings.
>
> We haven't really been monitoring the W=1 stuff that closely. I'll
> see what we can do going forward.
IMHO keeping the W=1 build
tication of clients against the X server, leaking
that all around was ok. With render nodes no leaking should happen,
with no knob for userspace to opt out of the forced clearing.
Seconded.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast
d update the comment added in patch 1.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedeskt
Pan, you're sending patches to amd-gfx-boun...@lists.freedesktop.org, which
doesn't work. You need to send them to amd-...@lists.freedesktop.org instead.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast |
driver and troubleshoot why a native
> DRM driver is not working. Or try updating the kernel package, etc.
For troubleshooting, it'll be helpful if this new parameter can be enabled for
the boot via the kernel command line, then disabled again after boot-up. One
simple possibilit
On 2021-10-25 14:28, Javier Martinez Canillas wrote:
> Hello Michel,
>
> On 10/25/21 12:45, Michel Dänzer wrote:
>> On 2021-10-24 22:32, Javier Martinez Canillas wrote:
>>> Hello Ville,
>>>
>>> On 10/22/21 21:12, Ville Syrjälä wrote:
>>>> On
start > 0x1ull)
> + upper_32_bits(res->start) != 0)
New code matches 1ull << 32, old code didn't. If this difference matters, this
would break if res->start is 64 bits?
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
ace while evicted, and this will appear to user-space like the
> WC-mapped object suddenly became WB-mapped. But it appears like mesa
> doesn't care about this as long as the mappings are fully coherent.
FWIW, the Mesa radeonsi driver avoids surprises due to this (e.g
On 2021-09-30 14:27, Matthew Auld wrote:
> On 30/09/2021 11:04, Michel Dänzer wrote:
>> On 2021-09-29 13:54, Thomas Hellström wrote:
>>> On Mon, 2021-09-27 at 12:41 +0100, Matthew Auld wrote:
>>>> This should let us do an accelerated copy directly to the shmem page
the same fbdev acceleration hooks as an fbdev driver.
(Most DRM drivers never bothered because the HW is more complex than
traditional 2D accelerators, and can't safely be used under all circumstances
where fbdev acceleration hooks could get called from. That's not an issue for a
On 2021-07-23 10:22, Christian König wrote:
> Am 23.07.21 um 10:19 schrieb Michel Dänzer:
>> On 2021-07-23 10:04 a.m., Christian König wrote:
>>> Am 23.07.21 um 09:58 schrieb Michel Dänzer:
>>>> From: Michel Dänzer
>>>>
>>>> This ma
before it returns -ERESTARTSYS.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
return err;
> - }
> -
> - drm_master_internal_release(fb_helper->dev);
> -
> - drm_dbg_kms(fb_helper->dev, "\n");
> -
> - drm_client_modeset_probe(&fb_helper->client, fb_helper->fb->width,
> fb_helper->fb->height);
> - drm_setup_crtcs_fb(fb_helper);
> - mutex_unlock(&fb_helper->lock);
> -
> - drm_fb_helper_set_par(fb_helper->fbdev);
> -
> - return 0;
> + return __drm_fb_helper_hotplug_event(fb_helper, false);
> }
> EXPORT_SYMBOL(drm_fb_helper_hotplug_event);
>
>
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
he
unpins seem unconditional. So could this be about virtual display, and the
problem is actually trying to unpin a BO that was never pinned?
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
On 2021-11-12 15:29, Michel Dänzer wrote:
> On 2021-11-12 13:47, Christian König wrote:
>>
>> Anyway this unfortunately turned out to be work for Harray and Nicholas. In
>> detail it's about this bug report here:
>> https://bugzilla.kernel.org/show_bug.cgi?
On 2021-11-12 16:03, Christian König wrote:
> Am 12.11.21 um 15:30 schrieb Michel Dänzer:
>> On 2021-11-12 15:29, Michel Dänzer wrote:
>>> On 2021-11-12 13:47, Christian König wrote:
>>>> Anyway this unfortunately turned out to be work for Harray and Nicholas.
>
On 2021-11-15 07:41, Lang Yu wrote:
> On Fri, Nov 12, 2021 at 05:10:27PM +0100, Michel DDDnzer wrote:
>> On 2021-11-12 16:03, Christian König wrote:
>>> Am 12.11.21 um 15:30 schrieb Michel Dänzer:
>>>> On 2021-11-12 15:29, Michel Dänzer wrote:
>>>>&g
>>>> Am 12.11.21 um 15:30 schrieb Michel Dänzer:
>>>>>> On 2021-11-12 15:29, Michel Dänzer wrote:
>>>>>>> On 2021-11-12 13:47, Christian König wrote:
>>>>>>>> Anyway this unfortunately turned out to b
> On Fri, Nov 12, 2021 at 05:10:27PM +0100, Michel DDDnzer wrote:
>>>>>> On 2021-11-12 16:03, Christian König wrote:
>>>>>>> Am 12.11.21 um 15:30 schrieb Michel Dänzer:
>>>>>>>> On 2021-11-12 15:29, Michel Dänzer wrote:
>>>>
) pins
>>> crtc->primary->fb(new),
>>> unpins old fb.
>>>
>>> 3, amdgpu_display_crtc_page_flip_target() pin/unpin operations.
>>>
>>> 4, third crtc_mode_set, dce_v*_0_crtc_do_set_base() pins
>>> crtc->primary->fb(new),
>>> unpins old
ngs in the right order.
With KMS, surely the kernel needs to be able to get to a known good state from
scratch when it's in control of the VT, no matter what state user space left
things in.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
From: Michel Dänzer
Use the struct display_mode_lib pointer instead of passing lots of large
arrays as parameters by value.
Addresses this warning (resulting in failure to build a RHEL debug kernel
with Werror enabled):
../drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_mode_vba_31
From: Michel Dänzer
Move code using the Pipe struct to a new helper function.
Works around[0] this warning (resulting in failure to build a RHEL debug
kernel with Werror enabled):
../drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_mode_vba_31.c: In
function
On 2021-12-11 13:20, Rodrigo Siqueira Jordao wrote:
>
>
> On 2021-12-09 11:46 a.m., Michel Dänzer wrote:
>> From: Michel Dänzer
>>
>> Move code using the Pipe struct to a new helper function.
>>
>> Works around[0] this warning (resulting in failure to b
which would even advertise PresentCapabilityUST, let
alone do anything with a timestamp passed in by the client).
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X deve
On 30.04.2016 12:18, Edward O'Callaghan wrote:
> Signed-off-by: Edward O'Callaghan
> ---
> drivers/gpu/drm/amd/dal/utils/bw_calc_test_harness/.gitignore | 4
> drivers/gpu/drm/amd/dal/utils/vba_to_c_converter/.gitignore | 4
> 2 files changed, 8 deletions(-)
> delete mode 100644
> d
On 30.04.2016 16:44, Michel Dänzer wrote:
> On 30.04.2016 12:18, Edward O'Callaghan wrote:
>> Signed-off-by: Edward O'Callaghan
>> ---
>> drivers/gpu/drm/amd/dal/utils/bw_calc_test_harness/.gitignore | 4
>> drivers/gpu/drm/amd/dal/utils/vba_to_c_converter/.gitignore | 4
>> 2 files
On 30.04.2016 17:50, Michel Dänzer wrote:
> On 30.04.2016 16:44, Michel Dänzer wrote:
>> On 30.04.2016 12:18, Edward O'Callaghan wrote:
>>> Signed-off-by: Edward O'Callaghan
>>> ---
>>> drivers/gpu/drm/amd/dal/utils/bw_calc_test_harness/.gitignore | 4
>>> drivers/gpu/drm/amd/dal/utils/vba
From: Michel Dänzer
Fixes warnings and miscompilation resulting in crashes with clang.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94249
Signed-off-by: Michel Dänzer
---
amdgpu/amdgpu_vamgr.c | 2 +-
util_double_list.h| 10 +-
2 files changed, 6 insertions(+), 6 delet
On 03.08.2016 02:49, Nicolai Hähnle wrote:
> On 02.08.2016 12:08, Michel Dänzer wrote:
>> From: Michel Dänzer
>>
>> Fixes warnings and miscompilation resulting in crashes with clang.
>
> How annoying. Seems like this would affect most (current and future)
> uses of container_of, and so it woul
On 04.08.2016 06:33, Rodrigo Vivi wrote:
> For now DC is only helping on screen off scenarios since PSR is disabled.
>
> But if we want to enable PSR first we need to make DC reliable with screen on.
> Biggest challenge is to deal with vblank counters since frame counter register
> is read only an
From: Michel Dänzer
With the previous change, it's safe to let page flips take effect
anytime during a vertical blank period.
This can avoid delaying a flip by a frame in some cases where we get to
amdgpu_flip_work_func -> adev->mode_info.funcs->page_flip during a
vertical blank period.
Signed
From: Michel Dänzer
Mostly the same as the existing page_flip hook, but takes an additional
parameter specifying the target vertical blank period when the flip
should take effect.
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/drm_crtc.c | 23 +++
include/drm/drm_crtc.h
From: Michel Dänzer
These flags allow userspace to explicitly specify the target vertical
blank period when a flip should take effect.
Signed-off-by: Michel Dänzer
---
Note that the previous patches in this series can avoid delaying page
flips in some cases even without this patch or any cor
From: Michel Dänzer
With the previous change, it's safe to let page flips take effect
anytime during a vertical blank period.
This can avoid delaying a flip by a frame in some cases where we get to
radeon_flip_work_func -> adev->mode_info.funcs->page_flip during a
vertical blank period.
Signed
The purpose of this series is to allow drivers to avoid unnecessarily
delaying page flips, by explicitly telling the driver which vblank seqno
a flip is supposed to take effect in.
Patch 1 sets the target to the vblank seqno after the current one when
the DRM_IOCTL_MODE_PAGE_FLIP ioctl is called,
From: Michel Dänzer
Now we can program a flip during a vertical blank period, if it's the
one targeted by the flip (or a later one). This allows simplifying
amdgpu_flip_work_func considerably.
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 3 +-
drivers/gpu/d
1 - 100 of 2081 matches
Mail list logo
