Easy for maintainance.
Signed-off-by: Guchun Chen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
index
For very subtle mistakes with topology refs, it can be rather difficult
to trace them down with the debugging info that we already have. I had
one such issue recently while trying to implement suspend/resume
reprobing for MST, and ended up coming up with this.
Inspired by Chris Wilson's wakeref
Finally! For a very long time, our MST helpers have had one very
annoying issue: They don't know how to reprobe the topology state when
coming out of suspend. This means that if a user has a machine connected
to an MST topology and decides to suspend their machine, we lose all
topology changes
Currently, every single piece of code in amdgpu that loops through
connectors does it incorrectly and doesn't use the proper list iteration
helpers, drm_connector_list_iter_begin() and
drm_connector_list_iter_end(). Yeesh.
So, do that.
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry
Since we're going to be reprobing the entire topology state on resume
now using sideband transactions, we need to ensure that we actually have
short HPD irqs enabled before calling drm_dp_mst_topology_mgr_resume().
So, do that.
Changes since v3:
* Fix typo in comments
Cc: Juston Li
Cc: Imre
Does what it says on the tin.
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Cc: Daniel Vetter
Reviewed-by: Sean Paul
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_mst_topology.c | 59 +--
1 file changed, 29 insertions(+), 30 deletions(-)
This is a complicated one. Essentially, there's currently a problem in the MST
core that hasn't really caused any issues that we're aware of (emphasis on "that
we're aware of"): locking.
When we go through and probe the link addresses and path resources in a
topology, we hold no locks when
This probably hasn't caused any problems up until now since it's
probably nearly impossible to encounter this in the wild, however if we
were to receive a connection status notification from the MST hub after
resume while we're in the middle of reprobing the link addresses for a
topology then
In order for suspend/resume reprobing to work, we need to be able to
perform sideband communications during suspend/resume, along with
runtime PM suspend/resume. In order to do so, we also need to make sure
that nouveau doesn't bother grabbing a runtime PM reference to do so,
since otherwise we'll
Currently, we enable hotplug detection only after we re-enable the
display. However, this is too late if we're planning on sending sideband
messages during the resume process - which we'll need to do in order to
reprobe the topology on resume.
So, enable hotplug events before reinitializing the
When reprobing an MST topology during resume, we have to account for the
fact that while we were suspended it's possible that mstbs may have been
removed from any ports in the topology. Since iterating downwards in the
topology requires that we hold >lock, destroying MSTBs from this
context would
This is the final portion of the large series for adding MST
suspend/resume reprobing that I've been working on for quite a while
now. In addition, I:
* Refactored and cleaned up any code I ended up digging through in the
process of understanding how some parts of these helpers worked.
* Added
Since we're going to be implementing suspend/resume reprobing very soon,
we need to make sure we are extra careful to ensure that our locking
actually protects the topology state where we expect it to. Turns out
this isn't the case with drm_dp_port_setup_pdt() and
drm_dp_port_teardown_pdt(), both
Currently, MST lacks locking in a lot of places that really should have
some sort of locking. Hotplugging and link address code paths are some
of the offenders here, as there is actually nothing preventing us from
running a link address probe while at the same time handling a
connection status
Once upon a time, hotplugging devices on MST branches actually worked in
DRM. Now, it only works in amdgpu (likely because of how it's hotplug
handlers are implemented). On both i915 and nouveau, hotplug
notifications from MST branches are noticed - but trying to respond to
them causes messaging
This will allow us to add some locking for port->* members, in
particular the PDT and ->connector, which can't be done from
drm_dp_destroy_port() since we don't know what locks the caller might be
holding.
Note that we already do this in delayed_destroy_work (renamed from
destroy_connector_work
Ras reboot debugfs node allows user one easy control to avoid
gpu recovery hang problem and directly reboot system per card
basis, after ras uncorrectable error happens. However, it is
one common entry, which should get rid of ras_ctrl node and
remove ip dependence when inputting by user. So add
If we decline the queue creation request in suspend state by returning -EAGAIN,
then this approach works for both hws and non-hws. This way the driver is clean
but application need to re-create queue later when it get a EAGAIN. Currently
application is not aware of the suspend/resume state, so
On 2019-10-21 5:04 p.m., Yang, Philip wrote:
> If device reset/suspend/resume failed for some reason, dqm lock is
> hold forever and this causes deadlock. Below is a kernel backtrace when
> application open kfd after suspend/resume failed.
>
> Instead of holding dqm lock in pre_reset and
Nice fix. Reviewed-by: Oak Zeng
Regards,
Oak
-Original Message-
From: amd-gfx On Behalf Of Yang, Philip
Sent: Monday, October 21, 2019 5:05 PM
To: amd-gfx@lists.freedesktop.org
Cc: Yang, Philip
Subject: [PATCH] drm/amdkfd: don't use dqm lock during device
reset/suspend/resume
If
If device reset/suspend/resume failed for some reason, dqm lock is
hold forever and this causes deadlock. Below is a kernel backtrace when
application open kfd after suspend/resume failed.
Instead of holding dqm lock in pre_reset and releasing dqm lock in
post_reset, add dqm->device_stopped flag
On Mon, Oct 21, 2019 at 07:24:53PM +, Jason Gunthorpe wrote:
> On Mon, Oct 21, 2019 at 03:11:57PM -0400, Jerome Glisse wrote:
> > > Since that reader is not locked we need release semantics here to
> > > ensure the unlocked reader sees a fully initinalized mmu_notifier_mm
> > > structure when
From: Leo Li
[Why]
Some LED panel drivers might not like fractional PWM. In such cases,
backlight flickering may be observed.
[How]
Add a DC feature mask to disable fractional PWM, and associate it with
the preexisting dc_config flag.
The flag is only plumbed through the dmcu firmware, so
From: Leo Li
[Why]
Some LED panel drivers might not like fractional PWM. In such cases,
backlight flickering may be observed.
[How]
Add a DC feature mask to disable fractional PWM, and associate it with
the preexisting dc_config flag.
The flag is only plumbed through the dmcu firmware, so
[PATCH] drm/amd/display: Change Navi14's DWB flag to 1
[Why]
DWB (Display Writeback) flag needs to be enabled as 1, or system
will throw out a few warnings when creating dcn20 resource pool.
Also, Navi14's dwb setting needs to match Navi10's,
which has already been set to 1.
[How]
Change value
On Mon, Oct 21, 2019 at 06:57:42PM +, Jason Gunthorpe wrote:
> On Mon, Oct 21, 2019 at 02:38:24PM -0400, Jerome Glisse wrote:
> > On Tue, Oct 15, 2019 at 03:12:42PM -0300, Jason Gunthorpe wrote:
> > > From: Jason Gunthorpe
> > >
> > > The only two users of this are now converted to use
On Mon, Oct 21, 2019 at 06:54:25PM +, Jason Gunthorpe wrote:
> On Mon, Oct 21, 2019 at 02:30:56PM -0400, Jerome Glisse wrote:
>
> > > +/**
> > > + * mmu_range_read_retry - End a read side critical section against a VA
> > > range
> > > + * mrn: The range under lock
> > > + * seq: The return
On Tue, Oct 15, 2019 at 03:12:27PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> 8 of the mmu_notifier using drivers (i915_gem, radeon_mn, umem_odp, hfi1,
> scif_dma, vhost, gntdev, hmm) drivers are using a common pattern where
> they only use invalidate_range_start/end and
On Tue, Oct 15, 2019 at 03:12:42PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> The only two users of this are now converted to use mmu_range_notifier,
> delete all the code and update hmm.rst.
I guess i should point out that the reasons for hmm_mirror and hmm
was for:
1) Maybe
On Tue, Oct 15, 2019 at 03:12:30PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> hmm_mirror's handling of ranges does not use a sequence count which
> results in this bug:
>
> CPU0 CPU1
>
On Tue, Oct 15, 2019 at 03:12:28PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> Now that we have KERNEL_HEADER_TEST all headers are generally compile
> tested, so relying on makefile tricks to avoid compiling code that depends
> on CONFIG_MMU_NOTIFIER is more annoying.
>
> Instead
On Tue, Oct 15, 2019 at 03:12:29PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> Of the 13 users of mmu_notifiers, 8 of them use only
> invalidate_range_start/end() and immediately intersect the
> mmu_notifier_range with some kind of internal list of VAs. 4 use an
> interval tree
On Tue, Oct 15, 2019 at 03:12:31PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> Only the function calls are stubbed out with static inlines that always
> fail. This is the standard way to write a header for an optional component
> and makes it easier for drivers that only optionally
On 2019-10-18 6:54 p.m., Zeng, Oak wrote:
> In current implementation, even dqm is stopped, user can still create (and
> start) new queue. This is not correct. We should forbid user create/start new
> queue if dqm is stopped - stop means stopping the current executing queues
> and stop
On 10/21/19 7:51 AM, Geert Uytterhoeven wrote:
Currently bool ionic_cq.done_color is exported using
debugfs_create_u8(), which requires a cast, preventing further compiler
checks.
Fix this by switching to debugfs_create_bool(), and dropping the cast.
Signed-off-by: Geert Uytterhoeven
> -Original Message-
> From: amd-gfx On Behalf Of
> Chen, Guchun
> Sent: Monday, October 21, 2019 5:33 AM
> To: amd-gfx@lists.freedesktop.org; Koenig, Christian
> ; Zhang, Hawking
> ; Li, Dennis ;
> Grodzovsky, Andrey ; Zhou1, Tao
>
> Cc: Li, Candice ; Chen, Guchun
>
> Subject: [PATCH]
On 2019-10-21 11:03 a.m., Siqueira, Rodrigo wrote:
> Commit d7cd0e05 introduced a change at DP_DSC_THROUGHPUT_MODE_0_170
> which is not aligned with the spec. This commit replace 15 << 4 by
> 15 << 0 for DP_DSC_THROUGHPUT_MODE_0_170 in order to make it follow the
> specification.
>
> Cc: Harry
Commit d7cd0e05 introduced a change at DP_DSC_THROUGHPUT_MODE_0_170
which is not aligned with the spec. This commit replace 15 << 4 by
15 << 0 for DP_DSC_THROUGHPUT_MODE_0_170 in order to make it follow the
specification.
Cc: Harry Wentland
Cc: Leo Li
Cc: Alex Deucher
Cc: Nikola Cornij
Cc:
Variables of type atomic{,64}_t can be used fine with
debugfs_create_u{32,64}, when passing a pointer to the embedded counter.
This allows to get rid of the casts, which prevented compiler checks.
Signed-off-by: Geert Uytterhoeven
---
drivers/crypto/nx/nx_debugfs.c | 18 +-
1
There is no need to cast a typed pointer to a void pointer when calling
a function that accepts the latter. Remove it, as the cast prevents
further compiler checks.
Signed-off-by: Geert Uytterhoeven
---
drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c | 2 +-
1 file changed, 1 insertion(+),
Hi all,
Casting parameters in debugfs_create_*() calls prevents the compiler
from performing some checks.
Hence this patch series removes superfluous casts, or reworks code to no
longer need the casts.
All patches can be applied independently, there are no dependencies.
Thanks for your
There is no need to cast a typed pointer to a void pointer when calling
a function that accepts the latter. Remove it, as the cast prevents
further compiler checks.
Signed-off-by: Geert Uytterhoeven
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 4 ++--
1 file changed, 2 insertions(+), 2
There is no need to cast a typed pointer to a void pointer when calling
a function that accepts the latter. Remove it, as the cast prevents
further compiler checks.
Signed-off-by: Geert Uytterhoeven
---
drivers/power/avs/smartreflex.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Currently bool ionic_cq.done_color is exported using
debugfs_create_u8(), which requires a cast, preventing further compiler
checks.
Fix this by switching to debugfs_create_bool(), and dropping the cast.
Signed-off-by: Geert Uytterhoeven
---
drivers/net/ethernet/pensando/ionic/ionic_debugfs.c
Am 21.10.19 um 15:57 schrieb Jason Gunthorpe:
> On Sun, Oct 20, 2019 at 02:21:42PM +, Koenig, Christian wrote:
>> Am 18.10.19 um 22:36 schrieb Jason Gunthorpe:
>>> On Thu, Oct 17, 2019 at 04:47:20PM +, Koenig, Christian wrote:
>>> [SNIP]
>>>
So again how are they serialized?
>>>
Thanks Christian.
Your suggestion is excellent, this can help get rid of parsing input code in
this patch. I will prepare patch v3 soon.
Regards,
Guchun
-Original Message-
From: Christian König
Sent: Monday, October 21, 2019 7:14 PM
To: Chen, Guchun ; amd-gfx@lists.freedesktop.org;
> -Original Message-
> From: amd-gfx On Behalf Of
> Chen, Guchun
> Sent: Monday, October 21, 2019 5:08 AM
> To: amd-gfx@lists.freedesktop.org; Zhang, Hawking
> ; Li, Dennis ;
> Grodzovsky, Andrey ; Zhou1, Tao
>
> Cc: Li, Candice ; Chen, Guchun
>
> Subject: [PATCH] drm/amdgpu: refine
> -Original Message-
> From: Li, Dennis
> Sent: Sunday, October 20, 2019 11:02 PM
> To: Grodzovsky, Andrey ; amd-
> g...@lists.freedesktop.org
> Cc: Grodzovsky, Andrey ; Chen, Guchun
> ; Zhou1, Tao ; noreply-
> conflue...@amd.com; Deucher, Alexander
> ; Quan, Evan
> Subject: RE: [PATCH
> -Original Message-
> From: Quan, Evan
> Sent: Sunday, October 20, 2019 10:48 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Grodzovsky,
> Andrey ; Xu, Feifei ;
> Quan, Evan ; Grodzovsky, Andrey
> ; Xu, Feifei
> Subject: [PATCH 1/3] drm/amd/powerplay: add lock
> -Original Message-
> From: Quan, Evan
> Sent: Sunday, October 20, 2019 10:48 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Grodzovsky,
> Andrey ; Xu, Feifei ;
> Quan, Evan
> Subject: [PATCH 2/3] drm/amd/powerplay: split out those internal used
> swSMU APIs V2
>
>
> -Original Message-
> From: Andrey Grodzovsky
> Sent: Friday, October 18, 2019 4:49 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Chen, Guchun ; Zhou1, Tao
> ; Deucher, Alexander
> ; noreply-conflue...@amd.com; Quan,
> Evan ; Grodzovsky, Andrey
>
> Subject: [PATCH 4/4] drm/amdgpu: Move
> -Original Message-
> From: Andrey Grodzovsky
> Sent: Friday, October 18, 2019 4:48 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Chen, Guchun ; Zhou1, Tao
> ; Deucher, Alexander
> ; noreply-conflue...@amd.com; Quan,
> Evan ; Grodzovsky, Andrey
>
> Subject: [PATCH 2/4] drm/amd/powerplay:
> -Original Message-
> From: Andrey Grodzovsky
> Sent: Friday, October 18, 2019 4:49 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Chen, Guchun ; Zhou1, Tao
> ; Deucher, Alexander
> ; noreply-conflue...@amd.com; Quan,
> Evan ; Grodzovsky, Andrey
>
> Subject: [PATCH 3/4] drm/amdgpu: Use
> -Original Message-
> From: Andrey Grodzovsky
> Sent: Friday, October 18, 2019 4:48 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Chen, Guchun ; Zhou1, Tao
> ; Deucher, Alexander
> ; noreply-conflue...@amd.com; Quan,
> Evan ; Grodzovsky, Andrey
>
> Subject: [PATCH 1/4] drm/amd/powerplay:
On 2019-10-21 3:54 a.m., Louis Li wrote:
> [Why]
> External monitor cannot be displayed consistently, if connecting
> via this Apple dongle (A1621, USB Type-C to HDMI).
> By experiments, it is confirmed that the dongle needs 200ms at least
> to be ready for communication, after it sets HPD signal
Am 21.10.19 um 11:33 schrieb Chen, Guchun:
Ras reboot debugfs node allows user one easy control to avoid
gpu recovery hang problem and directly reboot system per card
basis, after ras uncorrectable error happens. However, it is
one common entry, which should get rid of ras_ctrl node and
remove
Ras reboot debugfs node allows user one easy control to avoid
gpu recovery hang problem and directly reboot system per card
basis, after ras uncorrectable error happens. However, it is
one common entry, which should get rid of ras_ctrl node and
remove ip dependence when inputting by user. So add
Thanks Christian.
Let me update commit body in v2.
Regards,
Guchun
-Original Message-
From: Christian König
Sent: Monday, October 21, 2019 5:12 PM
To: Chen, Guchun ; amd-gfx@lists.freedesktop.org; Zhang,
Hawking ; Li, Dennis ; Grodzovsky,
Andrey ; Zhou1, Tao
Cc: Li, Candice
Am 21.10.19 um 11:08 schrieb Chen, Guchun:
Reboot operation for ras recovery is one common debugfs
entry, which should get rid of ras_ctrl node and remove
ip dependence when inputting by user. So add one new
auto_reboot node in ras debugfs dir to achieve this.
We need some justification why
Reboot operation for ras recovery is one common debugfs
entry, which should get rid of ras_ctrl node and remove
ip dependence when inputting by user. So add one new
auto_reboot node in ras debugfs dir to achieve this.
Signed-off-by: Guchun Chen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 55
[Why]
External monitor cannot be displayed consistently, if connecting
via this Apple dongle (A1621, USB Type-C to HDMI).
By experiments, it is confirmed that the dongle needs 200ms at least
to be ready for communication, after it sets HPD signal high.
[How]
When receiving HPD IRQ, delay 500ms at
61 matches
Mail list logo
