[Bug 205497] Attempt to read amd gpu id causes a freeze
https://bugzilla.kernel.org/show_bug.cgi?id=205497 --- Comment #14 from Trek (tre...@inbox.ru) --- (In reply to Alex Deucher from comment #11) > If you access the BAR directly you will likely have problems in certain > power saving modes. thank you, I'll add a warning message when accessing BAR directly -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205497] Attempt to read amd gpu id causes a freeze
https://bugzilla.kernel.org/show_bug.cgi?id=205497 --- Comment #13 from Luya Tshimbalanga (l...@fedoraproject.org) --- (In reply to Alex Deucher from comment #11) > (In reply to Trek from comment #7) > > by default, radeontop calls amdgpu_read_mm_registers, amdgpu_query_info and > > amdgpu_query_sensor_info, but it can be forced by the command line to read > > BAR from /dev/mem > > If you access the BAR directly you will likely have problems in certain > power saving modes. > > Can someone test the patch? Currently building on https://copr.fedorainfracloud.org/coprs/luya/kernel-amgpu-gfxoff/build/1095660/ -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201539] AMDGPU R9 390 automatic fan speed control in Linux 4.19/4.20/5.0
https://bugzilla.kernel.org/show_bug.cgi?id=201539 --- Comment #28 from MasterCATZ (masterc...@hotmail.com) --- hmm maybe not it lets me briefly access manual Found the following PWM controls: hwmon1/pwm1 current value: 68 hwmon1/pwm1 is currently setup for automatic speed control. In general, automatic mode is preferred over manual mode, as it is more efficient and it reacts faster. Are you sure that you want to setup this output for manual control? (n) y hwmon1/pwm1_enable stuck to 2 Manual control mode not supported, skipping hwmon1/pwm1. wish I knew what the heck keeps locking pwm1_enable to auto @ low speeds :@ -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201539] AMDGPU R9 390 automatic fan speed control in Linux 4.19/4.20/5.0
https://bugzilla.kernel.org/show_bug.cgi?id=201539 --- Comment #27 from MasterCATZ (masterc...@hotmail.com) --- pwmconfig seems to be the only thing that allows me to get manual mode back on I wounder if this is the actual program giving grieve -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: Signed-off-by missing for commit in the drm tree
Hi all,
Commit
b4011644b03c ("drm/vmwgfx: remove set but not used variable 'srf'")
is missing a Signed-off-by from its committer.
--
Cheers,
Stephen Rothwell
pgpCwR7wqyTYm.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] drm/ttm: rework BO delayed delete.
On 2019-11-11 9:58 a.m., Christian König wrote:
This patch reworks the whole delayed deletion of BOs which aren't idle.
Instead of having two counters for the BO structure we resurrect the BO
when we find that a deleted BO is not idle yet.
This has many advantages, especially that we don't need to
increment/decrement the BOs reference counter any more when it
moves on the LRUs.
Signed-off-by: Christian König
I reviewed it fairly thoroughly and couldn't find anything wrong. But I
don't know this code well enough, including all the implications of all
the calls being moved around, to give a confident R-b.
Acked-by: Felix Kuehling
---
drivers/gpu/drm/ttm/ttm_bo.c | 215 +-
drivers/gpu/drm/ttm/ttm_bo_util.c | 1 -
include/drm/ttm/ttm_bo_api.h | 11 +-
3 files changed, 97 insertions(+), 130 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 1178980f4147..570b0e1089b7 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -145,26 +145,6 @@ static inline uint32_t ttm_bo_type_flags(unsigned type)
return 1 << (type);
}
-static void ttm_bo_release_list(struct kref *list_kref)
-{
- struct ttm_buffer_object *bo =
- container_of(list_kref, struct ttm_buffer_object, list_kref);
- size_t acc_size = bo->acc_size;
-
- BUG_ON(kref_read(>list_kref));
- BUG_ON(kref_read(>kref));
- BUG_ON(bo->mem.mm_node != NULL);
- BUG_ON(!list_empty(>lru));
- BUG_ON(!list_empty(>ddestroy));
- ttm_tt_destroy(bo->ttm);
- atomic_dec(_bo_glob.bo_count);
- dma_fence_put(bo->moving);
- if (!ttm_bo_uses_embedded_gem_object(bo))
- dma_resv_fini(>base._resv);
- bo->destroy(bo);
- ttm_mem_global_free(_mem_glob, acc_size);
-}
-
static void ttm_bo_add_mem_to_lru(struct ttm_buffer_object *bo,
struct ttm_mem_reg *mem)
{
@@ -181,21 +161,14 @@ static void ttm_bo_add_mem_to_lru(struct
ttm_buffer_object *bo,
man = >man[mem->mem_type];
list_add_tail(>lru, >lru[bo->priority]);
- kref_get(>list_kref);
if (!(man->flags & TTM_MEMTYPE_FLAG_FIXED) && bo->ttm &&
!(bo->ttm->page_flags & (TTM_PAGE_FLAG_SG |
TTM_PAGE_FLAG_SWAPPED))) {
list_add_tail(>swap, _bo_glob.swap_lru[bo->priority]);
- kref_get(>list_kref);
}
}
-static void ttm_bo_ref_bug(struct kref *list_kref)
-{
- BUG();
-}
-
static void ttm_bo_del_from_lru(struct ttm_buffer_object *bo)
{
struct ttm_bo_device *bdev = bo->bdev;
@@ -203,12 +176,10 @@ static void ttm_bo_del_from_lru(struct ttm_buffer_object
*bo)
if (!list_empty(>swap)) {
list_del_init(>swap);
- kref_put(>list_kref, ttm_bo_ref_bug);
notify = true;
}
if (!list_empty(>lru)) {
list_del_init(>lru);
- kref_put(>list_kref, ttm_bo_ref_bug);
notify = true;
}
@@ -446,74 +417,17 @@ static void ttm_bo_flush_all_fences(struct ttm_buffer_object *bo)
dma_fence_enable_sw_signaling(fence);
for (i = 0; fobj && i < fobj->shared_count; ++i) {
- fence = rcu_dereference_protected(fobj->shared[i],
- dma_resv_held(bo->base.resv));
+ fence = rcu_dereference_protected(fobj->shared[i], true);
if (!fence->ops->signaled)
dma_fence_enable_sw_signaling(fence);
}
}
-static void ttm_bo_cleanup_refs_or_queue(struct ttm_buffer_object *bo)
-{
- struct ttm_bo_device *bdev = bo->bdev;
- int ret;
-
- ret = ttm_bo_individualize_resv(bo);
- if (ret) {
- /* Last resort, if we fail to allocate memory for the
-* fences block for the BO to become idle
-*/
- dma_resv_wait_timeout_rcu(bo->base.resv, true, false,
- 30 * HZ);
- spin_lock(_bo_glob.lru_lock);
- goto error;
- }
-
- spin_lock(_bo_glob.lru_lock);
- ret = dma_resv_trylock(bo->base.resv) ? 0 : -EBUSY;
- if (!ret) {
- if (dma_resv_test_signaled_rcu(>base._resv, true)) {
- ttm_bo_del_from_lru(bo);
- spin_unlock(_bo_glob.lru_lock);
- if (bo->base.resv != >base._resv)
- dma_resv_unlock(>base._resv);
-
- ttm_bo_cleanup_memtype_use(bo);
- dma_resv_unlock(bo->base.resv);
- return;
- }
-
- ttm_bo_flush_all_fences(bo);
-
- /*
-* Make NO_EVICT bos immediately available to
-* shrinkers, now that they are queued for
-* destruction.
Re: [PATCH 2/4] drm/ttm: cleanup ttm_buffer_object_transfer
The subject doesn't match the change. This changes ttm_bo_cleanup_refs,
not ttm_buffer_object_transfer.
On 2019-11-11 9:58 a.m., Christian König wrote:
The function is always called with deleted BOs.
While at it cleanup the indentation as well.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 7e7925fecd9e..1178980f4147 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -527,14 +527,9 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object
*bo,
bool interruptible, bool no_wait_gpu,
bool unlock_resv)
{
- struct dma_resv *resv;
+ struct dma_resv *resv = >base._resv;
int ret;
- if (unlikely(list_empty(>ddestroy)))
Would it make sense to add a BUG_ON or WARN_ON here to check the
assumption made by this code?
Regards,
Felix
- resv = bo->base.resv;
- else
- resv = >base._resv;
-
if (dma_resv_test_signaled_rcu(resv, true))
ret = 0;
else
@@ -547,9 +542,8 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object *bo,
dma_resv_unlock(bo->base.resv);
spin_unlock(_bo_glob.lru_lock);
- lret = dma_resv_wait_timeout_rcu(resv, true,
- interruptible,
- 30 * HZ);
+ lret = dma_resv_wait_timeout_rcu(resv, true, interruptible,
+30 * HZ);
if (lret < 0)
return lret;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdkfd: remove set but not used variable 'top_dev'
On 2019-11-13 10:20 p.m., zhengbin wrote:
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/amd/amdkfd/kfd_iommu.c: In function kfd_iommu_device_init:
drivers/gpu/drm/amd/amdkfd/kfd_iommu.c:65:30: warning: variable top_dev set but
not used [-Wunused-but-set-variable]
Reported-by: Hulk Robot
Fixes: 1ae99eab34f9 ("drm/amdkfd: Initialize HSA_CAP_ATS_PRESENT capability in
topology codes")
Signed-off-by: zhengbin
The patch is
Reviewed-by: Felix Kuehling
I'm applying it to amd-staging-drm-next.
Thanks,
Felix
---
drivers/gpu/drm/amd/amdkfd/kfd_iommu.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_iommu.c
b/drivers/gpu/drm/amd/amdkfd/kfd_iommu.c
index 193e283..8d87151 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_iommu.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_iommu.c
@@ -62,9 +62,6 @@ int kfd_iommu_device_init(struct kfd_dev *kfd)
struct amd_iommu_device_info iommu_info;
unsigned int pasid_limit;
int err;
- struct kfd_topology_device *top_dev;
-
- top_dev = kfd_topology_device_by_id(kfd->id);
if (!kfd->device_info->needs_iommu_device)
return 0;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #232 from viste.sylv...@gmail.com --- (In reply to Sander Lienaerts from comment #231) > Been following this thread for a while now. Can't believe this has been > known for 3 months, without a fix released. > > Just a moment ago a random freeze occurred running Firefox and other > applications, no games. Spotify kept playing in the background. Cursor not > moving and unable to open another shell. > > This happened with AMD_DEBUG="nongg,nodma" enabled. Running kernel 5.4rc7 > and Mesa 19.2.4. I'm currently using kernel 5.4 and mesa-git (using lcarlier repo, it's written mesa 20 but there is no mesa 20 on the git repository so ...) on Arch and I'm not having any hang or freeze so it seems to be fixed but maybe I'm lucky. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 112266] [Navi] Pathfinder: Kingmaker is causing a GPU hang: flip_done timed out error
https://bugs.freedesktop.org/show_bug.cgi?id=112266 --- Comment #8 from rLy --- (In reply to Alex Deucher from comment #6) > Created attachment 145971 [details] [review] > possible fix > > Does this patch help? I tried it as well on 5.4-rc7 and fixed every game I mentioned(CS:GO, SOTTR, TS2020, KSP). -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/nouveau/kms/nv50-: Limit MST BPC to 8
Noticed this while working on some unrelated CRC stuff. Currently,
userspace has very little support for BPCs higher than 8. While this
doesn't matter for most things, on MST topologies we need to be careful
about ensuring that we do our best to make any given display
configuration fit within the bandwidth restraints of the topology, since
otherwise less people's monitor configurations will work.
Allowing for BPC settings higher than 8 dramatically increases the
required bandwidth for displays in most configurations, and consequently
makes it a lot less likely that said display configurations will pass
the atomic check.
In the future we want to fix this correctly by making it so that we
adjust the bpp for each display in a topology to be as high as possible,
while making sure to lower the bpp of each display in the event that we
run out of bandwidth and need to rerun our atomic check. But for now,
follow the behavior that both i915 and amdgpu are sticking to.
Signed-off-by: Lyude Paul
Fixes: 232c9eec417a ("drm/nouveau: Use atomic VCPI helpers for MST")
Cc: Ben Skeggs
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc: Juston Li
Cc: Sam Ravnborg
Cc: Sean Paul
Cc: # v5.1+
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 93665aecce57..9ac47fe519f8 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -798,7 +798,14 @@ nv50_msto_atomic_check(struct drm_encoder *encoder,
if (!state->duplicated) {
const int clock = crtc_state->adjusted_mode.clock;
- asyh->or.bpc = connector->display_info.bpc;
+ /*
+* XXX: Since we don't use HDR in userspace quite yet, limit
+* the bpc to 8 to save bandwidth on the topology. In the
+* future, we'll want to properly fix this by dynamically
+* selecting the highest possible bpc that would fit in the
+* topology
+*/
+ asyh->or.bpc = min(connector->display_info.bpc, 8U);
asyh->dp.pbn = drm_dp_calc_pbn_mode(clock, asyh->or.bpc * 3);
}
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/nouveau/kms/nv50-: Store the bpc we're using in nv50_head_atom
In order to be able to use bpc values that are different from what the
connector reports, we want to be able to store the bpc value we decide
on using for an atomic state in nv50_head_atom and refer to that instead
of simply using the value that the connector reports throughout the
whole atomic check phase and commit phase. This will let us (eventually)
implement the max bpc connector property, and will also be needed for
limiting the bpc we use on MST displays to 8 in the next commit.
Signed-off-by: Lyude Paul
Fixes: 232c9eec417a ("drm/nouveau: Use atomic VCPI helpers for MST")
Cc: Ben Skeggs
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc: Juston Li
Cc: Sean Paul
Cc: Laurent Pinchart
Cc: # v5.1+
---
drivers/gpu/drm/nouveau/dispnv50/atom.h | 1 +
drivers/gpu/drm/nouveau/dispnv50/disp.c | 57 ++---
drivers/gpu/drm/nouveau/dispnv50/head.c | 5 +--
3 files changed, 36 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/atom.h
b/drivers/gpu/drm/nouveau/dispnv50/atom.h
index 43df86c38f58..24f7700768da 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/atom.h
+++ b/drivers/gpu/drm/nouveau/dispnv50/atom.h
@@ -114,6 +114,7 @@ struct nv50_head_atom {
u8 nhsync:1;
u8 nvsync:1;
u8 depth:4;
+ u8 bpc;
} or;
/* Currently only used for MST */
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 6327aaf37c08..93665aecce57 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -353,10 +353,20 @@ nv50_outp_atomic_check(struct drm_encoder *encoder,
struct drm_crtc_state *crtc_state,
struct drm_connector_state *conn_state)
{
- struct nouveau_connector *nv_connector =
- nouveau_connector(conn_state->connector);
- return nv50_outp_atomic_check_view(encoder, crtc_state, conn_state,
- nv_connector->native_mode);
+ struct drm_connector *connector = conn_state->connector;
+ struct nouveau_connector *nv_connector = nouveau_connector(connector);
+ struct nv50_head_atom *asyh = nv50_head_atom(crtc_state);
+ int ret;
+
+ ret = nv50_outp_atomic_check_view(encoder, crtc_state, conn_state,
+ nv_connector->native_mode);
+ if (ret)
+ return ret;
+
+ if (crtc_state->mode_changed || crtc_state->connectors_changed)
+ asyh->or.bpc = connector->display_info.bpc;
+
+ return 0;
}
/**
@@ -786,10 +796,10 @@ nv50_msto_atomic_check(struct drm_encoder *encoder,
* may have changed after the state was duplicated
*/
if (!state->duplicated) {
- const int bpp = connector->display_info.bpc * 3;
const int clock = crtc_state->adjusted_mode.clock;
- asyh->dp.pbn = drm_dp_calc_pbn_mode(clock, bpp);
+ asyh->or.bpc = connector->display_info.bpc;
+ asyh->dp.pbn = drm_dp_calc_pbn_mode(clock, asyh->or.bpc * 3);
}
slots = drm_dp_atomic_find_vcpi_slots(state, >mgr, mstc->port,
@@ -802,6 +812,17 @@ nv50_msto_atomic_check(struct drm_encoder *encoder,
return 0;
}
+static u8
+nv50_dp_bpc_to_depth(unsigned int bpc)
+{
+ switch (bpc) {
+ case 6: return 0x2;
+ case 8: return 0x5;
+ case 10: /* fall-through */
+ default: return 0x6;
+ }
+}
+
static void
nv50_msto_enable(struct drm_encoder *encoder)
{
@@ -812,7 +833,7 @@ nv50_msto_enable(struct drm_encoder *encoder)
struct nv50_mstm *mstm = NULL;
struct drm_connector *connector;
struct drm_connector_list_iter conn_iter;
- u8 proto, depth;
+ u8 proto;
bool r;
drm_connector_list_iter_begin(encoder->dev, _iter);
@@ -841,14 +862,8 @@ nv50_msto_enable(struct drm_encoder *encoder)
else
proto = 0x9;
- switch (mstc->connector.display_info.bpc) {
- case 6: depth = 0x2; break;
- case 8: depth = 0x5; break;
- case 10:
- default: depth = 0x6; break;
- }
-
- mstm->outp->update(mstm->outp, head->base.index, armh, proto, depth);
+ mstm->outp->update(mstm->outp, head->base.index, armh, proto,
+ nv50_dp_bpc_to_depth(armh->or.bpc));
msto->head = head;
msto->mstc = mstc;
@@ -1502,20 +1517,14 @@ nv50_sor_enable(struct drm_encoder *encoder)
lvds.lvds.script |= 0x0200;
}
- if (nv_connector->base.display_info.bpc == 8)
+ if (asyh->or.bpc == 8)
lvds.lvds.script |= 0x0200;
}
[PATCH 1/3] drm/nouveau/kms/nv50-: Call outp_atomic_check_view() before handling PBN
Since nv50_outp_atomic_check_view() can set crtc_state->mode_changed, we
probably should be calling it before handling any PBN changes. Just a
precaution.
Signed-off-by: Lyude Paul
Fixes: 232c9eec417a ("drm/nouveau: Use atomic VCPI helpers for MST")
Cc: Ben Skeggs
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc: Juston Li
Cc: Sean Paul
Cc: Laurent Pinchart
Cc: # v5.1+
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 44 ++---
1 file changed, 24 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 549486f1d937..6327aaf37c08 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -770,32 +770,36 @@ nv50_msto_atomic_check(struct drm_encoder *encoder,
struct nv50_mstm *mstm = mstc->mstm;
struct nv50_head_atom *asyh = nv50_head_atom(crtc_state);
int slots;
+ int ret;
- if (crtc_state->mode_changed || crtc_state->connectors_changed) {
- /*
-* When restoring duplicated states, we need to make sure that
-* the bw remains the same and avoid recalculating it, as the
-* connector's bpc may have changed after the state was
-* duplicated
-*/
- if (!state->duplicated) {
- const int bpp = connector->display_info.bpc * 3;
- const int clock = crtc_state->adjusted_mode.clock;
+ ret = nv50_outp_atomic_check_view(encoder, crtc_state, conn_state,
+ mstc->native);
+ if (ret)
+ return ret;
- asyh->dp.pbn = drm_dp_calc_pbn_mode(clock, bpp);
- }
+ if (!crtc_state->mode_changed && !crtc_state->connectors_changed)
+ return 0;
- slots = drm_dp_atomic_find_vcpi_slots(state, >mgr,
- mstc->port,
- asyh->dp.pbn);
- if (slots < 0)
- return slots;
+ /*
+* When restoring duplicated states, we need to make sure that the bw
+* remains the same and avoid recalculating it, as the connector's bpc
+* may have changed after the state was duplicated
+*/
+ if (!state->duplicated) {
+ const int bpp = connector->display_info.bpc * 3;
+ const int clock = crtc_state->adjusted_mode.clock;
- asyh->dp.tu = slots;
+ asyh->dp.pbn = drm_dp_calc_pbn_mode(clock, bpp);
}
- return nv50_outp_atomic_check_view(encoder, crtc_state, conn_state,
- mstc->native);
+ slots = drm_dp_atomic_find_vcpi_slots(state, >mgr, mstc->port,
+ asyh->dp.pbn);
+ if (slots < 0)
+ return slots;
+
+ asyh->dp.tu = slots;
+
+ return 0;
}
static void
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] MST BPC fixes for nouveau
Realized when I moved nouveau over to using the atomic DP MST VCPI helpers that I forgot to ensure that we clamp the BPC to 8 to make us less likely to run out of bandwidth on a topology when enabling multiple displays that support >8 BPC - something we want to do until we have support for dynamically selecting the bpc based on the topology's available bandwidth, since userspace isn't really using HDR yet anyway. This matches the behavior that i915 has, along with the behavior of amdgpu and should fix some people's displays not turning on. Lyude Paul (3): drm/nouveau/kms/nv50-: Call outp_atomic_check_view() before handling PBN drm/nouveau/kms/nv50-: Store the bpc we're using in nv50_head_atom drm/nouveau/kms/nv50-: Limit MST BPC to 8 drivers/gpu/drm/nouveau/dispnv50/atom.h | 1 + drivers/gpu/drm/nouveau/dispnv50/disp.c | 102 ++-- drivers/gpu/drm/nouveau/dispnv50/head.c | 5 +- 3 files changed, 64 insertions(+), 44 deletions(-) -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] MAINTAINERS: Remove myself from drm-misc entry
Cc: Dave Airlie Cc: Daniel Vetter Cc: Maarten Lankhorst Cc: Maxime Ripard Signed-off-by: Sean Paul --- I need to step away from -misc to prioritize other work that I have on my plate. It's been great fun (most of the time) and very rewarding doing this job. I will really miss it! I plan on the 5.5 release being my last one before transitioning to my new role as committer :-) Sean MAINTAINERS | 1 - 1 file changed, 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index b63c291ad029..c2b89453805f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5362,7 +5362,6 @@ F:include/linux/vga* DRM DRIVERS AND MISC GPU PATCHES M: Maarten Lankhorst M: Maxime Ripard -M: Sean Paul W: https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-misc.html S: Maintained T: git git://anongit.freedesktop.org/drm/drm-misc -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #231 from Sander Lienaerts --- Been following this thread for a while now. Can't believe this has been known for 3 months, without a fix released. Just a moment ago a random freeze occurred running Firefox and other applications, no games. Spotify kept playing in the background. Cursor not moving and unable to open another shell. This happened with AMD_DEBUG="nongg,nodma" enabled. Running kernel 5.4rc7 and Mesa 19.2.4. Here is an output of the log before reboot: nov 15 20:47:58 sander-pc kernel: amdgpu :0a:00.0: [gfxhub] page fault (src_id:0 ring:40 vmid:5 pasid:32769, for process Xorg pid 811 thread Xorg:cs0 pid 974) nov 15 20:47:58 sander-pc kernel: amdgpu :0a:00.0: in page starting at address 0x0318c00e7000 from client 27 nov 15 20:47:58 sander-pc kernel: amdgpu :0a:00.0: GCVM_L2_PROTECTION_FAULT_STATUS:0x00541C51 nov 15 20:47:58 sander-pc kernel: amdgpu :0a:00.0: MORE_FAULTS: 0x1 nov 15 20:47:58 sander-pc kernel: amdgpu :0a:00.0: WALKER_ERROR: 0x0 nov 15 20:47:58 sander-pc kernel: amdgpu :0a:00.0: PERMISSION_FAULTS: 0x5 nov 15 20:47:58 sander-pc kernel: amdgpu :0a:00.0: MAPPING_ERROR: 0x0 nov 15 20:47:58 sander-pc kernel: amdgpu :0a:00.0: RW: 0x1 nov 15 20:47:58 sander-pc kernel: amdgpu :0a:00.0: [gfxhub] page fault (src_id:0 ring:40 vmid:5 pasid:32769, for process Xorg pid 811 thread Xorg:cs0 pid 974) nov 15 20:47:58 sander-pc kernel: amdgpu :0a:00.0: in page starting at address 0x0318c00e6000 from client 27 nov 15 20:47:58 sander-pc kernel: amdgpu :0a:00.0: GCVM_L2_PROTECTION_FAULT_STATUS:0x nov 15 20:47:58 sander-pc kernel: amdgpu :0a:00.0: MORE_FAULTS: 0x0 nov 15 20:47:58 sander-pc kernel: amdgpu :0a:00.0: WALKER_ERROR: 0x0 nov 15 20:47:58 sander-pc kernel: amdgpu :0a:00.0: PERMISSION_FAULTS: 0x0 nov 15 20:47:58 sander-pc kernel: amdgpu :0a:00.0: MAPPING_ERROR: 0x0 nov 15 20:47:58 sander-pc kernel: amdgpu :0a:00.0: RW: 0x0 nov 15 20:47:58 sander-pc kernel: amdgpu :0a:00.0: [gfxhub] page fault (src_id:0 ring:40 vmid:5 pasid:32769, for process Xorg pid 811 thread Xorg:cs0 pid 974) nov 15 20:47:58 sander-pc kernel: amdgpu :0a:00.0: in page starting at address 0x0318c00e9000 from client 27 nov 15 20:47:58 sander-pc kernel: amdgpu :0a:00.0: GCVM_L2_PROTECTION_FAULT_STATUS:0x nov 15 20:47:58 sander-pc kernel: amdgpu :0a:00.0: MORE_FAULTS: 0x0 nov 15 20:47:58 sander-pc kernel: amdgpu :0a:00.0: WALKER_ERROR: 0x0 nov 15 20:47:58 sander-pc kernel: amdgpu :0a:00.0: PERMISSION_FAULTS: 0x0 nov 15 20:47:58 sander-pc kernel: amdgpu :0a:00.0: MAPPING_ERROR: 0x0 nov 15 20:47:58 sander-pc kernel: amdgpu :0a:00.0: RW: 0x0 nov 15 20:47:58 sander-pc kernel: amdgpu :0a:00.0: [gfxhub] page fault (src_id:0 ring:40 vmid:5 pasid:32769, for process Xorg pid 811 thread Xorg:cs0 pid 974) nov 15 20:47:58 sander-pc kernel: amdgpu :0a:00.0: in page starting at address 0x0318c00e8000 from client 27 nov 15 20:47:58 sander-pc kernel: amdgpu :0a:00.0: GCVM_L2_PROTECTION_FAULT_STATUS:0x nov 15 20:47:58 sander-pc kernel: amdgpu :0a:00.0: MORE_FAULTS: 0x0 nov 15 20:47:58 sander-pc kernel: amdgpu :0a:00.0: WALKER_ERROR: 0x0 nov 15 20:47:58 sander-pc kernel: amdgpu :0a:00.0: PERMISSION_FAULTS: 0x0 nov 15 20:47:58 sander-pc kernel: amdgpu :0a:00.0: MAPPING_ERROR: 0x0 nov 15 20:47:58 sander-pc kernel: amdgpu :0a:00.0: RW: 0x0 nov 15 20:47:58 sander-pc kernel: amdgpu :0a:00.0: [gfxhub] page fault (src_id:0 ring:40 vmid:5 pasid:32769, for process Xorg pid 811 thread Xorg:cs0 pid 974) nov 15 20:47:58 sander-pc kernel: amdgpu :0a:00.0: in page starting at address 0x0318c00ea000 from client 27 nov 15 20:47:58 sander-pc kernel: amdgpu :0a:00.0: GCVM_L2_PROTECTION_FAULT_STATUS:0x nov 15 20:47:58 sander-pc kernel: amdgpu :0a:00.0: MORE_FAULTS: 0x0 nov 15 20:47:58 sander-pc kernel: amdgpu :0a:00.0: WALKER_ERROR: 0x0 nov 15 20:47:58 sander-pc kernel: amdgpu :0a:00.0: PERMISSION_FAULTS: 0x0 nov 15 20:47:58 sander-pc kernel: amdgpu :0a:00.0: MAPPING_ERROR: 0x0 nov 15 20:47:58 sander-pc kernel: amdgpu :0a:00.0: RW: 0x0 nov 15 20:48:09 sander-pc kernel: [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out! nov 15 20:48:09 sander-pc kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma1 timeout, signaled seq=6760, emitted seq=6763 nov 15 20:48:09 sander-pc kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process Xorg pid 811 thread Xorg:cs0 pid 974 nov 15 20:48:09 sander-pc kernel: [drm] GPU recovery disabled. -- You are receiving this mail because: You are the assignee for the
[Bug 205169] AMDGPU driver with Navi card hangs Xorg in fullscreen only.
https://bugzilla.kernel.org/show_bug.cgi?id=205169 --- Comment #23 from ArneJ (kernelbug5...@arnej.de) --- I just let Borderlands 2 run for about one hour in the menu which causes a hang without this patch in at most 3 minutes. Consider Borderlands 2 also fixed with this :) -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] drm/gma500: remove some set but not used variables
On Fri, Nov 15, 2019 at 10:27:04PM +0800, zhengbin wrote: > zhengbin (3): > drm/gma500: remove set but not used variable 'htotal' > drm/gma500: remove set but not used variable 'error' > drm/gma500: remove set but not used variable 'is_hdmi','is_crt' All three applied, thanks for the patches. -Daniel > > drivers/gpu/drm/gma500/cdv_intel_display.c | 7 ++- > drivers/gpu/drm/gma500/oaktrail_hdmi.c | 4 +--- > drivers/gpu/drm/gma500/psb_irq.c | 2 -- > 3 files changed, 3 insertions(+), 10 deletions(-) > > -- > 2.7.4 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/7] drm/atomic: Fix the early return in drm_atomic_set_mode_for_crtc()
From: Ville Syrjälä
The early return in drm_atomic_set_mode_for_crtc() isn't quite
right. It would mistakenly return and fail to update
crtc_state->enable if someone actually tried to set a zeroed
mode on a currently disabled crtc. That should never actually
happen in response to any userspace request as the zeroed mode
would get rejected earlier. However there is some chance of this
happening internally (eg. during hw state readout) so it seems
best to not let the state become totally inconsistent.
Additionally the early return will not be taken if we're trying to
disable an already disabled crtc. While that is not actually
harmful it is inconsistent, so let's handle that case as well.
Testcase: igt/kms_selftest/check_atomic_set_mode_for_crtc
Testcase: igt/kms_selftest/check_atomic_set_zeroed_mode_fort_crtc
Reviewed-by: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic_uapi.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 0d466d3b0809..a3a6a8137af4 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -68,8 +68,13 @@ int drm_atomic_set_mode_for_crtc(struct drm_crtc_state
*state,
struct drm_mode_modeinfo umode;
/* Early return for no change. */
- if (mode && memcmp(>mode, mode, sizeof(*mode)) == 0)
- return 0;
+ if (state->enable) {
+ if (mode && memcmp(>mode, mode, sizeof(*mode)) == 0)
+ return 0;
+ } else {
+ if (!mode)
+ return 0;
+ }
drm_property_blob_put(state->mode_blob);
state->mode_blob = NULL;
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 7/7] drm/atomic: Reduce setplane locking
From: Ville Syrjälä
Currently setplane grabs all modeset locks, which seems a bit
excessive. Let's reduce that to just the locks we really need
on atomic drivers. For non-atomic drivers let's stick to the
current scheme for now.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_plane.c | 56 +++--
1 file changed, 29 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index ef0cc33b43ce..e40d8a93294b 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -680,10 +680,14 @@ static int __setplane_internal(struct drm_plane *plane,
uint32_t src_w, uint32_t src_h,
struct drm_modeset_acquire_ctx *ctx)
{
- int ret = 0;
+ int ret;
WARN_ON(drm_drv_uses_atomic_modeset(plane->dev));
+ ret = drm_modeset_lock_all_ctx(plane->dev, ctx);
+ if (ret)
+ return ret;
+
/* No fb means shut it down */
if (!fb) {
plane->old_fb = plane->fb;
@@ -767,32 +771,24 @@ static int setplane_internal(struct drm_plane *plane,
uint32_t crtc_w, uint32_t crtc_h,
/* src_{x,y,w,h} values are 16.16 fixed point */
uint32_t src_x, uint32_t src_y,
-uint32_t src_w, uint32_t src_h)
+uint32_t src_w, uint32_t src_h,
+struct drm_modeset_acquire_ctx *ctx)
{
- struct drm_modeset_acquire_ctx ctx;
- int ret;
-
- DRM_MODESET_LOCK_ALL_BEGIN(plane->dev, ctx,
- DRM_MODESET_ACQUIRE_INTERRUPTIBLE, ret);
-
if (drm_drv_uses_atomic_modeset(plane->dev))
- ret = __setplane_atomic(plane, crtc, fb,
- crtc_x, crtc_y, crtc_w, crtc_h,
- src_x, src_y, src_w, src_h, );
+ return __setplane_atomic(plane, crtc, fb,
+crtc_x, crtc_y, crtc_w, crtc_h,
+src_x, src_y, src_w, src_h, ctx);
else
- ret = __setplane_internal(plane, crtc, fb,
- crtc_x, crtc_y, crtc_w, crtc_h,
- src_x, src_y, src_w, src_h, );
-
- DRM_MODESET_LOCK_ALL_END(ctx, ret);
-
- return ret;
+ return __setplane_internal(plane, crtc, fb,
+ crtc_x, crtc_y, crtc_w, crtc_h,
+ src_x, src_y, src_w, src_h, ctx);
}
int drm_mode_setplane(struct drm_device *dev, void *data,
struct drm_file *file_priv)
{
struct drm_mode_set_plane *plane_req = data;
+ struct drm_modeset_acquire_ctx ctx;
struct drm_plane *plane;
struct drm_crtc *crtc = NULL;
struct drm_framebuffer *fb = NULL;
@@ -829,11 +825,22 @@ int drm_mode_setplane(struct drm_device *dev, void *data,
}
}
+ drm_modeset_acquire_init(, DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
+
+retry:
ret = setplane_internal(plane, crtc, fb,
plane_req->crtc_x, plane_req->crtc_y,
plane_req->crtc_w, plane_req->crtc_h,
plane_req->src_x, plane_req->src_y,
- plane_req->src_w, plane_req->src_h);
+ plane_req->src_w, plane_req->src_h, );
+ if (ret == -EDEADLK) {
+ ret = drm_modeset_backoff();
+ if (!ret)
+ goto retry;
+ }
+
+ drm_modeset_drop_locks();
+ drm_modeset_acquire_fini();
if (fb)
drm_framebuffer_put(fb);
@@ -907,14 +914,9 @@ static int drm_mode_cursor_universal(struct drm_crtc *crtc,
src_h = fb->height << 16;
}
- if (drm_drv_uses_atomic_modeset(dev))
- ret = __setplane_atomic(plane, crtc, fb,
- crtc_x, crtc_y, crtc_w, crtc_h,
- 0, 0, src_w, src_h, ctx);
- else
- ret = __setplane_internal(plane, crtc, fb,
- crtc_x, crtc_y, crtc_w, crtc_h,
- 0, 0, src_w, src_h, ctx);
+ ret = setplane_internal(plane, crtc, fb,
+ crtc_x, crtc_y, crtc_w, crtc_h,
+ 0, 0, src_w, src_h, ctx);
if (fb)
drm_framebuffer_put(fb);
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/7] drm/selftests: Add some selftests for drm_atomic_set_mode_for_crtc()
From: Ville Syrjälä
Test the basics of drm_atomic_set_mode_for_crtc(), and in particular
verify that the function doesn't take the shortcut incorrectly.
Cc: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/selftests/Makefile| 3 +-
.../gpu/drm/selftests/drm_modeset_selftests.h | 2 +
.../gpu/drm/selftests/test-drm_atomic_uapi.c | 110 ++
.../drm/selftests/test-drm_modeset_common.h | 2 +
4 files changed, 116 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/selftests/test-drm_atomic_uapi.c
diff --git a/drivers/gpu/drm/selftests/Makefile
b/drivers/gpu/drm/selftests/Makefile
index d2137342b371..a5adc25bd345 100644
--- a/drivers/gpu/drm/selftests/Makefile
+++ b/drivers/gpu/drm/selftests/Makefile
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only
test-drm_modeset-y := test-drm_modeset_common.o test-drm_plane_helper.o \
test-drm_format.o test-drm_framebuffer.o \
- test-drm_damage_helper.o test-drm_dp_mst_helper.o
+ test-drm_damage_helper.o test-drm_dp_mst_helper.o \
+ test-drm_atomic_uapi.o
obj-$(CONFIG_DRM_DEBUG_SELFTEST) += test-drm_mm.o test-drm_modeset.o
test-drm_cmdline_parser.o
diff --git a/drivers/gpu/drm/selftests/drm_modeset_selftests.h
b/drivers/gpu/drm/selftests/drm_modeset_selftests.h
index 1898de0b4a4d..2cc4e2f43286 100644
--- a/drivers/gpu/drm/selftests/drm_modeset_selftests.h
+++ b/drivers/gpu/drm/selftests/drm_modeset_selftests.h
@@ -6,6 +6,8 @@
*
* Tests are executed in order by igt/drm_selftests_helper
*/
+selftest(atomic_set_mode_for_crtc, igt_atomic_set_mode_for_crtc)
+selftest(atomic_set_zeroed_mode_for_crtc, igt_atomic_set_zeroed_mode_for_crtc)
selftest(check_plane_state, igt_check_plane_state)
selftest(check_drm_format_block_width, igt_check_drm_format_block_width)
selftest(check_drm_format_block_height, igt_check_drm_format_block_height)
diff --git a/drivers/gpu/drm/selftests/test-drm_atomic_uapi.c
b/drivers/gpu/drm/selftests/test-drm_atomic_uapi.c
new file mode 100644
index ..0f9a4d0d2541
--- /dev/null
+++ b/drivers/gpu/drm/selftests/test-drm_atomic_uapi.c
@@ -0,0 +1,110 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Test cases for the drm_atomic_uapi functions
+ */
+
+#define pr_fmt(fmt) "drm_atomic_uapi: " fmt
+
+#include
+#include
+#include
+#include
+
+#include "test-drm_modeset_common.h"
+
+static const struct drm_display_mode zeroed_mode;
+
+static struct drm_driver mock_driver;
+static struct drm_device mock_device;
+static struct drm_crtc mock_crtc;
+
+static void init(void)
+{
+ memset(_driver, 0, sizeof(mock_driver));
+ memset(_device, 0, sizeof(mock_device));
+ memset(_crtc, 0, sizeof(mock_crtc));
+
+ mock_device.driver = _driver;
+ mock_crtc.dev = _device;
+
+ drm_mode_config_init(_device);
+}
+
+static void cleanup(void)
+{
+ drm_mode_config_cleanup(_device);
+}
+
+int igt_atomic_set_mode_for_crtc(void *ignored)
+{
+ static const struct drm_display_mode mode1 = {
+ DRM_MODE("640x480", DRM_MODE_TYPE_DRIVER, 25175,
+640, 656, 752, 800, 0, 480, 490, 492, 525, 0,
+DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC)
+ };
+ static const struct drm_display_mode mode2 = {
+ DRM_MODE("1024x768", DRM_MODE_TYPE_DRIVER, 65000,
+1024, 1048, 1184, 1344, 0, 768, 771, 777, 806, 0,
+DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC)
+ };
+ struct drm_crtc_state crtc_state = {
+ .crtc = _crtc,
+ };
+ int ret;
+
+ init();
+
+ /*
+* Make sure drm_atomic_set_mode_for_crtc()
+* updates the crtc state correctly.
+*/
+ ret = drm_atomic_set_mode_for_crtc(_state, );
+ FAIL(ret < 0, "Unable to set mode on crtc\n");
+ FAIL_ON(!crtc_state.enable);
+ FAIL_ON(memcmp(_state.mode, , sizeof(mode1)));
+
+ ret = drm_atomic_set_mode_for_crtc(_state, );
+ FAIL(ret < 0, "Unable to set mode on crtc\n");
+ FAIL_ON(!crtc_state.enable);
+ FAIL_ON(memcmp(_state.mode, , sizeof(mode2)));
+
+ ret = drm_atomic_set_mode_for_crtc(_state, NULL);
+ FAIL(ret < 0, "Unable to unset mode on crtc\n");
+ FAIL_ON(crtc_state.enable);
+ FAIL_ON(memcmp(_state.mode, _mode, sizeof(zeroed_mode)));
+
+ cleanup();
+
+ return 0;
+}
+
+int igt_atomic_set_zeroed_mode_for_crtc(void *ignored)
+{
+ struct drm_crtc_state crtc_state = {
+ .crtc = _crtc,
+ };
+ int ret;
+
+ init();
+
+ /*
+* Make sure drm_atomic_set_mode_for_crtc() doesn't
+* take the shortcut and fail to update crtc_state.enable
+* when passed a zeroed mode (which is technically not
+* valid, but as drm_atomic_set_mode_for_crtc() does no
+* mode validation it should still work).
+
[PATCH 2/7] drm: Allocate the page flip event earlier
From: Ville Syrjälä
Can't see why we need to delay the page flip event allocation until the
last moment. Move it earlier to simplify error handling.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_plane.c | 45 +++--
1 file changed, 23 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 14a292d7817d..38878da5b704 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -1116,6 +1116,26 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
goto put_vblank;
}
+ if (page_flip->flags & DRM_MODE_PAGE_FLIP_EVENT) {
+ e = kzalloc(sizeof(*e), GFP_KERNEL);
+ if (!e) {
+ ret = -ENOMEM;
+ goto put_fb;
+ }
+
+ e->event.base.type = DRM_EVENT_FLIP_COMPLETE;
+ e->event.base.length = sizeof(e->event);
+ e->event.vbl.user_data = page_flip->user_data;
+ e->event.vbl.crtc_id = crtc->base.id;
+
+ ret = drm_event_reserve_init(dev, file_priv, >base,
>event.base);
+ if (ret) {
+ kfree(e);
+ e = NULL;
+ goto put_fb;
+ }
+ }
+
drm_modeset_acquire_init(, DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
retry:
ret = drm_modeset_lock(>mutex, );
@@ -1160,26 +1180,6 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
goto out;
}
- if (page_flip->flags & DRM_MODE_PAGE_FLIP_EVENT) {
- e = kzalloc(sizeof *e, GFP_KERNEL);
- if (!e) {
- ret = -ENOMEM;
- goto out;
- }
-
- e->event.base.type = DRM_EVENT_FLIP_COMPLETE;
- e->event.base.length = sizeof(e->event);
- e->event.vbl.user_data = page_flip->user_data;
- e->event.vbl.crtc_id = crtc->base.id;
-
- ret = drm_event_reserve_init(dev, file_priv, >base,
>event.base);
- if (ret) {
- kfree(e);
- e = NULL;
- goto out;
- }
- }
-
plane->old_fb = plane->fb;
if (crtc->funcs->page_flip_target)
ret = crtc->funcs->page_flip_target(crtc, fb, e,
@@ -1190,8 +1190,6 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
ret = crtc->funcs->page_flip(crtc, fb, e, page_flip->flags,
);
if (ret) {
- if (page_flip->flags & DRM_MODE_PAGE_FLIP_EVENT)
- drm_event_cancel_free(dev, >base);
/* Keep the old fb, don't unref it. */
plane->old_fb = NULL;
} else {
@@ -1215,6 +1213,9 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
drm_modeset_drop_locks();
drm_modeset_acquire_fini();
+ if (ret && e)
+ drm_event_cancel_free(dev, >base);
+put_fb:
drm_framebuffer_put(fb);
put_vblank:
if (ret && crtc->funcs->page_flip_target)
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/7] drm: Extract page_flip_{internal,atomic}()
From: Ville Syrjälä
Yank out the code for the plane->fb/old_fb/crtc handling from
the page flip path into page_flip_internal(), and provide a
simpler variant for atomic drivers.
We'll also move the fb vs. src viewport checks into the new
functions as they are slightly different between the two paths.
If the atomic .page_flip() implementations are guaranteed
to call drm_atomic_plane_check() we could even drop the check
entirely from page_flip_atomic(). For now toss in a FIXME.
v2: Bit more polish in page_flip_internal()
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_plane.c | 159 +++-
1 file changed, 102 insertions(+), 57 deletions(-)
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 38878da5b704..6052475a20a5 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -1031,13 +1031,109 @@ int drm_mode_cursor2_ioctl(struct drm_device *dev,
return drm_mode_cursor_common(dev, req, file_priv);
}
+static int page_flip_check_fbs(const struct drm_framebuffer *fb,
+ const struct drm_framebuffer *old_fb)
+{
+ /* The framebuffer is currently unbound, presumably
+* due to a hotplug event, that userspace has not
+* yet discovered.
+*/
+ if (!old_fb)
+ return -EBUSY;
+
+ if (old_fb->format != fb->format) {
+ DRM_DEBUG_KMS("Page flip is not allowed to change frame buffer
format.\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int page_flip_internal(struct drm_crtc *crtc,
+ struct drm_framebuffer *fb,
+ struct drm_pending_vblank_event *e,
+ u32 flags,
+ u32 target_vblank,
+ struct drm_modeset_acquire_ctx *ctx)
+{
+ struct drm_plane *plane = crtc->primary;
+ int ret;
+
+ WARN_ON(drm_drv_uses_atomic_modeset(crtc->dev));
+
+ ret = drm_crtc_check_viewport(crtc, crtc->x, crtc->y,
+ >mode, fb);
+ if (ret)
+ return ret;
+
+ ret = page_flip_check_fbs(fb, plane->fb);
+ if (ret)
+ return ret;
+
+ plane->old_fb = plane->fb;
+ if (crtc->funcs->page_flip_target)
+ ret = crtc->funcs->page_flip_target(crtc, fb, e, flags,
+ target_vblank, ctx);
+ else
+ ret = crtc->funcs->page_flip(crtc, fb, e, flags, ctx);
+ if (ret) {
+ plane->old_fb = NULL;
+ return ret;
+ }
+
+ plane->fb = fb;
+ drm_framebuffer_get(plane->fb);
+
+ drm_framebuffer_put(plane->old_fb);
+ plane->old_fb = NULL;
+
+ return 0;
+}
+
+static int page_flip_atomic(struct drm_crtc *crtc,
+ struct drm_framebuffer *fb,
+ struct drm_pending_vblank_event *e,
+ u32 flags,
+ u32 target_vblank,
+ struct drm_modeset_acquire_ctx *ctx)
+{
+ struct drm_plane *plane = crtc->primary;
+ struct drm_plane_state *plane_state = plane->state;
+ int ret;
+
+ WARN_ON(!drm_drv_uses_atomic_modeset(crtc->dev));
+
+ /*
+* FIXME: Can we assume all drivers end up calling
+* drm_atomic_plane_check() in their page flip paths?
+* If so we could remove this.
+*/
+ ret = drm_framebuffer_check_src_coords(plane_state->src_x,
+ plane_state->src_y,
+ plane_state->src_w,
+ plane_state->src_h,
+ fb);
+ if (ret)
+ return ret;
+
+ ret = page_flip_check_fbs(fb, plane_state->fb);
+ if (ret)
+ return ret;
+
+ if (crtc->funcs->page_flip_target)
+ return crtc->funcs->page_flip_target(crtc, fb, e, flags,
+target_vblank, ctx);
+ else
+ return crtc->funcs->page_flip(crtc, fb, e, flags, ctx);
+}
+
int drm_mode_page_flip_ioctl(struct drm_device *dev,
void *data, struct drm_file *file_priv)
{
struct drm_mode_crtc_page_flip_target *page_flip = data;
struct drm_crtc *crtc;
struct drm_plane *plane;
- struct drm_framebuffer *fb, *old_fb;
+ struct drm_framebuffer *fb;
struct drm_pending_vblank_event *e = NULL;
u32 target_vblank = page_flip->sequence;
struct drm_modeset_acquire_ctx ctx;
@@ -1145,65 +1241,14 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
if (ret)
goto out;
- if (plane->state)
- old_fb = plane->state->fb;
+ if
[PATCH 4/7] drm: Simplify the setplane old_fb handling further
From: Ville Syrjälä
Instead of doing the things in a convoluted way with the failure and
success paths mixed up let's just clear old_fb when we encounter an
error and bail out immediately. We already did this for the pageflip
path.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_plane.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 6052475a20a5..ef0cc33b43ce 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -688,12 +688,13 @@ static int __setplane_internal(struct drm_plane *plane,
if (!fb) {
plane->old_fb = plane->fb;
ret = plane->funcs->disable_plane(plane, ctx);
- if (!ret) {
- plane->crtc = NULL;
- plane->fb = NULL;
- } else {
+ if (ret) {
plane->old_fb = NULL;
+ return ret;
}
+
+ plane->crtc = NULL;
+ plane->fb = NULL;
goto out;
}
@@ -701,26 +702,27 @@ static int __setplane_internal(struct drm_plane *plane,
crtc_x, crtc_y, crtc_w, crtc_h,
src_x, src_y, src_w, src_h);
if (ret)
- goto out;
+ return ret;
plane->old_fb = plane->fb;
ret = plane->funcs->update_plane(plane, crtc, fb,
crtc_x, crtc_y, crtc_w, crtc_h,
src_x, src_y, src_w, src_h, ctx);
- if (!ret) {
- plane->crtc = crtc;
- plane->fb = fb;
- drm_framebuffer_get(plane->fb);
- } else {
+ if (ret) {
plane->old_fb = NULL;
+ return ret;
}
+ plane->crtc = crtc;
+ plane->fb = fb;
+ drm_framebuffer_get(plane->fb);
+
out:
if (plane->old_fb)
drm_framebuffer_put(plane->old_fb);
plane->old_fb = NULL;
- return ret;
+ return 0;
}
static int __setplane_atomic(struct drm_plane *plane,
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/7] drm: Random pile of core stuff
From: Ville Syrjälä
I found this random pile of stuff lying around. Dusted it off
and tossed in the new selftests.
Ville Syrjälä (7):
drm: Move page_flip fb lookup earlier
drm: Allocate the page flip event earlier
drm: Extract page_flip_{internal,atomic}()
drm: Simplify the setplane old_fb handling further
drm/selftests: Add some selftests for drm_atomic_set_mode_for_crtc()
drm/atomic: Fix the early return in drm_atomic_set_mode_for_crtc()
drm/atomic: Reduce setplane locking
drivers/gpu/drm/drm_atomic_uapi.c | 9 +-
drivers/gpu/drm/drm_plane.c | 285 +++---
drivers/gpu/drm/selftests/Makefile| 3 +-
.../gpu/drm/selftests/drm_modeset_selftests.h | 2 +
.../gpu/drm/selftests/test-drm_atomic_uapi.c | 110 +++
.../drm/selftests/test-drm_modeset_common.h | 2 +
6 files changed, 291 insertions(+), 120 deletions(-)
create mode 100644 drivers/gpu/drm/selftests/test-drm_atomic_uapi.c
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/7] drm: Move page_flip fb lookup earlier
From: Ville Syrjälä
No reason that I can see to delay the fb lookup this late. Moving it
earlier allows us to keep it outside of the lock retry loop. This
makes error handling and whatnot simpler.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_plane.c | 29 +++--
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index d6ad60ab0d38..14a292d7817d 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -1037,7 +1037,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
struct drm_mode_crtc_page_flip_target *page_flip = data;
struct drm_crtc *crtc;
struct drm_plane *plane;
- struct drm_framebuffer *fb = NULL, *old_fb;
+ struct drm_framebuffer *fb, *old_fb;
struct drm_pending_vblank_event *e = NULL;
u32 target_vblank = page_flip->sequence;
struct drm_modeset_acquire_ctx ctx;
@@ -1086,16 +1086,16 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
DRM_DEBUG("Invalid absolute flip target %u, "
"must be <= %u\n", target_vblank,
current_vblank + 1);
- drm_crtc_vblank_put(crtc);
- return -EINVAL;
+ ret = -EINVAL;
+ goto put_vblank;
}
break;
case DRM_MODE_PAGE_FLIP_TARGET_RELATIVE:
if (target_vblank != 0 && target_vblank != 1) {
DRM_DEBUG("Invalid relative flip target %u, "
"must be 0 or 1\n", target_vblank);
- drm_crtc_vblank_put(crtc);
- return -EINVAL;
+ ret = -EINVAL;
+ goto put_vblank;
}
target_vblank += current_vblank;
break;
@@ -1106,7 +1106,14 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
}
} else if (crtc->funcs->page_flip == NULL ||
(page_flip->flags & DRM_MODE_PAGE_FLIP_TARGET)) {
- return -EINVAL;
+ ret = -EINVAL;
+ goto put_vblank;
+ }
+
+ fb = drm_framebuffer_lookup(dev, file_priv, page_flip->fb_id);
+ if (!fb) {
+ ret = -ENOENT;
+ goto put_vblank;
}
drm_modeset_acquire_init(, DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
@@ -1132,12 +1139,6 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
goto out;
}
- fb = drm_framebuffer_lookup(dev, file_priv, page_flip->fb_id);
- if (!fb) {
- ret = -ENOENT;
- goto out;
- }
-
if (plane->state) {
const struct drm_plane_state *state = plane->state;
@@ -1201,8 +1202,6 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
}
out:
- if (fb)
- drm_framebuffer_put(fb);
if (plane->old_fb)
drm_framebuffer_put(plane->old_fb);
plane->old_fb = NULL;
@@ -1216,6 +1215,8 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
drm_modeset_drop_locks();
drm_modeset_acquire_fini();
+ drm_framebuffer_put(fb);
+put_vblank:
if (ret && crtc->funcs->page_flip_target)
drm_crtc_vblank_put(crtc);
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/amdgpu/dm: Do not throw an error for a display with no audio
On Fri, Nov 15, 2019 at 10:18:26AM +0100, Daniel Vetter wrote:
> On Fri, Nov 15, 2019 at 10:04 AM Jean Delvare wrote:
> >
> > Hi Chris,
> >
> > On Thu, 14 Nov 2019 20:44:13 +, Chris Wilson wrote:
> > > An old display with no audio may not have an EDID with a CEA block, or
> > > it may simply be too old to support audio. This is not a driver error,
> > > so don't flag it as such.
> > >
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112140
> > > References: ae2a3495973e ("drm/amd: be quiet when no SAD block is found")
> > > Signed-off-by: Chris Wilson
> > > Cc: Harry Wentland
> > > Cc: Jean Delvare
> > > Cc: Alex Deucher
> > > ---
> > > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 --
> > > 1 file changed, 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > > index 11e5784aa62a..04808dbecab3 100644
> > > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > > @@ -97,8 +97,6 @@ enum dc_edid_status dm_helpers_parse_edid_caps(
> > > (struct edid *) edid->raw_edid);
> > >
> > > sad_count = drm_edid_to_sad((struct edid *) edid->raw_edid, );
> > > - if (sad_count < 0)
> > > - DRM_ERROR("Couldn't read SADs: %d\n", sad_count);
> > > if (sad_count <= 0)
> > > return result;
> > >
> >
> > I still believe that my approach was a better way to solve this problem:
> >
> > https://patchwork.freedesktop.org/patch/329066/
> >
> > Your approach would have to be applied to all individual drivers (all
> > callers of drm_edid_to_sad). It also prevents reporting actual errors.
> >
> > Should I resend my patch?
>
> I think we can do both, just ask Ville to apply the patch for you (he
> has commit rights to drm-misc). Or resend and then ping Ville on irc.
Ideally would have been something for AMD folks since they're the
only user of those functions AFAICS. But I just pushed it anyway.
Thanks for the patch.
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/edid: Add alternate clock for SMPTE 4K
On Tue, Nov 12, 2019 at 10:36:54AM +0100, Neil Armstrong wrote:
> On 12/11/2019 08:53, Wayne Lin wrote:
> > [Why]
> > In hdmi_mode_alternate_clock(), it adds an exception for VIC 4
> > mode (4096x2160@24) due to there is no alternate clock defined for
> > that mode in HDMI1.4b. But HDMI2.0 adds 23.98Hz for that mode.
> >
> > [How]
> > Remove the exception
>
> Shouldn't it be only bypassed when the sink is HDMI2 ?
IMO just nuke the check. Can't see much harm coming
from adding the 23.98Hz mode on HDMI 1.4 as well.
>
> Neil
>
> >
> > Signed-off-by: Wayne Lin
> > ---
> > drivers/gpu/drm/drm_edid.c | 3 ---
> > 1 file changed, 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index fcd7ae29049d..ed2782c53a93 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -3126,9 +3126,6 @@ static enum hdmi_picture_aspect
> > drm_get_hdmi_aspect_ratio(const u8 video_code)
> > static unsigned int
> > hdmi_mode_alternate_clock(const struct drm_display_mode *hdmi_mode)
> > {
> > - if (hdmi_mode->vdisplay == 4096 && hdmi_mode->hdisplay == 2160)
> > - return hdmi_mode->clock;
> > -
> > return cea_mode_alternate_clock(hdmi_mode);
> > }
> >
> >
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/edid: Add alternate clock for SMPTE 4K
On Tue, Nov 12, 2019 at 03:53:07PM +0800, Wayne Lin wrote:
> [Why]
> In hdmi_mode_alternate_clock(), it adds an exception for VIC 4
> mode (4096x2160@24) due to there is no alternate clock defined for
> that mode in HDMI1.4b. But HDMI2.0 adds 23.98Hz for that mode.
>
> [How]
> Remove the exception
>
> Signed-off-by: Wayne Lin
> ---
> drivers/gpu/drm/drm_edid.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index fcd7ae29049d..ed2782c53a93 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3126,9 +3126,6 @@ static enum hdmi_picture_aspect
> drm_get_hdmi_aspect_ratio(const u8 video_code)
^ the comment above would no longer match the code. Pls fix it up.
> static unsigned int
> hdmi_mode_alternate_clock(const struct drm_display_mode *hdmi_mode)
> {
> - if (hdmi_mode->vdisplay == 4096 && hdmi_mode->hdisplay == 2160)
> - return hdmi_mode->clock;
> -
> return cea_mode_alternate_clock(hdmi_mode);
> }
>
> --
> 2.17.1
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/edid: Add aspect ratios to HDMI 4K modes
On Tue, Nov 12, 2019 at 03:53:06PM +0800, Wayne Lin wrote:
> [Why]
> HDMI 2.0 adds aspect ratio attribute to distinguish different
> 4k modes. According to Appendix E of HDMI 2.0 spec, source should
> use VSIF to indicate video mode only when the mode is one defined
> in HDMI 1.4b 4K modes. Otherwise, use AVI infoframes to convey VIC.
>
> Current code doesn't take aspect ratio into consideration while
> constructing avi infoframe. Should modify that.
>
> [How]
> Inherit Ville Syrjälä's work
> "drm/edid: Prep for HDMI VIC aspect ratio" at
> https://patchwork.kernel.org/patch/11174639/
>
> Add picture_aspect_ratio attributes to edid_4k_modes[] and
> construct VIC and HDMI_VIC by taking aspect ratio into
> consideration.
>
> Signed-off-by: Wayne Lin
> ---
> drivers/gpu/drm/drm_edid.c | 45 +-
> 1 file changed, 35 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 77a39fc76045..fcd7ae29049d 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1288,25 +1288,25 @@ static const struct drm_display_mode edid_4k_modes[]
> = {
> 3840, 4016, 4104, 4400, 0,
> 2160, 2168, 2178, 2250, 0,
> DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> - .vrefresh = 30, },
> + .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> /* 2 - 3840x2160@25Hz */
> { DRM_MODE("3840x2160", DRM_MODE_TYPE_DRIVER, 297000,
> 3840, 4896, 4984, 5280, 0,
> 2160, 2168, 2178, 2250, 0,
> DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> - .vrefresh = 25, },
> + .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> /* 3 - 3840x2160@24Hz */
> { DRM_MODE("3840x2160", DRM_MODE_TYPE_DRIVER, 297000,
> 3840, 5116, 5204, 5500, 0,
> 2160, 2168, 2178, 2250, 0,
> DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> - .vrefresh = 24, },
> + .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> /* 4 - 4096x2160@24Hz (SMPTE) */
> { DRM_MODE("4096x2160", DRM_MODE_TYPE_DRIVER, 297000,
> 4096, 5116, 5204, 5500, 0,
> 2160, 2168, 2178, 2250, 0,
> DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> - .vrefresh = 24, },
> + .vrefresh = 24, HDMI_PICTURE_ASPECT_256_135},
^ ^
Missing named initializer. Missing ", "
> };
>
> /*** DDC fetch and block validation ***/
> @@ -3110,6 +3110,11 @@ static enum hdmi_picture_aspect
> drm_get_cea_aspect_ratio(const u8 video_code)
> return edid_cea_modes[video_code].picture_aspect_ratio;
> }
>
> +static enum hdmi_picture_aspect drm_get_hdmi_aspect_ratio(const u8
> video_code)
> +{
> + return edid_4k_modes[video_code].picture_aspect_ratio;
> +}
> +
> /*
> * Calculate the alternate clock for HDMI modes (those from the HDMI vendor
> * specific block).
> @@ -3136,6 +3141,9 @@ static u8 drm_match_hdmi_mode_clock_tolerance(const
> struct drm_display_mode *to_
> if (!to_match->clock)
> return 0;
>
> + if (to_match->picture_aspect_ratio)
> + match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
> +
> for (vic = 1; vic < ARRAY_SIZE(edid_4k_modes); vic++) {
> const struct drm_display_mode *hdmi_mode = _4k_modes[vic];
> unsigned int clock1, clock2;
> @@ -3171,6 +3179,9 @@ static u8 drm_match_hdmi_mode(const struct
> drm_display_mode *to_match)
> if (!to_match->clock)
> return 0;
>
> + if (to_match->picture_aspect_ratio)
> + match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
> +
> for (vic = 1; vic < ARRAY_SIZE(edid_4k_modes); vic++) {
> const struct drm_display_mode *hdmi_mode = _4k_modes[vic];
> unsigned int clock1, clock2;
> @@ -5118,6 +5129,7 @@ drm_hdmi_avi_infoframe_from_display_mode(struct
> hdmi_avi_infoframe *frame,
>const struct drm_display_mode *mode)
> {
> enum hdmi_picture_aspect picture_aspect;
> + u8 vic, hdmi_vic;
> int err;
>
> if (!frame || !mode)
> @@ -5130,7 +5142,8 @@ drm_hdmi_avi_infoframe_from_display_mode(struct
> hdmi_avi_infoframe *frame,
> if (mode->flags & DRM_MODE_FLAG_DBLCLK)
> frame->pixel_repeat = 1;
>
> - frame->video_code = drm_mode_cea_vic(connector, mode);
> + vic = drm_mode_cea_vic(connector, mode);
> + hdmi_vic = drm_mode_hdmi_vic(connector, mode);
>
> frame->picture_aspect = HDMI_PICTURE_ASPECT_NONE;
>
> @@ -5144,11 +5157,15 @@ drm_hdmi_avi_infoframe_from_display_mode(struct
> hdmi_avi_infoframe *frame,
>
> /*
>* Populate picture aspect ratio from either
> - * user input (if specified) or from the CEA mode list.
>
[Bug 205169] AMDGPU driver with Navi card hangs Xorg in fullscreen only.
https://bugzilla.kernel.org/show_bug.cgi?id=205169 --- Comment #22 from Shmerl (shtetl...@gmail.com) --- It fixes Pathfinder: Kingamer too. But first let the patch be upstreamed, then it's OK to close the bug :) -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205169] AMDGPU driver with Navi card hangs Xorg in fullscreen only.
https://bugzilla.kernel.org/show_bug.cgi?id=205169 --- Comment #21 from Dmitri Seletski (drj...@gmail.com) --- (In reply to Alex Deucher from comment #20) > Created attachment 285935 [details] > possible fix > > Does this patch help? It did not just solve one problem, but two! First of all it solved original issue. Second of all, some games were hanging right before quitting. Xorg was responsive, but processes did not disappear. I was blaming on proprietary code. Apparently it was same bug, just different invocation of it. Please close this bug report. My problem is now fixed. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 112266] [Navi] Pathfinder: Kingmaker is causing a GPU hang: flip_done timed out error
https://bugs.freedesktop.org/show_bug.cgi?id=112266 --- Comment #7 from Shmerl --- (In reply to Alex Deucher from comment #6) > Created attachment 145971 [details] [review] > possible fix > > Does this patch help? Just applied that patch on on top of latest 5.4-rc7+ and tested it. It prevents the hang in Pathfinder: Kingmaker! Thanks! -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 09/24] vfio, mm: fix get_user_pages_remote() and FOLL_LONGTERM
On Thu, Nov 14, 2019 at 09:53:25PM -0800, John Hubbard wrote:
> As it says in the updated comment in gup.c: current FOLL_LONGTERM
> behavior is incompatible with FAULT_FLAG_ALLOW_RETRY because of the
> FS DAX check requirement on vmas.
>
> However, the corresponding restriction in get_user_pages_remote() was
> slightly stricter than is actually required: it forbade all
> FOLL_LONGTERM callers, but we can actually allow FOLL_LONGTERM callers
> that do not set the "locked" arg.
>
> Update the code and comments accordingly, and update the VFIO caller
> to take advantage of this, fixing a bug as a result: the VFIO caller
> is logically a FOLL_LONGTERM user.
>
> Also, remove an unnessary pair of calls that were releasing and
> reacquiring the mmap_sem. There is no need to avoid holding mmap_sem
> just in order to call page_to_pfn().
>
> Also, move the DAX check ("if a VMA is DAX, don't allow long term
> pinning") from the VFIO call site, all the way into the internals
> of get_user_pages_remote() and __gup_longterm_locked(). That is:
> get_user_pages_remote() calls __gup_longterm_locked(), which in turn
> calls check_dax_vmas(). It's lightly explained in the comments as well.
>
> Thanks to Jason Gunthorpe for pointing out a clean way to fix this,
> and to Dan Williams for helping clarify the DAX refactoring.
>
> Suggested-by: Jason Gunthorpe
> Cc: Dan Williams
> Cc: Jerome Glisse
> Cc: Ira Weiny
Reviewed-by: Ira Weiny
> Signed-off-by: John Hubbard
> ---
> drivers/vfio/vfio_iommu_type1.c | 30 +-
> mm/gup.c| 27 ++-
> 2 files changed, 27 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
> index d864277ea16f..c7a111ad9975 100644
> --- a/drivers/vfio/vfio_iommu_type1.c
> +++ b/drivers/vfio/vfio_iommu_type1.c
> @@ -340,7 +340,6 @@ static int vaddr_get_pfn(struct mm_struct *mm, unsigned
> long vaddr,
> {
> struct page *page[1];
> struct vm_area_struct *vma;
> - struct vm_area_struct *vmas[1];
> unsigned int flags = 0;
> int ret;
>
> @@ -348,33 +347,14 @@ static int vaddr_get_pfn(struct mm_struct *mm, unsigned
> long vaddr,
> flags |= FOLL_WRITE;
>
> down_read(>mmap_sem);
> - if (mm == current->mm) {
> - ret = get_user_pages(vaddr, 1, flags | FOLL_LONGTERM, page,
> - vmas);
> - } else {
> - ret = get_user_pages_remote(NULL, mm, vaddr, 1, flags, page,
> - vmas, NULL);
> - /*
> - * The lifetime of a vaddr_get_pfn() page pin is
> - * userspace-controlled. In the fs-dax case this could
> - * lead to indefinite stalls in filesystem operations.
> - * Disallow attempts to pin fs-dax pages via this
> - * interface.
> - */
> - if (ret > 0 && vma_is_fsdax(vmas[0])) {
> - ret = -EOPNOTSUPP;
> - put_page(page[0]);
> - }
> - }
> - up_read(>mmap_sem);
> -
> + ret = get_user_pages_remote(NULL, mm, vaddr, 1, flags | FOLL_LONGTERM,
> + page, NULL, NULL);
> if (ret == 1) {
> *pfn = page_to_pfn(page[0]);
> - return 0;
> + ret = 0;
> + goto done;
> }
>
> - down_read(>mmap_sem);
> -
> vaddr = untagged_addr(vaddr);
>
> vma = find_vma_intersection(mm, vaddr, vaddr + 1);
> @@ -384,7 +364,7 @@ static int vaddr_get_pfn(struct mm_struct *mm, unsigned
> long vaddr,
> if (is_invalid_reserved_pfn(*pfn))
> ret = 0;
> }
> -
> +done:
> up_read(>mmap_sem);
> return ret;
> }
> diff --git a/mm/gup.c b/mm/gup.c
> index b859bd4da4d7..6cf613bfe7dc 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -29,6 +29,13 @@ struct follow_page_context {
> unsigned int page_mask;
> };
>
> +static __always_inline long __gup_longterm_locked(struct task_struct *tsk,
> + struct mm_struct *mm,
> + unsigned long start,
> + unsigned long nr_pages,
> + struct page **pages,
> + struct vm_area_struct **vmas,
> + unsigned int flags);
> /*
> * Return the compound head page with ref appropriately incremented,
> * or NULL if that failed.
> @@ -1167,13 +1174,23 @@ long get_user_pages_remote(struct task_struct *tsk,
> struct mm_struct *mm,
> struct vm_area_struct **vmas, int *locked)
> {
> /*
> - * FIXME: Current FOLL_LONGTERM behavior is incompatible with
> + * Parts of FOLL_LONGTERM behavior are incompatible with
>*
Re: [PATCH 1/2] drm/nouveau: remove set but not used variable 'pclks','width'
Reviewed-by: Lyude Paul
On Fri, 2019-11-15 at 21:42 +0800, zhengbin wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/nouveau/dispnv04/arb.c: In function nv04_calc_arb:
> drivers/gpu/drm/nouveau/dispnv04/arb.c:59:21: warning: variable pclks set
> but not used [-Wunused-but-set-variable]
> drivers/gpu/drm/nouveau/dispnv04/arb.c: In function nv04_calc_arb:
> drivers/gpu/drm/nouveau/dispnv04/arb.c:58:21: warning: variable width set
> but not used [-Wunused-but-set-variable]
>
> It is introduced by commit 6ee738610f41 ("drm/nouveau:
> Add DRM driver for NVIDIA GPUs"), but never used,
> so remove it.
>
> Reported-by: Hulk Robot
> Signed-off-by: zhengbin
> ---
> drivers/gpu/drm/nouveau/dispnv04/arb.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv04/arb.c
> b/drivers/gpu/drm/nouveau/dispnv04/arb.c
> index 3624955..9d4a2d9 100644
> --- a/drivers/gpu/drm/nouveau/dispnv04/arb.c
> +++ b/drivers/gpu/drm/nouveau/dispnv04/arb.c
> @@ -53,8 +53,8 @@ struct nv_sim_state {
> static void
> nv04_calc_arb(struct nv_fifo_info *fifo, struct nv_sim_state *arb)
> {
> - int pagemiss, cas, width, bpp;
> - int nvclks, mclks, pclks, crtpagemiss;
> + int pagemiss, cas, bpp;
> + int nvclks, mclks, crtpagemiss;
> int found, mclk_extra, mclk_loop, cbs, m1, p1;
> int mclk_freq, pclk_freq, nvclk_freq;
> int us_m, us_n, us_p, crtc_drain_rate;
> @@ -65,11 +65,9 @@ nv04_calc_arb(struct nv_fifo_info *fifo, struct
> nv_sim_state *arb)
> nvclk_freq = arb->nvclk_khz;
> pagemiss = arb->mem_page_miss;
> cas = arb->mem_latency;
> - width = arb->memory_width >> 6;
> bpp = arb->bpp;
> cbs = 128;
>
> - pclks = 2;
> nvclks = 10;
> mclks = 13 + cas;
> mclk_extra = 3;
> --
> 2.7.4
>
--
Cheers,
Lyude Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/nouveau: remove set but not used variable 'mem'
Reviewed-by: Lyude Paul
On Fri, 2019-11-15 at 21:42 +0800, zhengbin wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/nouveau/nouveau_ttm.c: In function nouveau_vram_manager_new:
> drivers/gpu/drm/nouveau/nouveau_ttm.c:66:22: warning: variable mem set but
> not used [-Wunused-but-set-variable]
> drivers/gpu/drm/nouveau/nouveau_ttm.c: In function nouveau_gart_manager_new:
> drivers/gpu/drm/nouveau/nouveau_ttm.c:106:22: warning: variable mem set but
> not used [-Wunused-but-set-variable]
>
> The first 'mem' is introduced by commit 9ce523cc3bf2 ("drm/nouveau:
> separate buffer object backing memory from nvkm structures"),
> but never used, so remove it.
>
> The second 'mem' is not used since commit d7722134b825 ("drm/nouveau:
> switch over to new memory and vmm interfaces")
>
> Reported-by: Hulk Robot
> Signed-off-by: zhengbin
> ---
> drivers/gpu/drm/nouveau/nouveau_ttm.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c
> b/drivers/gpu/drm/nouveau/nouveau_ttm.c
> index 77a0c6a..7ca0a24 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
> @@ -63,14 +63,12 @@ nouveau_vram_manager_new(struct ttm_mem_type_manager
> *man,
> {
> struct nouveau_bo *nvbo = nouveau_bo(bo);
> struct nouveau_drm *drm = nouveau_bdev(bo->bdev);
> - struct nouveau_mem *mem;
> int ret;
>
> if (drm->client.device.info.ram_size == 0)
> return -ENOMEM;
>
> ret = nouveau_mem_new(>master, nvbo->kind, nvbo->comp, reg);
> - mem = nouveau_mem(reg);
> if (ret)
> return ret;
>
> @@ -103,11 +101,9 @@ nouveau_gart_manager_new(struct ttm_mem_type_manager
> *man,
> {
> struct nouveau_bo *nvbo = nouveau_bo(bo);
> struct nouveau_drm *drm = nouveau_bdev(bo->bdev);
> - struct nouveau_mem *mem;
> int ret;
>
> ret = nouveau_mem_new(>master, nvbo->kind, nvbo->comp, reg);
> - mem = nouveau_mem(reg);
> if (ret)
> return ret;
>
> --
> 2.7.4
>
--
Cheers,
Lyude Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm fixes for 5.4-rc8
The pull request you sent on Fri, 15 Nov 2019 11:18:16 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-11-15 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/37b49f31e800b563ed7a601816ea4b6fc3c5d165 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205497] Attempt to read amd gpu id causes a freeze
https://bugzilla.kernel.org/show_bug.cgi?id=205497 --- Comment #12 from V.I.S. (itemc...@mail.ru) --- I need approx 3-5 days for testing, because this bug is not persistent. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] radeon and amdgpu drm-next-5.5
Hi Dave, Daniel, Misc fixes for 5.5. The following changes since commit 53dbc27ad5a93932ff1892a8e4ef266827d74a0f: drm/amdgpu/powerplay: fix AVFS handling with custom powerplay table (2019-11-08 12:30:24 -0500) are available in the Git repository at: git://people.freedesktop.org/~agd5f/linux tags/drm-next-5.5-2019-11-15 for you to fetch changes up to 622b2a0ab647d2755f2c1f1000d3403e86a69763: drm/amdgpu/vcn: finish delay work before release resources (2019-11-13 15:29:42 -0500) drm-next-5.5-2019-11-15: amdgpu: - Fix AVFS handling on SMU7 parts with custom power tables - Enable Overdrive sysfs interface for Navi parts - Fix power limit handling on smu11 parts - Fix pcie link sysfs output for Navi - Properly cancel MM worker threads on shutdown radeon: - Cleanup for ppc change Alex Deucher (2): drm/amdgpu/powerplay/smu7: fix AVFS handling with custom powerplay table drm/amdgpu/vcn: finish delay work before release resources Hawking Zhang (1): drm/amdgpu: avoid upload corrupted ta ucode to psp Jesse Zhang (1): drm/amd/amdgpu: finish delay works before release resources Kenneth Feng (1): drm/amd/powerplay: read pcie speed/width info (v2) KyleMahlkuch (1): drm/radeon: Clean up code in radeon_pci_shutdown() Matt Coffin (4): drm/amdgpu/navi10: implement sclk/mclk OD via pp_od_clk_voltage drm/amdgpu/navi10: implement GFXCLK_CURVE overdrive drm/amdgpu/navi10: Implement od clk printing drm/amdgpu/smu_v11: Unify and fix power limits drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 + drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c| 22 +- drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c| 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c| 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c| 2 + drivers/gpu/drm/amd/powerplay/amdgpu_smu.c | 22 +- drivers/gpu/drm/amd/powerplay/arcturus_ppt.c | 23 +- drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 7 + drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h | 4 +- drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h | 12 + .../gpu/drm/amd/powerplay/inc/smu_v11_0_pptable.h | 2 + drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 351 - drivers/gpu/drm/amd/powerplay/navi10_ppt.h | 5 + drivers/gpu/drm/amd/powerplay/smu_v11_0.c | 67 +++- drivers/gpu/drm/amd/powerplay/vega20_ppt.c | 1 - drivers/gpu/drm/radeon/radeon_drv.c| 9 +- 16 files changed, 493 insertions(+), 39 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205521] 5.3.11 update broke AMDGPU Raven Ridge
https://bugzilla.kernel.org/show_bug.cgi?id=205521 Luya Tshimbalanga (l...@fedoraproject.org) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |UNREPRODUCIBLE --- Comment #5 from Luya Tshimbalanga (l...@fedoraproject.org) --- I am closing this report for now as I reinstalled the system. The update proceeded normally with the result: sudo lsinitrd /boot/initramfs-5.3.11-300.fc31.x86_64.img | grep raven -rw-r--r-- 2 root root86528 Jul 24 15:24 usr/lib/firmware/amdgpu/raven2_asd.bin -rw-r--r-- 1 root root 9344 Jul 24 15:24 usr/lib/firmware/amdgpu/raven2_ce.bin -rw-r--r-- 1 root root 316 Jul 24 15:24 usr/lib/firmware/amdgpu/raven2_gpu_info.bin -rw-r--r-- 1 root root17536 Jul 24 15:24 usr/lib/firmware/amdgpu/raven2_me.bin -rw-r--r-- 2 root root 268048 Jul 24 15:24 usr/lib/firmware/amdgpu/raven2_mec2.bin -rw-r--r-- 2 root root0 Jul 24 15:24 usr/lib/firmware/amdgpu/raven2_mec.bin -rw-r--r-- 1 root root21632 Jul 24 15:24 usr/lib/firmware/amdgpu/raven2_pfp.bin -rw-r--r-- 1 root root38324 Jul 24 15:24 usr/lib/firmware/amdgpu/raven2_rlc.bin -rw-r--r-- 1 root root17408 Jul 24 15:24 usr/lib/firmware/amdgpu/raven2_sdma.bin -rw-r--r-- 1 root root 343456 Jul 24 15:24 usr/lib/firmware/amdgpu/raven2_vcn.bin -rw-r--r-- 1 root root78336 Jul 24 15:24 usr/lib/firmware/amdgpu/raven_asd.bin -rw-r--r-- 1 root root 9344 Jul 24 15:24 usr/lib/firmware/amdgpu/raven_ce.bin -rw-r--r-- 1 root root23152 Jul 24 15:24 usr/lib/firmware/amdgpu/raven_dmcu.bin -rw-r--r-- 2 root root 316 Jul 24 15:24 usr/lib/firmware/amdgpu/raven_gpu_info.bin -rw-r--r-- 1 root root39084 Jul 24 15:24 usr/lib/firmware/amdgpu/raven_kicker_rlc.bin -rw-r--r-- 1 root root17536 Jul 24 15:24 usr/lib/firmware/amdgpu/raven_me.bin -rw-r--r-- 2 root root 268048 Jul 24 15:24 usr/lib/firmware/amdgpu/raven_mec2.bin -rw-r--r-- 2 root root0 Jul 24 15:24 usr/lib/firmware/amdgpu/raven_mec.bin -rw-r--r-- 1 root root21632 Jul 24 15:24 usr/lib/firmware/amdgpu/raven_pfp.bin -rw-r--r-- 1 root root39084 Jul 24 15:24 usr/lib/firmware/amdgpu/raven_rlc.bin -rw-r--r-- 2 root root17408 Jul 24 15:24 usr/lib/firmware/amdgpu/raven_sdma.bin -rw-r--r-- 2 root root 341728 Jul 24 15:24 usr/lib/firmware/amdgpu/raven_vcn.bin It appears dracut somehow managed to not install the firmware prior to the failure. I can no longer reproduce it with a reinstall. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 112266] [Navi] Pathfinder: Kingmaker is causing a GPU hang: flip_done timed out error
https://bugs.freedesktop.org/show_bug.cgi?id=112266 --- Comment #6 from Alex Deucher --- Created attachment 145971 --> https://bugs.freedesktop.org/attachment.cgi?id=145971=edit possible fix Does this patch help? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205169] AMDGPU driver with Navi card hangs Xorg in fullscreen only.
https://bugzilla.kernel.org/show_bug.cgi?id=205169 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #20 from Alex Deucher (alexdeuc...@gmail.com) --- Created attachment 285935 --> https://bugzilla.kernel.org/attachment.cgi?id=285935=edit possible fix Does this patch help? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 112290] sanoop
https://bugs.freedesktop.org/show_bug.cgi?id=112290 Andre Klapper changed: What|Removed |Added Group||spam Version|XOrg git|unspecified Product|DRI |Spam Resolution|--- |INVALID Status|NEW |RESOLVED Component|DRM/other |Two --- Comment #1 from Andre Klapper --- Go away and test somewhere else. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205497] Attempt to read amd gpu id causes a freeze
https://bugzilla.kernel.org/show_bug.cgi?id=205497 --- Comment #11 from Alex Deucher (alexdeuc...@gmail.com) --- (In reply to Trek from comment #7) > by default, radeontop calls amdgpu_read_mm_registers, amdgpu_query_info and > amdgpu_query_sensor_info, but it can be forced by the command line to read > BAR from /dev/mem If you access the BAR directly you will likely have problems in certain power saving modes. Can someone test the patch? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm core/helpers and MIT license
On Tue, Nov 12, 2019 at 10:03 AM Daniel Vetter wrote: > > Hi all, > > Dave and me chatted about this last week on irc. Essentially we have: > > $ git grep SPDX.*GPL -- ':(glob)drivers/gpu/drm/*c' > drivers/gpu/drm/drm_client.c:// SPDX-License-Identifier: GPL-2.0 > drivers/gpu/drm/drm_damage_helper.c:// SPDX-License-Identifier: GPL-2.0 OR MIT > drivers/gpu/drm/drm_dp_cec.c:// SPDX-License-Identifier: GPL-2.0 > drivers/gpu/drm/drm_edid_load.c:// SPDX-License-Identifier: GPL-2.0-or-later > drivers/gpu/drm/drm_fb_cma_helper.c:// SPDX-License-Identifier: > GPL-2.0-or-later > drivers/gpu/drm/drm_format_helper.c:/* SPDX-License-Identifier: GPL-2.0 */ > drivers/gpu/drm/drm_gem_cma_helper.c:// SPDX-License-Identifier: > GPL-2.0-or-later > drivers/gpu/drm/drm_gem_framebuffer_helper.c:// > SPDX-License-Identifier: GPL-2.0-or-later > drivers/gpu/drm/drm_gem_shmem_helper.c:// SPDX-License-Identifier: GPL-2.0 > drivers/gpu/drm/drm_gem_ttm_helper.c:// SPDX-License-Identifier: > GPL-2.0-or-later > drivers/gpu/drm/drm_gem_vram_helper.c:// SPDX-License-Identifier: > GPL-2.0-or-later > drivers/gpu/drm/drm_hdcp.c:// SPDX-License-Identifier: GPL-2.0 > drivers/gpu/drm/drm_lease.c:// SPDX-License-Identifier: GPL-2.0-or-later > drivers/gpu/drm/drm_mipi_dbi.c:// SPDX-License-Identifier: GPL-2.0-or-later > drivers/gpu/drm/drm_of.c:// SPDX-License-Identifier: GPL-2.0-only > drivers/gpu/drm/drm_simple_kms_helper.c:// SPDX-License-Identifier: > GPL-2.0-or-later > drivers/gpu/drm/drm_sysfs.c:// SPDX-License-Identifier: GPL-2.0-only > drivers/gpu/drm/drm_vma_manager.c:// SPDX-License-Identifier: GPL-2.0 OR MIT > drivers/gpu/drm/drm_vram_helper_common.c:// SPDX-License-Identifier: > GPL-2.0-or-later > drivers/gpu/drm/drm_writeback.c:// SPDX-License-Identifier: GPL-2.0 > > One is GPL+MIT, so ok, and one is a default GPL-only header from > Greg's infamous patch (so could probably be changed to MIT license > header). I only looked at .c sources, since headers are worse wrt > having questionable default headers. So about 18 files with clear GPL > licenses thus far in drm core/helpers. > > Looking at where that code came from, it is mostly from GPL-only > drivers (we have a lot of those nowadays), so seems legit non-MIT > licensed. Question is now what do we do: > > - Nothing, which means GPL will slowly encroach on drm core/helpers, > which is roughly the same as ... > > - Throw in the towel on MIT drm core officially. Same as above, except > lets just make it official. > > - Try to counter this, which means at least a) relicensing a bunch of > stuff b) rewriting a bunch of stuff c) making sure that's ok with > everyone, there's a lot of GPL-by-default for the kernel (that's how > we got most of the above code through merged drivers I think). I > suspect that whomever cares will need to put in the work to make this > happen (since it will need a pile of active resistance at least). > I'd like to try and keep as much MIT as possible. I'd be willing to help with the re-licensing effort. Alex > Cc maintainers/driver teams who might care most about this. > > Also if people could cc *bsd, they probably care and I don't know best > contacts for graphics stuff (or anything else really at all). > > Cheers, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/gem: Fix mmap fake offset handling for drm_gem_object_funcs.mmap
On Fri, Nov 15, 2019 at 11:56 AM Gerd Hoffmann wrote:
>
> On Fri, Nov 15, 2019 at 11:18:28AM +0100, Daniel Vetter wrote:
> > On Fri, Nov 15, 2019 at 10:37 AM Gerd Hoffmann wrote:
> > >
> > > > You need memory pressure, to force ttm to unmap the bo, not userspace.
> > > > So
> > > > roughly
> > > > 1. create bo
> > > > 2. mmap it through drm fd, write some stuff
> > > > 3. export to dma-buf, mmap it, verify stuff is there
> > > > 4. create a pile more bo, mmap them write to them
> > > > 5. once you've thrashed all of vram enough, recheck your original bo. If
> > > > I'm right you should get the following:
> > > >- drm fd mmap still show right content
> > > >- dma-buf fd mmap shows random crap that you've written into other
> > > > buffers
> > > >
> > > > Ofc you need to make sure that an mmap actually forces the buffer into
> > > > vram. So might need a combo of modeset+mmap, to make that happen. Plain
> > > > mmap might just give you ptes that point into system memory, which is
> > > > not
> > > > managed by ttm like vram.
> > >
> > > Is any move buffer good enough to trigger this, i.e. will SYSTEM -> VRAM
> > > work too? That'll be easier because all I need to do is map the buffer
> > > to a crtc to force pinning to vram, then check if the mappings are
> > > intact still ...
> >
> > I think that should work too.
>
> Seems to work ok for ttm/vram.
>
> Test code:
>
> https://git.kraxel.org/cgit/drminfo/commit/?id=a9eb96504dc17376e07b5c6edf5296b41a48bbfe
I think that's not nasty enough. If the mappings aren't updated, then
you'll still see the the same old pages with the right contents. You
need to change them somehow after they migrated (with vram eviction
that happens automatically since there'll b another object in the same
spot, for system memory I think you need the shrinker to kick in and
free the pages first). Easiest probably to wait for a key press so you
can appreciate the color, then write a different color (full screen)
when the buffer is in vram.
> > Just make sure you actually write
> > through SYSTEM first (maybe with some printk or whatever).
>
> That works fine. Sprinkled ...
>
> system("cat /sys/kernel/debug/dri/0/vram-mm");
>
> ... into the test code, and drmModeSetCrtc() indeed makes the gem object show
> up there.
You'd need to check the ptes themselves. Which I think not even proc
shows by default (only the file that's supposed to be mapped). But
good to confirm that the buffer moved at least.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 1/8] drm/fb: More paranoia in addfb checks
On Fri, Nov 15, 2019 at 1:44 PM Ville Syrjälä
wrote:
>
> On Fri, Nov 15, 2019 at 10:21:13AM +0100, Daniel Vetter wrote:
> > - Our limit is uint32_t, make that explicit.
> >
> > - Untangle the one overflow check, I think (but not sure) that with
> > all three together you could overflow the uint64_t and it'd look
> > cool again.
>
> It can't overflow. All theree inputs are u32 so the max value
> you can get is 0x.
Hm right, I just checked, I guess I should have beforehand.
> > Hence two steps. Also go with the more common (and imo
> > safer approach)
>
> Also results in multiple divisions which is needlessly expensive.
> The original is just mul+add.
>
> > of reducing the range we accept, instead of trying
> > to compute the overflow in high enough precision.
> >
> > - The above would blow up if we get a 0 pitches, so check for that
> > too, but only if block_size is a thing.
> >
> > Cc: Pekka Paalanen
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_framebuffer.c | 17 +++--
> > 1 file changed, 11 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_framebuffer.c
> > b/drivers/gpu/drm/drm_framebuffer.c
> > index 57564318ceea..3141c6ed6dd2 100644
> > --- a/drivers/gpu/drm/drm_framebuffer.c
> > +++ b/drivers/gpu/drm/drm_framebuffer.c
> > @@ -214,15 +214,20 @@ static int framebuffer_check(struct drm_device *dev,
> > return -EINVAL;
> > }
> >
> > - if (min_pitch > UINT_MAX)
> > + if (min_pitch > U8_MAX)
>
> U8?
Oh dear, some patch editing gone really wrong. I think I'll drop this
one here, not doing any good :-)
-Daniel
>
> > return -ERANGE;
> >
> > - if ((uint64_t) height * r->pitches[i] + r->offsets[i] >
> > UINT_MAX)
> > - return -ERANGE;
> > + if (block_size) {
> > + if (r->pitches[i] < min_pitch) {
> > + DRM_DEBUG_KMS("bad pitch %u for plane %d\n",
> > r->pitches[i], i);
> > + return -EINVAL;
> > + }
> >
> > - if (block_size && r->pitches[i] < min_pitch) {
> > - DRM_DEBUG_KMS("bad pitch %u for plane %d\n",
> > r->pitches[i], i);
> > - return -EINVAL;
> > + if (height > U8_MAX / r->pitches[i])
> > + return -ERANGE;
> > +
> > + if (r->offsets[i] > U8_MAX / r->pitches[i] - height)
> > + return -ERANGE;
> > }
> >
> > if (r->modifier[i] && !(r->flags & DRM_MODE_FB_MODIFIERS)) {
> > --
> > 2.24.0
> >
> > ___
> > Intel-gfx mailing list
> > intel-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Ville Syrjälä
> Intel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 112288] Blank display on Ubuntu 19.10 on Ryzen 3 2200G and Ryzen 5 2400G APUs
https://bugs.freedesktop.org/show_bug.cgi?id=112288 --- Comment #12 from Alex Deucher --- Does disabling the iommu help? Append iommu=off or iommu=pt to the kernel command line. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 112297] AMDGPU.gpu_recovery does recover desktop to an unusable state
https://bugs.freedesktop.org/show_bug.cgi?id=112297 --- Comment #1 from Daniel Suarez --- Don't expect this to work anytime soon unfortunately. AMD really slacked off with the drivers for this and similar bug reports have been open for months. As for your work, save early, save often while writing. Don't rely on auto-save doing it for you. Get in the habit of Ctrl+S'ing often. Ideally you shouldn't be using a 5700 if you're dealing with sensitive work. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 112297] AMDGPU.gpu_recovery does recover desktop to an unusable state
https://bugs.freedesktop.org/show_bug.cgi?id=112297 Daniel Suarez changed: What|Removed |Added Priority|not set |highest -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/1] drm/radeon drm/amdgpu: fix bad DMA from INTERRUPT_CNTL2
On Thu, Nov 14, 2019 at 9:05 PM Sam Bobroff wrote:
>
> The INTERRUPT_CNTL2 register expects a valid DMA address, but is
> currently set with a GPU MC address. This can cause problems on
> systems that detect the resulting DMA read from an invalid address
> (found on a Power8 guest).
>
> Instead, use the DMA address of the dummy page because it will always
> be safe.
>
> Fixes: d8f60cfc9345 ("drm/radeon/kms: Add support for interrupts on r6xx/r7xx
> chips (v3)")
> Fixes: 25a857fbe973 ("drm/radeon/kms: add support for interrupts on SI")
> Fixes: a59781bbe528 ("drm/radeon: add support for interrupts on CIK (v5)")
> Fixes: 27ae10641e9c ("drm/amdgpu: add interupt handler implementation for si
> v3")
> Signed-off-by: Sam Bobroff
Can you split this into two patches, one for radeon and one for
amdgpu? I'll apply them.
Thanks!
Alex
> ---
> A couple of notes:
> - Initial discussion:
> https://lists.freedesktop.org/archives/dri-devel/2019-November/244090.html
> - I have only tested the case that uses r600_irq_init(), but they are all very
> similar.
> - I've included a fixes tag for each change, but I don't know if that's the
> right thing to do in this case (please feel free to fix them on commit or
> whatever).
>
> Cheers,
> Sam.
>
> drivers/gpu/drm/amd/amdgpu/si_ih.c | 3 ++-
> drivers/gpu/drm/radeon/cik.c | 4 ++--
> drivers/gpu/drm/radeon/r600.c | 4 ++--
> drivers/gpu/drm/radeon/si.c| 4 ++--
> 4 files changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/si_ih.c
> b/drivers/gpu/drm/amd/amdgpu/si_ih.c
> index 57bb5f9e08b2..88ae27a5a03d 100644
> --- a/drivers/gpu/drm/amd/amdgpu/si_ih.c
> +++ b/drivers/gpu/drm/amd/amdgpu/si_ih.c
> @@ -64,7 +64,8 @@ static int si_ih_irq_init(struct amdgpu_device *adev)
> u32 interrupt_cntl, ih_cntl, ih_rb_cntl;
>
> si_ih_disable_interrupts(adev);
> - WREG32(INTERRUPT_CNTL2, adev->irq.ih.gpu_addr >> 8);
> + /* set dummy read address to dummy page address */
> + WREG32(INTERRUPT_CNTL2, adev->dummy_page_addr >> 8);
> interrupt_cntl = RREG32(INTERRUPT_CNTL);
> interrupt_cntl &= ~IH_DUMMY_RD_OVERRIDE;
> interrupt_cntl &= ~IH_REQ_NONSNOOP_EN;
> diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
> index 62eab82a64f9..897442754fd0 100644
> --- a/drivers/gpu/drm/radeon/cik.c
> +++ b/drivers/gpu/drm/radeon/cik.c
> @@ -6969,8 +6969,8 @@ static int cik_irq_init(struct radeon_device *rdev)
> }
>
> /* setup interrupt control */
> - /* XXX this should actually be a bus address, not an MC address. same
> on older asics */
> - WREG32(INTERRUPT_CNTL2, rdev->ih.gpu_addr >> 8);
> + /* set dummy read address to dummy page address */
> + WREG32(INTERRUPT_CNTL2, rdev->dummy_page.addr >> 8);
> interrupt_cntl = RREG32(INTERRUPT_CNTL);
> /* IH_DUMMY_RD_OVERRIDE=0 - dummy read disabled with msi, enabled
> without msi
> * IH_DUMMY_RD_OVERRIDE=1 - dummy read controlled by IH_DUMMY_RD_EN
> diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
> index e937cc01910d..033bc466a862 100644
> --- a/drivers/gpu/drm/radeon/r600.c
> +++ b/drivers/gpu/drm/radeon/r600.c
> @@ -3696,8 +3696,8 @@ int r600_irq_init(struct radeon_device *rdev)
> }
>
> /* setup interrupt control */
> - /* set dummy read address to ring address */
> - WREG32(INTERRUPT_CNTL2, rdev->ih.gpu_addr >> 8);
> + /* set dummy read address to dummy page address */
> + WREG32(INTERRUPT_CNTL2, rdev->dummy_page.addr >> 8);
> interrupt_cntl = RREG32(INTERRUPT_CNTL);
> /* IH_DUMMY_RD_OVERRIDE=0 - dummy read disabled with msi, enabled
> without msi
> * IH_DUMMY_RD_OVERRIDE=1 - dummy read controlled by IH_DUMMY_RD_EN
> diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
> index 05894d198a79..1d8efb0eefdb 100644
> --- a/drivers/gpu/drm/radeon/si.c
> +++ b/drivers/gpu/drm/radeon/si.c
> @@ -5997,8 +5997,8 @@ static int si_irq_init(struct radeon_device *rdev)
> }
>
> /* setup interrupt control */
> - /* set dummy read address to ring address */
> - WREG32(INTERRUPT_CNTL2, rdev->ih.gpu_addr >> 8);
> + /* set dummy read address to dummy page address */
> + WREG32(INTERRUPT_CNTL2, rdev->dummy_page.addr >> 8);
> interrupt_cntl = RREG32(INTERRUPT_CNTL);
> /* IH_DUMMY_RD_OVERRIDE=0 - dummy read disabled with msi, enabled
> without msi
> * IH_DUMMY_RD_OVERRIDE=1 - dummy read controlled by IH_DUMMY_RD_EN
> --
> 2.22.0.216.g00a2a96fc9
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm core/helpers and MIT license
Den 15.11.2019 13.34, skrev Ville Syrjälä: > On Thu, Nov 14, 2019 at 08:01:32PM +, co...@sdf.org wrote: >> Hi Daniel, >> >> I don't think we can make any complaints about GPL being more widely >> used in the DRM code. It's nice to have the code at all, the MIT license >> is a bonus. Thanks for writing it and bearing with us. >> >> Would rewrites done purely for licensing reasons be accepted upstream? > > Rewrite should be the last resort. I think a lot of the GPL only stuff > is quite recent so there's a good chance the author(s) are still around > to discuss relicensing. > If someone sends patches to MIT license the work I've done, I'll be happy to ack it. It's only recently that I've been aware of the fact that MIT licensed was a thing in the kernel. I was under the impression that all new code should be GPL and MIT were for code imported from elsewhere. I would love to see my work being used on the BSD's. Noralf. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/8] drm/tilcdc: Drop drm_gem_fb_create wrapper
On 15/11/2019 11:21, Daniel Vetter wrote:
> Doesn't do anything.
>
> Signed-off-by: Daniel Vetter
> Cc: Jyri Sarha
> Cc: Tomi Valkeinen
Acked-by: Jyri Sarha
> ---
> drivers/gpu/drm/tilcdc/tilcdc_drv.c | 8 +---
> 1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> index 2a9e67597375..a160880bea0a 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> @@ -64,12 +64,6 @@ void tilcdc_module_cleanup(struct tilcdc_module *mod)
>
> static struct of_device_id tilcdc_of_match[];
>
> -static struct drm_framebuffer *tilcdc_fb_create(struct drm_device *dev,
> - struct drm_file *file_priv, const struct drm_mode_fb_cmd2
> *mode_cmd)
> -{
> - return drm_gem_fb_create(dev, file_priv, mode_cmd);
> -}
> -
> static int tilcdc_atomic_check(struct drm_device *dev,
> struct drm_atomic_state *state)
> {
> @@ -140,7 +134,7 @@ static int tilcdc_commit(struct drm_device *dev,
> }
>
> static const struct drm_mode_config_funcs mode_config_funcs = {
> - .fb_create = tilcdc_fb_create,
> + .fb_create = drm_gem_fb_create,
> .atomic_check = tilcdc_atomic_check,
> .atomic_commit = tilcdc_commit,
> };
>
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 1/8] drm/fb: More paranoia in addfb checks
On Fri, Nov 15, 2019 at 10:21:13AM +0100, Daniel Vetter wrote:
> - Our limit is uint32_t, make that explicit.
>
> - Untangle the one overflow check, I think (but not sure) that with
> all three together you could overflow the uint64_t and it'd look
> cool again.
It can't overflow. All theree inputs are u32 so the max value
you can get is 0x.
> Hence two steps. Also go with the more common (and imo
> safer approach)
Also results in multiple divisions which is needlessly expensive.
The original is just mul+add.
> of reducing the range we accept, instead of trying
> to compute the overflow in high enough precision.
>
> - The above would blow up if we get a 0 pitches, so check for that
> too, but only if block_size is a thing.
>
> Cc: Pekka Paalanen
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_framebuffer.c | 17 +++--
> 1 file changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_framebuffer.c
> b/drivers/gpu/drm/drm_framebuffer.c
> index 57564318ceea..3141c6ed6dd2 100644
> --- a/drivers/gpu/drm/drm_framebuffer.c
> +++ b/drivers/gpu/drm/drm_framebuffer.c
> @@ -214,15 +214,20 @@ static int framebuffer_check(struct drm_device *dev,
> return -EINVAL;
> }
>
> - if (min_pitch > UINT_MAX)
> + if (min_pitch > U8_MAX)
U8?
> return -ERANGE;
>
> - if ((uint64_t) height * r->pitches[i] + r->offsets[i] >
> UINT_MAX)
> - return -ERANGE;
> + if (block_size) {
> + if (r->pitches[i] < min_pitch) {
> + DRM_DEBUG_KMS("bad pitch %u for plane %d\n",
> r->pitches[i], i);
> + return -EINVAL;
> + }
>
> - if (block_size && r->pitches[i] < min_pitch) {
> - DRM_DEBUG_KMS("bad pitch %u for plane %d\n",
> r->pitches[i], i);
> - return -EINVAL;
> + if (height > U8_MAX / r->pitches[i])
> + return -ERANGE;
> +
> + if (r->offsets[i] > U8_MAX / r->pitches[i] - height)
> + return -ERANGE;
> }
>
> if (r->modifier[i] && !(r->flags & DRM_MODE_FB_MODIFIERS)) {
> --
> 2.24.0
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm core/helpers and MIT license
On Thu, Nov 14, 2019 at 08:01:32PM +, co...@sdf.org wrote: > Hi Daniel, > > I don't think we can make any complaints about GPL being more widely > used in the DRM code. It's nice to have the code at all, the MIT license > is a bonus. Thanks for writing it and bearing with us. > > Would rewrites done purely for licensing reasons be accepted upstream? Rewrite should be the last resort. I think a lot of the GPL only stuff is quite recent so there's a good chance the author(s) are still around to discuss relicensing. -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 112297] AMDGPU.gpu_recovery does recover desktop to an unusable state
https://bugs.freedesktop.org/show_bug.cgi?id=112297 David Biró changed: What|Removed |Added Summary|AMDGPU recovery does|AMDGPU.gpu_recovery does |recover desktop to an |recover desktop to an |unstable state |unusable state -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 112297] AMDGPU recovery does recover desktop to an unstable state
https://bugs.freedesktop.org/show_bug.cgi?id=112297 Bug ID: 112297 Summary: AMDGPU recovery does recover desktop to an unstable state Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: critical Priority: not set Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: dbir...@gmail.com I have got Radeon RX 5700 XT which has unstable driver. So that amdgpu.gpu_recovery=1 flag would be helpful if even that could work well. Unfortunately it doesn't. My kernel's latest commit ID: 53dbc27ad5a93932ff1892a8e4ef266827d74a0f ( fix AVFS handling with custom powerplay table) On branch drm-next-5.5 Display server: X11 WM: BSPWM DM: Slim Journalctl output: https://pastebin.com/if4PYda7 The error is the "average" ring sdma0 timeout. After reset, the actual application that caused the crash, stays on the screen, The screen is flickering, vibrating, I'm frequently able to see some green rectangle at the top of the screen with full width. But I can able to move mouse. Also I cannot do anything else, because then BSPWM can switch workspaces (I can see it by the type of the mouse cursor), but the crashed application stays on the screen anyway, so I have to restart. At least, I can save my work if I remember which workspace contained my work. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/2] add new DRM_DEV_WARN macro
On Thu, 14 Nov 2019, Wambui Karuga wrote: > This adds a new DRM_DEV_WARN helper macro for warnings log output that include > device pointers. It also includes the use of the DRM_DEV_WARN macro in > drm/rockchip to replace dev_warn. I'm trying to solicit new struct drm_device based logging macros, and starting to convert to those. [1] BR, Jani. [1] http://patchwork.freedesktop.org/patch/msgid/63d1e72b99e9c13ee5b1b362a653ff9c21e19124.1572258936.git.jani.nik...@intel.com > > Wambui Karuga (2): > drm/print: add DRM_DEV_WARN macro > drm/rockchip: use DRM_DEV_WARN macro in debug output > > drivers/gpu/drm/rockchip/inno_hdmi.c | 3 ++- > include/drm/drm_print.h | 9 + > 2 files changed, 11 insertions(+), 1 deletion(-) -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm-next + i915 CVE yolo merge
On Fri, 15 Nov 2019, Joonas Lahtinen wrote: > Quoting Dave Airlie (2019-11-14 03:33:24) >> The landing of the i915 CVE fixes into Linus tree has created a bit of >> a mess in linux-next and downstream in drm-next trees. >> >> I talked to Daniel and he had talked to Joonas a bit, and I decided to >> go with what Daniel describes as the YOLO merge, where I just solve it >> and pray, and everyone else verifies/fixes it. >> >> In my favour I've been reading these patches for a couple of months >> now and applied them to a lot of places, so I'm quite familiar with >> what they are doing. >> >> The worst culprit was the RC6 ctx corruption fix since the whole of >> rc6 got refactored in next. However I also had access to a version of >> this patch Jon wrote on drm-tip a couple of weeks ago. > > We've now tested drm-next and found it working fine. As a next step Jani > will be backmerge to drm-intel-next-queued. Done and pushed out. Thanks, Jani. > > Regards, Joonas > >> I took that patch, applied it and fixed it up on top of drm-next. Then >> I backmerged the commit that also went into Linus' tree. Then I >> removed any evidence of the RC6 patch from Linus' tree and left the >> newer version pieces in place. The other stuff mostly merged fine and >> the results looked fine, but I'd definitely think everyone at Intel >> should be staring at it, and my dinq tip resolutions ASAP and >> hopefully it goes into CI and comes out smelling of something good. >> >> Let me know if it's all horrible asap, >> Thanks, >> Dave. -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm-next + i915 CVE yolo merge
Quoting Dave Airlie (2019-11-14 03:33:24) > The landing of the i915 CVE fixes into Linus tree has created a bit of > a mess in linux-next and downstream in drm-next trees. > > I talked to Daniel and he had talked to Joonas a bit, and I decided to > go with what Daniel describes as the YOLO merge, where I just solve it > and pray, and everyone else verifies/fixes it. > > In my favour I've been reading these patches for a couple of months > now and applied them to a lot of places, so I'm quite familiar with > what they are doing. > > The worst culprit was the RC6 ctx corruption fix since the whole of > rc6 got refactored in next. However I also had access to a version of > this patch Jon wrote on drm-tip a couple of weeks ago. We've now tested drm-next and found it working fine. As a next step Jani will be backmerge to drm-intel-next-queued. Regards, Joonas > I took that patch, applied it and fixed it up on top of drm-next. Then > I backmerged the commit that also went into Linus' tree. Then I > removed any evidence of the RC6 patch from Linus' tree and left the > newer version pieces in place. The other stuff mostly merged fine and > the results looked fine, but I'd definitely think everyone at Intel > should be staring at it, and my dinq tip resolutions ASAP and > hopefully it goes into CI and comes out smelling of something good. > > Let me know if it's all horrible asap, > Thanks, > Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/gem: Fix mmap fake offset handling for drm_gem_object_funcs.mmap
On Fri, Nov 15, 2019 at 11:18:28AM +0100, Daniel Vetter wrote:
> On Fri, Nov 15, 2019 at 10:37 AM Gerd Hoffmann wrote:
> >
> > > You need memory pressure, to force ttm to unmap the bo, not userspace. So
> > > roughly
> > > 1. create bo
> > > 2. mmap it through drm fd, write some stuff
> > > 3. export to dma-buf, mmap it, verify stuff is there
> > > 4. create a pile more bo, mmap them write to them
> > > 5. once you've thrashed all of vram enough, recheck your original bo. If
> > > I'm right you should get the following:
> > >- drm fd mmap still show right content
> > >- dma-buf fd mmap shows random crap that you've written into other
> > > buffers
> > >
> > > Ofc you need to make sure that an mmap actually forces the buffer into
> > > vram. So might need a combo of modeset+mmap, to make that happen. Plain
> > > mmap might just give you ptes that point into system memory, which is not
> > > managed by ttm like vram.
> >
> > Is any move buffer good enough to trigger this, i.e. will SYSTEM -> VRAM
> > work too? That'll be easier because all I need to do is map the buffer
> > to a crtc to force pinning to vram, then check if the mappings are
> > intact still ...
>
> I think that should work too.
Seems to work ok for ttm/vram.
Test code:
https://git.kraxel.org/cgit/drminfo/commit/?id=a9eb96504dc17376e07b5c6edf5296b41a48bbfe
> Just make sure you actually write
> through SYSTEM first (maybe with some printk or whatever).
That works fine. Sprinkled ...
system("cat /sys/kernel/debug/dri/0/vram-mm");
... into the test code, and drmModeSetCrtc() indeed makes the gem object show
up there.
cheers,
Gerd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/8] drm/fb: More paranoia in addfb checks
On Fri, 15 Nov 2019 10:21:13 +0100
Daniel Vetter wrote:
> - Our limit is uint32_t, make that explicit.
>
> - Untangle the one overflow check, I think (but not sure) that with
> all three together you could overflow the uint64_t and it'd look
> cool again. Hence two steps. Also go with the more common (and imo
> safer approach) of reducing the range we accept, instead of trying
> to compute the overflow in high enough precision.
>
> - The above would blow up if we get a 0 pitches, so check for that
> too, but only if block_size is a thing.
>
> Cc: Pekka Paalanen
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_framebuffer.c | 17 +++--
> 1 file changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_framebuffer.c
> b/drivers/gpu/drm/drm_framebuffer.c
> index 57564318ceea..3141c6ed6dd2 100644
> --- a/drivers/gpu/drm/drm_framebuffer.c
> +++ b/drivers/gpu/drm/drm_framebuffer.c
> @@ -214,15 +214,20 @@ static int framebuffer_check(struct drm_device *dev,
> return -EINVAL;
> }
>
> - if (min_pitch > UINT_MAX)
> + if (min_pitch > U8_MAX)
This looks odd, but I don't know what min_pitch is or why it should be
limited to 255(?). What's with the U8, should it not be U32?
> return -ERANGE;
>
> - if ((uint64_t) height * r->pitches[i] + r->offsets[i] >
> UINT_MAX)
> - return -ERANGE;
> + if (block_size) {
> + if (r->pitches[i] < min_pitch) {
> + DRM_DEBUG_KMS("bad pitch %u for plane %d\n",
> r->pitches[i], i);
> + return -EINVAL;
> + }
>
> - if (block_size && r->pitches[i] < min_pitch) {
> - DRM_DEBUG_KMS("bad pitch %u for plane %d\n",
> r->pitches[i], i);
> - return -EINVAL;
> + if (height > U8_MAX / r->pitches[i])
> + return -ERANGE;
> +
> + if (r->offsets[i] > U8_MAX / r->pitches[i] - height)
Aside from the U8 again, this looks strange too. You want to check that
offset + height * pitch does not exceed MAX?
Wouldn't that be height > (MAX - offset) / pitch for bad?
If offset cannot be negative, this could also replace height > U8_MAX /
r->pitches[i].
> + return -ERANGE;
> }
>
> if (r->modifier[i] && !(r->flags & DRM_MODE_FB_MODIFIERS)) {
Thanks,
pq
pgp2IpuwepPuV.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 4/4] drm/bridge: add it6505 driver
From: Allen Chen
This adds support for the iTE IT6505.
This device can convert DPI signal to DP output.
Signed-off-by: Jitao Shi
Signed-off-by: Yilun Lin
Signed-off-by: Allen Chen
Signed-off-by: Pi-Hsun Shih
---
drivers/gpu/drm/bridge/Kconfig |7 +
drivers/gpu/drm/bridge/Makefile |1 +
drivers/gpu/drm/bridge/ite-it6505.c | 2697 +++
3 files changed, 2705 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/ite-it6505.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 3436297..c8cfaf7 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -45,6 +45,13 @@ config DRM_DUMB_VGA_DAC
Support for non-programmable RGB to VGA DAC bridges, such as ADI
ADV7123, TI THS8134 and THS8135 or passive resistor ladder DACs.
+config DRM_ITE_IT6505
+ tristate "ITE IT6505 DP bridge"
+ depends on OF
+ select DRM_KMS_HELPER
+ help
+ ITE IT6505 DP bridge chip driver.
+
config DRM_LVDS_ENCODER
tristate "Transparent parallel to LVDS encoder support"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 4934fcf..f5abca5 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -2,6 +2,7 @@
obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
+obj-$(CONFIG_DRM_ITE_IT6505) += ite-it6505.o
obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
megachips-stdp-ge-b850v3-fw.o
obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
diff --git a/drivers/gpu/drm/bridge/ite-it6505.c
b/drivers/gpu/drm/bridge/ite-it6505.c
new file mode 100644
index ..166310a
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ite-it6505.c
@@ -0,0 +1,2697 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define AX 0
+#define BX 1
+#define AUDSEL I2S
+#define AUDTYPE LPCM
+#define AUDFS AUD48K
+#define AUDCH 2
+/* 0: Standard I2S;1: 32bit I2S */
+#define I2SINPUTFMT 1
+/* 0: Left-justified;1: Right-justified */
+#define I2SJUSTIFIED 0
+/* 0: Data delay 1T correspond to WS;1: No data delay correspond to WS */
+#define I2SDATADELAY 0
+/* 0: is left channel;1: is right channel */
+#define I2SWSCHANNEL 0
+/* 0: MSB shift first;1: LSB shift first */
+#define I2SDATASEQ 0
+
+#define LANESWAP 0
+#define LANE 4
+#define _HBR 1
+#define ENSSC 1
+#define FLAGTRAINDOWN 150
+#define POLLINGKSVLIST 400
+#define TRAINFAILCNT 5
+#define TRAINFAILHPD 3
+#define AUX_WAIT_TIMEOUT_MS 15
+#define PCLK_DELAY 1
+#define PCLK_INV 0
+#define ADJUST_PHASE_THRESHOLD 8
+#define PWROFFRETRYTIME 5
+#define MAXPCLK 95000
+#define DEFAULTHDCP 1
+#define DEFAULTAUDIO 0
+#define DEFAULTPWRONOFF 1
+#define DEFAULTDRVHOLD 0
+#define DEFAULTPWRON 0
+#define AUX_FIFO_MAX_SIZE 0x10
+
+/* AX or BX */
+#define CHIP_VERSION BX
+
+/*
+ * afe settings for different platforms
+ * 0: for bitland 10e, quanta zde
+ * 1: for google kukui p1/p2, huaqin krane
+ */
+#define AFE_SETTING 1
+
+static u8 afe_setting_table[2][3] = {
+ {0, 0, 0},
+ {0x93, 0x2a, 0x85}
+};
+
+enum sys_status {
+ SYS_UNPLUG = 0,
+ SYS_HPD,
+ SYS_AUTOTRAIN,
+ SYS_WAIT,
+ SYS_TRAINFAIL,
+ SYS_ReHDCP,
+ SYS_NOROP,
+ SYS_Unknown,
+};
+
+enum it6505_aud_sel {
+ I2S = 0,
+ SPDIF,
+};
+
+enum it6505_aud_fs {
+ AUD24K = 0x6,
+ AUD32K = 0x3,
+ AUD48K = 0x2,
+ AUD96K = 0xA,
+ AUD192K = 0xE,
+ AUD44P1K = 0x0,
+ AUD88P2K = 0x8,
+ AUD176P4K = 0xC,
+};
+
+enum it6505_aud_type {
+ LPCM = 0,
+ NLPCM,
+ DSS,
+ HBR,
+};
+
+enum aud_word_length {
+ AUD16BIT = 0,
+ AUD18BIT,
+ AUD20BIT,
+ AUD24BIT,
+};
+
+/* Audio Sample Word Length: AUD16BIT, AUD18BIT, AUD20BIT, AUD24BIT */
+#define AUDWORDLENGTH AUD24BIT
+
+struct it6505_platform_data {
+ struct regulator *pwr18;
+ struct regulator *ovdd;
+ struct gpio_desc *gpiod_hpd;
+ struct gpio_desc *gpiod_reset;
+};
+
+struct it6505 {
+ struct drm_dp_aux aux;
+ struct drm_bridge bridge;
+ struct i2c_client *client;
+ struct edid *edid;
+ struct drm_connector connector;
+ struct drm_dp_link link;
+ struct it6505_platform_data pdata;
+ struct mutex lock;
+ struct mutex mode_lock;
+ struct regmap *regmap;
+ struct drm_display_mode vid_info;
+
+ struct notifier_block event_nb;
+ struct extcon_dev *extcon;
+
Re: [PATCH v10 4/4] arm64: dts: zynqmp: zcu106-revA: Wire up the DisplayPort subsystem
On 08. 11. 19 18:59, Laurent Pinchart wrote:
> Enable the dpsub device and wire it up to the PS-GTR PHY lanes routed to
> the DisplayPort connector.
>
> Signed-off-by: Laurent Pinchart
> ---
> .../arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts
> b/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts
> index 93ce7eb81498..4656f25b6b04 100644
> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts
> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts
> @@ -13,6 +13,7 @@
> #include "zynqmp-clk.dtsi"
> #include
> #include
> +#include
>
> / {
> model = "ZynqMP ZCU106 RevA";
> @@ -69,6 +70,17 @@
> status = "okay";
> };
>
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> + phy-names = "dp-phy0", "dp-phy1";
> + phys = < PHY_TYPE_DP 0 3 2700>,
> +< PHY_TYPE_DP 1 3 2700>;
It is aligned with stuff in Xilinx tree.
I think that putting any clock value here is wrong.
It should really be pointing to whatever it is.
Then you can support more cases where clock doesn't need to be fixed and
it is also aligned with clock binding.
> +};
> +
> /* fpd_dma clk 667MHz, lpd_dma 500MHz */
> _dma_chan1 {
> status = "okay";
> @@ -503,6 +515,10 @@
> no-1-8-v;
> };
>
> + {
> + status = "okay";
> +};
> +
> {
> status = "okay";
> };
>
M
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/4] Revert "drm/tegra: Move drm_dp_link helpers to Tegra DRM"
This reverts commit 9a42c7c647a9ad0f7ebb147a52eda3dcb7c84292.
Signed-off-by: Allen Chen
---
drivers/gpu/drm/drm_dp_helper.c | 128 ++
drivers/gpu/drm/tegra/Makefile | 1 -
drivers/gpu/drm/tegra/dp.c | 876
drivers/gpu/drm/tegra/dp.h | 177
drivers/gpu/drm/tegra/dpaux.c | 1 -
drivers/gpu/drm/tegra/sor.c | 1 -
include/drm/drm_dp_helper.h | 16 +
7 files changed, 144 insertions(+), 1056 deletions(-)
delete mode 100644 drivers/gpu/drm/tegra/dp.c
delete mode 100644 drivers/gpu/drm/tegra/dp.h
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 2c7870a..f567141 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -352,6 +352,134 @@ int drm_dp_dpcd_read_link_status(struct drm_dp_aux *aux,
EXPORT_SYMBOL(drm_dp_dpcd_read_link_status);
/**
+ * drm_dp_link_probe() - probe a DisplayPort link for capabilities
+ * @aux: DisplayPort AUX channel
+ * @link: pointer to structure in which to return link capabilities
+ *
+ * The structure filled in by this function can usually be passed directly
+ * into drm_dp_link_power_up() and drm_dp_link_configure() to power up and
+ * configure the link based on the link's capabilities.
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int drm_dp_link_probe(struct drm_dp_aux *aux, struct drm_dp_link *link)
+{
+ u8 values[3];
+ int err;
+
+ memset(link, 0, sizeof(*link));
+
+ err = drm_dp_dpcd_read(aux, DP_DPCD_REV, values, sizeof(values));
+ if (err < 0)
+ return err;
+
+ link->revision = values[0];
+ link->rate = drm_dp_bw_code_to_link_rate(values[1]);
+ link->num_lanes = values[2] & DP_MAX_LANE_COUNT_MASK;
+
+ if (values[2] & DP_ENHANCED_FRAME_CAP)
+ link->capabilities |= DP_LINK_CAP_ENHANCED_FRAMING;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_link_probe);
+
+/**
+ * drm_dp_link_power_up() - power up a DisplayPort link
+ * @aux: DisplayPort AUX channel
+ * @link: pointer to a structure containing the link configuration
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int drm_dp_link_power_up(struct drm_dp_aux *aux, struct drm_dp_link *link)
+{
+ u8 value;
+ int err;
+
+ /* DP_SET_POWER register is only available on DPCD v1.1 and later */
+ if (link->revision < 0x11)
+ return 0;
+
+ err = drm_dp_dpcd_readb(aux, DP_SET_POWER, );
+ if (err < 0)
+ return err;
+
+ value &= ~DP_SET_POWER_MASK;
+ value |= DP_SET_POWER_D0;
+
+ err = drm_dp_dpcd_writeb(aux, DP_SET_POWER, value);
+ if (err < 0)
+ return err;
+
+ /*
+* According to the DP 1.1 specification, a "Sink Device must exit the
+* power saving state within 1 ms" (Section 2.5.3.1, Table 5-52, "Sink
+* Control Field" (register 0x600).
+*/
+ usleep_range(1000, 2000);
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_link_power_up);
+
+/**
+ * drm_dp_link_power_down() - power down a DisplayPort link
+ * @aux: DisplayPort AUX channel
+ * @link: pointer to a structure containing the link configuration
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int drm_dp_link_power_down(struct drm_dp_aux *aux, struct drm_dp_link *link)
+{
+ u8 value;
+ int err;
+
+ /* DP_SET_POWER register is only available on DPCD v1.1 and later */
+ if (link->revision < 0x11)
+ return 0;
+
+ err = drm_dp_dpcd_readb(aux, DP_SET_POWER, );
+ if (err < 0)
+ return err;
+
+ value &= ~DP_SET_POWER_MASK;
+ value |= DP_SET_POWER_D3;
+
+ err = drm_dp_dpcd_writeb(aux, DP_SET_POWER, value);
+ if (err < 0)
+ return err;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_link_power_down);
+
+/**
+ * drm_dp_link_configure() - configure a DisplayPort link
+ * @aux: DisplayPort AUX channel
+ * @link: pointer to a structure containing the link configuration
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int drm_dp_link_configure(struct drm_dp_aux *aux, struct drm_dp_link *link)
+{
+ u8 values[2];
+ int err;
+
+ values[0] = drm_dp_link_rate_to_bw_code(link->rate);
+ values[1] = link->num_lanes;
+
+ if (link->capabilities & DP_LINK_CAP_ENHANCED_FRAMING)
+ values[1] |= DP_LANE_COUNT_ENHANCED_FRAME_EN;
+
+ err = drm_dp_dpcd_write(aux, DP_LINK_BW_SET, values, sizeof(values));
+ if (err < 0)
+ return err;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_link_configure);
+
+/**
* drm_dp_downstream_max_clock() - extract branch device max
* pixel rate for legacy VGA
* converter or max TMDS clock
diff --git a/drivers/gpu/drm/tegra/Makefile b/drivers/gpu/drm/tegra/Makefile
index d6cf202..33c463e
[PATCH v4 0/4] IT6505 cover letter
The IT6505 is a high-performance DisplayPort 1.1a transmitter, fully compliant with DisplayPort 1.1a, HDCP 1.3 specifications. The IT6505 supports color depth of up to 36 bits (12 bits/color) and ensures robust transmission of high-quality uncompressed video content, along with uncompressed and compressed digital audio content. This series contains document bindings, revert commit, add vendor prefix, Kconfig to control the function enable or not. Allen Chen (2): dt-bindings: Add binding for IT6505. drm/bridge: add it6505 driver allen (2): dt-bindings: Add vendor prefix for ITE Tech. Inc. Revert "drm/tegra: Move drm_dp_link helpers to Tegra DRM" .../bindings/display/bridge/ite,it6505.txt | 28 + .../devicetree/bindings/vendor-prefixes.yaml |2 + drivers/gpu/drm/bridge/Kconfig |7 + drivers/gpu/drm/bridge/Makefile|1 + drivers/gpu/drm/bridge/ite-it6505.c| 2697 drivers/gpu/drm/drm_dp_helper.c| 128 + drivers/gpu/drm/tegra/Makefile |1 - drivers/gpu/drm/tegra/dp.c | 876 --- drivers/gpu/drm/tegra/dp.h | 177 -- drivers/gpu/drm/tegra/dpaux.c |1 - drivers/gpu/drm/tegra/sor.c|1 - include/drm/drm_dp_helper.h| 16 + 12 files changed, 2879 insertions(+), 1056 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/bridge/ite,it6505.txt create mode 100644 drivers/gpu/drm/bridge/ite-it6505.c delete mode 100644 drivers/gpu/drm/tegra/dp.c delete mode 100644 drivers/gpu/drm/tegra/dp.h -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 3/4] dt-bindings: Add binding for IT6505.
From: Allen Chen
Add a DT binding documentation for IT6505.
Signed-off-by: Allen Chen
Signed-off-by: Pi-Hsun Shih
---
.../bindings/display/bridge/ite,it6505.txt | 28 ++
1 file changed, 28 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/ite,it6505.txt
diff --git a/Documentation/devicetree/bindings/display/bridge/ite,it6505.txt
b/Documentation/devicetree/bindings/display/bridge/ite,it6505.txt
new file mode 100644
index ..72da0c4
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ite,it6505.txt
@@ -0,0 +1,28 @@
+iTE it6505 DP bridge bindings
+
+Required properties:
+- compatible: "ite,it6505"
+- reg: i2c address of the bridge
+- ovdd-supply: I/O voltage
+- pwr18-supply: Core voltage
+- interrupts: interrupt specifier of INT pin
+- reset-gpios: gpio specifier of RESET pin
+ - hpd-gpios:
+ Hotplug detect GPIO.
+ Indicates which GPIO should be used for hotplug detection
+ - port@[x]: SoC specific port nodes with endpoint definitions as defined
+ in
Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
+
+Example:
+ dp-bridge@5c {
+compatible = "ite,it6505";
+interrupts = <152 IRQ_TYPE_EDGE_RISING 152 0>;
+reg = <0x5c>;
+pinctrl-names = "default";
+pinctrl-0 = <_pins>;
+ovdd-supply = <_vsim1_reg>;
+pwr18-supply = <_pp18_reg>;
+reset-gpios = < 179 1>;
+hpd-gpios = < 9 0>;
+extcon = <_extcon>;
+};
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu/dm: Do not throw an error for a display with no audio
Hi Chris,
On Thu, 14 Nov 2019 20:44:13 +, Chris Wilson wrote:
> An old display with no audio may not have an EDID with a CEA block, or
> it may simply be too old to support audio. This is not a driver error,
> so don't flag it as such.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112140
> References: ae2a3495973e ("drm/amd: be quiet when no SAD block is found")
> Signed-off-by: Chris Wilson
> Cc: Harry Wentland
> Cc: Jean Delvare
> Cc: Alex Deucher
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> index 11e5784aa62a..04808dbecab3 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> @@ -97,8 +97,6 @@ enum dc_edid_status dm_helpers_parse_edid_caps(
> (struct edid *) edid->raw_edid);
>
> sad_count = drm_edid_to_sad((struct edid *) edid->raw_edid, );
> - if (sad_count < 0)
> - DRM_ERROR("Couldn't read SADs: %d\n", sad_count);
> if (sad_count <= 0)
> return result;
>
I still believe that my approach was a better way to solve this problem:
https://patchwork.freedesktop.org/patch/329066/
Your approach would have to be applied to all individual drivers (all
callers of drm_edid_to_sad). It also prevents reporting actual errors.
Should I resend my patch?
--
Jean Delvare
SUSE L3 Support
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/gem: Fix mmap fake offset handling for drm_gem_object_funcs.mmap
On Fri, Nov 15, 2019 at 10:37 AM Gerd Hoffmann wrote: > > > You need memory pressure, to force ttm to unmap the bo, not userspace. So > > roughly > > 1. create bo > > 2. mmap it through drm fd, write some stuff > > 3. export to dma-buf, mmap it, verify stuff is there > > 4. create a pile more bo, mmap them write to them > > 5. once you've thrashed all of vram enough, recheck your original bo. If > > I'm right you should get the following: > >- drm fd mmap still show right content > >- dma-buf fd mmap shows random crap that you've written into other > > buffers > > > > Ofc you need to make sure that an mmap actually forces the buffer into > > vram. So might need a combo of modeset+mmap, to make that happen. Plain > > mmap might just give you ptes that point into system memory, which is not > > managed by ttm like vram. > > Is any move buffer good enough to trigger this, i.e. will SYSTEM -> VRAM > work too? That'll be easier because all I need to do is map the buffer > to a crtc to force pinning to vram, then check if the mappings are > intact still ... I think that should work too. Just make sure you actually write through SYSTEM first (maybe with some printk or whatever). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH][next] drm/amdgpu/powerplay: fix dereference before null check of pointer hwmgr
From: Colin Ian King
The assignment of adev dereferences pointer hwmgr before hwmgr is null
checked, hence there is a potential null pointer deference issue. Fix
this by assigning adev after the null check.
Addresses-Coverity: ("Dereference before null check")
Fixes: 0896d2f7ba4d ("drm/amdgpu/powerplay: properly set PP_GFXOFF_MASK")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
index 443625c83ec9..d2909c91d65b 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
@@ -81,7 +81,7 @@ static void hwmgr_init_workload_prority(struct pp_hwmgr
*hwmgr)
int hwmgr_early_init(struct pp_hwmgr *hwmgr)
{
- struct amdgpu_device *adev = hwmgr->adev;
+ struct amdgpu_device *adev;
if (!hwmgr)
return -EINVAL;
@@ -96,6 +96,8 @@ int hwmgr_early_init(struct pp_hwmgr *hwmgr)
hwmgr_init_workload_prority(hwmgr);
hwmgr->gfxoff_state_changed_by_workload = false;
+ adev = hwmgr->adev;
+
switch (hwmgr->chip_family) {
case AMDGPU_FAMILY_CI:
adev->pm.pp_feature &= ~PP_GFXOFF_MASK;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/gem: Fix mmap fake offset handling for drm_gem_object_funcs.mmap
> You need memory pressure, to force ttm to unmap the bo, not userspace. So > roughly > 1. create bo > 2. mmap it through drm fd, write some stuff > 3. export to dma-buf, mmap it, verify stuff is there > 4. create a pile more bo, mmap them write to them > 5. once you've thrashed all of vram enough, recheck your original bo. If > I'm right you should get the following: >- drm fd mmap still show right content >- dma-buf fd mmap shows random crap that you've written into other > buffers > > Ofc you need to make sure that an mmap actually forces the buffer into > vram. So might need a combo of modeset+mmap, to make that happen. Plain > mmap might just give you ptes that point into system memory, which is not > managed by ttm like vram. Is any move buffer good enough to trigger this, i.e. will SYSTEM -> VRAM work too? That'll be easier because all I need to do is map the buffer to a crtc to force pinning to vram, then check if the mappings are intact still ... cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/8] drm/atmel: ditch fb_create wrapper
On Fri, 15 Nov 2019 10:21:14 +0100
Daniel Vetter wrote:
> Spotted while looking through them all.
>
> Signed-off-by: Daniel Vetter
> Cc: Sam Ravnborg
> Cc: Boris Brezillon
Acked-by: Boris Brezillon
> Cc: Nicolas Ferre
> Cc: Alexandre Belloni
> Cc: Ludovic Desroches
> Cc: linux-arm-ker...@lists.infradead.org
> ---
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 8 +---
> 1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> index 92640298ad41..8dc917a1270b 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> @@ -557,12 +557,6 @@ static irqreturn_t atmel_hlcdc_dc_irq_handler(int irq,
> void *data)
> return IRQ_HANDLED;
> }
>
> -static struct drm_framebuffer *atmel_hlcdc_fb_create(struct drm_device *dev,
> - struct drm_file *file_priv, const struct drm_mode_fb_cmd2
> *mode_cmd)
> -{
> - return drm_gem_fb_create(dev, file_priv, mode_cmd);
> -}
> -
> struct atmel_hlcdc_dc_commit {
> struct work_struct work;
> struct drm_device *dev;
> @@ -657,7 +651,7 @@ static int atmel_hlcdc_dc_atomic_commit(struct drm_device
> *dev,
> }
>
> static const struct drm_mode_config_funcs mode_config_funcs = {
> - .fb_create = atmel_hlcdc_fb_create,
> + .fb_create = drm_gem_fb_create,
> .atomic_check = drm_atomic_helper_check,
> .atomic_commit = atmel_hlcdc_dc_atomic_commit,
> };
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/8] drm/mediatek: don't open-code drm_gem_fb_create
Aside: There's a few other fb_create implementations which
simply check for valid buffer format (or an approximation thereof),
and then call drm_gem_fb_create. For atomic drivers at least we could
walk all planes and make sure the format/modifier combo is valid,
and remove even more code.
For non-atomic drivers that's not possible, since the format list for
the primary buffer might be garbage (and most likely it is).
Also delete mtk_drm_fb.[hc] since it would now only contain one
function.
Signed-off-by: Daniel Vetter
Cc: CK Hu
Cc: Philipp Zabel
Cc: Matthias Brugger
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-media...@lists.infradead.org
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 16 -
drivers/gpu/drm/mediatek/mtk_drm_fb.c| 92
drivers/gpu/drm/mediatek/mtk_drm_fb.h| 13
drivers/gpu/drm/mediatek/mtk_drm_plane.c | 1 -
4 files changed, 15 insertions(+), 107 deletions(-)
delete mode 100644 drivers/gpu/drm/mediatek/mtk_drm_fb.c
delete mode 100644 drivers/gpu/drm/mediatek/mtk_drm_fb.h
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 84d14213d992..2b1c122066ea 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -16,8 +16,10 @@
#include
#include
#include
+#include
#include
#include
+#include
#include
#include
#include
@@ -27,7 +29,6 @@
#include "mtk_drm_ddp.h"
#include "mtk_drm_ddp_comp.h"
#include "mtk_drm_drv.h"
-#include "mtk_drm_fb.h"
#include "mtk_drm_gem.h"
#define DRIVER_NAME "mediatek"
@@ -115,6 +116,19 @@ static int mtk_atomic_commit(struct drm_device *drm,
return 0;
}
+static struct drm_framebuffer *
+mtk_drm_mode_fb_create(struct drm_device *dev,
+ struct drm_file *file,
+ const struct drm_mode_fb_cmd2 *cmd)
+{
+ const struct drm_format_info *info = drm_get_format_info(dev, cmd);
+
+ if (info->num_planes != 1)
+ return ERR_PTR(-EINVAL);
+
+ return drm_gem_fb_create(dev, file, cmd);
+}
+
static const struct drm_mode_config_funcs mtk_drm_mode_config_funcs = {
.fb_create = mtk_drm_mode_fb_create,
.atomic_check = drm_atomic_helper_check,
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_fb.c
b/drivers/gpu/drm/mediatek/mtk_drm_fb.c
deleted file mode 100644
index 3f230a28a2dc..
--- a/drivers/gpu/drm/mediatek/mtk_drm_fb.c
+++ /dev/null
@@ -1,92 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Copyright (c) 2015 MediaTek Inc.
- */
-
-#include
-#include
-
-#include
-#include
-#include
-#include
-#include
-
-#include "mtk_drm_drv.h"
-#include "mtk_drm_fb.h"
-#include "mtk_drm_gem.h"
-
-static const struct drm_framebuffer_funcs mtk_drm_fb_funcs = {
- .create_handle = drm_gem_fb_create_handle,
- .destroy = drm_gem_fb_destroy,
-};
-
-static struct drm_framebuffer *mtk_drm_framebuffer_init(struct drm_device *dev,
- const struct drm_mode_fb_cmd2 *mode,
- struct drm_gem_object *obj)
-{
- const struct drm_format_info *info = drm_get_format_info(dev, mode);
- struct drm_framebuffer *fb;
- int ret;
-
- if (info->num_planes != 1)
- return ERR_PTR(-EINVAL);
-
- fb = kzalloc(sizeof(*fb), GFP_KERNEL);
- if (!fb)
- return ERR_PTR(-ENOMEM);
-
- drm_helper_mode_fill_fb_struct(dev, fb, mode);
-
- fb->obj[0] = obj;
-
- ret = drm_framebuffer_init(dev, fb, _drm_fb_funcs);
- if (ret) {
- DRM_ERROR("failed to initialize framebuffer\n");
- kfree(fb);
- return ERR_PTR(ret);
- }
-
- return fb;
-}
-
-struct drm_framebuffer *mtk_drm_mode_fb_create(struct drm_device *dev,
- struct drm_file *file,
- const struct drm_mode_fb_cmd2
*cmd)
-{
- const struct drm_format_info *info = drm_get_format_info(dev, cmd);
- struct drm_framebuffer *fb;
- struct drm_gem_object *gem;
- unsigned int width = cmd->width;
- unsigned int height = cmd->height;
- unsigned int size, bpp;
- int ret;
-
- if (info->num_planes != 1)
- return ERR_PTR(-EINVAL);
-
- gem = drm_gem_object_lookup(file, cmd->handles[0]);
- if (!gem)
- return ERR_PTR(-ENOENT);
-
- bpp = info->cpp[0];
- size = (height - 1) * cmd->pitches[0] + width * bpp;
- size += cmd->offsets[0];
-
- if (gem->size < size) {
- ret = -EINVAL;
- goto unreference;
- }
-
- fb = mtk_drm_framebuffer_init(dev, cmd, gem);
- if (IS_ERR(fb)) {
- ret = PTR_ERR(fb);
- goto unreference;
- }
-
- return fb;
-
-unreference:
- drm_gem_object_put_unlocked(gem);
- return ERR_PTR(ret);
-}
diff --git
[PATCH 7/8] drm/hibmc: Use drm_gem_fb_create
Again we could delete a lot more if we'd switch over to the generic
fbdev stuff.
Signed-off-by: Daniel Vetter
---
.../gpu/drm/hisilicon/hibmc/hibmc_drm_de.c| 4 +-
.../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 11 +---
.../gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 5 +-
drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 62 +--
4 files changed, 19 insertions(+), 63 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
index 6527a97f68a3..2d0920ec4554 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
@@ -99,14 +99,12 @@ static void hibmc_plane_atomic_update(struct drm_plane
*plane,
s64 gpu_addr = 0;
unsigned int line_l;
struct hibmc_drm_private *priv = plane->dev->dev_private;
- struct hibmc_framebuffer *hibmc_fb;
struct drm_gem_vram_object *gbo;
if (!state->fb)
return;
- hibmc_fb = to_hibmc_framebuffer(state->fb);
- gbo = drm_gem_vram_of_gem(hibmc_fb->obj);
+ gbo = drm_gem_vram_of_gem(fb->obj[0]);
gpu_addr = drm_gem_vram_offset(gbo);
if (WARN_ON_ONCE(gpu_addr < 0))
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
index e58ecd7edcf8..ab5b4a4a2095 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
@@ -20,14 +20,9 @@
struct drm_device;
struct drm_gem_object;
-struct hibmc_framebuffer {
- struct drm_framebuffer fb;
- struct drm_gem_object *obj;
-};
-
struct hibmc_fbdev {
struct drm_fb_helper helper; /* must be first */
- struct hibmc_framebuffer *fb;
+ struct drm_framebuffer *fb;
int size;
};
@@ -47,8 +42,6 @@ struct hibmc_drm_private {
struct hibmc_fbdev *fbdev;
};
-#define to_hibmc_framebuffer(x) container_of(x, struct hibmc_framebuffer, fb)
-
void hibmc_set_power_mode(struct hibmc_drm_private *priv,
unsigned int power_mode);
void hibmc_set_current_gate(struct hibmc_drm_private *priv,
@@ -61,7 +54,7 @@ void hibmc_fbdev_fini(struct hibmc_drm_private *priv);
int hibmc_gem_create(struct drm_device *dev, u32 size, bool iskernel,
struct drm_gem_object **obj);
-struct hibmc_framebuffer *
+struct drm_framebuffer *
hibmc_framebuffer_init(struct drm_device *dev,
const struct drm_mode_fb_cmd2 *mode_cmd,
struct drm_gem_object *obj);
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
index b4c1cea051e8..446aeedc9e29 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
@@ -141,15 +141,14 @@ static int hibmc_drm_fb_create(struct drm_fb_helper
*helper,
static void hibmc_fbdev_destroy(struct hibmc_fbdev *fbdev)
{
- struct hibmc_framebuffer *gfb = fbdev->fb;
struct drm_fb_helper *fbh = >helper;
drm_fb_helper_unregister_fbi(fbh);
drm_fb_helper_fini(fbh);
- if (gfb)
- drm_framebuffer_put(>fb);
+ if (fbdev->fb)
+ drm_framebuffer_put(fbdev->fb);
}
static const struct drm_fb_helper_funcs hibmc_fbdev_helper_funcs = {
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
index 21b684eab5c9..386033b0d3a2 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include "hibmc_drm_drv.h"
@@ -97,74 +98,39 @@ int hibmc_dumb_create(struct drm_file *file, struct
drm_device *dev,
return 0;
}
-static void hibmc_user_framebuffer_destroy(struct drm_framebuffer *fb)
-{
- struct hibmc_framebuffer *hibmc_fb = to_hibmc_framebuffer(fb);
-
- drm_gem_object_put_unlocked(hibmc_fb->obj);
- drm_framebuffer_cleanup(fb);
- kfree(hibmc_fb);
-}
-
static const struct drm_framebuffer_funcs hibmc_fb_funcs = {
- .destroy = hibmc_user_framebuffer_destroy,
+ .destroy= drm_gem_fb_destroy,
+ .create_handle = drm_gem_fb_create_handle,
};
-struct hibmc_framebuffer *
+struct drm_framebuffer *
hibmc_framebuffer_init(struct drm_device *dev,
const struct drm_mode_fb_cmd2 *mode_cmd,
struct drm_gem_object *obj)
{
- struct hibmc_framebuffer *hibmc_fb;
+ struct drm_framebuffer *fb;
int ret;
- hibmc_fb = kzalloc(sizeof(*hibmc_fb), GFP_KERNEL);
- if (!hibmc_fb) {
- DRM_ERROR("failed to allocate hibmc_fb\n");
+ fb = kzalloc(sizeof(*fb), GFP_KERNEL);
+ if (!fb) {
+ DRM_ERROR("failed to allocate fb\n");
return ERR_PTR(-ENOMEM);
}
-
[PATCH 2/8] drm/atmel: ditch fb_create wrapper
Spotted while looking through them all.
Signed-off-by: Daniel Vetter
Cc: Sam Ravnborg
Cc: Boris Brezillon
Cc: Nicolas Ferre
Cc: Alexandre Belloni
Cc: Ludovic Desroches
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 92640298ad41..8dc917a1270b 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -557,12 +557,6 @@ static irqreturn_t atmel_hlcdc_dc_irq_handler(int irq,
void *data)
return IRQ_HANDLED;
}
-static struct drm_framebuffer *atmel_hlcdc_fb_create(struct drm_device *dev,
- struct drm_file *file_priv, const struct drm_mode_fb_cmd2
*mode_cmd)
-{
- return drm_gem_fb_create(dev, file_priv, mode_cmd);
-}
-
struct atmel_hlcdc_dc_commit {
struct work_struct work;
struct drm_device *dev;
@@ -657,7 +651,7 @@ static int atmel_hlcdc_dc_atomic_commit(struct drm_device
*dev,
}
static const struct drm_mode_config_funcs mode_config_funcs = {
- .fb_create = atmel_hlcdc_fb_create,
+ .fb_create = drm_gem_fb_create,
.atomic_check = drm_atomic_helper_check,
.atomic_commit = atmel_hlcdc_dc_atomic_commit,
};
--
2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/8] drm/xen: Simplify fb_create
The current code is a pretty good wtf moment, since we drop the
reference before we use it. It's not a big deal, because a) we only
use the pointer, so doesn't blow up and the real reason b) fb->obj[0]
already holds a full reference for us.
Might as well take the real pointer ins't of complicated games that
baffle.
Signed-off-by: Daniel Vetter
Cc: Oleksandr Andrushchenko
Cc: xen-de...@lists.xenproject.org
---
drivers/gpu/drm/xen/xen_drm_front_kms.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front_kms.c
b/drivers/gpu/drm/xen/xen_drm_front_kms.c
index ff506bc99414..4f34c5208180 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_kms.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_kms.c
@@ -63,14 +63,7 @@ fb_create(struct drm_device *dev, struct drm_file *filp,
if (IS_ERR_OR_NULL(fb))
return fb;
- gem_obj = drm_gem_object_lookup(filp, mode_cmd->handles[0]);
- if (!gem_obj) {
- DRM_ERROR("Failed to lookup GEM object\n");
- ret = -ENOENT;
- goto fail;
- }
-
- drm_gem_object_put_unlocked(gem_obj);
+ gem_obj = fb->obj[0];
ret = xen_drm_front_fb_attach(drm_info->front_info,
xen_drm_front_dbuf_to_cookie(gem_obj),
--
2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/8] fb_create drive-through cleanups
Hi all, Inspired by some chatting with Pekka on irc I looked a lot at our ->fb_create implementations. Some cleanups (the simpler ones) and some todos (the more involved stuff). It's not a lot of code that we can collect even with all the todos, but we have so many drivers nowadays it's worth it even for the tiny things. Review and for the driver patches especially some testing very much welcome. Cheers, Daniel Daniel Vetter (8): drm/fb: More paranoia in addfb checks drm/atmel: ditch fb_create wrapper drm/mediatek: don't open-code drm_gem_fb_create drm/rockchip: Use drm_gem_fb_create_with_dirty drm/tilcdc: Drop drm_gem_fb_create wrapper drm/xen: Simplify fb_create drm/hibmc: Use drm_gem_fb_create drm/todo: Add entry for fb funcs related cleanups Documentation/gpu/todo.rst| 26 ++ drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 8 +- drivers/gpu/drm/drm_framebuffer.c | 17 ++-- .../gpu/drm/hisilicon/hibmc/hibmc_drm_de.c| 4 +- .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 11 +-- .../gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 5 +- drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 62 +++-- drivers/gpu/drm/mediatek/mtk_drm_drv.c| 16 +++- drivers/gpu/drm/mediatek/mtk_drm_fb.c | 92 --- drivers/gpu/drm/mediatek/mtk_drm_fb.h | 13 --- drivers/gpu/drm/mediatek/mtk_drm_plane.c | 1 - drivers/gpu/drm/rockchip/rockchip_drm_fb.c| 54 +-- drivers/gpu/drm/tilcdc/tilcdc_drv.c | 8 +- drivers/gpu/drm/xen/xen_drm_front_kms.c | 9 +- 14 files changed, 75 insertions(+), 251 deletions(-) delete mode 100644 drivers/gpu/drm/mediatek/mtk_drm_fb.c delete mode 100644 drivers/gpu/drm/mediatek/mtk_drm_fb.h -- 2.24.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 8/8] drm/todo: Add entry for fb funcs related cleanups
We're doing a great job for really simple drivers right now, but still a lot of boilerplate for the bigger ones. Signed-off-by: Daniel Vetter --- Documentation/gpu/todo.rst | 26 ++ 1 file changed, 26 insertions(+) diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 3ec509381fc5..2d85f37284a1 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -182,6 +182,32 @@ Contact: Maintainer of the driver you plan to convert Level: Intermediate +drm_framebuffer_funcs and drm_mode_config_funcs.fb_create cleanup +- + +A lot more drivers could be switched over to the drm_gem_framebuffer helpers. +Various hold-ups: + +- Need to switch over to the generic dirty tracking code using + drm_atomic_helper_dirtyfb first (e.g. qxl). + +- Need to switch to drm_fbdev_generic_setup(), otherwise a lot of the custom fb + setup code can't be deleted. + +- Many drivers wrap drm_gem_fb_create() only to check for valid formats. For + atomic drivers we could check for valid formats by calling + drm_plane_check_pixel_format() against all planes, and pass if any plane + supports the format. For non-atomic that's not possible since like the format + list for the primary plane is fake and we'd therefor reject valid formats. + +- Many drivers subclass drm_framebuffer, we'd need a embedding compatible + version of the varios drm_gem_fb_create functions. Maybe called + drm_gem_fb_create/_with_dirty/_with_funcs as needed. + +Contact: Daniel Vetter + +Level: Intermediate + Clean up mmap forwarding -- 2.24.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/8] drm/fb: More paranoia in addfb checks
- Our limit is uint32_t, make that explicit.
- Untangle the one overflow check, I think (but not sure) that with
all three together you could overflow the uint64_t and it'd look
cool again. Hence two steps. Also go with the more common (and imo
safer approach) of reducing the range we accept, instead of trying
to compute the overflow in high enough precision.
- The above would blow up if we get a 0 pitches, so check for that
too, but only if block_size is a thing.
Cc: Pekka Paalanen
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_framebuffer.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_framebuffer.c
b/drivers/gpu/drm/drm_framebuffer.c
index 57564318ceea..3141c6ed6dd2 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -214,15 +214,20 @@ static int framebuffer_check(struct drm_device *dev,
return -EINVAL;
}
- if (min_pitch > UINT_MAX)
+ if (min_pitch > U8_MAX)
return -ERANGE;
- if ((uint64_t) height * r->pitches[i] + r->offsets[i] >
UINT_MAX)
- return -ERANGE;
+ if (block_size) {
+ if (r->pitches[i] < min_pitch) {
+ DRM_DEBUG_KMS("bad pitch %u for plane %d\n",
r->pitches[i], i);
+ return -EINVAL;
+ }
- if (block_size && r->pitches[i] < min_pitch) {
- DRM_DEBUG_KMS("bad pitch %u for plane %d\n",
r->pitches[i], i);
- return -EINVAL;
+ if (height > U8_MAX / r->pitches[i])
+ return -ERANGE;
+
+ if (r->offsets[i] > U8_MAX / r->pitches[i] - height)
+ return -ERANGE;
}
if (r->modifier[i] && !(r->flags & DRM_MODE_FB_MODIFIERS)) {
--
2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/8] drm/rockchip: Use drm_gem_fb_create_with_dirty
If rockchip would switch over to the generic fbdev setup we could
grabage collect even more of all this code (all of the remaining fb
handling code really).
Signed-off-by: Daniel Vetter
Cc: Sandy Huang
Cc: "Heiko Stübner"
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
---
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 54 +-
1 file changed, 1 insertion(+), 53 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index ca01234c037c..081dbdaa0b07 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -53,64 +53,12 @@ rockchip_fb_alloc(struct drm_device *dev, const struct
drm_mode_fb_cmd2 *mode_cm
return fb;
}
-static struct drm_framebuffer *
-rockchip_user_fb_create(struct drm_device *dev, struct drm_file *file_priv,
- const struct drm_mode_fb_cmd2 *mode_cmd)
-{
- const struct drm_format_info *info = drm_get_format_info(dev,
-mode_cmd);
- struct drm_framebuffer *fb;
- struct drm_gem_object *objs[ROCKCHIP_MAX_FB_BUFFER];
- struct drm_gem_object *obj;
- int num_planes = min_t(int, info->num_planes, ROCKCHIP_MAX_FB_BUFFER);
- int ret;
- int i;
-
- for (i = 0; i < num_planes; i++) {
- unsigned int width = mode_cmd->width / (i ? info->hsub : 1);
- unsigned int height = mode_cmd->height / (i ? info->vsub : 1);
- unsigned int min_size;
-
- obj = drm_gem_object_lookup(file_priv, mode_cmd->handles[i]);
- if (!obj) {
- DRM_DEV_ERROR(dev->dev,
- "Failed to lookup GEM object\n");
- ret = -ENXIO;
- goto err_gem_object_unreference;
- }
-
- min_size = (height - 1) * mode_cmd->pitches[i] +
- mode_cmd->offsets[i] +
- width * info->cpp[i];
-
- if (obj->size < min_size) {
- drm_gem_object_put_unlocked(obj);
- ret = -EINVAL;
- goto err_gem_object_unreference;
- }
- objs[i] = obj;
- }
-
- fb = rockchip_fb_alloc(dev, mode_cmd, objs, i);
- if (IS_ERR(fb)) {
- ret = PTR_ERR(fb);
- goto err_gem_object_unreference;
- }
-
- return fb;
-
-err_gem_object_unreference:
- for (i--; i >= 0; i--)
- drm_gem_object_put_unlocked(objs[i]);
- return ERR_PTR(ret);
-}
-
static const struct drm_mode_config_helper_funcs rockchip_mode_config_helpers
= {
.atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
};
static const struct drm_mode_config_funcs rockchip_drm_mode_config_funcs = {
- .fb_create = rockchip_user_fb_create,
+ .fb_create = drm_gem_fb_create,
.output_poll_changed = drm_fb_helper_output_poll_changed,
.atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
--
2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/8] drm/tilcdc: Drop drm_gem_fb_create wrapper
Doesn't do anything.
Signed-off-by: Daniel Vetter
Cc: Jyri Sarha
Cc: Tomi Valkeinen
---
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 2a9e67597375..a160880bea0a 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -64,12 +64,6 @@ void tilcdc_module_cleanup(struct tilcdc_module *mod)
static struct of_device_id tilcdc_of_match[];
-static struct drm_framebuffer *tilcdc_fb_create(struct drm_device *dev,
- struct drm_file *file_priv, const struct drm_mode_fb_cmd2
*mode_cmd)
-{
- return drm_gem_fb_create(dev, file_priv, mode_cmd);
-}
-
static int tilcdc_atomic_check(struct drm_device *dev,
struct drm_atomic_state *state)
{
@@ -140,7 +134,7 @@ static int tilcdc_commit(struct drm_device *dev,
}
static const struct drm_mode_config_funcs mode_config_funcs = {
- .fb_create = tilcdc_fb_create,
+ .fb_create = drm_gem_fb_create,
.atomic_check = tilcdc_atomic_check,
.atomic_commit = tilcdc_commit,
};
--
2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/amdgpu/dm: Do not throw an error for a display with no audio
On Fri, Nov 15, 2019 at 10:04 AM Jean Delvare wrote:
>
> Hi Chris,
>
> On Thu, 14 Nov 2019 20:44:13 +, Chris Wilson wrote:
> > An old display with no audio may not have an EDID with a CEA block, or
> > it may simply be too old to support audio. This is not a driver error,
> > so don't flag it as such.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112140
> > References: ae2a3495973e ("drm/amd: be quiet when no SAD block is found")
> > Signed-off-by: Chris Wilson
> > Cc: Harry Wentland
> > Cc: Jean Delvare
> > Cc: Alex Deucher
> > ---
> > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 --
> > 1 file changed, 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > index 11e5784aa62a..04808dbecab3 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > @@ -97,8 +97,6 @@ enum dc_edid_status dm_helpers_parse_edid_caps(
> > (struct edid *) edid->raw_edid);
> >
> > sad_count = drm_edid_to_sad((struct edid *) edid->raw_edid, );
> > - if (sad_count < 0)
> > - DRM_ERROR("Couldn't read SADs: %d\n", sad_count);
> > if (sad_count <= 0)
> > return result;
> >
>
> I still believe that my approach was a better way to solve this problem:
>
> https://patchwork.freedesktop.org/patch/329066/
>
> Your approach would have to be applied to all individual drivers (all
> callers of drm_edid_to_sad). It also prevents reporting actual errors.
>
> Should I resend my patch?
I think we can do both, just ask Ville to apply the patch for you (he
has commit rights to drm-misc). Or resend and then ping Ville on irc.
-Daniel
>
> --
> Jean Delvare
> SUSE L3 Support
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205497] Attempt to read amd gpu id causes a freeze
https://bugzilla.kernel.org/show_bug.cgi?id=205497 --- Comment #10 from V.I.S. (itemc...@mail.ru) --- AMD Ryzen 5 2600G + AMD RX560 (multiseat system), system freezed after few days on kernel 4.19.83 in my case. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 112288] Blank display on Ubuntu 19.10 on Ryzen 3 2200G and Ryzen 5 2400G APUs
https://bugs.freedesktop.org/show_bug.cgi?id=112288 --- Comment #11 from Michel Dänzer --- (In reply to Alex Deucher from comment #3) > [1.094054] [drm:amdgpu_init [amdgpu]] *ERROR* VGACON disables amdgpu > kernel modesetting. > Did you enable vga console? FWIW, that message is due to "nomodeset" on the kernel command line, which was presumably used to work around this problem? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205497] Attempt to read amd gpu id causes a freeze
https://bugzilla.kernel.org/show_bug.cgi?id=205497 --- Comment #9 from Trek (tre...@inbox.ru) --- thanks, I was not aware of it, may be different hardware from the ones on which kernel 4.19/5.1 works? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm core/helpers and MIT license
On Thu, Nov 14, 2019 at 08:01:32PM +, co...@sdf.org wrote: > Hi Daniel, > > I don't think we can make any complaints about GPL being more widely > used in the DRM code. It's nice to have the code at all, the MIT license > is a bonus. Thanks for writing it and bearing with us. > > Would rewrites done purely for licensing reasons be accepted upstream? Figuring that out is why I started this thread. Thus far the consensus seems to be a deafening *shrug*, so no idea. Personally I'm happy to take any patches with a clear net benefit in terms of contributions/hw support/maintenability for linux gpu support. Everything else probably needs a much wider support in the community. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205497] Attempt to read amd gpu id causes a freeze
https://bugzilla.kernel.org/show_bug.cgi?id=205497 --- Comment #8 from V.I.S. (itemc...@mail.ru) --- Please read here... https://github.com/lestofante/ksysguard-gpu/issues/4 Same issue on 4.19.x LTS kernel. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205497] Attempt to read amd gpu id causes a freeze
https://bugzilla.kernel.org/show_bug.cgi?id=205497 Trek (tre...@inbox.ru) changed: What|Removed |Added CC||tre...@inbox.ru --- Comment #7 from Trek (tre...@inbox.ru) --- as users reported, this bug should only affects kernels 5.2+ by default, radeontop calls amdgpu_read_mm_registers, amdgpu_query_info and amdgpu_query_sensor_info, but it can be forced by the command line to read BAR from /dev/mem there is a kernel dump at https://github.com/clbr/radeontop/issues/87#issuecomment-529267244 thank you for the patch, but I cannot test it as my hardware is not affected (KAVERI) -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] drm/amd/display: remove set but not used variable 'bp' in bios_parser2.c
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c: In function
bios_get_board_layout_info:
drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c:1826:22: warning: variable
bp set but not used [-Wunused-but-set-variable]
It is introduced by commit 1eeedbcc20d6 ("drm/amd/display:
get board layout for edid emulation"), but never used,
so remove it.
Reported-by: Hulk Robot
Signed-off-by: zhengbin
---
drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
index 6e29ba8..9dc8d4e 100644
--- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
+++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
@@ -1838,7 +1838,6 @@ static enum bp_result bios_get_board_layout_info(
struct board_layout_info *board_layout_info)
{
unsigned int i;
- struct bios_parser *bp;
enum bp_result record_result;
const unsigned int slot_index_to_vbios_id[MAX_BOARD_SLOTS] = {
@@ -1847,7 +1846,6 @@ static enum bp_result bios_get_board_layout_info(
0, 0
};
- bp = BP_FROM_DCB(dcb);
if (board_layout_info == NULL) {
DC_LOG_DETECTION_EDID_PARSER("Invalid board_layout_info\n");
return BP_RESULT_BADINPUT;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Proposal to report GPU private memory allocations with sysfs nodes [plain text version]
Thanks for all the comments and feedback, and they are all so valuable to me.
Let me summarize the main concerns so far here:
(1) Open source driver never specifies what API is creating a gem
object (opengl, vulkan, ...) nor what purpose (transient, shader,
...).
(2) The ioctl to label anything to a BO and the label can change over
the BO's lifetime: https://patchwork.kernel.org/patch/11185643/
(3) BOs are not attached to pids, but files, and can be shared.
Besides the discussions here, there was a lot of internal discussion
for this proposal as well. The general principle is that I'll align my
proposal with what exists on the upstream so that to help Android
common kernel stay close to the upstream kernel for the sake of future
graphics driver architecture.
I think tracking BOs per process would be a good thing on upstream as
well. Some of the GPU addressable memory may have been mapped to the
userspace which is visible in RSS. However, tools consuming RSS data
can benefit more by knowing the amount of GPU memory which are not
mapped. It's a good thing for per process memory accounting.
BOs on the upstream is not equal to what's on Android today. Android
GPU memory objects are purely private and thus indexed by pid, and the
shared memory is allocated through ion/dmabuf interface. The
ion/dmabuf is similar to the upstream BO except that GEM BOs may just
be an anon inode without a fd before sharing. For Android ion/dmabuf
accounting, there was already an effort here to improve the dma-buf
tracking(https://patchwork.kernel.org/cover/10831029/), and there's
userspace API built on top of the "proc//fdinfo"
node(https://android.googlesource.com/platform/system/core/+/refs/heads/master/libmeminfo/libdmabufinfo/include/dmabufinfo/dmabufinfo.h#103).
Is it reasonable to add another ioctl or something equivalent to label
a BO with what PID makes the allocation? When the BO gets shared to
other processes, this information also needs to be bookkept somewhere
for tracking. Basically I wonder if it's possible for upstream to
track BOs in a similar way Android tracks dmabuf. Then there's a node
implemented by cgroup in proc listing all the BOs per process with
information like label, refcount, etc. Then Android GPU vendors can
implement the same nodes which is going to be compatible even if they
later adopts drm subsystem.
So my sketch idea for the nodes are:
(1) /proc/gpu0_meminfo, /proc/gpu1_meminfo
This is a list of all BOs with pids holding a reference to it and the
current label of each BO
(2) /proc//gpu0_meminfo, /proc//gpu1_meminfo
This is a list of all BOs this process holds a reference to.
(3) Is it reasonable to implement another nodes for {total,
total_unmapped} counters? or just surface through /proc/meminfo?
Many thanks for the feedback!
Yiwei
On Tue, Nov 12, 2019 at 12:18 PM Jerome Glisse wrote:
>
> On Tue, Nov 12, 2019 at 10:17:10AM -0800, Yiwei Zhang wrote:
> > Hi folks,
> >
> > What do you think about:
> > > For the sysfs approach, I'm assuming the upstream vendors still need
> > > to provide a pair of UMD and KMD, and this ioctl to label the BO is
> > > kept as driver private ioctl. Then will each driver just define their
> > > own set of "label"s and the KMD will only consume the corresponding
> > > ones so that the sysfs nodes won't change at all? Report zero if
> > > there's no allocation or re-use under a particular "label".
>
> To me this looks like a way to abuse the kernel into provide a specific
> message passing API between process only for GPU. It would be better to
> use existing kernel/userspace API to pass message between process than
> add a new one just for a special case.
>
> Note that I believe that listing GPU allocation for a process might
> useful but only if it is a generic thing accross all GPU (for upstream
> GPU driver we do not care about non upstream).
>
> Cheers,
> Jérôme
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 1/2] drm/panel: add support for rm69299 visionox panel driver
Add support for Visionox panel driver.
Signed-off-by: Harigovindan P
---
drivers/gpu/drm/panel/Kconfig | 9 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-visionox-rm69299.c | 478 +
3 files changed, 488 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-visionox-rm69299.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index f152bc4..c06c403 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -355,4 +355,13 @@ config DRM_PANEL_TRULY_NT35597_WQXGA
help
Say Y here if you want to enable support for Truly NT35597 WQXGA Dual
DSI
Video Mode panel
+
+config DRM_PANEL_VISIONOX_RM69299
+ tristate "Visionox RM69299"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ help
+ Say Y here if you want to enable support for Visionox
+ RM69299 DSI Video Mode panel.
+
endmenu
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index b6cd39f..6f1e4c6 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -38,3 +38,4 @@ obj-$(CONFIG_DRM_PANEL_TPO_TD028TTEC1) +=
panel-tpo-td028ttec1.o
obj-$(CONFIG_DRM_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o
obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o
+obj-$(CONFIG_DRM_PANEL_VISIONOX_RM69299) += panel-visionox-rm69299.o
diff --git a/drivers/gpu/drm/panel/panel-visionox-rm69299.c
b/drivers/gpu/drm/panel/panel-visionox-rm69299.c
new file mode 100644
index 000..faf6d05
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-visionox-rm69299.c
@@ -0,0 +1,478 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019, The Linux Foundation. All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+static const char * const regulator_names[] = {
+ "vdda",
+ "vdd3p3",
+};
+
+static unsigned long const regulator_enable_loads[] = {
+ 32000,
+ 13200,
+};
+
+static unsigned long const regulator_disable_loads[] = {
+ 80,
+ 80,
+};
+
+struct cmd_set {
+ u8 commands[4];
+ u8 size;
+};
+
+struct rm69299_config {
+ u32 width_mm;
+ u32 height_mm;
+ const char *panel_name;
+ const struct cmd_set *panel_on_cmds;
+ u32 num_on_cmds;
+ const struct drm_display_mode *dm;
+};
+
+struct visionox_rm69299 {
+ struct device *dev;
+ struct drm_panel panel;
+
+ struct regulator_bulk_data supplies[ARRAY_SIZE(regulator_names)];
+
+ struct gpio_desc *reset_gpio;
+
+ struct backlight_device *backlight;
+
+ struct mipi_dsi_device *dsi;
+ const struct rm69299_config *config;
+ bool prepared;
+ bool enabled;
+};
+
+static inline struct visionox_rm69299 *panel_to_ctx(struct drm_panel *panel)
+{
+ return container_of(panel, struct visionox_rm69299, panel);
+}
+
+static const struct cmd_set qcom_rm69299_1080p_panel_magic_cmds[] = {
+ { { 0xfe, 0x00 }, 2 },
+ { { 0xc2, 0x08 }, 2 },
+ { { 0x35, 0x00 }, 2 },
+ { { 0x51, 0xff }, 2 },
+};
+
+static int visionox_dcs_write(struct drm_panel *panel, u32 command)
+{
+ struct visionox_rm69299 *ctx = panel_to_ctx(panel);
+ int i = 0, ret;
+
+ ret = mipi_dsi_dcs_write(ctx->dsi, command, NULL, 0);
+ if (ret < 0) {
+ DRM_DEV_ERROR(ctx->dev,
+ "cmd 0x%x failed for dsi = %d\n",
+ command, i);
+ }
+
+ return ret;
+}
+
+static int visionox_dcs_write_buf(struct drm_panel *panel,
+ u32 size, const u8 *buf)
+{
+ struct visionox_rm69299 *ctx = panel_to_ctx(panel);
+ int ret = 0;
+ int i = 0;
+
+ ret = mipi_dsi_dcs_write_buffer(ctx->dsi, buf, size);
+ if (ret < 0) {
+ DRM_DEV_ERROR(ctx->dev,
+ "failed to tx cmd [%d], err: %d\n", i, ret);
+ return ret;
+ }
+
+ return ret;
+}
+
+static int visionox_35597_power_on(struct visionox_rm69299 *ctx)
+{
+ int ret, i;
+ for (i = 0; i < ARRAY_SIZE(ctx->supplies); i++) {
+ ret = regulator_set_load(ctx->supplies[i].consumer,
+ regulator_enable_loads[i]);
+ if (ret)
+ return ret;
+ }
+
+ ret = regulator_bulk_enable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
+ if (ret < 0)
+ return ret;
+
+ /*
+* Reset sequence of visionox panel requires the panel to be
+* out of reset for 10ms, followed by being held in reset
+* for 10ms and then out again
+*/
+ gpiod_set_value(ctx->reset_gpio, 1);
+ usleep_range(1, 2);
+
[PATCH] drm/imx: parallel-display: Adjust bus_flags and bus_format handling
The bus_flags and bus_format handling logic does not seem to cover
all potential usecases. Specifically, this seems to fail with an
"edt,etm0700g0edh6" display attached to an 24bit display interface,
with interface-pix-fmt = "rgb24" set in DT.
In this specific setup, the panel-simple.c driver entry for the display
sets .bus_flags to non-zero value. However, as imxpd->bus_format is set
from the DT property "interface-pix-fmt", imx_pd_encoder_atomic_check()
will set imx_crtc_state->bus_flags = imxpd->bus_flags even though the
imxpd->bus_flags is zero, while the di->bus_flags is correctly set by
the panel-simple.c and non-zero. The result is incorrect flags being
used for the display configuration and thus an image corruption.
(Specifically, DRM_BUS_FLAG_PIXDATA_POSEDGE is not propagated and thus
the ipuv3 clocks pixels on the wrong edge).
This patch fixes the problem by overriding the imx_crtc_state->bus_format
from the imxpd->bus_format only if the DT property "interface-pix-fmt" is
present or if the DI provides no formats. Similarly for bus_flags, which
are set from imxpd->bus_flags only if the DI provides no formats.
Signed-off-by: Marek Vasut
Cc: Daniel Vetter
Cc: David Airlie
Cc: Fabio Estevam
Cc: NXP Linux Team
Cc: Philipp Zabel
Cc: Sascha Hauer
Cc: Shawn Guo
Cc: linux-arm-ker...@lists.infradead.org
To: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/imx/parallel-display.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/imx/parallel-display.c
b/drivers/gpu/drm/imx/parallel-display.c
index 35518e5de356..92f00b12c068 100644
--- a/drivers/gpu/drm/imx/parallel-display.c
+++ b/drivers/gpu/drm/imx/parallel-display.c
@@ -113,13 +113,16 @@ static int imx_pd_encoder_atomic_check(struct drm_encoder
*encoder,
struct drm_display_info *di = _state->connector->display_info;
struct imx_parallel_display *imxpd = enc_to_imxpd(encoder);
- if (!imxpd->bus_format && di->num_bus_formats) {
- imx_crtc_state->bus_flags = di->bus_flags;
+ if (imxpd->bus_format || !di->num_bus_formats)
+ imx_crtc_state->bus_format = imxpd->bus_format;
+ else
imx_crtc_state->bus_format = di->bus_formats[0];
- } else {
+
+ if (di->num_bus_formats)
+ imx_crtc_state->bus_flags = di->bus_flags;
+ else
imx_crtc_state->bus_flags = imxpd->bus_flags;
- imx_crtc_state->bus_format = imxpd->bus_format;
- }
+
imx_crtc_state->di_hsync_pin = 2;
imx_crtc_state->di_vsync_pin = 3;
--
2.24.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] drm/amd/display: remove set but not used variable 'min_content'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/amd/display/modules/color/color_gamma.c: In function
build_freesync_hdr:
drivers/gpu/drm/amd/display/modules/color/color_gamma.c:830:20: warning:
variable min_content set but not used [-Wunused-but-set-variable]
It is not used since commit 50575eb5b339 ("drm/amd/display:
Only use EETF when maxCL > max display")
Reported-by: Hulk Robot
Signed-off-by: zhengbin
---
drivers/gpu/drm/amd/display/modules/color/color_gamma.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/modules/color/color_gamma.c
b/drivers/gpu/drm/amd/display/modules/color/color_gamma.c
index 1de4805..9b121b0 100644
--- a/drivers/gpu/drm/amd/display/modules/color/color_gamma.c
+++ b/drivers/gpu/drm/amd/display/modules/color/color_gamma.c
@@ -937,7 +937,6 @@ static bool build_freesync_hdr(struct pwl_float_data_ex
*rgb_regamma,
struct fixed31_32 max_display;
struct fixed31_32 min_display;
struct fixed31_32 max_content;
- struct fixed31_32 min_content;
struct fixed31_32 clip = dc_fixpt_one;
struct fixed31_32 output;
bool use_eetf = false;
@@ -951,7 +950,6 @@ static bool build_freesync_hdr(struct pwl_float_data_ex
*rgb_regamma,
max_display = dc_fixpt_from_int(fs_params->max_display);
min_display = dc_fixpt_from_fraction(fs_params->min_display, 1);
max_content = dc_fixpt_from_int(fs_params->max_content);
- min_content = dc_fixpt_from_fraction(fs_params->min_content, 1);
sdr_white_level = dc_fixpt_from_int(fs_params->sdr_white_level);
if (fs_params->min_display > 1000) // cap at 0.1 at the bottom
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] add new DRM_DEV_WARN macro
This adds a new DRM_DEV_WARN helper macro for warnings log output that include device pointers. It also includes the use of the DRM_DEV_WARN macro in drm/rockchip to replace dev_warn. Wambui Karuga (2): drm/print: add DRM_DEV_WARN macro drm/rockchip: use DRM_DEV_WARN macro in debug output drivers/gpu/drm/rockchip/inno_hdmi.c | 3 ++- include/drm/drm_print.h | 9 + 2 files changed, 11 insertions(+), 1 deletion(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/rockchip: use DRM_DEV_WARN macro in debug output
Replace the use of dev_warn in debug output with the new DRM specific
DRM_DEV_WARN debug output macro to maintain consistency across the driver.
Signed-off-by: Wambui Karuga
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index e5864e823020..d7ee8d1835c4 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -796,7 +796,8 @@ static struct i2c_adapter *inno_hdmi_i2c_adapter(struct
inno_hdmi *hdmi)
ret = i2c_add_adapter(adap);
if (ret) {
- dev_warn(hdmi->dev, "cannot add %s I2C adapter\n", adap->name);
+ DRM_DEV_WARN(hdmi->dev,
+"cannot add %s I2C adapter\n", adap->name);
devm_kfree(hdmi->dev, i2c);
return ERR_PTR(ret);
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] drm/amd/display: remove set but not used variable 'old_plane_crtc'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c: In function
dm_determine_update_type_for_commit:
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:6516:36: warning: variable
old_plane_crtc set but not used [-Wunused-but-set-variable]
It is introduced by commit a87fa9938749 ("drm/amd/display:
Build stream update and plane updates in dm"), but never used,
so remove it.
Reported-by: Hulk Robot
Signed-off-by: zhengbin
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index c2700bc..700cbd5 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7611,7 +7611,7 @@ dm_determine_update_type_for_commit(struct
amdgpu_display_manager *dm,
int i, j, num_plane, ret = 0;
struct drm_plane_state *old_plane_state, *new_plane_state;
struct dm_plane_state *new_dm_plane_state, *old_dm_plane_state;
- struct drm_crtc *new_plane_crtc, *old_plane_crtc;
+ struct drm_crtc *new_plane_crtc;
struct drm_plane *plane;
struct drm_crtc *crtc;
@@ -7657,7 +7657,6 @@ dm_determine_update_type_for_commit(struct
amdgpu_display_manager *dm,
uint64_t tiling_flags;
new_plane_crtc = new_plane_state->crtc;
- old_plane_crtc = old_plane_state->crtc;
new_dm_plane_state = to_dm_plane_state(new_plane_state);
old_dm_plane_state = to_dm_plane_state(old_plane_state);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4] drm/amd/display: remove set but not used variable 'bp' in bios_parser.c
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/amd/display/dc/bios/bios_parser.c: In function
bios_get_board_layout_info:
drivers/gpu/drm/amd/display/dc/bios/bios_parser.c:2743:22: warning: variable bp
set but not used [-Wunused-but-set-variable]
It is introduced by commit 1eeedbcc20d6 ("drm/amd/display:
get board layout for edid emulation"), but never used,
so remove it.
Reported-by: Hulk Robot
Signed-off-by: zhengbin
---
drivers/gpu/drm/amd/display/dc/bios/bios_parser.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
b/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
index 823843c..c34797c 100644
--- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
+++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
@@ -2739,7 +2739,6 @@ static enum bp_result bios_get_board_layout_info(
struct board_layout_info *board_layout_info)
{
unsigned int i;
- struct bios_parser *bp;
enum bp_result record_result;
const unsigned int slot_index_to_vbios_id[MAX_BOARD_SLOTS] = {
@@ -2748,7 +2747,6 @@ static enum bp_result bios_get_board_layout_info(
0, 0
};
- bp = BP_FROM_DCB(dcb);
if (board_layout_info == NULL) {
DC_LOG_DETECTION_EDID_PARSER("Invalid board_layout_info\n");
return BP_RESULT_BADINPUT;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/4] drm/amd/display: remove some set but not used variables
zhengbin (4): drm/amd/display: remove set but not used variable 'old_plane_crtc' drm/amd/display: remove set but not used variable 'bp' in bios_parser2.c drm/amd/display: remove set but not used variable 'bp' in bios_parser.c drm/amd/display: remove set but not used variable 'min_content' drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +-- drivers/gpu/drm/amd/display/dc/bios/bios_parser.c | 2 -- drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c | 2 -- drivers/gpu/drm/amd/display/modules/color/color_gamma.c | 2 -- 4 files changed, 1 insertion(+), 8 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH v1 2/2] drm/msm: add DSI config changes to support DSI version
On Thu, Nov 14, 2019 at 10:47 AM Rob Clark wrote:
>
> On Thu, Nov 14, 2019 at 2:16 AM Harigovindan P
> wrote:
> >
> > Add DSI config changes to support DSI version.
> >
> > Signed-off-by: Harigovindan P
>
> Reviewed-by: Rob Clark
Can we fix the subject/commit text for this to indicate what DSI
version and/or SoC this is for? This is a SoC enablement patch, but
at first I thought this was some bug fix or something.
>
> For patch 1/2 with the panel driver, probably best to split that out
> into a different patch(set), since panel drivers are merged into
> drm-next via a different tree
>
> BR,
> -R
>
> > ---
> > drivers/gpu/drm/msm/dsi/dsi_cfg.c | 21 +
> > drivers/gpu/drm/msm/dsi/dsi_cfg.h | 1 +
> > 2 files changed, 22 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
> > b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
> > index b7b7c1a..d2c4592 100644
> > --- a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
> > +++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
> > @@ -133,6 +133,10 @@ static const char * const dsi_sdm845_bus_clk_names[] =
> > {
> > "iface", "bus",
> > };
> >
> > +static const char * const dsi_sc7180_bus_clk_names[] = {
> > +"iface", "bus",
> > +};
> > +
> > static const struct msm_dsi_config sdm845_dsi_cfg = {
> > .io_offset = DSI_6G_REG_SHIFT,
> > .reg_cfg = {
> > @@ -147,6 +151,20 @@ static const struct msm_dsi_config sdm845_dsi_cfg = {
> > .num_dsi = 2,
> > };
> >
> > +static const struct msm_dsi_config sc7180_dsi_cfg = {
> > + .io_offset = DSI_6G_REG_SHIFT,
> > + .reg_cfg = {
> > + .num = 1,
> > + .regs = {
> > + {"vdda", 21800, 4 },/* 1.2 V */
> > + },
> > + },
> > + .bus_clk_names = dsi_sc7180_bus_clk_names,
> > + .num_bus_clks = ARRAY_SIZE(dsi_sc7180_bus_clk_names),
> > + .io_start = { 0xae94000 },
> > + .num_dsi = 1,
> > +};
> > +
> > const static struct msm_dsi_host_cfg_ops msm_dsi_v2_host_ops = {
> > .link_clk_enable = dsi_link_clk_enable_v2,
> > .link_clk_disable = dsi_link_clk_disable_v2,
> > @@ -201,6 +219,9 @@ static const struct msm_dsi_cfg_handler
> > dsi_cfg_handlers[] = {
> > _dsi_cfg, _dsi_6g_v2_host_ops},
> > {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V2_2_1,
> > _dsi_cfg, _dsi_6g_v2_host_ops},
> > + {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V2_4_1,
> > + _dsi_cfg, _dsi_6g_v2_host_ops},
> > +
> > };
> >
> > const struct msm_dsi_cfg_handler *msm_dsi_cfg_get(u32 major, u32 minor)
> > diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.h
> > b/drivers/gpu/drm/msm/dsi/dsi_cfg.h
> > index e2b7a7d..9919536 100644
> > --- a/drivers/gpu/drm/msm/dsi/dsi_cfg.h
> > +++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.h
> > @@ -19,6 +19,7 @@
> > #define MSM_DSI_6G_VER_MINOR_V1_4_10x10040001
> > #define MSM_DSI_6G_VER_MINOR_V2_2_00x2000
> > #define MSM_DSI_6G_VER_MINOR_V2_2_10x20020001
> > +#define MSM_DSI_6G_VER_MINOR_V2_4_10x20040001
> >
> > #define MSM_DSI_V2_VER_MINOR_8064 0x0
> >
> > --
> > 2.7.4
> >
> ___
> Freedreno mailing list
> freedr...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 0/2] Add suppport for rm69299 Visionox panel driver and add DSI config to support DSI version
Current patchset adds support for rm69299 visionox panel driver used in MSM reference platforms and also adds DSI config that supports the respective DSI version. The visionox panel driver supports a resolution of 1080x2248 with 4 lanes and supports only single DSI mode. Current patchset is tested on actual panel. Harigovindan P (2): drm/panel: add support for rm69299 visionox panel driver drm/msm: add DSI config changes to support DSI version drivers/gpu/drm/msm/dsi/dsi_cfg.c | 21 ++ drivers/gpu/drm/msm/dsi/dsi_cfg.h | 1 + drivers/gpu/drm/panel/Kconfig | 9 + drivers/gpu/drm/panel/Makefile | 1 + drivers/gpu/drm/panel/panel-visionox-rm69299.c | 478 + 5 files changed, 510 insertions(+) create mode 100644 drivers/gpu/drm/panel/panel-visionox-rm69299.c -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
