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 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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc: Juston Li
---
On Fri, 4 Jan 2019 at 23:02, Michel Dänzer wrote:
>
> On 2019-01-04 4:24 p.m., Alex Deucher wrote:
> > On Fri, Jan 4, 2019 at 9:52 AM Mikhail Gavrilov
> > wrote:
> >>
> >> Hi folks I found that kernel 4.21 unworkable with AMD hardware.
> >> Also I am make kernel bisect and founded the blame
Hi Ezequiel,
On 1/4/19 10:40 AM, Ezequiel Garcia wrote:
Hey Gustavo,
On Thu, 3 Jan 2019 at 17:25, Gustavo A. R. Silva wrote:
Fix boolean expressions by using logical AND operator '&&'
instead of bitwise operator '&'.
This issue was detected with the help of Coccinelle.
Fixes: 9a4b7d4c769e
Add message print out and return -EINVAL when driver can not get valid hive
from hive arrary on xgmi configuration
Change-Id: Ic03927904edf0e384b8c4651e19274bb3f2a7d9a
Signed-off-by: shaoyunl
---
drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 7 ++-
1 file changed, 6 insertions(+), 1
Add message print out and return -EINVAL when driver can not get valid hive
from hive arrary on xgmi configuration
Change-Id: Ic03927904edf0e384b8c4651e19274bb3f2a7d9a
Signed-off-by: shaoyunl
---
drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 7 ++-
1 file changed, 6 insertions(+), 1
On Thu, Jan 3, 2019 at 3:21 PM Gustavo A. R. Silva
wrote:
>
> Fix boolean expressions by using logical AND operator '&&'
> instead of bitwise operator '&'.
>
> This issue was detected with the help of Coccinelle.
>
> Fixes: 9a4b7d4c769e ("drm/amdgpu: Add vm context module param")
> Cc:
It seems patch d492c564 revert to this original code otherwise we
shouldn't get the warning . I can add ret = -EINVAL for this.
Regards
shaoyun.liu
On 2019-01-04 6:53 a.m., Dan Carpenter wrote:
> Hello Shaoyun Liu,
>
> The patch fb30fc59a245: "drm/amdgpu : Generate XGMI topology info
>
Hey Gustavo,
On Thu, 3 Jan 2019 at 17:25, Gustavo A. R. Silva wrote:
>
> Fix boolean expressions by using logical AND operator '&&'
> instead of bitwise operator '&'.
>
> This issue was detected with the help of Coccinelle.
>
> Fixes: 9a4b7d4c769e ("drm/amdgpu: Add vm context module param")
>
On Fri, Jan 4, 2019 at 7:35 AM Russell, Kent wrote:
>
> Add a sysfs file that reports the number of bytes transmitted and
> received in the last second. This can be used to approximate the PCIe
> bandwidth usage over the last second.
>
> Change-Id: I6c82fe1cb17726825736512990fa64f5c1489861
>
On Fri, Jan 4, 2019 at 7:35 AM Russell, Kent wrote:
>
> We need these offsets for PCIE perf counters, so include them as well as
> the the previously-used defines from the nbio_*.c files
>
> Change-Id: I0e090e5b5b97359a67b28952f069ff6e603edf10
> Signed-off-by: Kent Russell
> ---
>
On 2019-01-04 4:32 p.m., Luís Mendes wrote:
> Hi Alex, Christian,
>
> I've tested amd-staging-drm-next at commit
> 9698024e8a191481321574bec1fe886bbce797cf - drm/amdgpu: Cleanup 2
> compiler warnings,
> and now RX 550 Polaris 12 still hangs in ring gfx with XOrg, but a gpu
> recovery is now
On 2019-01-04 4:24 p.m., Alex Deucher wrote:
> On Fri, Jan 4, 2019 at 9:52 AM Mikhail Gavrilov
> wrote:
>>
>> Hi folks I found that kernel 4.21 unworkable with AMD hardware.
>> Also I am make kernel bisect and founded the blame commit.
>> First bad commit:
On Fri, Jan 4, 2019 at 9:52 AM Mikhail Gavrilov
wrote:
>
> Hi folks I found that kernel 4.21 unworkable with AMD hardware.
> Also I am make kernel bisect and founded the blame commit.
> First bad commit: [674e78acae0dfb4beb56132e41cbae5b60f7d662]
> drm/amd/display: Add fast path for cursor plane
Hi folks I found that kernel 4.21 unworkable with AMD hardware.
Also I am make kernel bisect and founded the blame commit.
First bad commit: [674e78acae0dfb4beb56132e41cbae5b60f7d662]
drm/amd/display: Add fast path for cursor plane updates
[ 41.841318] [ cut here ]
[
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: 9a4b7d4c769e drm/amdgpu: Add vm context module param.
The bot has tested the following trees: v4.20.0, v4.19.13, v4.14.91,
v4.20.0: Build OK!
v4.19.13: Build OK!
v4.14.91: Failed
Add a sysfs file that reports the number of bytes transmitted and
received in the last second. This can be used to approximate the PCIe
bandwidth usage over the last second.
Change-Id: I6c82fe1cb17726825736512990fa64f5c1489861
Signed-off-by: Kent Russell
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h
We need these offsets for PCIE perf counters, so include them as well as
the the previously-used defines from the nbio_*.c files
Change-Id: I0e090e5b5b97359a67b28952f069ff6e603edf10
Signed-off-by: Kent Russell
---
drivers/gpu/drm/amd/amdgpu/nbio_v6_1.c | 6 +--
Hello Shaoyun Liu,
The patch fb30fc59a245: "drm/amdgpu : Generate XGMI topology info
from driver level" from Jun 27, 2018, leads to the following static
checker warning:
drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c:117 amdgpu_xgmi_add_device()
warn: missing error code here?
On 1/3/19 3:11 PM, Wentland, Harry wrote:
On 2019-01-03 2:48 p.m., Gustavo A. R. Silva wrote:
Fix boolean expression by using logical AND operator '&&'
instead of bitwise operator '&'.
This issue was detected with the help of Coccinelle.
Fixes: 6d04ee9dc101 ("drm/amd/display: Restructuring
35 matches
Mail list logo
