On Tue, Jan 08, 2019 at 07:35:04PM -0500, Lyude Paul wrote:
> While this isn't a complete fix, this will improve the reliability of
> drm_dp_get_last_connected_port_and_mstb() pretty significantly during
> hotplug events, since there's a chance that the in-memory topology tree
> may not be fully
On Tue, Jan 08, 2019 at 07:35:05PM -0500, Lyude Paul wrote:
> This has never actually worked, and isn't needed anyway: the driver's
> always going to try to deallocate VCPI when it tears down the display
> that the VCPI belongs to.
>
> Signed-off-by: Lyude Paul
> Reviewed-by: Harry Wentland
>
On 2019-01-09 10:12 p.m., Mikhail Gavrilov wrote:
> On Thu, 10 Jan 2019 at 01:35, Grodzovsky, Andrey
> wrote:
>>
>> I think the 'verbose' flag causes it do dump so much output, maybe try
>> without it in ALL the commands above.
>> Are you are aware of any particular application during which run
Am 10.01.19 um 00:39 schrieb Marek Olšák:
On Wed, Jan 9, 2019 at 1:41 PM Christian König
mailto:ckoenig.leichtzumer...@gmail.com>>
wrote:
Am 09.01.19 um 17:14 schrieb Marek Olšák:
On Wed, Jan 9, 2019 at 8:09 AM Christian König
mailto:ckoenig.leichtzumer...@gmail.com>>
wrote:
Am 09.01.19 um
On Thu, Jan 10, 2019 at 11:59 AM Christian König <
ckoenig.leichtzumer...@gmail.com> wrote:
> The PCI Express controller as instantiated on this chip does not support
> hardware coherency. All incoming PCI Express transactions are made non
> IO-coherent.
>
> Would AMDGPU still work with that PCI
Am 10.01.19 um 14:57 schrieb Christoph Hellwig:
On Thu, Jan 10, 2019 at 10:59:02AM +0100, Michel Dänzer wrote:
Hi Christoph,
https://bugs.freedesktop.org/109234 (please ignore comments #6-#9) was
bisected to your commit 55897af63091 "dma-direct: merge swiotlb_dma_ops
into the dma_direct
On Tue, Jan 08, 2019 at 07:35:03PM -0500, Lyude Paul wrote:
> The current way of handling refcounting in the DP MST helpers is really
> confusing and probably just plain wrong because it's been hacked up many
> times over the years without anyone actually going over the code and
> seeing if things
On Tue, Jan 08, 2019 at 07:35:14PM -0500, Lyude Paul wrote:
> Changes since v6:
> - Move EXPORT_SYMBOL() for drm_dp_mst_topology_state_funcs to this
>commit
> - Document __drm_dp_mst_state_iter_get() and note that it shouldn't be
>called directly
>
> Signed-off-by: Lyude Paul
>
On Tue, Jan 08, 2019 at 07:35:15PM -0500, Lyude Paul wrote:
> There has been a TODO waiting for quite a long time in
> drm_dp_mst_topology.c:
>
> /* We cannot rely on port->vcpi.num_slots to update
>* topology_state->avail_slots as the port may not exist if the parent
>*
On Tue, Jan 08, 2019 at 07:35:16PM -0500, Lyude Paul wrote:
> It occurred to me that we never actually check this! So let's start
> doing that.
>
> Signed-off-by: Lyude Paul
> Reviewed-by: Daniel Vetter
> Cc: David Airlie
> Cc: Jerry Zuo
> Cc: Harry Wentland
> Cc: Juston Li
Reviewed-by:
Am 10.01.19 um 14:31 schrieb Bas Vermeulen:
On Thu, Jan 10, 2019 at 11:59 AM Christian König
mailto:ckoenig.leichtzumer...@gmail.com>>
wrote:
The PCI Express controller as instantiated on this chip does not support
hardware coherency. All incoming PCI Express transactions are made non
Signed-off-by: Alex Deucher
---
data/amdgpu.ids | 28 +++-
1 file changed, 19 insertions(+), 9 deletions(-)
diff --git a/data/amdgpu.ids b/data/amdgpu.ids
index 1828e410..d9ed5660 100644
--- a/data/amdgpu.ids
+++ b/data/amdgpu.ids
@@ -63,9 +63,12 @@
67DF, C7, AMD
allow driver do somethings when lru changed.
Change-Id: Ie82053da49272881d4b52b1c406f7c221a3fcadf
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/ttm/ttm_bo.c| 11 +++
include/drm/ttm/ttm_bo_driver.h | 9 +
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git
if lru is changed, we cannot do bulk moving.
Change-Id: Ide0fe920295cc25f7cabcf41a6400519e5783f2a
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 20
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 2 ++
On Thu, Jan 10, 2019 at 10:59:02AM +0100, Michel Dänzer wrote:
>
> Hi Christoph,
>
>
> https://bugs.freedesktop.org/109234 (please ignore comments #6-#9) was
> bisected to your commit 55897af63091 "dma-direct: merge swiotlb_dma_ops
> into the dma_direct code". Any ideas?
From the trace it
On Thu, Jan 10, 2019 at 6:21 AM Michel Dänzer wrote:
>
> From: Michel Dänzer
>
> It was at the same time too strict (for linear tiling modes, where no
> height alignment is required) and too lenient (for 2D tiling modes,
> where height may need to be aligned to values > 8).
>
> Signed-off-by:
From: Michel Dänzer
It was at the same time too strict (for linear tiling modes, where no
height alignment is required) and too lenient (for 2D tiling modes,
where height may need to be aligned to values > 8).
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 8
Hi,
after yesterday's fetch of amd-staging-drm-next tree from agd5f git repo my
xorg server is segfaulting when starting up.
I am using gentoo ~amd64, xorg-server 1.20.3, xf86-video-amdgpu-18.1.0.
Machine is an old Lenovo g50-45 netbook with A6-6310 APU - R4 Mullins.
- excerpt from Xorg.log:
On Thu, 10 Jan 2019 at 13:54, Michel Dänzer wrote:
>
> Assuming that's using DXVK, it could be an issue between DXVK and RADV.
> I'd start by filing a bug report against RADV.
>
In the case of the last report, I agree it makes sense.
But from the beginning I started this discussion because "*
On 2019-01-10 10:42 a.m., Mikhail Gavrilov wrote:
> On Thu, 10 Jan 2019 at 13:54, Michel Dänzer wrote:
>>
>> Assuming that's using DXVK, it could be an issue between DXVK and RADV.
>> I'd start by filing a bug report against RADV.
>
> In the case of the last report, I agree it makes sense.
> But
Am 10.01.19 um 12:41 schrieb Marek Olšák:
On Thu, Jan 10, 2019, 4:15 AM Koenig, Christian
mailto:christian.koe...@amd.com> wrote:
Am 10.01.19 um 00:39 schrieb Marek Olšák:
On Wed, Jan 9, 2019 at 1:41 PM Christian König
mailto:ckoenig.leichtzumer...@gmail.com>> wrote:
Hi Christoph,
https://bugs.freedesktop.org/109234 (please ignore comments #6-#9) was
bisected to your commit 55897af63091 "dma-direct: merge swiotlb_dma_ops
into the dma_direct code". Any ideas?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software
The PCI Express controller as instantiated on this chip does not
support hardware coherency. All incoming PCI Express transactions are
made non IO-coherent.
Would AMDGPU still work with that PCI Express controller, or is this a
show-stopper?
I'm really wondering what this comment in the
On Thu, Jan 10, 2019, 4:15 AM Koenig, Christian Am 10.01.19 um 00:39 schrieb Marek Olšák:
>
> On Wed, Jan 9, 2019 at 1:41 PM Christian König <
> ckoenig.leichtzumer...@gmail.com> wrote:
>
>> Am 09.01.19 um 17:14 schrieb Marek Olšák:
>>
>> On Wed, Jan 9, 2019 at 8:09 AM Christian König <
>>
Hi Alex,
I've managed to get a little further. I am currently running mainline
(5.0.0-rc1) and am getting the errors below.
Looking at the datasheet for the LS1012A, it mentions in the PCI Express
section that:
The PCI Express controller as instantiated on this chip does not support
hardware
On Thu, Jan 10, 2019, 6:51 AM Christian König <
ckoenig.leichtzumer...@gmail.com wrote:
> Am 10.01.19 um 12:41 schrieb Marek Olšák:
>
>
>
> On Thu, Jan 10, 2019, 4:15 AM Koenig, Christian wrote:
>
>> Am 10.01.19 um 00:39 schrieb Marek Olšák:
>>
>> On Wed, Jan 9, 2019 at 1:41 PM Christian König <
On 2019-01-10 10:44 a.m., Przemek Socha wrote:
> Hi,
> after yesterday's fetch of amd-staging-drm-next tree from agd5f git repo my
> xorg server is segfaulting when starting up.
>
> I am using gentoo ~amd64, xorg-server 1.20.3, xf86-video-amdgpu-18.1.0.
> Machine is an old Lenovo g50-45 netbook
On 2019-01-10 3:52 p.m., Chunming Zhou wrote:
> allow driver do somethings when lru changed.
>
> Change-Id: Ie82053da49272881d4b52b1c406f7c221a3fcadf
> Signed-off-by: Chunming Zhou
>
> [...]
>
> void ttm_bo_del_sub_from_lru(struct ttm_buffer_object *bo)
> diff --git
On Thu, 10 Jan 2019 at 14:57, Christoph Hellwig wrote:
>
> On Thu, Jan 10, 2019 at 10:59:02AM +0100, Michel Dänzer wrote:
> >
> > Hi Christoph,
> >
> >
> > https://bugs.freedesktop.org/109234 (please ignore comments #6-#9) was
> > bisected to your commit 55897af63091 "dma-direct: merge
On Thu, Jan 10, 2019 at 03:00:31PM +0100, Christian König wrote:
>> From the trace it looks like we git the case where swiotlb tries
>> to copy back data from a bounce buffer, but hits a dangling or NULL
>> pointer. So a couple questions for the submitter:
>>
>> - does the system have more
Just a ping.
Andrey
On 01/09/2019 10:18 AM, Andrey Grodzovsky wrote:
>
>
> On 01/09/2019 05:22 AM, Christian König wrote:
>> Am 07.01.19 um 20:47 schrieb Grodzovsky, Andrey:
>>>
>>> On 01/07/2019 09:13 AM, Christian König wrote:
Am 03.01.19 um 18:42 schrieb Grodzovsky, Andrey:
> On
On 2019-01-10 5:06 p.m., Przemek Socha wrote:
> Dnia czwartek, 10 stycznia 2019 12:25:01 CET piszesz:
>> On 2019-01-10 10:44 a.m., Przemek Socha wrote:
>>> Hi,
>>> after yesterday's fetch of amd-staging-drm-next tree from agd5f git repo
>>> my
>>> xorg server is segfaulting when starting up.
>>>
Dnia czwartek, 10 stycznia 2019 12:25:01 CET piszesz:
> On 2019-01-10 10:44 a.m., Przemek Socha wrote:
> > Hi,
> > after yesterday's fetch of amd-staging-drm-next tree from agd5f git repo
> > my
> > xorg server is segfaulting when starting up.
> >
> > I am using gentoo ~amd64, xorg-server 1.20.3,
On 2019-01-10 3:22 p.m., Alex Deucher wrote:
> Signed-off-by: Alex Deucher
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
On Thu, 10 Jan 2019 at 00:36, Mikhail Gavrilov
wrote:
>
> All new one logs attached here.
>
> Thanks.
>
> P.S. This time I had to terminate command `./umr -O verbose,follow -R
> gfx[.] > gfx.log 2>&1` cause it tried to write log infinitely.
> I also had to terminate command `./umr -O
Hi Mike,
This might be an issue better suited for our llvm team since umr just
uses llvm-dev to access the diassembly code.
I'll make sure the key folk are aware.
Cheers,
Tom
On 2019-01-10 10:22 a.m., Mikhail Gavrilov wrote:
> On Thu, 10 Jan 2019 at 00:36, Mikhail Gavrilov
> wrote:
>>
>>
Use HMM helper function hmm_vma_fault() to get physical pages backing
userptr and start CPU page table update track of those pages. Then use
hmm_vma_range_done() to check if those pages are updated before
amdgpu_cs_submit for gfx or before user queues are resumed for kfd.
If userptr pages are
On Thu, Jan 10, 2019 at 04:26:43PM +0100, Sibren Vasse wrote:
> On Thu, 10 Jan 2019 at 14:57, Christoph Hellwig wrote:
> >
> > On Thu, Jan 10, 2019 at 10:59:02AM +0100, Michel Dänzer wrote:
> > >
> > > Hi Christoph,
> > >
> > >
> > > https://bugs.freedesktop.org/109234 (please ignore comments
On Thu, 10 Jan 2019 at 18:06, Konrad Rzeszutek Wilk
wrote:
>
> On Thu, Jan 10, 2019 at 04:26:43PM +0100, Sibren Vasse wrote:
> > On Thu, 10 Jan 2019 at 14:57, Christoph Hellwig wrote:
> > >
> > > On Thu, Jan 10, 2019 at 10:59:02AM +0100, Michel Dänzer wrote:
> > > >
> > > > Hi Christoph,
> > > >
Replace our MMU notifier with hmm_mirror_ops.sync_cpu_device_pagetables
callback. Enable CONFIG_HMM and CONFIG_HMM_MIRROR as a dependency in
DRM_AMDGPU_USERPTR Kconfig.
It supports both KFD userptr and gfx userptr paths.
The depdent HMM patchset from Jérôme Glisse are all merged into 4.20.0
There is circular lock between gfx and kfd path with HMM change:
lock(dqm) -> bo::reserve -> amdgpu_mn_lock
To avoid this, move init/unint_mqd() out of lock(dqm), to remove nested
locking between mmap_sem and bo::reserve. The locking order
is: bo::reserve -> amdgpu_mn_lock(p->mn)
Change-Id:
Dnia czwartek, 10 stycznia 2019 17:22:07 CET piszesz:
> On 2019-01-10 5:06 p.m., Przemek Socha wrote:
> > Dnia czwartek, 10 stycznia 2019 12:25:01 CET piszesz:
> >> On 2019-01-10 10:44 a.m., Przemek Socha wrote:
> >>> Hi,
> >>> after yesterday's fetch of amd-staging-drm-next tree from agd5f git
On Thu, 10 Jan 2019 at 15:48, Christoph Hellwig wrote:
>
> On Thu, Jan 10, 2019 at 03:00:31PM +0100, Christian König wrote:
> >> From the trace it looks like we git the case where swiotlb tries
> >> to copy back data from a bounce buffer, but hits a dangling or NULL
> >> pointer. So a couple
Fix some indenting, split some stuff across multiple lines.
Signed-off-by: Lyude Paul
Reviewed-by: Harry Wentland
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
Trying to destroy the connector using mstc->connector.funcs->destroy()
if connector initialization fails is wrong: there is no possible
codepath in nv50_mstc_new where nv50_mstm_add_connector() would return
<0 and mstc would be non-NULL.
Signed-off-by: Lyude Paul
Cc: Daniel Vetter
Cc: David
Up until now, freeing payloads on remote MST hubs that just had ports
removed has almost never worked because we've been relying on port
validation in order to stop us from accessing ports that have already
been freed from memory, but ports which need their payloads released due
to being removed
s/drm_dp_get_validated_port_ref/drm_dp_mst_topology_get_port_validated/
s/drm_dp_put_port/drm_dp_mst_topology_put_port/
s/drm_dp_get_validated_mstb_ref/drm_dp_mst_topology_get_mstb_validated/
s/drm_dp_put_mst_branch_device/drm_dp_mst_topology_put_mstb/
This is a much more consistent naming
Split some stuff across multiple lines
Signed-off-by: Lyude Paul
Reviewed-by: Harry Wentland
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
While this isn't a complete fix, this will improve the reliability of
drm_dp_get_last_connected_port_and_mstb() pretty significantly during
hotplug events, since there's a chance that the in-memory topology tree
may not be fully updated when drm_dp_get_last_connected_port_and_mstb()
is called and
The current way of handling refcounting in the DP MST helpers is really
confusing and probably just plain wrong because it's been hacked up many
times over the years without anyone actually going over the code and
seeing if things could be simplified.
To the best of my understanding, the current
Split some stuff across multiple lines, remove some unnecessary braces
Signed-off-by: Lyude Paul
Reviewed-by: Harry Wentland
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 14 --
1 file changed, 8
This is the series I've been working on for a while now to get all of
the atomic DRM drivers in the tree to use the atomic MST helpers, and to
make the atomic MST helpers actually idempotent. Turns out it's a lot
more difficult to do that without also fixing how port and branch device
refcounting
Going through the currently programmed payloads isn't safe without
holding mgr->payload_lock, so actually do that and warn if anyone tries
calling nv50_msto_payload() in the future without grabbing the right
locks.
Signed-off-by: Lyude Paul
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc:
Reindent some stuff, and split some stuff across multiple lines so we
aren't going over the text width limit.
Signed-off-by: Lyude Paul
Reviewed-by: Harry Wentland
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 18
There is no need to look at the port's VCPI allocation before calling
drm_dp_mst_deallocate_vcpi(), as we already have msto->disabled to let
us avoid cleaning up an msto more then once. The DP MST core will never
call drm_dp_mst_deallocate_vcpi() on it's own, which is presumably what
these checks
This has never actually worked, and isn't needed anyway: the driver's
always going to try to deallocate VCPI when it tears down the display
that the VCPI belongs to.
Signed-off-by: Lyude Paul
Reviewed-by: Harry Wentland
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Juston Li
Just like i915 and nouveau, it's a good idea for us to hold a malloc
reference to the port here so that we never pass a freed pointer to any
of the DP MST helper functions.
Also, we stop unsetting aconnector->port in
dm_dp_destroy_mst_connector(). There's literally no point to that
assignment
So that the ports stay around until we've destroyed the connectors, in
order to ensure that we don't pass an invalid pointer to any MST helpers
once we introduce the new MST VCPI helpers.
Changes since v1:
* Move drm_dp_mst_get_port_malloc() to where we assign
intel_connector->port - danvet
There has been a TODO waiting for quite a long time in
drm_dp_mst_topology.c:
/* We cannot rely on port->vcpi.num_slots to update
* topology_state->avail_slots as the port may not exist if the parent
* branch device was unplugged. This should be fixed by tracking
Currently, nouveau uses the yolo method of setting up MST displays: it
uses the old VCPI helpers (drm_dp_find_vcpi_slots()) for computing the
display configuration. These helpers don't take care to make sure they
take a reference to the mstb port that they're checking, and
additionally don't
It occurred to me that we never actually check this! So let's start
doing that.
Signed-off-by: Lyude Paul
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 8 +++-
1 file changed, 7 insertions(+), 1
Changes since v6:
- Move EXPORT_SYMBOL() for drm_dp_mst_topology_state_funcs to this
commit
- Document __drm_dp_mst_state_iter_get() and note that it shouldn't be
called directly
Signed-off-by: Lyude Paul
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Same as we did for i915, but for nouveau this time. Additionally, we
grab a malloc reference to the port that lasts for the entire lifetime
of nv50_mstc, which gives us the guarantee that mstc->port will always
point to valid memory for as long as the mstc stays around.
Signed-off-by: Lyude Paul
Now that we finally have a sane way to keep port allocations around, use
it to fix the potential unchecked ->port accesses that nouveau makes by
making sure we keep the mst port allocated for as long as it's
drm_connector is accessible.
Additionally, now that we've guaranteed that mstc->port is
[Why]
This fixes a stuttering issue that occurs when moving a hardware cursor
when VRR is enabled.
Previously when VRR is enabled atomic check will grab the connector
state for every atomic update. This has to lock the connector in order
to do so. The locking is bad enough by itself for
Same as we did for i915, but for nouveau this time. Additionally, we
grab a malloc reference to the port that lasts for the entire lifetime
of nv50_mstc, which gives us the guarantee that mstc->port will always
point to valid memory for as long as the mstc stays around.
Signed-off-by: Lyude Paul
Currently, nouveau uses the yolo method of setting up MST displays: it
uses the old VCPI helpers (drm_dp_find_vcpi_slots()) for computing the
display configuration. These helpers don't take care to make sure they
take a reference to the mstb port that they're checking, and
additionally don't
Changes since v6:
- Move EXPORT_SYMBOL() for drm_dp_mst_topology_state_funcs to this
commit
- Document __drm_dp_mst_state_iter_get() and note that it shouldn't be
called directly
Signed-off-by: Lyude Paul
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Trying to destroy the connector using mstc->connector.funcs->destroy()
if connector initialization fails is wrong: there is no possible
codepath in nv50_mstc_new where nv50_mstm_add_connector() would return
<0 and mstc would be non-NULL.
Signed-off-by: Lyude Paul
Reviewed-By: Ben Skeggs
Cc:
It occurred to me that we never actually check this! So let's start
doing that.
Signed-off-by: Lyude Paul
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 8 +++-
1 file changed, 7 insertions(+), 1
There is no need to look at the port's VCPI allocation before calling
drm_dp_mst_deallocate_vcpi(), as we already have msto->disabled to let
us avoid cleaning up an msto more then once. The DP MST core will never
call drm_dp_mst_deallocate_vcpi() on it's own, which is presumably what
these checks
There has been a TODO waiting for quite a long time in
drm_dp_mst_topology.c:
/* We cannot rely on port->vcpi.num_slots to update
* topology_state->avail_slots as the port may not exist if the parent
* branch device was unplugged. This should be fixed by tracking
Going through the currently programmed payloads isn't safe without
holding mgr->payload_lock, so actually do that and warn if anyone tries
calling nv50_msto_payload() in the future without grabbing the right
locks.
Signed-off-by: Lyude Paul
Reviewed-By: Ben Skeggs
Cc: Daniel Vetter
Cc: David
Reviewed-by: Evan Quan
> -Original Message-
> From: amd-gfx On Behalf Of
> Kenneth Feng
> Sent: 2019年1月11日 12:46
> To: amd-gfx@lists.freedesktop.org
> Cc: Feng, Kenneth
> Subject: [PATCH] drm/amd/powerplay: run acg btc for Vega12
>
> acg btc was added to Vega12
>
> Signed-off-by:
acg btc was added to Vega12
Signed-off-by: Kenneth Feng
---
drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c
On Thu, 2019-01-10 at 16:18 -0500, Jerry (Fangzhi) Zuo wrote:
> MST has its unique sequence that may get failed due to no stream
> in atomic check in some cases, e.g., hotplug, S3 resume.
You might want to elaborate more here, e.g. what's the actual reason for MST
not having streams in the case
OK, I see your point. I originally found this issue that fails in dm_resume()
due to the crtc check failure (no stream but mode set required). I'll remove it.
Jerry
-Original Message-
From: Lyude Paul
Sent: January 10, 2019 4:26 PM
To: Zuo, Jerry ; amd-gfx@lists.freedesktop.org;
In MST S3 topology change, dc_sink is created in .get_mode hook
later than the resume sequence. No stream created in atomic check
is normal in MST S3 resume. In such case, mark false to
mode_changed flag to skip the check in
dm_crtc_helper_atomic_check(), instead of returning error.
JFYI: In the future patches like this should also be sent to
dri-de...@lists.freedesktop.org
Anyway, sorry but NAK
It's usually OK to set crtc_state->mode_changed = true, but it's never okay to
set it to false from atomic check code. This is because atomic helpers will
sometimes force modesets
While this isn't a complete fix, this will improve the reliability of
drm_dp_get_last_connected_port_and_mstb() pretty significantly during
hotplug events, since there's a chance that the in-memory topology tree
may not be fully updated when drm_dp_get_last_connected_port_and_mstb()
is called and
The current way of handling refcounting in the DP MST helpers is really
confusing and probably just plain wrong because it's been hacked up many
times over the years without anyone actually going over the code and
seeing if things could be simplified.
To the best of my understanding, the current
Now that we finally have a sane way to keep port allocations around, use
it to fix the potential unchecked ->port accesses that nouveau makes by
making sure we keep the mst port allocated for as long as it's
drm_connector is accessible.
Additionally, now that we've guaranteed that mstc->port is
This has never actually worked, and isn't needed anyway: the driver's
always going to try to deallocate VCPI when it tears down the display
that the VCPI belongs to.
Signed-off-by: Lyude Paul
Reviewed-by: Harry Wentland
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Juston Li
Fix some indenting, split some stuff across multiple lines.
Signed-off-by: Lyude Paul
Reviewed-by: Harry Wentland
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
Just like i915 and nouveau, it's a good idea for us to hold a malloc
reference to the port here so that we never pass a freed pointer to any
of the DP MST helper functions.
Also, we stop unsetting aconnector->port in
dm_dp_destroy_mst_connector(). There's literally no point to that
assignment
Split some stuff across multiple lines, remove some unnecessary braces
Signed-off-by: Lyude Paul
Reviewed-by: Harry Wentland
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 14 --
1 file changed, 8
So that the ports stay around until we've destroyed the connectors, in
order to ensure that we don't pass an invalid pointer to any MST helpers
once we introduce the new MST VCPI helpers.
Changes since v1:
* Move drm_dp_mst_get_port_malloc() to where we assign
intel_connector->port - danvet
Up until now, freeing payloads on remote MST hubs that just had ports
removed has almost never worked because we've been relying on port
validation in order to stop us from accessing ports that have already
been freed from memory, but ports which need their payloads released due
to being removed
Split some stuff across multiple lines
Signed-off-by: Lyude Paul
Reviewed-by: Harry Wentland
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
This is the series I've been working on for a while now to get all of
the atomic DRM drivers in the tree to use the atomic MST helpers, and to
make the atomic MST helpers actually idempotent. Turns out it's a lot
more difficult to do that without also fixing how port and branch device
refcounting
s/drm_dp_get_validated_port_ref/drm_dp_mst_topology_get_port_validated/
s/drm_dp_put_port/drm_dp_mst_topology_put_port/
s/drm_dp_get_validated_mstb_ref/drm_dp_mst_topology_get_mstb_validated/
s/drm_dp_put_mst_branch_device/drm_dp_mst_topology_put_mstb/
This is a much more consistent naming
Reindent some stuff, and split some stuff across multiple lines so we
aren't going over the text width limit.
Signed-off-by: Lyude Paul
Reviewed-by: Harry Wentland
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 18
MST has its unique sequence that may get failed due to no stream
in atomic check in some cases, e.g., hotplug, S3 resume.
Remove the ERROR message in the stream create routine, and leave
its caller to decide if additional action is required.
Signed-off-by: Jerry (Fangzhi) Zuo
---
For the nouveau patches in the series:
Reviewed-By: Ben Skeggs
On Fri, 11 Jan 2019 at 05:59, Lyude Paul wrote:
>
> This is the series I've been working on for a while now to get all of
> the atomic DRM drivers in the tree to use the atomic MST helpers, and to
> make the atomic MST helpers
Change-Id: I484ba66c2e6f20123e6004cb6671e6a6ee6cf27b
Signed-off-by: Jim Qu
Reviewed-by: Alex Deucher
Reviewed-by: Hawking Zhang
---
drivers/gpu/drm/amd/include/asic_reg/thm/thm_11_0_2_offset.h | 3 +++
1 file changed, 3 insertions(+)
diff --git
Change-Id: Ie2ecdb78114e4c319aba33fdc68713047417bc7b
Signed-off-by: Jim Qu
Reviewed-by: Alex Deucher
Reviewed-by: Hawking Zhang
---
drivers/gpu/drm/amd/include/asic_reg/nbio/nbio_7_4_offset.h | 2 ++
drivers/gpu/drm/amd/include/asic_reg/nbio/nbio_7_4_sh_mask.h | 3 +++
2 files changed, 5
Change-Id: I1e55db9e508f96353b1b2e6aa153e05962b9e7fe
Signed-off-by: Jim Qu
Reviewed-by: Alex Deucher
Reviewed-by: Hawking Zhang
---
drivers/gpu/drm/amd/powerplay/hwmgr/Makefile | 2 +-
.../gpu/drm/amd/powerplay/hwmgr/vega20_baco.c | 81 +++
Change-Id: Ib5f3afa6c2da4733e39373ce2a950b6ec63ccdff
Signed-off-by: Jim Qu
Reviewed-by: Alex Deucher
Reviewed-by: Hawking Zhang
---
drivers/gpu/drm/amd/powerplay/hwmgr/vega20_inc.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_inc.h
Jim Qu (5):
drm/amdgpu: update NBIO v7.4 to support BACO
drm/amdgpu: also include NBIO v7.4 register mask header
drm/amdgpu: update THM IP register header to support BACO
drm/amdgpu/powerper: add vega20 BACO functins
drm/amdgpu: use BACO reset on vega20 if platform support
Change-Id: I531fa83ccf4abf593194afd6ff0702ba1393d6c7
Signed-off-by: Jim Qu
Reviewed-by: Alex Deucher
Reviewed-by: Hawking Zhang
---
drivers/gpu/drm/amd/amdgpu/soc15.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/soc15.c
b/drivers/gpu/drm/amd/amdgpu/soc15.c
100 matches
Mail list logo
