When 2 rings met timeout at same time, triggered job_timedout separately.
Each job_timedout called gpu_recover, but one of gpu_recover locked by
another's mutex_lock.
Bad jod’s callback should be removed by dma_fence_remove_callback but locked
inside mutex_lock.
So dma_fence_remove_callback
On 12/21/2018 01:37 PM, Christian König wrote:
> Am 20.12.18 um 20:23 schrieb Andrey Grodzovsky:
>> Decauple sched threads stop and start and ring mirror
>> list handling from the policy of what to do about the
>> guilty jobs.
>> When stoppping the sched thread and detaching sched fences
>> from
Hi Yu,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.20-rc7]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
On 2018-12-21 8:26 a.m., Emily Deng wrote:
> When the bo is used to set mode, the bo need to be pinned.
>
> Signed-off-by: Emily Deng
>
> [...]
>
> @@ -235,6 +222,47 @@ static bool dce_virtual_crtc_mode_fixup(struct drm_crtc
> *crtc,
> static int dce_virtual_crtc_set_base(struct drm_crtc
On 2018-12-21 8:26 a.m., Emily Deng wrote:
> When the bo is used to set mode, the bo need to be pinned.
On second thought, why does the BO need to be pinned? When using the
display hardware, the BO needs to be pinned to prevent it from being
moved while the hardware is scanning out from it, but
On 2018-12-21 9:45 a.m., Deng, Emily wrote:
>> -Original Message-
>> From: Michel Dänzer
>> Sent: Friday, December 21, 2018 4:38 PM
>> To: Deng, Emily
>> Cc: amd-gfx@lists.freedesktop.org
>> Subject: Re: [PATCH] drm/amdgpu/virtual_dce: Need to pin the fb's bo
>>
>> On 2018-12-21 8:26
On 2018-12-21 10:32 a.m., Deng, Emily wrote:
>> -Original Message-
>> From: Michel Dänzer
>> Sent: Friday, December 21, 2018 5:28 PM
>> To: Deng, Emily
>> Cc: amd-gfx@lists.freedesktop.org
>> Subject: Re: [PATCH] drm/amdgpu/virtual_dce: Need to pin the fb's bo
>>
>> On 2018-12-21 10:17
On 2018-12-21 11:15 a.m., Deng, Emily wrote:
>> -Original Message-
>> From: Michel Dänzer
>> Sent: Friday, December 21, 2018 6:08 PM
>> To: Deng, Emily
>> Cc: amd-gfx@lists.freedesktop.org
>> Subject: Re: [PATCH] drm/amdgpu/virtual_dce: Need to pin the fb's bo
>>
>> On 2018-12-21 10:55
>-Original Message-
>From: Michel Dänzer
>Sent: Friday, December 21, 2018 5:28 PM
>To: Deng, Emily
>Cc: amd-gfx@lists.freedesktop.org
>Subject: Re: [PATCH] drm/amdgpu/virtual_dce: Need to pin the fb's bo
>
>On 2018-12-21 10:17 a.m., Deng, Emily wrote:
>>> From: amd-gfx On Behalf Of
>>>
>-Original Message-
>From: amd-gfx On Behalf Of Deng,
>Emily
>Sent: Friday, December 21, 2018 5:41 PM
>To: Michel Dänzer
>Cc: amd-gfx@lists.freedesktop.org
>Subject: RE: [PATCH] drm/amdgpu/virtual_dce: Need to pin the fb's bo
>
>>-Original Message-
>>From: Michel Dänzer
>>Sent:
>-Original Message-
>From: Michel Dänzer
>Sent: Friday, December 21, 2018 6:08 PM
>To: Deng, Emily
>Cc: amd-gfx@lists.freedesktop.org
>Subject: Re: [PATCH] drm/amdgpu/virtual_dce: Need to pin the fb's bo
>
>On 2018-12-21 10:55 a.m., Deng, Emily wrote:
>>> -Original Message-
>>>
On 2018-12-21 4:10 a.m., Yu Zhao wrote:
> Fix race between page flip job submission and completion. We invoke
> page_flip callback to submit page flip job to GPU first and then set
> pflip_status. If GPU fires page flip done irq in between, its handler
> won't see the correct pflip_status thus
On 2018-12-21 10:17 a.m., Deng, Emily wrote:
>> From: amd-gfx On Behalf Of Deng,
>> Emily
>>> From: Michel Dänzer
>>> On 2018-12-21 9:45 a.m., Deng, Emily wrote:
> From: Michel Dänzer
> On 2018-12-21 8:26 a.m., Emily Deng wrote:
>> When the bo is used to set mode, the bo need to be
>-Original Message-
>From: Michel Dänzer
>Sent: Friday, December 21, 2018 4:38 PM
>To: Deng, Emily
>Cc: amd-gfx@lists.freedesktop.org
>Subject: Re: [PATCH] drm/amdgpu/virtual_dce: Need to pin the fb's bo
>
>On 2018-12-21 8:26 a.m., Emily Deng wrote:
>> When the bo is used to set mode,
On 2018-12-21 4:10 a.m., Yu Zhao wrote:
> Userspace may request pitch alignment that is not supported by GPU.
> Some requests 32, but GPU ignores it and uses default 64 when cpp is
> 4. If GEM object is allocated based on the smaller alignment, GPU
> DMA will go out of bound.
>
> For GPU that
On 2018-12-21 4:10 a.m., Yu Zhao wrote:
> When creating frame buffer, userspace may request to attach to a
> previously allocated GEM object that is smaller than what GPU
> requires. Validation must be done to prevent out-of-bound DMA,
> which could not only corrupt memory but also reveal
>-Original Message-
>From: Michel Dänzer
>Sent: Friday, December 21, 2018 4:52 PM
>To: Deng, Emily
>Cc: amd-gfx@lists.freedesktop.org
>Subject: Re: [PATCH] drm/amdgpu/virtual_dce: Need to pin the fb's bo
>
>On 2018-12-21 9:45 a.m., Deng, Emily wrote:
>>> -Original Message-
>>>
On 2018-12-21 10:55 a.m., Deng, Emily wrote:
>> -Original Message-
>> From: amd-gfx On Behalf Of Deng,
>> Emily
>> Sent: Friday, December 21, 2018 5:41 PM
>> To: Michel Dänzer
>> Cc: amd-gfx@lists.freedesktop.org
>> Subject: RE: [PATCH] drm/amdgpu/virtual_dce: Need to pin the fb's bo
>>
When creating frame buffer, userspace may request to attach to a
previously allocated GEM object that is smaller than what GPU
requires. Validation must be done to prevent out-of-bound DMA,
which could not only corrupt memory but also reveal sensitive data.
This fix is not done in a common code
Userspace may request pitch alignment that is not supported by GPU.
Some requests 32, but GPU ignores it and uses default 64 when cpp is
4. If GEM object is allocated based on the smaller alignment, GPU
DMA will go out of bound.
For GPU that does frame buffer compression, DMA writing out of bound
Fix race between page flip job submission and completion. We invoke
page_flip callback to submit page flip job to GPU first and then set
pflip_status. If GPU fires page flip done irq in between, its handler
won't see the correct pflip_status thus will refuse to notify the job
completion. The job
On 2018-12-21 4:10 a.m., Yu Zhao wrote:
> Userspace may request pitch alignment that is not supported by GPU.
> Some requests 32, but GPU ignores it and uses default 64 when cpp is
> 4. If GEM object is allocated based on the smaller alignment, GPU
> DMA will go out of bound.
>
> For GPU that
>-Original Message-
>From: amd-gfx On Behalf Of Deng,
>Emily
>Sent: Friday, December 21, 2018 5:10 PM
>To: Michel Dänzer
>Cc: amd-gfx@lists.freedesktop.org
>Subject: RE: [PATCH] drm/amdgpu/virtual_dce: Need to pin the fb's bo
>
>>-Original Message-
>>From: Michel Dänzer
>>Sent:
>-Original Message-
>From: Michel Dänzer
>Sent: Friday, December 21, 2018 5:37 PM
>To: Deng, Emily
>Cc: amd-gfx@lists.freedesktop.org
>Subject: Re: [PATCH] drm/amdgpu/virtual_dce: Need to pin the fb's bo
>
>On 2018-12-21 10:32 a.m., Deng, Emily wrote:
>>> -Original Message-
>>>
On 2018-12-20 3:01 p.m., S, Shirish wrote:
> Initializing structures with { } is known to be problematic since
> it doesn't necessararily initializes all bytes, in case of padding,
> causing random failures when structures are memcmp().
>
> This patch fixes the structure initialisation compiler
On Fri, Dec 21, 2018 at 9:16 AM Liviu Dudau wrote:
>
> On Thu, Dec 20, 2018 at 04:36:19PM +0100, Daniel Vetter wrote:
> > On Thu, Dec 20, 2018 at 09:56:57AM -0500, Alex Deucher wrote:
> > > I'm not familiar enough with ARM to know if write combining
> > > is actually an architectural limitation
On Thu, Dec 20, 2018 at 04:36:19PM +0100, Daniel Vetter wrote:
> On Thu, Dec 20, 2018 at 09:56:57AM -0500, Alex Deucher wrote:
> > I'm not familiar enough with ARM to know if write combining
> > is actually an architectural limitation or if it's an issue
> > with the PCIe IPs used on various
Am 21.12.18 um 12:18 schrieb Michel Dänzer:
> On 2018-12-20 3:01 p.m., S, Shirish wrote:
>> Initializing structures with { } is known to be problematic since
>> it doesn't necessararily initializes all bytes, in case of padding,
>> causing random failures when structures are memcmp().
>>
>> This
Hi Yu,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.20-rc7 next-20181221]
[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
Am 21.12.18 um 10:09 schrieb Deng, Emily:
-Original Message-
From: Michel Dänzer
Sent: Friday, December 21, 2018 4:52 PM
To: Deng, Emily
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu/virtual_dce: Need to pin the fb's bo
On 2018-12-21 9:45 a.m., Deng, Emily wrote:
On Fri, Dec 21, 2018 at 1:15 PM Christian König
wrote:
>
> Am 21.12.18 um 10:09 schrieb Deng, Emily:
> >> -Original Message-
> >> From: Michel Dänzer
> >> Sent: Friday, December 21, 2018 4:52 PM
> >> To: Deng, Emily
> >> Cc: amd-gfx@lists.freedesktop.org
> >> Subject: Re: [PATCH]
Am 21.12.18 um 19:19 schrieb Alex Deucher:
> On Fri, Dec 21, 2018 at 1:15 PM Christian König
> wrote:
>> Am 21.12.18 um 10:09 schrieb Deng, Emily:
-Original Message-
From: Michel Dänzer
Sent: Friday, December 21, 2018 4:52 PM
To: Deng, Emily
Cc:
Already fixed here:
https://cgit.freedesktop.org/drm/drm/commit/?id=7e07834c12b96214e95a473f7b14fc03b20e2e7a
Thanks,
Alex
On Fri, Dec 21, 2018 at 9:59 AM Brajeswar Ghosh
wrote:
>
> Remove ppatomctrl.h which is included more than once
>
> Signed-off-by: Brajeswar Ghosh
> ---
>
Am 20.12.18 um 20:23 schrieb Andrey Grodzovsky:
Decauple sched threads stop and start and ring mirror
list handling from the policy of what to do about the
guilty jobs.
When stoppping the sched thread and detaching sched fences
from non signaled HW fenes wait for all signaled HW fences
to
On Fri, Dec 21, 2018 at 2:49 PM Brajeswar Ghosh
wrote:
>
> Remove hwmgr_ppt.h which is included more than once
>
> Signed-off-by: Brajeswar Ghosh
> ---
Acked-by: Souptick Joarder
> drivers/gpu/drm/amd/powerplay/inc/hwmgr.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git
Remove ppatomctrl.h which is included more than once
Signed-off-by: Brajeswar Ghosh
---
drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c
Remove hwmgr_ppt.h which is included more than once
Signed-off-by: Brajeswar Ghosh
---
drivers/gpu/drm/amd/powerplay/inc/hwmgr.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h
b/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h
index
Alex Deucher writes:
> On Fri, Dec 21, 2018 at 9:16 AM Liviu Dudau wrote:
>>
>> On Thu, Dec 20, 2018 at 04:36:19PM +0100, Daniel Vetter wrote:
>> > On Thu, Dec 20, 2018 at 09:56:57AM -0500, Alex Deucher wrote:
>> > > I'm not familiar enough with ARM to know if write combining
>> > > is actually
Reviewed-by: Leo Liu
On 12/21/18 11:36 AM, Alex Deucher wrote:
> ping?
>
> On Thu, Dec 20, 2018 at 10:10 AM Alex Deucher wrote:
>> Add a new pci id.
>>
>> Signed-off-by: Alex Deucher
>> Cc: sta...@vger.kernel.org
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 +
>> 1 file changed, 1
I believe this issue would be resolved by my pending in review patch
set, specifically 'drm/sched: Refactor ring mirror list handling.' since
already on the first TO handler it will go over all the rings including
the second timed out ring and will remove all call backs including the
bad job
From: Michel Dänzer
This should be functionally equivalent to what drmModeSetCursor(2) do
behind the scenes, but allows for new tricks in following changes.
(Ported from amdgpu commit b344e1559e936046ef02c777fc4f6bcefa3830bc)
Signed-off-by: Michel Dänzer
---
src/drmmode_display.c | 21
From: Michel Dänzer
The un-premultiplied R/G/B values would overflow the gamma LUT, so just
pass through the data unchanged, and leave it up to the HW how to
interpret such weird premultiplied alpha pixels.
Bugzilla: https://bugs.freedesktop.org/108355
(Ported from amdgpu commit
From: Michel Dänzer
Not needed or even useful for anything.
(Ported from amdgpu commit e95044e45350870fa7e237860e89ade91ac03550)
Signed-off-by: Michel Dänzer
---
src/drmmode_display.c | 9 -
src/drmmode_display.h | 1 -
src/radeon.h | 1 -
src/radeon_kms.c | 21
From: Michel Dänzer
Otherwise the damaged screen contents may never be displayed in that
case.
(Ported from amdgpu commit 500fadb16285146e91f62fce3a0ce1360ca684ba)
Signed-off-by: Michel Dänzer
---
src/radeon_kms.c | 29 +++--
1 file changed, 19 insertions(+), 10
From: Michel Dänzer
It was still possible for nested xorg_list_for_each_entry_safe loops
to occur over the drm_vblank_signalled list, which could mess up that
list. Moving deferred events to a separate list allows processing the
drm_vblank_signalled list without xorg_list_for_each_entry_safe.
From: Michel Dänzer
drmmode_crtc_scanout_update does the equivalent of a scanout update,
so no need to do it again. This might also avoid issues if there's a
pending scanout update at this point.
(Ported from amdgpu commit 4e7a24ac5a64e402146953ec5850d13c05742116)
Signed-off-by: Michel Dänzer
From: Michel Dänzer
When an async flip is performed, and TearFree is enabled on the CRTC
used for timing, we schedule a vblank event for completing the page
flip. The DRM event queuing code treated this event like a vblank event,
but it needs to be treated like a page flip event.
(Ported from
From: Michel Dänzer
X server >= 1.18 already had code for this, but it only caught cases
where some pixels have 0 for alpha and non-0 for a non-alpha component.
Turns out some apps (e.g. the Civilization VI game) use
non-premultiplied cursor data which doesn't have such pixels, but can
still
From: Michel Dänzer
The cursor position is updated to be consistent with the new hotspot in
the same ioctl call.
(Ported from amdgpu commit b04697de5270e8e45744a7025c24df1f454a4cf0)
Signed-off-by: Michel Dänzer
---
src/drmmode_display.c | 75 +--
From: Michel Dänzer
At this point, we've already established that e->handler is NULL, no
need to check again in drm_queue_handle_one. This also makes it clearer
what's happening.
(Ported from amdgpu commit eda571222f5a6be47f8897e82d85199bb9d95251)
Signed-off-by: Michel Dänzer
---
From: Michel Dänzer
These are the outstanding applicable changes ported from
xf86-video-amdgpu.
Michel Dänzer (13):
Detect and fix up non-premultiplied cursor data
Skip gamma correction of cursor data if premultiplied R/G/B > alpha
glamor: Can work at depth >= 15 with current xserver Git
From: Michel Dänzer
(Ported from amdgpu commit 0734cdf544ffd3f2ac8749ad0e4bf43f8a5cea50)
Signed-off-by: Michel Dänzer
---
src/radeon_bo_helper.c | 2 ++
src/radeon_glamor.c| 9 +++--
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/src/radeon_bo_helper.c
From: Michel Dänzer
Switch to the other buffer when xf86_config->cursor changes. Avoids
these issues possible when re-using the same buffer:
* The HW may intermittently display a mix of the old and new cursor
images.
* If the hotspot changes, the HW may intermittently display the new
cursor
On Fri, Dec 21, 2018 at 10:07:26AM +0100, Michel Dänzer wrote:
> On 2018-12-21 4:10 a.m., Yu Zhao wrote:
> > Userspace may request pitch alignment that is not supported by GPU.
> > Some requests 32, but GPU ignores it and uses default 64 when cpp is
> > 4. If GEM object is allocated based on the
Userspace may request pitch alignment that is not supported by GPU.
Some requests 32, but GPU ignores it and uses default 64 when cpp is
4. If GEM object is allocated based on the smaller alignment, GPU
DMA will go out of bound.
For GPU that does frame buffer compression, DMA writing out of bound
When creating frame buffer, userspace may request to attach to a
previously allocated GEM object that is smaller than what GPU
requires. Validation must be done to prevent out-of-bound DMA,
which could not only corrupt memory but also reveal sensitive data.
This fix is not done in a common code
56 matches
Mail list logo
