On Mon, 23 Jul 2018 22:53:08 +0200,
Alex Deucher wrote:
>
> On Mon, Jul 23, 2018 at 10:50 AM, Takashi Iwai wrote:
> > Hi,
> >
> > this is a patch set to add the support of drm_audio_component for
> > AMD/ATI HDMI codecs. With the drm_audio_component, the HDMI/DP audio
> > hotplug and ELD read-ou
This patch moves amdgpu_fbdev_set_suspend() to the beginning
of suspend sequence.
This is to ensure fbcon does not to write to the VRAM
after GPU is powerd down.
Signed-off-by: Shirish S
Reviewed-by: Michel Dänzer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 6 +++---
1 file changed, 3 ins
Properly handle cases where one or more instance of the IP
block may be harvested.
v2: make sure ip_num_rings is initialized amdgpu_queue_mgr.c
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 10 -
drivers/gpu/drm/amd/amdgpu/amdgpu_queue_mgr.c | 13 +--
d
On Mon, Jul 23, 2018 at 10:50 AM, Takashi Iwai wrote:
> Hi,
>
> this is a patch set to add the support of drm_audio_component for
> AMD/ATI HDMI codecs. With the drm_audio_component, the HDMI/DP audio
> hotplug and ELD read-out can be achieved directly without the hardware
> access. The best poi
Properly handle cases where one or more instance of the IP
block may be harvested.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 10 -
drivers/gpu/drm/amd/amdgpu/amdgpu_queue_mgr.c | 13 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 11 +-
driv
On 2018-07-19 02:51 PM, Alex Deucher wrote:
On Wed, Jul 18, 2018 at 4:39 PM, wrote:
From: Boyuan Zhang
Enable system interrupt for jrbc during engine starting time.
Signed-off-by: Boyuan Zhang
---
drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c | 8 +++-
1 file changed, 7 insertions(+), 1 d
Hi
I was hitting this
Feel free to add my tested by
Tested-by: Mike Lothian
Cheers
Mike
On Mon, 23 Jul 2018 at 17:50 Michel Dänzer wrote:
> 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
>
On Mon, Jul 23, 2018 at 12:50 PM, Michel Dänzer wrote:
> 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
On Mon, Jul 23, 2018 at 12:56 PM, Michel Dänzer wrote:
> 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 5f06d6b8ba570b500956ad26fe
idx can be indirectly controlled by user-space, hence leading to a
potential exploitation of the Spectre variant 1 vulnerability.
This issue was detected with the help of Smatch:
drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c:408 amdgpu_set_pp_force_state()
warn: potential spectre issue 'data.states'
Fi
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/drmmode_disp
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 anymore to fix code doing this.
>
> S
Reviewed-by: Slava Abramov
From: amd-gfx on behalf of Michel
Dänzer
Sent: Monday, July 23, 2018 12:45:11 PM
To: amd-gfx@lists.freedesktop.org
Subject: [PATCH xf86-video-amdgpu] Use strcpy for RandR output property names
From: Michel Dänzer
Instead of strncpy
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 a string
On Mon, Jul 23, 2018 at 11:14 AM, Christian König
wrote:
> We are going to need that for the second UVD instance on Vega20.
>
> Signed-off-by: Christian König
A couple of nits below. Patches 1, 2, 4 are:
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
> dri
On Mon, Jul 23, 2018 at 5:04 AM, Michel Dänzer wrote:
> 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)
>
> Signe
We are going to need that for the second UVD instance on Vega20.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 22 +++---
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 1 +
3 files changed, 17 insertio
Patch the IBs for the second UVD instance so that userspace don't need
to care about the instance they submit to.
v2: use direct IB patching
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/
Going to completely rework the context to ring mapping with Nayan's GSoC
work, but for now just stopping to expose the second UVD instance should
do it.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 13 +
drivers/gpu/drm/amd/amdgpu/amdgpu_queue_mg
No need to bitcast a boolean and even if we should use "!!" instead.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
b/drivers/gpu/drm/am
cik_pcie_gen3_enable() is only called by cik_common_hw_init(), which is
never called in atomic context.
cik_pcie_gen3_enable() calls mdelay() to busily wait, which is not
necessary.
mdelay() can be replaced with msleep().
This is found by a static analysis tool named DCNS written by myself.
Signe
AMD/ATI HDMI codec drivers didn't have the audio component binding
like i915, but it worked only with the traditional HD-audio
unsolicited event for the HDMI hotplug detection and the ELD read-up
thereafter. This has been a problem in many ways: first of all, it
goes through the hardware event tra
Hi,
this is a patch set to add the support of drm_audio_component for
AMD/ATI HDMI codecs. With the drm_audio_component, the HDMI/DP audio
hotplug and ELD read-out can be achieved directly without the hardware
access. The best point by that is that it makes the hotplug
notification working even
Instead of calling mutex_unlock() at each error path multiple times,
take the standard goto-and-a-single-unlock approach. This will
simplify the code and make easier to find the unbalanced mutex locks.
No functional changes, but only the code readability improvement as a
preliminary work for furt
This patch introduces the HDMI audio component binding like what i915
does to amdgpu driver. Unlike i915, we need only the hotplug
notification and the ELD query, hence the code is relatively simple,
just adding the hook at each *_audio_enable() call and giving the eld
query by copying the connect
This patch introduces the HDMI audio component binding like what i915
does to radeon driver. Unlike i915, we need only the hotplug
notification and the ELD query, hence the code is relatively simple,
just adding the hook at radeon_audio_enable() and giving the eld query
by copying the connector->e
Acked-by: Alex Deucher
From: amd-gfx on behalf of Evan Quan
Sent: Monday, July 23, 2018 2:37:46 AM
To: amd-gfx@lists.freedesktop.org
Cc: Quan, Evan; Zhu, Rex
Subject: [PATCH] drm/amd/powerplay: allow slow switch only if NBPState enabled
v2
Otherwise there may
On 2018-07-23 12:06 PM, Shirish S wrote:
> This patch moves amdgpu_fbdev_set_suspend() to the beginning
> of suspend sequence.
Would be nice to have some rationale, e.g.:
This is to avoid fbcon trying to write to the GPU's memory when the GPU
is already powered down.
Other than that looks gr
This patch moves amdgpu_fbdev_set_suspend() to the beginning
of suspend sequence.
Signed-off-by: Shirish S
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/a
On 07/20/2018 11:47 PM, Andrey Grodzovsky wrote:
Problem:
amdgpu_ttm_set_buffer_funcs_status destroys adev->mman.entity on suspend
without releasing adev->mman.bdev.man[TTM_PL_VRAM].move fence
so on resume the new drm_sched_entity.fence_context causes
the warning against the old fence context whi
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/drmmod
On Fri 20-07-18 16:01:25, Andrew Morton wrote:
> On Tue, 17 Jul 2018 10:12:01 +0200 Michal Hocko wrote:
>
> > > Any suggestions regarding how the driver developers can test this code
> > > path? I don't think we presently have a way to fake an oom-killing
> > > event? Perhaps we should add such
On Mon 23-07-18 09:11:54, Michal Hocko wrote:
> On Mon 23-07-18 09:03:06, Michal Hocko wrote:
> > On Fri 20-07-18 17:09:02, Andrew Morton wrote:
> > [...]
> > > Please take a look?
> >
> > Are you OK to have these in a separate patch?
>
> Btw. I will rebase this patch once oom stuff in linux-next
On Mon, 16 Jul 2018 13:50:58 +0200 Michal Hocko wrote:
> From: Michal Hocko
>
> There are several blockable mmu notifiers which might sleep in
> mmu_notifier_invalidate_range_start and that is a problem for the
> oom_reaper because it needs to guarantee a forward progress so it cannot
> depend
On Tue, 17 Jul 2018 10:12:01 +0200 Michal Hocko wrote:
> > Any suggestions regarding how the driver developers can test this code
> > path? I don't think we presently have a way to fake an oom-killing
> > event? Perhaps we should add such a thing, given the problems we're
> > having with that f
On Mon 23-07-18 09:03:06, Michal Hocko wrote:
> On Fri 20-07-18 17:09:02, Andrew Morton wrote:
> [...]
> > Please take a look?
>
> Are you OK to have these in a separate patch?
Btw. I will rebase this patch once oom stuff in linux-next settles. At
least oom_lock removal from oom_reaper will confl
On Fri 20-07-18 17:09:02, Andrew Morton wrote:
[...]
> Please take a look?
Are you OK to have these in a separate patch?
--
Michal Hocko
SUSE Labs
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd
37 matches
Mail list logo
