There is a race where the reply could get processed by another
work queue before we've updated the state.
Update the state before sending the msg to close it.
Pointed out by Adam J Richter on
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91481
Signed-off-by: Dave Airlie <airlied(a)redhat.com>
---
drivers/gpu/drm/drm_dp_mst_topology.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/…
[View More]drm_dp_mst_topology.c
index e23df5f..18c2a74 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1106,8 +1106,8 @@ static void drm_dp_add_port(struct drm_dp_mst_branch *mstb,
ret = drm_dp_port_setup_pdt(port);
if (ret == true) {
- drm_dp_send_link_address(mstb->mgr, port->mstb);
port->mstb->link_address_sent = true;
+ drm_dp_send_link_address(mstb->mgr, port->mstb);
}
}
@@ -1203,8 +1203,8 @@ static void drm_dp_check_and_send_link_address(struct drm_dp_mst_topology_mgr *m
struct drm_dp_mst_port *port;
struct drm_dp_mst_branch *mstb_child;
if (!mstb->link_address_sent) {
- drm_dp_send_link_address(mgr, mstb);
mstb->link_address_sent = true;
+ drm_dp_send_link_address(mgr, mstb);
}
list_for_each_entry(port, &mstb->ports, next) {
if (port->input)
--
2.4.3
[View Less]
Hi Dave,
A few more fixes for amdgpu from the last few days:
- Fix several copy paste typos
- Resume from suspend fixes for VCE
- Fix the GPU scheduler warning in kfifo_out
- Re-enable GPUVM fault interrupts which were inadvertently disabled
- GPUVM page table hang fix when paging
The following changes since commit bddf8026386927985ef6d0d11c3ba78f70b76bad:
drm/amdgpu: set MEC doorbell range for Fiji (2015-09-02 12:35:52 -0400)
are available in the git repository at:
git://people.…
[View More]freedesktop.org/~agd5f/linux drm-next-4.3
for you to fetch changes up to 35c7a9526af75040fac744babd0fafe18b8fe0a1:
drm/amdgpu: rename gmc_v8_0_init_compute_vmid (2015-09-04 16:36:28 -0400)
----------------------------------------------------------------
Alex Deucher (8):
drm/amdgpu: be explicit about cpu vram access for driver BOs (v2)
drm/amdgpu: use top down allocation for non-CPU accessible vram
drm/amdgpu: fix typo in dce10 watermark setup
drm/amdgpu: fix typo in dce11 watermark setup
drm/amdgpu/cz: fix cz_dpm_update_low_memory_pstate logic
drm/amdgpu: fix warning in scheduler
drm/amdgpu: fix vce3 instance handling
drm/amdgpu: rename gmc_v8_0_init_compute_vmid
Christian König (2):
drm/amdgpu: fix buffer placement under memory pressure
drm/amdgpu: properly enable VM fault interrupts
Leo Liu (1):
drm/amdgpu: remove ib test for the second VCE Ring
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 4 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c | 3 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 3 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 3 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 12 +++++--
drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 8 ++++-
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 7 ++--
drivers/gpu/drm/amd/amdgpu/cz_dpm.c | 4 +--
drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/fiji_smc.c | 8 +++--
drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 12 +++++--
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 6 ++--
drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 16 +++++----
drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 17 +++++-----
drivers/gpu/drm/amd/amdgpu/iceland_smc.c | 4 ++-
drivers/gpu/drm/amd/amdgpu/tonga_smc.c | 8 +++--
drivers/gpu/drm/amd/amdgpu/vce_v3_0.c | 48 +++++++++++++++++++++++----
drivers/gpu/drm/amd/scheduler/gpu_scheduler.c | 5 +--
22 files changed, 127 insertions(+), 52 deletions(-)
[View Less]
Hello everyone,
I'm currently working on the issue that when device drivers allocate memory on
behalf of an application the OOM killer usually doesn't knew about that unless
the application also get this memory mapped into their address space.
This is especially annoying for graphics drivers where a lot of the VRAM
usually isn't CPU accessible and so doesn't make sense to map into the
address space of the process using it.
The problem now is that when an application starts to use a lot of …
[View More]VRAM those
buffers objects sooner or later get swapped out to system memory, but when we
now run into an out of memory situation the OOM killer obviously doesn't knew
anything about that memory and so usually kills the wrong process.
The following set of patches tries to address this problem by introducing a per
file OOM badness score, which device drivers can use to give the OOM killer a
hint how many resources are bound to a file descriptor so that it can make
better decisions which process to kill.
So question at every one: What do you think about this approach?
My biggest concern right now is the patches are messing with a core kernel
structure (adding a field to struct file). Any better idea? I'm considering
to put a callback into file_ops instead.
Best regards and feel free to tear this idea apart,
Christian.
[View Less]
drivers/gpu/drm/bridge/nxp-ptn3460.c:403:3-8: No need to set .owner here. The core will do it.
Remove .owner field if calls are used which set it automatically
Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
Signed-off-by: Fengguang Wu <fengguang.wu(a)intel.com>
---
nxp-ptn3460.c | 1 -
1 file changed, 1 deletion(-)
--- a/drivers/gpu/drm/bridge/nxp-ptn3460.c
+++ b/drivers/gpu/drm/bridge/nxp-ptn3460.c
@@ -400,7 +400,6 @@ static struct i2c_driver ptn3460_driver
.…
[View More]remove = ptn3460_remove,
.driver = {
.name = "nxp,ptn3460",
- .owner = THIS_MODULE,
.of_match_table = ptn3460_match,
},
};
[View Less]
drivers/gpu/drm/bridge/parade-ps8622.c:671:3-8: No need to set .owner here. The core will do it.
Remove .owner field if calls are used which set it automatically
Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
Signed-off-by: Fengguang Wu <fengguang.wu(a)intel.com>
---
parade-ps8622.c | 1 -
1 file changed, 1 deletion(-)
--- a/drivers/gpu/drm/bridge/parade-ps8622.c
+++ b/drivers/gpu/drm/bridge/parade-ps8622.c
@@ -668,7 +668,6 @@ static struct i2c_driver …
[View More]ps8622_driver =
.remove = ps8622_remove,
.driver = {
.name = "ps8622",
- .owner = THIS_MODULE,
.of_match_table = ps8622_devices,
},
};
[View Less]
https://bugs.freedesktop.org/show_bug.cgi?id=91871
Bug ID: 91871
Summary: link retraining for DP not possible with current
design of Atomic modeset framework
Product: DRI
Version: XOrg git
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: medium
Component: General
Assignee: dri-devel(a)lists.freedesktop.org
Reporter: sivakumar.…
[View More]thulasimani(a)intel.com
DP spec requires Link training from highest link rate supported by panel to
lowest link rate supported by panel.
It is not possible to implement this in the current atomic modeset logic since
it splits modeset into two half atomic_check and atomic_commit, where it is
expected all values to be calculated in atomic_check and programmed in
atomic_commit.
link training being a negotiation phase of DP modeset it is not possible to
predict if a training at certain link rate will succeed or not. if it does fail
it will require us to disable, calculate new values and enable pll. this is not
possible in current DRM Atomic modeset framework.
--
You are receiving this mail because:
You are the assignee for the bug.
[View Less]
https://bugs.freedesktop.org/show_bug.cgi?id=90889
--- Comment #3 from lolwoot1234(a)gmail.com ---
Issue still not fixed...
Early KMS doesn't really change anything
anything.
--
You are receiving this mail because:
You are the assignee for the bug.