From: Michel Dänzer
Although normally it only warns about it, under some circumstances,
aclocal can error out if this directory doesn't exist.
Reported-by: John Lumby
(Cherry picked from radeon commit 7b01c10137aba24c8f61dd9b2a19ea257ad24371)
Signed-off-by: Michel Dänzer
---
.gitignore
From: Michel Dänzer
Older versions of autoconf only supported the former.
(Cherry picked from radeon commit cba8fe4d64819aaa8ba516aa68dbe6d2aa153046)
Signed-off-by: Michel Dänzer
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
change, I'm getting various badness when running piglit using
radeonsi on Bonaire, see the attached dmesg excerpt.
Reverting just this change on top of current amd-staging-drm-next avoids
the problem.
Looks like some list manipulation isn't sufficiently protected against
concurrent execution?
From: Michel Dänzer
Doing it earlier hits a WARN_ON_ONCE in amdgpu_bo_gpu_offset.
Fixes: "drm/amdgpu: remove gart.table_addr"
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c | 5 -
drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 5 -
drivers/gpu/drm/amd/amdgp
; -{
> - switch (bo->tbo.mem.mem_type) {
> - case TTM_PL_TT: return amdgpu_gtt_mgr_has_gart_addr(>tbo.mem);
> - case TTM_PL_VRAM: return true;
> - default: return false;
> - }
> -}
> -
> /**
> * amdgpu_bo_in_cpu_visible_vram -
On 2018-08-28 11:14 a.m., Michel Dänzer wrote:
>
> Hi Ray,
>
>
> On 2018-08-22 9:52 a.m., Huang Rui wrote:
>> The new bulk moving functionality is ready, the overhead of moving PD/PT bos
>> to
>> LRU is fixed. So move them on LRU again.
>>
>>
On 2018-08-29 10:57 a.m., Christian König wrote:
> Am 29.08.2018 um 09:52 schrieb Michel Dänzer:
>> On 2018-08-28 7:03 p.m., Michel Dänzer wrote:
>>> On 2018-08-28 11:14 a.m., Michel Dänzer wrote:
>>>> On 2018-08-22 9:52 a.m., Huang Rui wrote:
>>>>&g
d/amdgpu/amdgpu_ucode.c
> @@ -277,6 +277,7 @@ amdgpu_ucode_get_load_type(struct amdgpu_device *adev,
> int load_type)
> case CHIP_PITCAIRN:
> case CHIP_VERDE:
> case CHIP_OLAND:
> + case CHIP_HAINAN:
> return AMDGPU_FW_LOAD_DIRECT;
> #endif
> #ifdef
On 2018-08-28 7:03 p.m., Michel Dänzer wrote:
> On 2018-08-28 11:14 a.m., Michel Dänzer wrote:
>> On 2018-08-22 9:52 a.m., Huang Rui wrote:
>>> The new bulk moving functionality is ready, the overhead of moving PD/PT
>>> bos to
>>> LRU is fixed. So move t
esktop.org/show_bug.cgi?id=107595
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
Aug 21 10:20:37 thor kernel: [4.429726] [drm] amdgpu kernel modesetting enabled.
Aug 21 10:20:37 thor kernel: [
rON);
> - kv_dpm_powergate_uvd(adev, false);
> + if (pi->caps_uvd_pg) /* power off the UVD block */
> + amdgpu_kv_notify_message_to_smu(adev, PPSMC_MSG_UVDPowerON);
The comment should say "power on", shouldn't it?
--
Earthling Michel Dänzer |
issue when loading amdkfd manually later),
see the attached kernel.log excerpt. This is also a regression in the
4.19 drm tree changes. It might be a separate issue, but TBH I don't
feel like another day or two bisecting right now. :)
Anyway, this series is
Tested-by: Michel Dä
On 2018-07-20 09:58 AM, S, Shirish wrote:
> Sure Michel, but not immediately.
> Is that fine?
Sure, thanks.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X dev
On 2018-07-19 11:20 AM, Michel Dänzer wrote:
>
> Possible follow-up work:
>
> * Move the console_(un)lock calls into amdgpu_fbdev_set_suspend, or
> maybe use drm_fb_helper_set_suspend_unlocked instead of locking ourselves
>
> * Move the amdgpu_fbdev_set_suspend call in
lper,
> - state);
> +
> drm_fb_helper_set_suspend_unlocked(>mode_info.rfbdev->helper,
> + state);
> }
>
> int amdgpu_fbdev_total_size(struct amdgpu_device *adev)
>
Thanks for
From: Michel Dänzer
We were testing the register offset, instead of the value stored in the
register, therefore always timing out the loop.
This reduces suspend time of the system in the bug report below by ~600
ms.
Bugzilla: https://bugs.freedesktop.org/107277
Tested-by: Paul Menzel
Signed
> return max_pix_clk;
> }
>
>
On my development system, max_pix_clk == 0 even though there's a display
connected via HDMI. Is that expected as well?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast |
On 2018-07-17 05:10 PM, Harry Wentland wrote:
> On 2018-07-17 10:17 AM, Michel Dänzer wrote:
>> On 2018-07-17 03:29 PM, sunpeng...@amd.com wrote:
>>> From: Mikita Lipski
>>>
>>> [why]
>>> The warning message floods the dmesg log on Tonga even
&g
From: Michel Dänzer
Only supported with the advanced colour management properties available
with DC as of kernel 4.17.
Signed-off-by: Michel Dänzer
---
src/drmmode_display.c | 47 +++
1 file changed, 34 insertions(+), 13 deletions(-)
diff --git a/src
->pdev, PCI_D0);
I don't think the amdgpu_fbdev_set_suspend call can be moved before the
pci_set_power_state call, because fbcon may presumably try writing to
the device's VRAM at any point after amdgpu_fbdev_set_suspend.
There might be other things that need to happen before
amdgpu_fbdev_
From: Michel Dänzer
The RandR screen private is already freed when our CloseScreen runs, so
this can't do anything useful. This cleanup has to be done by the X
server itself.
Signed-off-by: Michel Dänzer
---
src/amdgpu_kms.c | 1 -
src/drmmode_display.c | 20
src
On 2018-07-18 06:17 PM, Michel Dänzer wrote:
> On 2018-07-18 06:05 PM, Tom St Denis wrote:
>> Hi Christian,
>>
>> This patch:
>>
>> [root@raven linux]# git bisect bad
>> 90f362bdf0d0d06a126a5fd35b084436dd8250ad is the first bad commit
>> commit 90f36
On 2018-07-18 06:46 PM, Christian König wrote:
> Am 18.07.2018 um 18:44 schrieb Michel Dänzer:
>> On 2018-07-18 06:17 PM, Michel Dänzer wrote:
>>> On 2018-07-18 06:05 PM, Tom St Denis wrote:
>>>> Hi Christian,
>>>>
>>>> Th
r libdrm_amdgpu. At least
Christian seems in favour of this change.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freede
04 04 9a09d3e9d055e4f5024019861c334ee9cc0bd11b
> 522540c31c3d1a4f4a6fbac75e985e9a7f7e93c9 M drivers
>
> causes a KASAN while running piglit. It's reproduceable 100% of the
> time. The commit before this doesn't not cause a KASAN.
I got the attached KASAN use-after-free report while runn
see if the warning message triggers?
If yes, what error does it report?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amd
On 2018-07-16 06:36 PM, Tom St Denis wrote:
> Will in a bit. I'm tracking down a KASAN oops that the tip of drm-next
> causes with unigine-heaven.
Is it different from the one I reported an hour ago?
https://lists.freedesktop.org/archives/amd-gfx/2018-July/024207.html
--
Earthling
{
> + DRM_ERROR("Trying to push to a killed entity\n");
This could result in spamming dmesg with this error message. I suggest
if (WARN_ON_ONCE(!entity->rq)) {
instead, no DRM_ERROR. That will produce a single warning with a backtrace.
--
Earthling
On 2018-07-17 09:59 AM, Christian König wrote:
> Am 17.07.2018 um 09:46 schrieb Michel Dänzer:
>> On 2018-07-17 09:33 AM, Christian König wrote:
>>> Am 17.07.2018 um 09:26 schrieb Michel Dänzer:
>>>> On 2018-07-17 08:50 AM, Christian König wrote:
>>>>>
On 2018-07-17 10:19 AM, Christian König wrote:
> Am 17.07.2018 um 10:03 schrieb Michel Dänzer:
>> On 2018-07-17 09:59 AM, Christian König wrote:
>>> Am 17.07.2018 um 09:46 schrieb Michel Dänzer:
>>>> On 2018-07-17 09:33 AM, Christian König wrote:
>>>>>
On 2018-07-16 08:51 PM, Marek Olšák wrote:
> On Mon, Jul 16, 2018 at 12:05 PM, Michel Dänzer wrote:
>> On 2018-07-13 08:47 PM, Marek Olšák wrote:
>>> On Fri, Jul 13, 2018 at 4:28 AM, Michel Dänzer wrote:
>>
>>>> I'd rather add the handle
On 2018-07-17 08:50 AM, Christian König wrote:
> Am 16.07.2018 um 18:05 schrieb Michel Dänzer:
>> On 2018-07-13 08:47 PM, Marek Olšák wrote:
>>> On Fri, Jul 13, 2018 at 4:28 AM, Michel Dänzer
>>> wrote:
>>>> On 2018-07-12 07:03 PM, Marek Olšák wrote:
>
On 2018-07-17 09:33 AM, Christian König wrote:
> Am 17.07.2018 um 09:26 schrieb Michel Dänzer:
>> On 2018-07-17 08:50 AM, Christian König wrote:
>>> Am 16.07.2018 um 18:05 schrieb Michel Dänzer:
>>>> On 2018-07-13 08:47 PM, Marek Olšák wrote:
>>>> [S
From: Michel Dänzer
Instead of strncpy with the string length. Avoids new warnings with GCC
8:
../../src/drmmode_display.c: In function ‘drmmode_output_create_resources’:
../../src/drmmode_display.c:2240:2: warning: ‘strncpy’ output truncated before
terminating nul copying 8 bytes from
From: Michel Dänzer
The RandR screen private is already freed when our CloseScreen runs, so
this can't do anything useful. This cleanup has to be done by the X
server itself.
(Ported from amdgpu commit 5f06d6b8ba570b500956ad26fee711d5ac427818)
Signed-off-by: Michel Dänzer
---
src
On 2018-07-19 05:39 PM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> The warning turned out to be not so useful, as BO destruction tends to
> be deferred to a workqueue.
>
> Also, we should be preventing any damage from this now, so not really
> important anym
From: Michel Dänzer
It's a bit silly to require current randrproto just for this definition,
which can't really change anyway.
Suggested-by: Qiang Yu
(Ported from amdgpu commit ae8e02c6fc4ef5d5340b8cd4739e66b19b9e3386)
Signed-off-by: Michel Dänzer
---
configure.ac | 2 +-
src
looks great, thanks. With a rationale added to the
commit log,
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx m
From: Michel Dänzer
We don't need it.
Signed-off-by: Michel Dänzer
---
src/drmmode_display.c | 39 +++
1 file changed, 11 insertions(+), 28 deletions(-)
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index e947ca979..bf8b1a8b6 100644
--- a/src
me(adev);
>
> -
> r = amdgpu_device_ip_late_init(adev);
> if (r)
> goto unlock;
Drop this hunk.
With the above fixed,
Reviewed-by: Michel Dänzer
Possible follow-up work:
* Move the console_(un)lock calls into amdgpu_fbdev_set_suspend, or
maybe use drm_fb_help
v_set_suspend after pci_set_power_state
> V3: Updated the commit message to clarify the real concern that this patch
> addresses.
> Signed-off-by: Shirish S
> Reviewed-by: Michel Dänzer
>
> [...]
>
> drm_kms_helper_poll_enable(dev);
> @@ -2808,13 +2808,7
From: Michel Dänzer
We were leaking it.
Also, don't bother allocating new memory if it's already the expected
size.
Signed-off-by: Michel Dänzer
---
src/drmmode_display.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
From: Michel Dänzer
The warning turned out to be not so useful, as BO destruction tends to
be deferred to a workqueue.
Also, we should be preventing any damage from this now, so not really
important anymore to fix code doing this.
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/amd/amdgpu
e gets suspended too, so you have to embed another
> eviction in between, after display is suspended but before
> SDMA and this forces ordering between them which kind of already in
> place (amd_ip_block_type) but still it's an extra constrain.
Ville's point (which I basically ag
v_set_suspend after pci_set_power_state
> V3: Updated the commit message to clarify the real concern that this patch
> addresses.
> V4: code clean-up.
> V5: fixed return value
>
> Signed-off-by: Shirish S
> Reviewed-by: Michel Dänzer
In the future, please mark which rev
gt; +T: git git://people.freedesktop.org/~agd5f/linux
> +S: Supported
> +F: drivers/gpu/drm/amd/display/
> +
> AMD FAM15H PROCESSOR POWER MONITORING DRIVER
> M: Huang Rui
> L: linux-hw...@vger.kernel.org
>
Reviewed-by: Michel Dänzer
--
Earthling Michel
From: Michel Dänzer
We always destroy the fbcon pixmap in drmmode_copy_fb anyway.
Signed-off-by: Michel Dänzer
---
src/amdgpu_drv.h | 1 -
src/amdgpu_kms.c | 3 ---
src/drmmode_display.c | 13 ++---
3 files changed, 2 insertions(+), 15 deletions(-)
diff --git a/src
On 2018-07-19 06:53 PM, Andrey Grodzovsky wrote:
>
>
> On 07/19/2018 12:47 PM, Michel Dänzer wrote:
>> On 2018-07-19 06:33 PM, Andrey Grodzovsky wrote:
>>> On 07/19/2018 11:39 AM, Ville Syrjälä wrote:
>>>> On Thu, Jul 19, 2018 at 11:19:56AM -0400, Andrey Grodz
DWARF4 is not set
CONFIG_UNWINDER_ORC=y
# CONFIG_UNWINDER_FRAME_POINTER is not set
# CONFIG_UNWINDER_GUESS is not set
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
__
of memory condition in
amdgpu_cs_ioctl, but before this change that was handled gracefully.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
Jul 16 17:35:32 kaveri kernel: [ 97.203039] [drm:amdgpu
On 2018-07-13 08:47 PM, Marek Olšák wrote:
> On Fri, Jul 13, 2018 at 4:28 AM, Michel Dänzer wrote:
>> On 2018-07-12 07:03 PM, Marek Olšák wrote:
>>> On Thu, Jul 12, 2018, 3:31 AM Michel Dänzer wrote:
>>>>
>>>> What is the rationale for this? I.e. why
From: Michel Dänzer
Not doing this resulted in falling back to software for DRI3 client
presentation operations with ShadowPrimary.
Signed-off-by: Michel Dänzer
---
src/amdgpu_dri3.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/amdgpu_dri3.c b/src/amdgpu_dri3.c
index 87e3d85c1
On 2018-07-24 02:47 PM, Christian König wrote:
> Am 23.07.2018 um 18:50 schrieb Michel Dänzer:
>> On 2018-07-19 05:39 PM, Michel Dänzer wrote:
>>> From: Michel Dänzer
>>>
>>> The warning turned out to be not so useful, as BO destruction tends to
>>>
From: Michel Dänzer
Instead of strncpy with the string length. Avoids new warnings with GCC
8:
../../src/drmmode_display.c: In function ‘drmmode_output_create_resources’:
../../src/drmmode_display.c:2240:2: warning: ‘strncpy’ output truncated before
terminating nul copying 8 bytes from
From: Michel Dänzer
This is a more robust way to prevent hangs due to nested calls to
drmHandleEvent.
Signed-off-by: Michel Dänzer
---
src/amdgpu_drm_queue.c | 124 +
src/amdgpu_drm_queue.h | 1 +
src/drmmode_display.c | 18 --
src
From: Michel Dänzer
Replacing the drmmode_crtc_wait_pending_event macro.
Signed-off-by: Michel Dänzer
---
src/amdgpu_drm_queue.c | 13 +
src/amdgpu_drm_queue.h | 1 +
src/drmmode_display.c | 22 --
3 files changed, 18 insertions(+), 18 deletions(-)
diff
From: Michel Dänzer
And make amdgpu_drm_queue_handler not directly accessible outside of
amdgpu_drm_queue.c.
Signed-off-by: Michel Dänzer
---
src/amdgpu_dri2.c | 14 --
src/amdgpu_drm_queue.c | 11 +--
src/amdgpu_drm_queue.h | 5 +
src/amdgpu_kms.c | 2
On 2018-07-24 07:20 PM, Paul Menzel wrote:
> On 07/20/18 18:33, Michel Dänzer wrote:
>> From: Michel Dänzer
>>
>> We were testing the register offset, instead of the value stored in the
>> register, therefore always timing out the loop.
>>
>> This reduce
From: Michel Dänzer
Allowing CONFIG_DRM_AMD_DC_DCN1_0 to be disabled on X86 was an
opportunity for display with Raven Ridge accidentally not working.
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 2 +-
drivers/gpu/drm/amd/display/Kconfig | 8
From: Michel Dänzer
We continued using the stale cached handle, causing issues e.g. when
resizing the screen via RandR.
Reported-by: iive on IRC
Signed-off-by: Michel Dänzer
---
src/radeon.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/radeon.h b/src/radeon.h
index 450c69aa8
dev->fd = dup(fd);
> + dev->fd = fcntl(fd, F_DUPFD_CLOEXEC, 0);
> dev->flink_fd = dev->fd;
> dev->major_version = version->version_major;
> dev->minor_version = version->version_minor;
>
Nice catch.
R
From: Michel Dänzer
(Ported from radeon commit de88ea2755611bdcb18d91d8234d2ab5be8ff2e9)
Signed-off-by: Michel Dänzer
---
src/amdgpu_glamor.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/amdgpu_glamor.c b/src/amdgpu_glamor.c
index 13d68fe36..699861f73 100644
On 2018-08-29 10:57 a.m., Christian König wrote:
> Am 29.08.2018 um 09:52 schrieb Michel Dänzer:
>> On 2018-08-28 7:03 p.m., Michel Dänzer wrote:
>>> On 2018-08-28 11:14 a.m., Michel Dänzer wrote:
>>>> On 2018-08-22 9:52 a.m., Huang Rui wrote:
>>>>&g
From: Michel Dänzer
It means to stop using the shared pixmap backing.
(Ported from radeon commit 1799680f7bd84e0618f34f4c7486799521ddaf83)
Signed-off-by: Michel Dänzer
---
src/amdgpu_bo_helper.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/amdgpu_bo_helper.c b/src
From: Michel Dänzer
drm_wait_pending_flip can get called from drm_handle_event, in which
case xorg_list_for_each_entry_safe can end up processing the same entry
in both. To avoid this, just process the first list entry until the list
is empty.
Signed-off-by: Michel Dänzer
---
src
From: Michel Dänzer
We left entries without a handler hook in the list, so the list could
keep taking longer to process and use up more memory.
Signed-off-by: Michel Dänzer
---
src/amdgpu_drm_queue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/amdgpu_drm_queue.c b
From: Michel Dänzer
No need to process any events in that case.
Signed-off-by: Michel Dänzer
---
src/amdgpu_drm_queue.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/amdgpu_drm_queue.c b/src/amdgpu_drm_queue.c
index ba841d1ef..61732b11c 100644
--- a/src/amdgpu_drm_queue.c
+++ b
tion(, , list);
So the problem was that the first list_cut_position call could result in
list2 pointing to la-la-land? Good catch!
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
From: Michel Dänzer
Fixes server reset.
Pointed out by clang:
../../src/radeon_kms.c:2721:9: warning: variable 'pitch' is used uninitialized
whenever 'if' condition is false [-Wsometimes-uninitialized]
if (!info->front_buffer) {
^~~
../../src/radeon_kms.c:2765
From: Michel Dänzer
No need to process any events in that case.
v2:
* Re-check drmmode_crtc->flip_pending after processing each event
Signed-off-by: Michel Dänzer
---
src/amdgpu_drm_queue.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/amdgpu_drm_queue.c b/
From: Michel Dänzer
drm_wait_pending_flip can get called from drm_handle_event, in which
case xorg_list_for_each_entry_safe can end up processing the same entry
in both. To avoid this, just process the first list entry until the list
is empty.
(Ported from amdgpu commit
From: Michel Dänzer
We left entries without a handler hook in the list, so the list could
keep taking longer to process and use up more memory.
(Ported from amdgpu commit 7eea3e2cd74eed22e982319144e18ae5b1087b78)
Signed-off-by: Michel Dänzer
---
src/radeon_drm_queue.c | 2 +-
1 file changed
From: Michel Dänzer
No need to process any events in that case.
(Ported from amdgpu commit ca5eb9894fff153c0a1df7bdc4a4745713309e27)
Signed-off-by: Michel Dänzer
---
src/radeon_drm_queue.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/radeon_drm_queue.c b/src
ter
> + * @adev: drm device pointer
> * @pasid: PASID identifier for VM
> * @task_info: task_info to fill.
> */
>
Queued in the amdgpu tree (with fixed spelling of "warnings"), thanks!
--
Earthling Michel Dänzer
q=8322, emitted seq=8325
> [drm] GPU recovery disabled.
>
> I tested that it doesn't happen with 4.17.14 kernel.
Can you bisect between 4.17 and 4.18?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast |
;
(How) were you able to actually trigger this condition in practice? The
only way I could imagine is via drmmode_output_set_property, in which
case I think it would be better to guard all the *cm_* related code
there with
if (drmmode_cm_enabled(drmmode_output->drmmode)) {
...
From: Michel Dänzer
The crtc->gamma_lut values aren't initialized yet at this point, and
the property values are pushed again from drmmode_setup_colormap
anyway.
Fixes intermittent flicker due to random gamma LUT values during server
startup.
Signed-off-by: Michel Dänzer
---
ay, with this patch, the attached warning dumps appear in dmesg
about 1000 times per second at the GDM login prompt, can't even attempt
to run piglit. Something else is needed, I'm afraid.
In case it's relevant, note that my development machine has a secondary
Turks card install
*buf_handle = NULL;
> *offset_in_bo = 0;
> + r = -EINVAL;
I think -ENOENT would be better, to differentiate this error from
passing invalid pointer / size parameters.
With that,
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer |
ring when userspace sets AMDGPU_GEM_CREATE_VRAM_CLEARED
would break the userspace ABI, so that's no go.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
__
On 2018-09-11 9:46 a.m., Christian König wrote:
> Am 11.09.2018 um 09:37 schrieb Michel Dänzer:
>> On 2018-09-11 8:49 a.m., Christian König wrote:
>>> But another question: Why do you want to clear VRAM on allocation? We
>>> perfectly support allocating VRAM wi
On 2018-09-11 10:20 a.m., Christian König wrote:
> Am 11.09.2018 um 09:55 schrieb Michel Dänzer:
>> On 2018-09-11 9:46 a.m., Christian König wrote:
>>> Am 11.09.2018 um 09:37 schrieb Michel Dänzer:
>>>> On 2018-09-11 8:49 a.m., Christian König wrote:
>>>&
On 2018-09-10 5:58 p.m., Michel Dänzer wrote:
> On 2018-09-10 1:14 p.m., Aaron Liu wrote:
>> Add gamma_lut/degamma_lut/ctm checking before pushing
>> staged color management properties on the CRTC.
>> If above object is NULL, return directly.
>
> (How) were y
ernally by kernel clients, including gfx,
> - * uvd, etc. for kernel managed allocations used by the GPU.
> - *
> - */
This comment shouldn't be removed, should it? Otherwise the commit log
needs to explain this, and the reference in Documentation/gpu/amdgpu.rst
needs to be removed as well.
--
Earthling Michel
kvcalloc(MAX_HW_POINTS + _EXTRA_POINTS,
> +sizeof(*rgb_degamma),
> GFP_KERNEL);
> if (!rgb_degamma)
> goto rgb_degamma_alloc_fail;
>
Since the values are constant, kvcalloc incurs the overflow checking
o
ionality that's
> currently split across both modules, such as suspend/resume, memory
> management and evictions.
>
> Some interfaces that just query information from amdgpu could be removed
> if KFD can access that information directly (e.g. firmware versions, CU
> info,
From: Michel Dänzer
No functional change intended.
Signed-off-by: Michel Dänzer
---
src/drmmode_display.c | 2 ++
src/radeon_kms.c | 8 +---
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index c7bec59c8..54b09730d 100644
From: Michel Dänzer
Not used with older GPUs.
Signed-off-by: Michel Dänzer
---
src/drmmode_display.c | 5 +++--
src/radeon_bo_helper.c | 7 ---
src/radeon_kms.c | 18 +++---
3 files changed, 18 insertions(+), 12 deletions(-)
diff --git a/src/drmmode_display.c b/src
From: Michel Dänzer
Signed-off-by: Michel Dänzer
---
src/drmmode_display.c | 66 +---
src/radeon.h | 5 +
src/radeon_bo_helper.c | 231 +
src/radeon_kms.c | 35 +--
4 files changed, 131 insertions(+), 206 deletions
From: Michel Dänzer
Only EXA needs them.
Signed-off-by: Michel Dänzer
---
src/drmmode_display.c | 77 +-
src/radeon.h | 19 ++-
src/radeon_bo_helper.c | 22 +---
src/radeon_glamor.c| 8 ++---
src/radeon_kms.c | 11
From: Michel Dänzer
Inspired by amdgpu, preparation for the following change. For now, this
is mostly a wrapper around struct radeon_bo, no functional change
intended.
Signed-off-by: Michel Dänzer
---
src/drmmode_display.c | 123 ++--
src
From: Michel Dänzer
Signed-off-by: Michel Dänzer
---
src/drmmode_display.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index f056bf3b4..958532fb6 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
From: Michel Dänzer
Not used by any supported version of xserver.
Signed-off-by: Michel Dänzer
---
src/evergreen_exa.c| 1 -
src/evergreen_state.h | 1 -
src/r600_exa.c | 1 -
src/r600_state.h | 1 -
src/radeon_exa.c | 29 -
src
From: Jammy Zhou
Throttling should be handled by the client-side drivers.
Signed-off-by: Jammy Zhou
(Ported from amdgpu commit 8a34a8149860ac15e83ccdbd8d9a527d8d3e5997)
Signed-off-by: Michel Dänzer
---
src/radeon_dri2.c | 22 --
1 file changed, 22 deletions(-)
diff --git
From: Michel Dänzer
This series addresses https://bugs.freedesktop.org/105381 and is mostly
inspired by the amdgpu driver.
Patches 1 & 2 clean up things I noticed being unused while working on
this series.
Patches 3-5 are struct radeon_surface related cleanups.
Patches 6-8 are flush/fi
From: Michel Dänzer
Inspired by amdgpu. This avoids various issues due to a GEM handle
lifetime conflict between us and Mesa with current glamor.
Bugzilla: https://bugs.freedesktop.org/105381
Signed-off-by: Michel Dänzer
---
configure.ac | 10
src/Makefile.am| 4
From: Michel Dänzer
Signed-off-by: Michel Dänzer
---
src/drmmode_display.c| 16 +++-
src/radeon.h | 1 +
src/radeon_bo_helper.c | 10 ++
src/radeon_bo_helper.h | 3 +++
src/radeon_glamor_wrappers.c | 21 ++---
src
der += (uint64_t)
> - (5 * calc_pll_cs->fract_fb_divider_precision_factor);
> + feedback_divider += 5UL *
> + calc_pll_cs->fract_fb_divider_precision_factor;
This should be 5ULL, as the commit log says, otherwise it's still only
32 bits on 32-bit platforms.
On 2018-07-04 08:55 AM, Zhang, Jerry (Junwei) wrote:
> On 07/04/2018 02:34 PM, Christian König wrote:
>> Am 04.07.2018 um 05:02 schrieb Junwei Zhang:
>>> From: Michel Dänzer
>>>
>>> Without this, there could not be enough slots
On 2018-07-04 10:31 AM, Christian König wrote:
> Am 26.06.2018 um 16:31 schrieb Michel Dänzer:
>> From: Michel Dänzer
>>
>> Fixes the BUG_ON spuriously triggering under the following
>> circumstances:
>>
>> * ttm_eu_reserve_buffers processes a list conta
1001 - 1100 of 1904 matches
Mail list logo