[PATCH] drm: i915: Fix a typo
s/nothign/nothing/ Signed-off-by: Bhaskar Chowdhury --- drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c index f6ad257a260e..14d784a6fae5 100644 --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c @@ -4185,7 +4185,7 @@ static void icl_pll_disable(struct drm_i915_private *dev_priv, /* * DVFS pre sequence would be here, but in our driver the cdclk code * paths should already be setting the appropriate voltage, hence we do -* nothign here. +* nothing here. */ val = intel_de_read(dev_priv, enable_reg); -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/ttm: switch to per device LRU lock
On Thu, Mar 18, 2021 at 08:47:19PM +0800, Christian König wrote:
> Instead of having a global lock.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 8 ++---
> drivers/gpu/drm/qxl/qxl_release.c | 5 +--
> drivers/gpu/drm/ttm/ttm_bo.c | 49 --
> drivers/gpu/drm/ttm/ttm_device.c | 12 +++
> drivers/gpu/drm/ttm/ttm_execbuf_util.c | 8 ++---
> drivers/gpu/drm/ttm/ttm_resource.c | 9 +++--
> include/drm/ttm/ttm_bo_driver.h| 4 +--
> include/drm/ttm/ttm_device.h | 4 +--
> 8 files changed, 43 insertions(+), 56 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> index 9d19078246c8..ae18c0e32347 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> @@ -638,15 +638,15 @@ void amdgpu_vm_move_to_lru_tail(struct amdgpu_device
> *adev,
> struct amdgpu_vm_bo_base *bo_base;
>
> if (vm->bulk_moveable) {
> - spin_lock(_glob.lru_lock);
> + spin_lock(>mman.bdev.lru_lock);
Could you please explain why do you want to instead of the global lock?
Thanks,
Ray
> ttm_bo_bulk_move_lru_tail(>lru_bulk_move);
> - spin_unlock(_glob.lru_lock);
> + spin_unlock(>mman.bdev.lru_lock);
> return;
> }
>
> memset(>lru_bulk_move, 0, sizeof(vm->lru_bulk_move));
>
> - spin_lock(_glob.lru_lock);
> + spin_lock(>mman.bdev.lru_lock);
> list_for_each_entry(bo_base, >idle, vm_status) {
> struct amdgpu_bo *bo = bo_base->bo;
>
> @@ -660,7 +660,7 @@ void amdgpu_vm_move_to_lru_tail(struct amdgpu_device
> *adev,
> >shadow->tbo.mem,
> >lru_bulk_move);
> }
> - spin_unlock(_glob.lru_lock);
> + spin_unlock(>mman.bdev.lru_lock);
>
> vm->bulk_moveable = true;
> }
> diff --git a/drivers/gpu/drm/qxl/qxl_release.c
> b/drivers/gpu/drm/qxl/qxl_release.c
> index f5845c96d414..b19f2f00b215 100644
> --- a/drivers/gpu/drm/qxl/qxl_release.c
> +++ b/drivers/gpu/drm/qxl/qxl_release.c
> @@ -426,16 +426,13 @@ void qxl_release_fence_buffer_objects(struct
> qxl_release *release)
> release->id | 0xf000, release->base.seqno);
> trace_dma_fence_emit(>base);
>
> - spin_lock(_glob.lru_lock);
> -
> list_for_each_entry(entry, >bos, head) {
> bo = entry->bo;
>
> dma_resv_add_shared_fence(bo->base.resv, >base);
> - ttm_bo_move_to_lru_tail(bo, >mem, NULL);
> + ttm_bo_move_to_lru_tail_unlocked(bo);
> dma_resv_unlock(bo->base.resv);
> }
> - spin_unlock(_glob.lru_lock);
> ww_acquire_fini(>ticket);
> }
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 3673157527ff..2d2ac532987e 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -243,9 +243,9 @@ static int ttm_bo_individualize_resv(struct
> ttm_buffer_object *bo)
>* reference it any more. The only tricky case is the trylock on
>* the resv object while holding the lru_lock.
>*/
> - spin_lock(_glob.lru_lock);
> + spin_lock(>bdev->lru_lock);
> bo->base.resv = >base._resv;
> - spin_unlock(_glob.lru_lock);
> + spin_unlock(>bdev->lru_lock);
> }
>
> return r;
> @@ -304,7 +304,7 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object
> *bo,
>
> if (unlock_resv)
> dma_resv_unlock(bo->base.resv);
> - spin_unlock(_glob.lru_lock);
> + spin_unlock(>bdev->lru_lock);
>
> lret = dma_resv_wait_timeout_rcu(resv, true, interruptible,
>30 * HZ);
> @@ -314,7 +314,7 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object
> *bo,
> else if (lret == 0)
> return -EBUSY;
>
> - spin_lock(_glob.lru_lock);
> + spin_lock(>bdev->lru_lock);
> if (unlock_resv && !dma_resv_trylock(bo->base.resv)) {
> /*
>* We raced, and lost, someone else holds the
> reservation now,
> @@ -324,7 +324,7 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object
> *bo,
>* delayed destruction would succeed, so just return
> success
>* here.
>*/
> - spin_unlock(_glob.lru_lock);
> + spin_unlock(>bdev->lru_lock);
> return 0;
> }
> ret = 0;
> @@ -333,13 +333,13 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object
> *bo,
> if (ret || unlikely(list_empty(>ddestroy))) {
>
Re: [PATCH 2/3] drm/ttm: remove swap LRU v3
On Thu, Mar 18, 2021 at 08:47:18PM +0800, Christian König wrote:
> Instead evict round robin from each devices SYSTEM and TT domain.
>
> v2: reorder num_pages access reported by Dan's script
> v3: fix rebase fallout, num_pages should be 32bit
>
> Signed-off-by: Christian König
Reviewed-by: Huang Rui
> ---
> drivers/gpu/drm/ttm/ttm_bo.c| 29 --
> drivers/gpu/drm/ttm/ttm_bo_util.c | 1 -
> drivers/gpu/drm/ttm/ttm_device.c| 60 +
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
> include/drm/ttm/ttm_bo_api.h| 1 -
> include/drm/ttm/ttm_bo_driver.h | 1 -
> include/drm/ttm/ttm_device.h| 7 +---
> 7 files changed, 48 insertions(+), 53 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 66e00b404ec3..3673157527ff 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -73,7 +73,6 @@ static void ttm_bo_del_from_lru(struct ttm_buffer_object
> *bo)
> {
> struct ttm_device *bdev = bo->bdev;
>
> - list_del_init(>swap);
> list_del_init(>lru);
>
> if (bdev->funcs->del_from_lru_notify)
> @@ -105,16 +104,6 @@ void ttm_bo_move_to_lru_tail(struct ttm_buffer_object
> *bo,
>
> man = ttm_manager_type(bdev, mem->mem_type);
> list_move_tail(>lru, >lru[bo->priority]);
> - if (man->use_tt && bo->ttm &&
> - !(bo->ttm->page_flags & (TTM_PAGE_FLAG_SG |
> - TTM_PAGE_FLAG_SWAPPED))) {
> - struct list_head *swap;
> -
> - swap = _glob.swap_lru[bo->priority];
> - list_move_tail(>swap, swap);
> - } else {
> - list_del_init(>swap);
> - }
>
> if (bdev->funcs->del_from_lru_notify)
> bdev->funcs->del_from_lru_notify(bo);
> @@ -129,9 +118,6 @@ void ttm_bo_move_to_lru_tail(struct ttm_buffer_object *bo,
> ttm_bo_bulk_move_set_pos(>vram[bo->priority], bo);
> break;
> }
> - if (bo->ttm && !(bo->ttm->page_flags &
> - (TTM_PAGE_FLAG_SG | TTM_PAGE_FLAG_SWAPPED)))
> - ttm_bo_bulk_move_set_pos(>swap[bo->priority], bo);
> }
> }
> EXPORT_SYMBOL(ttm_bo_move_to_lru_tail);
> @@ -169,20 +155,6 @@ void ttm_bo_bulk_move_lru_tail(struct ttm_lru_bulk_move
> *bulk)
> list_bulk_move_tail(>lru[i], >first->lru,
> >last->lru);
> }
> -
> - for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
> - struct ttm_lru_bulk_move_pos *pos = >swap[i];
> - struct list_head *lru;
> -
> - if (!pos->first)
> - continue;
> -
> - dma_resv_assert_held(pos->first->base.resv);
> - dma_resv_assert_held(pos->last->base.resv);
> -
> - lru = _glob.swap_lru[i];
> - list_bulk_move_tail(lru, >first->swap, >last->swap);
> - }
> }
> EXPORT_SYMBOL(ttm_bo_bulk_move_lru_tail);
>
> @@ -1065,7 +1037,6 @@ int ttm_bo_init_reserved(struct ttm_device *bdev,
> kref_init(>kref);
> INIT_LIST_HEAD(>lru);
> INIT_LIST_HEAD(>ddestroy);
> - INIT_LIST_HEAD(>swap);
> bo->bdev = bdev;
> bo->type = type;
> bo->mem.mem_type = TTM_PL_SYSTEM;
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
> b/drivers/gpu/drm/ttm/ttm_bo_util.c
> index 031e5819fec4..a2a17c84ceb3 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
> @@ -303,7 +303,6 @@ static int ttm_buffer_object_transfer(struct
> ttm_buffer_object *bo,
> atomic_inc(_glob.bo_count);
> INIT_LIST_HEAD(>base.ddestroy);
> INIT_LIST_HEAD(>base.lru);
> - INIT_LIST_HEAD(>base.swap);
> fbo->base.moving = NULL;
> drm_vma_node_reset(>base.base.vma_node);
>
> diff --git a/drivers/gpu/drm/ttm/ttm_device.c
> b/drivers/gpu/drm/ttm/ttm_device.c
> index b1424189fdfb..2096a0fd9c35 100644
> --- a/drivers/gpu/drm/ttm/ttm_device.c
> +++ b/drivers/gpu/drm/ttm/ttm_device.c
> @@ -67,7 +67,6 @@ static int ttm_global_init(void)
> unsigned long num_pages;
> struct sysinfo si;
> int ret = 0;
> - unsigned i;
>
> mutex_lock(_global_mutex);
> if (++ttm_glob_use_count > 1)
> @@ -90,8 +89,6 @@ static int ttm_global_init(void)
> goto out;
> }
>
> - for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i)
> - INIT_LIST_HEAD(>swap_lru[i]);
> INIT_LIST_HEAD(>device_list);
> atomic_set(>bo_count, 0);
>
> @@ -109,27 +106,60 @@ static int ttm_global_init(void)
> int ttm_global_swapout(struct ttm_operation_ctx *ctx, gfp_t gfp_flags)
> {
> struct ttm_global *glob = _glob;
> + struct ttm_device *bdev;
> + int ret = -EBUSY;
> +
> + mutex_lock(_global_mutex);
> + list_for_each_entry(bdev, >device_list, device_list) {
> + ret = ttm_device_swapout(bdev, ctx, gfp_flags);
> + if
Re: [PATCH 1/3] drm/ttm: move swapout logic around v2
On Thu, Mar 18, 2021 at 08:47:17PM +0800, Christian K�nig wrote:
> Move the iteration of the global lru into the new function
> ttm_global_swapout() and use that instead in drivers.
>
> v2: consistently return int
>
> Signed-off-by: Christian K?nig
Reviewed-by: Huang Rui
> ---
> drivers/gpu/drm/ttm/ttm_bo.c| 57 -
> drivers/gpu/drm/ttm/ttm_device.c| 29 +++
> drivers/gpu/drm/ttm/ttm_tt.c| 2 +-
> drivers/gpu/drm/vmwgfx/ttm_memory.c | 3 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
> include/drm/ttm/ttm_bo_api.h| 3 +-
> include/drm/ttm/ttm_device.h| 2 +
> 7 files changed, 53 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 3c23e863a3f0..66e00b404ec3 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -1193,56 +1193,35 @@ int ttm_bo_wait(struct ttm_buffer_object *bo,
> }
> EXPORT_SYMBOL(ttm_bo_wait);
>
> -/*
> - * A buffer object shrink method that tries to swap out the first
> - * buffer object on the bo_global::swap_lru list.
> - */
> -int ttm_bo_swapout(struct ttm_operation_ctx *ctx, gfp_t gfp_flags)
> +int ttm_bo_swapout(struct ttm_buffer_object *bo, struct ttm_operation_ctx
> *ctx,
> +gfp_t gfp_flags)
> {
> struct ttm_global *glob = _glob;
> - struct ttm_buffer_object *bo;
> - int ret = -EBUSY;
> bool locked;
> - unsigned i;
> -
> - spin_lock(>lru_lock);
> - for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
> - list_for_each_entry(bo, >swap_lru[i], swap) {
> - if (!ttm_bo_evict_swapout_allowable(bo, ctx, ,
> - NULL))
> - continue;
> -
> - if (!ttm_bo_get_unless_zero(bo)) {
> - if (locked)
> - dma_resv_unlock(bo->base.resv);
> - continue;
> - }
> + int ret;
>
> - ret = 0;
> - break;
> - }
> - if (!ret)
> - break;
> - }
> + if (!ttm_bo_evict_swapout_allowable(bo, ctx, , NULL))
> + return -EBUSY;
>
> - if (ret) {
> - spin_unlock(>lru_lock);
> - return ret;
> + if (!ttm_bo_get_unless_zero(bo)) {
> + if (locked)
> + dma_resv_unlock(bo->base.resv);
> + return -EBUSY;
> }
>
> if (bo->deleted) {
> - ret = ttm_bo_cleanup_refs(bo, false, false, locked);
> + ttm_bo_cleanup_refs(bo, false, false, locked);
> ttm_bo_put(bo);
> - return ret;
> + return 0;
> }
>
> ttm_bo_del_from_lru(bo);
> + /* TODO: Cleanup the locking */
> spin_unlock(>lru_lock);
>
> - /**
> + /*
>* Move to system cached
>*/
> -
> if (bo->mem.mem_type != TTM_PL_SYSTEM) {
> struct ttm_operation_ctx ctx = { false, false };
> struct ttm_resource evict_mem;
> @@ -1262,29 +1241,26 @@ int ttm_bo_swapout(struct ttm_operation_ctx *ctx,
> gfp_t gfp_flags)
> }
> }
>
> - /**
> + /*
>* Make sure BO is idle.
>*/
> -
> ret = ttm_bo_wait(bo, false, false);
> if (unlikely(ret != 0))
> goto out;
>
> ttm_bo_unmap_virtual(bo);
>
> - /**
> + /*
>* Swap out. Buffer will be swapped in again as soon as
>* anyone tries to access a ttm page.
>*/
> -
> if (bo->bdev->funcs->swap_notify)
> bo->bdev->funcs->swap_notify(bo);
>
> ret = ttm_tt_swapout(bo->bdev, bo->ttm, gfp_flags);
> out:
>
> - /**
> - *
> + /*
>* Unreserve without putting on LRU to avoid swapping out an
>* already swapped buffer.
>*/
> @@ -1293,7 +1269,6 @@ int ttm_bo_swapout(struct ttm_operation_ctx *ctx, gfp_t
> gfp_flags)
> ttm_bo_put(bo);
> return ret;
> }
> -EXPORT_SYMBOL(ttm_bo_swapout);
>
> void ttm_bo_tt_destroy(struct ttm_buffer_object *bo)
> {
> diff --git a/drivers/gpu/drm/ttm/ttm_device.c
> b/drivers/gpu/drm/ttm/ttm_device.c
> index 95e1b7b1f2e6..b1424189fdfb 100644
> --- a/drivers/gpu/drm/ttm/ttm_device.c
> +++ b/drivers/gpu/drm/ttm/ttm_device.c
> @@ -102,6 +102,35 @@ static int ttm_global_init(void)
> return ret;
> }
>
> +/**
> + * A buffer object shrink method that tries to swap out the first
> + * buffer object on the global::swap_lru list.
> + */
> +int ttm_global_swapout(struct ttm_operation_ctx *ctx, gfp_t gfp_flags)
> +{
> + struct ttm_global *glob = _glob;
> + struct ttm_buffer_object *bo;
> + unsigned i;
> + int ret;
> +
> + spin_lock(>lru_lock);
> + for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
> + list_for_each_entry(bo,
Re: [PATCH] scsi: csiostor: Assign boolean values to a bool variable
On Tue, 9 Mar 2021 17:37:48 +0800, Jiapeng Chong wrote: > Fix the following coccicheck warnings: > > ./drivers/scsi/csiostor/csio_scsi.c:150:9-10: WARNING: return of 0/1 in > function 'csio_scsi_itnexus_loss_error' with return type bool. Applied to 5.13/scsi-queue, thanks! [1/1] scsi: csiostor: Assign boolean values to a bool variable https://git.kernel.org/mkp/scsi/c/2ed0fc2b9a79 -- Martin K. Petersen Oracle Linux Engineering ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/30] [Set 1] Rid W=1 warnings in SCSI
On Wed, 3 Mar 2021 14:46:01 +, Lee Jones wrote: > This set is part of a larger effort attempting to clean-up W=1 > kernel builds, which are currently overwhelmingly riddled with > niggly little warnings. > > Lee Jones (30): > scsi: megaraid: megaraid_mm: Fix incorrect function name in header > scsi: megaraid: megaraid_sas_base: Fix a bunch of misnamed functions > in their headers > scsi: fcoe: Fix function name fcoe_set_vport_symbolic_name() in > description > scsi: megaraid: megaraid_mbox: Fix function name > megaraid_queue_command_lck() in description > scsi: fcoe: fcoe_ctlr: Fix a couple of incorrectly named functions > scsi: aic94xx: aic94xx_hwi: Fix a couple of misnamed function names > scsi: aacraid: aachba: Fix a few incorrectly named functions > scsi: pm8001: pm8001_init: Provide function name and fix a misspelling > scsi: aacraid: commctrl: Fix incorrect spelling of aac_send_raw_srb() > scsi: bnx2fc: bnx2fc_hwi: Fix typo in bnx2fc_indicate_kcqe() > scsi: pm8001: pm8001_sas: Provide function name > 'pm8001_I_T_nexus_reset()' in header > scsi: qla4xxx: ql4_os: Fix formatting issues - missing '-' and '_' > scsi: pm8001: pm8001_ctl: Fix incorrectly named functions in headers > scsi: aic94xx: aic94xx_sds: Fix asd_erase_nv_sector()'s header > scsi: qla2xxx: qla_iocb: Replace __qla2x00_marker()'s missing > underscores > scsi: aacraid: commsup: Repair formatting issue in > aac_handle_sa_aif()'s header > scsi: lpfc: lpfc_sli: Fix a bunch of kernel-doc issues > scsi: pm8001: pm8001_hwi: Fix some misnamed function descriptions > scsi: qla4xxx: ql4_mbx: Fix kernel-doc formatting and misnaming issue > scsi: bnx2fc: bnx2fc_tgt: Fix misnaming of bnx2fc_free_session_resc() > scsi: aic94xx: aic94xx_dump: Remove code that has been unused for at > least 13 years > scsi: pm8001: pm80xx_hwi: Fix a bunch of doc-rotted function headers > scsi: qla2xxx: qla_gs: Fix some incorrect formatting/spelling issues > scsi: aacraid: rx: Fix misspelling of _aac_rx_init() > scsi: lpfc: lpfc_ct: Fix formatting and misspelling issues > scsi: libfc: fc_lport: Fix some possible copy/paste issues > scsi: lpfc: lpfc_hbadisc: Fix incorrect naming of > __lpfc_update_fcf_record() > scsi: mpt3sas: mpt3sas_base: Fix misspelling of > _base_put_smid_default_atomic() > scsi: lpfc: lpfc_nportdisc: Fix misspelling of lpfc_defer_acc_rsp() > scsi: mpt3sas: mpt3sas_scs: Move a little data from the stack onto the > heap > > [...] Applied to 5.13/scsi-queue, thanks! [01/30] scsi: megaraid: megaraid_mm: Fix incorrect function name in header https://git.kernel.org/mkp/scsi/c/bbb2c0374552 [02/30] scsi: megaraid: megaraid_sas_base: Fix a bunch of misnamed functions in their headers https://git.kernel.org/mkp/scsi/c/616f6d8d9e16 [03/30] scsi: fcoe: Fix function name fcoe_set_vport_symbolic_name() in description https://git.kernel.org/mkp/scsi/c/276f9aa2530a [04/30] scsi: megaraid: megaraid_mbox: Fix function name megaraid_queue_command_lck() in description https://git.kernel.org/mkp/scsi/c/d4f5ae21597b [05/30] scsi: fcoe: fcoe_ctlr: Fix a couple of incorrectly named functions https://git.kernel.org/mkp/scsi/c/dc173575097f [06/30] scsi: aic94xx: aic94xx_hwi: Fix a couple of misnamed function names https://git.kernel.org/mkp/scsi/c/577c65b07a55 [07/30] scsi: aacraid: aachba: Fix a few incorrectly named functions https://git.kernel.org/mkp/scsi/c/a80218c7c565 [08/30] scsi: pm8001: pm8001_init: Provide function name and fix a misspelling https://git.kernel.org/mkp/scsi/c/bd1050e13889 [09/30] scsi: aacraid: commctrl: Fix incorrect spelling of aac_send_raw_srb() https://git.kernel.org/mkp/scsi/c/4c4b8cf5a109 [10/30] scsi: bnx2fc: bnx2fc_hwi: Fix typo in bnx2fc_indicate_kcqe() https://git.kernel.org/mkp/scsi/c/52ffc08d9454 [11/30] scsi: pm8001: pm8001_sas: Provide function name 'pm8001_I_T_nexus_reset()' in header https://git.kernel.org/mkp/scsi/c/62690c056ac0 [12/30] scsi: qla4xxx: ql4_os: Fix formatting issues - missing '-' and '_' https://git.kernel.org/mkp/scsi/c/ecef0c9e6407 [13/30] scsi: pm8001: pm8001_ctl: Fix incorrectly named functions in headers https://git.kernel.org/mkp/scsi/c/3978e59b6d6c [14/30] scsi: aic94xx: aic94xx_sds: Fix asd_erase_nv_sector()'s header https://git.kernel.org/mkp/scsi/c/3528b9abbd06 [15/30] scsi: qla2xxx: qla_iocb: Replace __qla2x00_marker()'s missing underscores https://git.kernel.org/mkp/scsi/c/52bb80f18def [16/30] scsi: aacraid: commsup: Repair formatting issue in aac_handle_sa_aif()'s header https://git.kernel.org/mkp/scsi/c/53616df28199 [17/30] scsi: lpfc: lpfc_sli: Fix a bunch of kernel-doc issues https://git.kernel.org/mkp/scsi/c/8514e2f1e2c6 [18/30] scsi: pm8001: pm8001_hwi: Fix some misnamed function descriptions https://git.kernel.org/mkp/scsi/c/6b87e435e4bc [19/30]
Re: [PATCH] drm/amdgpu: Fix a typo
Applied both patches. Thanks!
Alex
On Thu, Mar 18, 2021 at 7:20 PM Bhaskar Chowdhury wrote:
>
>
> s/proces/process/
>
> Signed-off-by: Bhaskar Chowdhury
> ---
> drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
> b/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
> index bf3857867f51..c1d5a3085bae 100644
> --- a/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
> @@ -598,7 +598,7 @@ static int psp_v11_0_memory_training_send_msg(struct
> psp_context *psp, int msg)
> }
>
> /*
> - * save and restore proces
> + * save and restore process
> */
> static int psp_v11_0_memory_training(struct psp_context *psp, uint32_t ops)
> {
> --
> 2.26.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dma-buf: use wake_up_process() instead of wake_up_state()
Using wake_up_process() is more simpler and friendly, and it is more convenient for analysis and statistics Signed-off-by: Wang Qing --- drivers/dma-buf/dma-fence.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c index 7475e09..de51326 --- a/drivers/dma-buf/dma-fence.c +++ b/drivers/dma-buf/dma-fence.c @@ -655,7 +655,7 @@ dma_fence_default_wait_cb(struct dma_fence *fence, struct dma_fence_cb *cb) struct default_wait_cb *wait = container_of(cb, struct default_wait_cb, base); - wake_up_state(wait->task, TASK_NORMAL); + wake_up_process(wait->task); } /** -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon/ttm: Fix memory leak userptr pages
Applied. Thanks! Alex On Thu, Mar 18, 2021 at 5:00 AM Koenig, Christian wrote: > > Reviewed-by: Christian König > > Von: Daniel Gomez > Gesendet: Donnerstag, 18. März 2021 09:32 > Cc: dag...@gmail.com ; Daniel Gomez ; > Deucher, Alexander ; Koenig, Christian > ; David Airlie ; Daniel Vetter > ; amd-...@lists.freedesktop.org > ; dri-devel@lists.freedesktop.org > ; linux-ker...@vger.kernel.org > > Betreff: [PATCH] drm/radeon/ttm: Fix memory leak userptr pages > > If userptr pages have been pinned but not bounded, > they remain uncleared. > > Signed-off-by: Daniel Gomez > --- > drivers/gpu/drm/radeon/radeon_ttm.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c > b/drivers/gpu/drm/radeon/radeon_ttm.c > index e8c66d10478f..bbcc6264d48f 100644 > --- a/drivers/gpu/drm/radeon/radeon_ttm.c > +++ b/drivers/gpu/drm/radeon/radeon_ttm.c > @@ -485,13 +485,14 @@ static void radeon_ttm_backend_unbind(struct > ttm_bo_device *bdev, struct ttm_tt > struct radeon_ttm_tt *gtt = (void *)ttm; > struct radeon_device *rdev = radeon_get_rdev(bdev); > > + if (gtt->userptr) > + radeon_ttm_tt_unpin_userptr(bdev, ttm); > + > if (!gtt->bound) > return; > > radeon_gart_unbind(rdev, gtt->offset, ttm->num_pages); > > - if (gtt->userptr) > - radeon_ttm_tt_unpin_userptr(bdev, ttm); > gtt->bound = false; > } > > -- > 2.30.2 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu/ttm: Fix memory leak userptr pages
Applied. Thanks! Alex On Wed, Mar 17, 2021 at 12:09 PM Daniel Gomez wrote: > > If userptr pages have been pinned but not bounded, > they remain uncleared. > > Signed-off-by: Daniel Gomez > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > index 9fd2157b133a..50c2b4827c13 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > @@ -1162,13 +1162,13 @@ static void amdgpu_ttm_backend_unbind(struct > ttm_bo_device *bdev, > struct amdgpu_ttm_tt *gtt = (void *)ttm; > int r; > > - if (!gtt->bound) > - return; > - > /* if the pages have userptr pinning then clear that first */ > if (gtt->userptr) > amdgpu_ttm_tt_unpin_userptr(bdev, ttm); > > + if (!gtt->bound) > + return; > + > if (gtt->offset == AMDGPU_BO_INVALID_OFFSET) > return; > > -- > 2.30.2 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/2] drm/bridge: anx7625: disable regulators when power off
On Thu, Mar 18, 2021 at 12:26:25PM +0800, Hsin-Yi Wang wrote:
> On Wed, Feb 24, 2021 at 2:14 PM Hsin-Yi Wang wrote:
> >
> > When suspending the driver, anx7625_power_standby() will be called to
> > turn off reset-gpios and enable-gpios. However, power supplies are not
> > disabled. To save power, the driver can get the power supply regulators
> > and turn off them in anx7625_power_standby().
> >
> > Signed-off-by: Hsin-Yi Wang
> > Reviewed-by: Robert Foss
> > ---
Hi Hsin-Yi, it's OK for me, please add my r-b.
Reviewed-by: Xin Ji
Thanks,
Xin
>
> Ping on the thread, thanks.
>
> > drivers/gpu/drm/bridge/analogix/anx7625.c | 34 +++
> > drivers/gpu/drm/bridge/analogix/anx7625.h | 1 +
> > 2 files changed, 35 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
> > b/drivers/gpu/drm/bridge/analogix/anx7625.c
> > index 65cc05982f826..23283ba0c4f93 100644
> > --- a/drivers/gpu/drm/bridge/analogix/anx7625.c
> > +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
> > @@ -11,6 +11,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -875,12 +876,25 @@ static int sp_tx_edid_read(struct anx7625_data *ctx,
> > static void anx7625_power_on(struct anx7625_data *ctx)
> > {
> > struct device *dev = >client->dev;
> > + int ret, i;
> >
> > if (!ctx->pdata.low_power_mode) {
> > DRM_DEV_DEBUG_DRIVER(dev, "not low power mode!\n");
> > return;
> > }
> >
> > + for (i = 0; i < ARRAY_SIZE(ctx->pdata.supplies); i++) {
> > + ret = regulator_enable(ctx->pdata.supplies[i].consumer);
> > + if (ret < 0) {
> > + DRM_DEV_DEBUG_DRIVER(dev, "cannot enable supply %d:
> > %d\n",
> > +i, ret);
> > + goto reg_err;
> > + }
> > + usleep_range(2000, 2100);
> > + }
> > +
> > + usleep_range(4000, 4100);
> > +
> > /* Power on pin enable */
> > gpiod_set_value(ctx->pdata.gpio_p_on, 1);
> > usleep_range(1, 11000);
> > @@ -889,11 +903,16 @@ static void anx7625_power_on(struct anx7625_data *ctx)
> > usleep_range(1, 11000);
> >
> > DRM_DEV_DEBUG_DRIVER(dev, "power on !\n");
> > + return;
> > +reg_err:
> > + for (--i; i >= 0; i--)
> > + regulator_disable(ctx->pdata.supplies[i].consumer);
> > }
> >
> > static void anx7625_power_standby(struct anx7625_data *ctx)
> > {
> > struct device *dev = >client->dev;
> > + int ret;
> >
> > if (!ctx->pdata.low_power_mode) {
> > DRM_DEV_DEBUG_DRIVER(dev, "not low power mode!\n");
> > @@ -904,6 +923,12 @@ static void anx7625_power_standby(struct anx7625_data
> > *ctx)
> > usleep_range(1000, 1100);
> > gpiod_set_value(ctx->pdata.gpio_p_on, 0);
> > usleep_range(1000, 1100);
> > +
> > + ret = regulator_bulk_disable(ARRAY_SIZE(ctx->pdata.supplies),
> > +ctx->pdata.supplies);
> > + if (ret < 0)
> > + DRM_DEV_DEBUG_DRIVER(dev, "cannot disable supplies %d\n",
> > ret);
> > +
> > DRM_DEV_DEBUG_DRIVER(dev, "power down\n");
> > }
> >
> > @@ -1742,6 +1767,15 @@ static int anx7625_i2c_probe(struct i2c_client
> > *client,
> > platform->client = client;
> > i2c_set_clientdata(client, platform);
> >
> > + pdata->supplies[0].supply = "vdd10";
> > + pdata->supplies[1].supply = "vdd18";
> > + pdata->supplies[2].supply = "vdd33";
> > + ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(pdata->supplies),
> > + pdata->supplies);
> > + if (ret) {
> > + DRM_DEV_ERROR(dev, "fail to get power supplies: %d\n", ret);
> > + return ret;
> > + }
> > anx7625_init_gpio(platform);
> >
> > atomic_set(>power_status, 0);
> > diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.h
> > b/drivers/gpu/drm/bridge/analogix/anx7625.h
> > index 193ad86c54503..e4a086b3a3d7b 100644
> > --- a/drivers/gpu/drm/bridge/analogix/anx7625.h
> > +++ b/drivers/gpu/drm/bridge/analogix/anx7625.h
> > @@ -350,6 +350,7 @@ struct s_edid_data {
> > struct anx7625_platform_data {
> > struct gpio_desc *gpio_p_on;
> > struct gpio_desc *gpio_reset;
> > + struct regulator_bulk_data supplies[3];
> > struct drm_bridge *panel_bridge;
> > int intp_irq;
> > u32 low_power_mode;
> > --
> > 2.30.1.766.gb4fecdf3b7-goog
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 5/5] drm/bridge: anx7625: add HDMI audio function
Add audio HDMI codec function support, enable it through device true flag
"analogix,audio-enable".
Signed-off-by: Xin Ji
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 227 ++
drivers/gpu/drm/bridge/analogix/anx7625.h | 5 +
2 files changed, 232 insertions(+)
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index 5e19170..f4653f2 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -30,6 +30,8 @@
#include
#include
+#include
+
#include
#include "anx7625.h"
@@ -150,6 +152,20 @@ static int anx7625_write_and(struct anx7625_data *ctx,
return anx7625_reg_write(ctx, client, offset, (val & (mask)));
}
+static int anx7625_write_and_or(struct anx7625_data *ctx,
+ struct i2c_client *client,
+ u8 offset, u8 and_mask, u8 or_mask)
+{
+ int val;
+
+ val = anx7625_reg_read(ctx, client, offset);
+ if (val < 0)
+ return val;
+
+ return anx7625_reg_write(ctx, client,
+offset, (val & and_mask) | (or_mask));
+}
+
static int anx7625_config_bit_matrix(struct anx7625_data *ctx)
{
int i, ret;
@@ -1496,6 +1512,9 @@ static int anx7625_parse_dt(struct device *dev,
else
DRM_DEV_DEBUG_DRIVER(dev, "found MIPI DSI host node.\n");
+ if (of_property_read_bool(np, "analogix,audio-enable"))
+ pdata->audio_en = 1;
+
ret = drm_of_find_panel_or_bridge(np, 1, 0, , NULL);
if (ret < 0) {
if (ret == -ENODEV)
@@ -1566,6 +1585,208 @@ static enum drm_connector_status
anx7625_sink_detect(struct anx7625_data *ctx)
connector_status_disconnected;
}
+int anx7625_audio_hw_params(struct device *dev, void *data,
+ struct hdmi_codec_daifmt *fmt,
+ struct hdmi_codec_params *params)
+{
+ struct anx7625_data *ctx = dev_get_drvdata(dev);
+ int wl, ch, rate;
+ int ret = 0;
+
+ if (fmt->fmt != HDMI_DSP_A) {
+ DRM_DEV_ERROR(dev, "only supports DSP_A\n");
+ return -EINVAL;
+ }
+
+ DRM_DEV_DEBUG_DRIVER(dev, "setting %d Hz, %d bit, %d channels\n",
+params->sample_rate, params->sample_width,
+params->cea.channels);
+
+ ret |= anx7625_write_and_or(ctx, ctx->i2c.tx_p2_client,
+ AUDIO_CHANNEL_STATUS_6,
+ ~I2S_SLAVE_MODE,
+ TDM_SLAVE_MODE);
+
+ /* Word length */
+ switch (params->sample_width) {
+ case 16:
+ wl = AUDIO_W_LEN_16_20MAX;
+ break;
+ case 18:
+ wl = AUDIO_W_LEN_18_20MAX;
+ break;
+ case 20:
+ wl = AUDIO_W_LEN_20_20MAX;
+ break;
+ case 24:
+ wl = AUDIO_W_LEN_24_24MAX;
+ break;
+ default:
+ DRM_DEV_DEBUG_DRIVER(dev, "wordlength: %d bit not support",
+params->sample_width);
+ return -EINVAL;
+ }
+ ret |= anx7625_write_and_or(ctx, ctx->i2c.tx_p2_client,
+ AUDIO_CHANNEL_STATUS_5,
+ 0xf0, wl);
+
+ /* Channel num */
+ switch (params->cea.channels) {
+ case 2:
+ ch = I2S_CH_2;
+ break;
+ case 4:
+ ch = TDM_CH_4;
+ break;
+ case 6:
+ ch = TDM_CH_6;
+ break;
+ case 8:
+ ch = TDM_CH_8;
+ break;
+ default:
+ DRM_DEV_DEBUG_DRIVER(dev, "channel number: %d not support",
+params->cea.channels);
+ return -EINVAL;
+ }
+ ret |= anx7625_write_and_or(ctx, ctx->i2c.tx_p2_client,
+ AUDIO_CHANNEL_STATUS_6, 0x1f, ch << 5);
+ if (ch > I2S_CH_2)
+ ret |= anx7625_write_or(ctx, ctx->i2c.tx_p2_client,
+ AUDIO_CHANNEL_STATUS_6, AUDIO_LAYOUT);
+ else
+ ret |= anx7625_write_and(ctx, ctx->i2c.tx_p2_client,
+ AUDIO_CHANNEL_STATUS_6, ~AUDIO_LAYOUT);
+
+ /* FS */
+ switch (params->sample_rate) {
+ case 32000:
+ rate = AUDIO_FS_32K;
+ break;
+ case 44100:
+ rate = AUDIO_FS_441K;
+ break;
+ case 48000:
+ rate = AUDIO_FS_48K;
+ break;
+ case 88200:
+ rate = AUDIO_FS_882K;
+ break;
+ case 96000:
+ rate = AUDIO_FS_96K;
+ break;
+ case 176400:
+ rate = AUDIO_FS_1764K;
+
[PATCH v5 4/5] drm/bridge: anx7625: add HDCP support
Add HDCP feature, enable HDCP function through chip internal key
and downstream's capability.
Signed-off-by: Xin Ji
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 147 ++
drivers/gpu/drm/bridge/analogix/anx7625.h | 36
2 files changed, 183 insertions(+)
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index 5c9b801..5e19170 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -633,6 +633,150 @@ static int anx7625_dpi_config(struct anx7625_data *ctx)
return ret;
}
+static int anx7625_aux_dpcd_read(struct anx7625_data *ctx,
+u8 addrh, u8 addrm, u8 addrl,
+u8 len, u8 *buf)
+{
+ struct device *dev = >client->dev;
+ int ret;
+ u8 cmd;
+
+ if (len > MAX_DPCD_BUFFER_SIZE) {
+ DRM_DEV_ERROR(dev, "exceed aux buffer len.\n");
+ return -E2BIG;
+ }
+
+ cmd = ((len - 1) << 4) | 0x09;
+
+ /* Set command and length */
+ ret = anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
+ AP_AUX_COMMAND, cmd);
+
+ /* Set aux access address */
+ ret |= anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
+AP_AUX_ADDR_7_0, addrl);
+ ret |= anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
+AP_AUX_ADDR_15_8, addrm);
+ ret |= anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
+AP_AUX_ADDR_19_16, addrh);
+
+ /* Enable aux access */
+ ret |= anx7625_write_or(ctx, ctx->i2c.rx_p0_client,
+ AP_AUX_CTRL_STATUS, AP_AUX_CTRL_OP_EN);
+
+ if (ret < 0) {
+ DRM_DEV_ERROR(dev, "cannot access aux related register.\n");
+ return -EIO;
+ }
+
+ usleep_range(2000, 2100);
+
+ ret = wait_aux_op_finish(ctx);
+ if (ret) {
+ DRM_DEV_ERROR(dev, "aux IO error: wait aux op finish.\n");
+ return ret;
+ }
+
+ ret = anx7625_reg_block_read(ctx, ctx->i2c.rx_p0_client,
+AP_AUX_BUFF_START, len, buf);
+ if (ret < 0) {
+ DRM_DEV_ERROR(dev, "read dpcd register failed\n");
+ return -EIO;
+ }
+
+ return 0;
+}
+
+static int anx7625_read_flash_status(struct anx7625_data *ctx)
+{
+ return anx7625_reg_read(ctx, ctx->i2c.rx_p0_client, R_RAM_CTRL);
+}
+
+static int anx7625_hdcp_key_probe(struct anx7625_data *ctx)
+{
+ int ret, val;
+ struct device *dev = >client->dev;
+ u8 ident[32];
+
+ ret = anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
+ FLASH_ADDR_HIGH, 0x91);
+ ret |= anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
+FLASH_ADDR_LOW, 0xA0);
+ if (ret < 0) {
+ DRM_DEV_ERROR(dev, "IO error : set key flash address.\n");
+ return ret;
+ }
+
+ ret = anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
+ FLASH_LEN_HIGH, (FLASH_BUF_LEN - 1) >> 8);
+ ret |= anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
+FLASH_LEN_LOW, (FLASH_BUF_LEN - 1) & 0xFF);
+ if (ret < 0) {
+ DRM_DEV_ERROR(dev, "IO error : set key flash len.\n");
+ return ret;
+ }
+
+ ret = anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
+ R_FLASH_RW_CTRL, FLASH_READ);
+ ret |= readx_poll_timeout(anx7625_read_flash_status,
+ ctx, val,
+ ((val & FLASH_DONE) || (val < 0)),
+ 2000,
+ 2000 * 150);
+ if (ret) {
+ DRM_DEV_ERROR(dev, "flash read access fail!\n");
+ return -EIO;
+ }
+
+ ret = anx7625_reg_block_read(ctx, ctx->i2c.rx_p0_client,
+FLASH_BUF_BASE_ADDR,
+FLASH_BUF_LEN, ident);
+ if (ret < 0) {
+ DRM_DEV_ERROR(dev, "read flash data fail!\n");
+ return -EIO;
+ }
+
+ if (ident[29] == 0xFF && ident[30] == 0xFF && ident[31] == 0xFF)
+ return -EINVAL;
+
+ return 0;
+}
+
+static int anx7625_hdcp_setting(struct anx7625_data *ctx)
+{
+ u8 bcap;
+ int ret;
+ struct device *dev = >client->dev;
+
+ ret = anx7625_hdcp_key_probe(ctx);
+ if (ret) {
+ DRM_DEV_DEBUG_DRIVER(dev, "disable HDCP by config\n");
+ return anx7625_write_and(ctx, ctx->i2c.rx_p1_client,
+0xee, 0x9f);
+ }
+
+ anx7625_aux_dpcd_read(ctx, 0x06, 0x80, 0x28, 1, );
+ if (!(bcap & 0x01)) {
+ DRM_DEV_DEBUG_DRIVER(dev,
[PATCH v5 3/5] drm/bridge: anx7625: add MIPI DPI input feature support
Add MIPI rx DPI input support.
Reported-by: kernel test robot
Signed-off-by: Xin Ji
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 243 ++
drivers/gpu/drm/bridge/analogix/anx7625.h | 18 ++-
2 files changed, 201 insertions(+), 60 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index 04536cc..5c9b801 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -150,18 +150,18 @@ static int anx7625_write_and(struct anx7625_data *ctx,
return anx7625_reg_write(ctx, client, offset, (val & (mask)));
}
-static int anx7625_write_and_or(struct anx7625_data *ctx,
- struct i2c_client *client,
- u8 offset, u8 and_mask, u8 or_mask)
+static int anx7625_config_bit_matrix(struct anx7625_data *ctx)
{
- int val;
+ int i, ret;
- val = anx7625_reg_read(ctx, client, offset);
- if (val < 0)
- return val;
+ ret = anx7625_write_or(ctx, ctx->i2c.tx_p2_client,
+ AUDIO_CONTROL_REGISTER, 0x80);
+ for (i = 0; i < 13; i++)
+ ret |= anx7625_reg_write(ctx, ctx->i2c.tx_p2_client,
+VIDEO_BIT_MATRIX_12 + i,
+0x18 + i);
- return anx7625_reg_write(ctx, client,
-offset, (val & and_mask) | (or_mask));
+ return ret;
}
static int anx7625_read_ctrl_status_p0(struct anx7625_data *ctx)
@@ -219,38 +219,6 @@ static int anx7625_video_mute_control(struct anx7625_data
*ctx,
return ret;
}
-static int anx7625_config_audio_input(struct anx7625_data *ctx)
-{
- struct device *dev = >client->dev;
- int ret;
-
- /* Channel num */
- ret = anx7625_reg_write(ctx, ctx->i2c.tx_p2_client,
- AUDIO_CHANNEL_STATUS_6, I2S_CH_2 << 5);
-
- /* FS */
- ret |= anx7625_write_and_or(ctx, ctx->i2c.tx_p2_client,
- AUDIO_CHANNEL_STATUS_4,
- 0xf0, AUDIO_FS_48K);
- /* Word length */
- ret |= anx7625_write_and_or(ctx, ctx->i2c.tx_p2_client,
- AUDIO_CHANNEL_STATUS_5,
- 0xf0, AUDIO_W_LEN_24_24MAX);
- /* I2S */
- ret |= anx7625_write_or(ctx, ctx->i2c.tx_p2_client,
- AUDIO_CHANNEL_STATUS_6, I2S_SLAVE_MODE);
- ret |= anx7625_write_and(ctx, ctx->i2c.tx_p2_client,
-AUDIO_CONTROL_REGISTER, ~TDM_TIMING_MODE);
- /* Audio change flag */
- ret |= anx7625_write_or(ctx, ctx->i2c.rx_p0_client,
- AP_AV_STATUS, AP_AUDIO_CHG);
-
- if (ret < 0)
- DRM_DEV_ERROR(dev, "fail to config audio.\n");
-
- return ret;
-}
-
/* Reduction of fraction a/b */
static void anx7625_reduction_of_a_fraction(unsigned long *a, unsigned long *b)
{
@@ -410,7 +378,7 @@ static int anx7625_dsi_video_timing_config(struct
anx7625_data *ctx)
ret |= anx7625_write_and(ctx, ctx->i2c.rx_p1_client,
MIPI_LANE_CTRL_0, 0xfc);
ret |= anx7625_write_or(ctx, ctx->i2c.rx_p1_client,
- MIPI_LANE_CTRL_0, 3);
+ MIPI_LANE_CTRL_0, ctx->pdata.mipi_lanes - 1);
/* Htotal */
htotal = ctx->dt.hactive.min + ctx->dt.hfront_porch.min +
@@ -595,6 +563,76 @@ static int anx7625_dsi_config(struct anx7625_data *ctx)
return ret;
}
+static int anx7625_api_dpi_config(struct anx7625_data *ctx)
+{
+ struct device *dev = >client->dev;
+ u16 freq = ctx->dt.pixelclock.min / 1000;
+ int ret;
+
+ /* configure pixel clock */
+ ret = anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
+ PIXEL_CLOCK_L, freq & 0xFF);
+ ret |= anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
+PIXEL_CLOCK_H, (freq >> 8));
+
+ /* set DPI mode */
+ /* set to DPI PLL module sel */
+ ret |= anx7625_reg_write(ctx, ctx->i2c.rx_p1_client,
+MIPI_DIGITAL_PLL_9, 0x20);
+ /* power down MIPI */
+ ret |= anx7625_reg_write(ctx, ctx->i2c.rx_p1_client,
+MIPI_LANE_CTRL_10, 0x08);
+ /* enable DPI mode */
+ ret |= anx7625_reg_write(ctx, ctx->i2c.rx_p1_client,
+MIPI_DIGITAL_PLL_18, 0x1C);
+ /* set first edge */
+ ret |= anx7625_reg_write(ctx, ctx->i2c.tx_p2_client,
+VIDEO_CONTROL_0, 0x06);
+ if (ret < 0)
+ DRM_DEV_ERROR(dev, "IO error : dpi phy set failed.\n");
+
+ return ret;
+}
+
+static int anx7625_dpi_config(struct anx7625_data *ctx)
+{
+ struct device *dev = >client->dev;
+
[PATCH v5 2/5] drm/bridge: anx7625: fix not correct return value
At some time, the original code may return non zero value, force return 0
if operation finished.
Signed-off-by: Xin Ji
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index 65cc059..04536cc 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -189,10 +189,10 @@ static int wait_aux_op_finish(struct anx7625_data *ctx)
AP_AUX_CTRL_STATUS);
if (val < 0 || (val & 0x0F)) {
DRM_DEV_ERROR(dev, "aux status %02x\n", val);
- val = -EIO;
+ return -EIO;
}
- return val;
+ return 0;
}
static int anx7625_video_mute_control(struct anx7625_data *ctx,
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 1/5] dt-bindings:drm/bridge:anx7625:add vendor define flags
Add 'bus-type' and 'data-lanes' define for port0. Define DP tx lane0,
lane1 swing register array define, and audio enable flag.
Signed-off-by: Xin Ji
---
.../bindings/display/bridge/analogix,anx7625.yaml | 58 +-
1 file changed, 57 insertions(+), 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
index c789784..3f54d58 100644
--- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
@@ -34,6 +34,26 @@ properties:
description: used for reset chip control, RESET_N pin B7.
maxItems: 1
+ analogix,lane0-swing:
+$ref: /schemas/types.yaml#/definitions/uint32-array
+minItems: 1
+maxItems: 20
+description:
+ an array of swing register setting for DP tx lane0 PHY, please don't
+ add this property, or contact vendor.
+
+ analogix,lane1-swing:
+$ref: /schemas/types.yaml#/definitions/uint32-array
+minItems: 1
+maxItems: 20
+description:
+ an array of swing register setting for DP tx lane1 PHY, please don't
+ add this property, or contact vendor.
+
+ analogix,audio-enable:
+type: boolean
+description: let the driver enable audio HDMI codec function or not.
+
ports:
$ref: /schemas/graph.yaml#/properties/ports
@@ -41,13 +61,43 @@ properties:
port@0:
$ref: /schemas/graph.yaml#/properties/port
description:
- Video port for MIPI DSI input.
+ MIPI DSI/DPI input.
+
+properties:
+ endpoint:
+$ref: /schemas/media/video-interfaces.yaml#
+type: object
+additionalProperties: false
+
+properties:
+ remote-endpoint: true
+ bus-type: true
+ data-lanes: true
+
+required:
+ - remote-endpoint
+
+required:
+ - endpoint
+
port@1:
$ref: /schemas/graph.yaml#/properties/port
description:
Video port for panel or connector.
+properties:
+ endpoint:
+$ref: /schemas/media/video-interfaces.yaml#
+type: object
+additionalProperties: false
+
+properties:
+ remote-endpoint: true
+
+required:
+ - remote-endpoint
+
required:
- port@0
- port@1
@@ -73,6 +123,10 @@ examples:
enable-gpios = < 45 GPIO_ACTIVE_HIGH>;
reset-gpios = < 73 GPIO_ACTIVE_HIGH>;
+analogix,audio-enable;
+analogix,lane0-swing = <0x14 0x54 0x64 0x74 0x29 0x7b 0x77 0x5b>;
+analogix,lane1-swing = <0x14 0x54 0x64 0x74 0x29 0x7b 0x77 0x5b>;
+
ports {
#address-cells = <1>;
#size-cells = <0>;
@@ -81,6 +135,8 @@ examples:
reg = <0>;
anx7625_in: endpoint {
remote-endpoint = <_dsi>;
+bus-type = <5>;
+data-lanes = <0 1 2 3>;
};
};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 0/5] Add MIPI rx DPI support
Hi all, this patch series implement MIPI rx DPI feature. Please help to review. This is the v5 version, any mistakes, please let me know, I'll fix it in the next series. Change history: v5: Fix Rob Herring, Hsin-Yi, Robert Foss comments - Rebase code on the branch 'drm-misc-next', refer video-interfaces.yaml - Seprate HDCP function to a new patch - Fix driver not correctly get 'bus-type' 'data-lanes' - Add audio HDMI codec function support v4: Fix Rob Herring comment - Rebase code on the branch 'drm-misc-next' - Change 'analogix,hdcp-support' type to boolean v3: Fix Rob Herring, Dan Carpenter, Nicolas comment - Split the patch, fix not correct return data - Fix several coding format - Split DP tx swing register setting to two property - Add HDCP support vender flag - remove 'analogix,swing-setting' and 'analogix,mipi-dpi-in' property v2: Fix Rob Herring comment - Fix yamllint warnings/errors in analogix,anx7625.yaml - Fix kernel robot compile warning v1: initial MIPI rx DPI feature support Xin Ji (5): dt-bindings:drm/bridge:anx7625:add vendor define flags drm/bridge: anx7625: fix not correct return value drm/bridge: anx7625: add MIPI DPI input feature support drm/bridge: anx7625: add HDCP support drm/bridge: anx7625: add HDMI audio function .../bindings/display/bridge/analogix,anx7625.yaml | 58 +- drivers/gpu/drm/bridge/analogix/anx7625.c | 601 +++-- drivers/gpu/drm/bridge/analogix/anx7625.h | 59 +- 3 files changed, 665 insertions(+), 53 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: xlnx: Update dependencies for ZynqMP DP
From: Dylan Yip ZynqMP DP requires the ZynqMP PHY and DPDMA to operate properly. So depend on both the PHY and DPDMA. Signed-off-by: Dylan Yip Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/xlnx/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/xlnx/Kconfig b/drivers/gpu/drm/xlnx/Kconfig index b52c6cdfc0b8..c3d08269faa9 100644 --- a/drivers/gpu/drm/xlnx/Kconfig +++ b/drivers/gpu/drm/xlnx/Kconfig @@ -3,6 +3,8 @@ config DRM_ZYNQMP_DPSUB depends on ARCH_ZYNQMP || COMPILE_TEST depends on COMMON_CLK && DRM && OF depends on DMADEVICES + depends on PHY_XILINX_ZYNQMP + depends on XILINX_ZYNQMP_DPDMA select DMA_ENGINE select DRM_GEM_CMA_HELPER select DRM_KMS_CMA_HELPER -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/tilcdc: fix LCD pixel clock setting
> Il 17/03/2021 09:19 Tomi Valkeinen ha scritto:
>
>
> On 14/03/2021 17:13, Dario Binacchi wrote:
> > As reported by TI spruh73x RM, the LCD pixel clock (LCD_PCLK) frequency
> > is obtained by dividing LCD_CLK, the LCD controller reference clock,
> > for CLKDIV:
> >
> > LCD_PCLK = LCD_CLK / CLKDIV
> >
> > where CLKDIV must be greater than 1.
> >
> > Therefore LCD_CLK must be set to 'req_rate * CLKDIV' instead of req_rate
>
> The above doesn't make sense, the code already sets LCD_CLK to 'req_rate
> * clkdiv', not req_rate.
>
> > and the real LCD_CLK rate must be compared with 'req_rate * CLKDIV' and
> > not with req_rate.
>
> This is true, the code looks at the wrong value.
>
> > Passing req_rate instead of 'req_rate * CLKDIV' to the tilcdc_pclk_diff
> > routine caused it to fail even if LCD_CLK was properly set.
> >
> > Signed-off-by: Dario Binacchi
> >
> > ---
> >
> > drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 9 +
> > 1 file changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> > b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> > index 30213708fc99..02f56c9a5da5 100644
> > --- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> > +++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> > @@ -203,7 +203,7 @@ static void tilcdc_crtc_set_clk(struct drm_crtc *crtc)
> > struct drm_device *dev = crtc->dev;
> > struct tilcdc_drm_private *priv = dev->dev_private;
> > struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
> > - unsigned long clk_rate, real_rate, req_rate;
> > + unsigned long clk_rate, real_rate, req_rate, clk_div_rate;
> > unsigned int clkdiv;
> > int ret;
> >
> > @@ -211,10 +211,11 @@ static void tilcdc_crtc_set_clk(struct drm_crtc *crtc)
> >
> > /* mode.clock is in KHz, set_rate wants parameter in Hz */
> > req_rate = crtc->mode.clock * 1000;
> > -
> > - ret = clk_set_rate(priv->clk, req_rate * clkdiv);
> > + /* LCD clock divisor input rate */
> > + clk_div_rate = req_rate * clkdiv;
>
> "clk_div_rate" sounds a bit odd to me. Why not lcd_fck_rate, as that's
> the name used later? Or lcd_clk_rate. Or maybe lcd_clk_req_rate...
I prefer lcd_clk_rate.
How about adding an additional patch that changes the variable names to make
the code more readable?
req_rate -> lcd_pclk_rate
clk_rate -> real_lcd_clk_rate
And add a comment to the function which highlights the relationship
LCD_CLK = LCD_PCLK * CLDIV ?
>
> > + ret = clk_set_rate(priv->clk, clk_div_rate);
> > clk_rate = clk_get_rate(priv->clk);
> > - if (ret < 0 || tilcdc_pclk_diff(req_rate, clk_rate) > 5) {
> > + if (ret < 0 || tilcdc_pclk_diff(clk_div_rate, clk_rate) > 5) {
> > /*
> > * If we fail to set the clock rate (some architectures don't
> > * use the common clock framework yet and may not implement
> >
>
> I think this fix is fine, but looking at the current code, it's calling
> tilcdc_pclk_diff(), but doesn't actually provide pixel clocks to the
> function, but fclk.
Yes, I agree.
Thanks and regards,
Dario
>
> Tomi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] dma-buf: add dma_fence_array_for_each (v2)
On March 18, 2021 08:13:41 Daniel Vetter wrote:
On Thu, Mar 18, 2021 at 10:38:11AM +0100, Christian König wrote:
Am 17.03.21 um 23:19 schrieb Jason Ekstrand:
From: Christian König
Add a helper to iterate over all fences in a dma_fence_array object.
v2 (Jason Ekstrand)
- Return NULL from dma_fence_array_first if head == NULL. This matches
the iterator behavior of dma_fence_chain_for_each in that it iterates
zero times if head == NULL.
- Return NULL from dma_fence_array_next if index > array->num_fences.
Is there any reason you send this patch alone out once more?
I don't see any changes compared to the last version.
Last patch has changed. Also I think mail delivery is a bit wobbly right
now.
Sorry. I'm still getting used to mailing lists again. Too spoiled by
GitLab. My intention was to re-send the series because I updated the last
one. I think it's in pretty good shape now.
--Jason
-Daniel
Christian.
Signed-off-by: Jason Ekstrand
---
drivers/dma-buf/dma-fence-array.c | 27 +++
include/linux/dma-fence-array.h | 17 +
2 files changed, 44 insertions(+)
diff --git a/drivers/dma-buf/dma-fence-array.c
b/drivers/dma-buf/dma-fence-array.c
index d3fbd950be944..2ac1afc697d0f 100644
--- a/drivers/dma-buf/dma-fence-array.c
+++ b/drivers/dma-buf/dma-fence-array.c
@@ -201,3 +201,30 @@ bool dma_fence_match_context(struct dma_fence *fence,
u64 context)
return true;
}
EXPORT_SYMBOL(dma_fence_match_context);
+
+struct dma_fence *dma_fence_array_first(struct dma_fence *head)
+{
+ struct dma_fence_array *array;
+
+ if (!head)
+ return NULL;
+
+ array = to_dma_fence_array(head);
+ if (!array)
+ return head;
+
+ return array->fences[0];
+}
+EXPORT_SYMBOL(dma_fence_array_first);
+
+struct dma_fence *dma_fence_array_next(struct dma_fence *head,
+ unsigned int index)
+{
+ struct dma_fence_array *array = to_dma_fence_array(head);
+
+ if (!array || index >= array->num_fences)
+ return NULL;
+
+ return array->fences[index];
+}
+EXPORT_SYMBOL(dma_fence_array_next);
diff --git a/include/linux/dma-fence-array.h b/include/linux/dma-fence-array.h
index 303dd712220fd..588ac8089dd61 100644
--- a/include/linux/dma-fence-array.h
+++ b/include/linux/dma-fence-array.h
@@ -74,6 +74,19 @@ to_dma_fence_array(struct dma_fence *fence)
return container_of(fence, struct dma_fence_array, base);
}
+/**
+ * dma_fence_array_for_each - iterate over all fences in array
+ * @fence: current fence
+ * @index: index into the array
+ * @head: potential dma_fence_array object
+ *
+ * Test if @array is a dma_fence_array object and if yes iterate over all
fences
+ * in the array. If not just iterate over the fence in @array itself.
+ */
+#define dma_fence_array_for_each(fence, index, head) \
+ for (index = 0, fence = dma_fence_array_first(head); fence; \
+ ++(index), fence = dma_fence_array_next(head, index))
+
struct dma_fence_array *dma_fence_array_create(int num_fences,
struct dma_fence **fences,
u64 context, unsigned seqno,
@@ -81,4 +94,8 @@ struct dma_fence_array *dma_fence_array_create(int
num_fences,
bool dma_fence_match_context(struct dma_fence *fence, u64 context);
+struct dma_fence *dma_fence_array_first(struct dma_fence *head);
+struct dma_fence *dma_fence_array_next(struct dma_fence *head,
+ unsigned int index);
+
#endif /* __LINUX_DMA_FENCE_ARRAY_H */
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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
Re: [git pull] drm fixes for 5.12-rc4
The pull request you sent on Fri, 19 Mar 2021 10:53:29 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-03-19 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/8b12a62a4e3ed4ae99c715034f557eb391d6b196 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm fixes for 5.12-rc4
Hi Linus, Regular fixes pull, pretty small set of fixes, a couple of i915 and amdgpu, one ttm, one nouveau and one omap. Probably smaller than usual for this time, so we'll see if something pops up next week or if this will continue to stay small. Dave. drm-fixes-2021-03-19: drm fixes for 5.12-rc4 ttm: - Make ttm_bo_unpin() not wraparound on too many unpins. omap: - Fix coccicheck warning in omap. amdgpu: - DCN 3.0 gamma fixes - DCN 2.1 corrupt screen fix i915: - Workaround async flip + VT-d frame corruption on HSW/BDW - Fix NMI watchdog crash due to uninitialized OA buffer use on gen12+ nouveau: - workaround oops with bo syncing The following changes since commit 1e28eed17697bcf343c6743f0028cc3b5dd88bf0: Linux 5.12-rc3 (2021-03-14 14:41:02 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-03-19 for you to fetch changes up to e94c55b8e0a0bbe9a026250cf31e2fa45957d776: nouveau: Skip unvailable ttm page entries (2021-03-19 10:38:31 +1000) drm fixes for 5.12-rc4 ttm: - Make ttm_bo_unpin() not wraparound on too many unpins. omap: - Fix coccicheck warning in omap. amdgpu: - DCN 3.0 gamma fixes - DCN 2.1 corrupt screen fix i915: - Workaround async flip + VT-d frame corruption on HSW/BDW - Fix NMI watchdog crash due to uninitialized OA buffer use on gen12+ nouveau: - workaround oops with bo syncing Calvin Hou (1): drm/amd/display: Correct algorithm for reversed gamma Christian König (1): drm/ttm: make ttm_bo_unpin more defensive Dave Airlie (3): Merge tag 'drm-misc-fixes-2021-03-18' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Merge tag 'amd-drm-fixes-5.12-2021-03-18' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes Merge tag 'drm-intel-fixes-2021-03-18' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Dillon Varone (1): drm/amd/display: Remove MPC gamut remap logic for DCN30 Junlin Yang (1): drm/omap: dsi: fix unsigned expression compared with zero Sung Lee (1): drm/amd/display: Copy over soc values before bounding box creation Tobias Klausmann (1): nouveau: Skip unvailable ttm page entries Umesh Nerlige Ramappa (1): i915/perf: Start hrtimer only if sampling the OA buffer Ville Syrjälä (1): drm/i915: Workaround async flip + VT-d corruption on HSW/BDW drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c | 34 ++ .../gpu/drm/amd/display/dc/dcn21/dcn21_resource.c | 5 .../gpu/drm/amd/display/dc/dcn30/dcn30_cm_common.c | 26 - drivers/gpu/drm/i915/i915_perf.c | 13 - drivers/gpu/drm/i915/i915_reg.h| 23 ++- drivers/gpu/drm/i915/intel_pm.c| 16 +- drivers/gpu/drm/nouveau/nouveau_bo.c | 8 + drivers/gpu/drm/omapdrm/dss/dsi.c | 7 +++-- include/drm/ttm/ttm_bo_api.h | 6 ++-- 9 files changed, 83 insertions(+), 55 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/2] dt-bindings: drm/bridge: MHDP8546 bridge binding changes for HDCP
Hi Parshuram,
Thank you for the patch.
On Thu, Mar 18, 2021 at 07:45:30AM +0100, Parshuram Thombare wrote:
> Add binding changes for HDCP in the MHDP8546 DPI/DP bridge binding.
>
> Signed-off-by: Parshuram Thombare
> ---
> .../display/bridge/cdns,mhdp8546.yaml | 24 +++
> 1 file changed, 14 insertions(+), 10 deletions(-)
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml
> b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml
> index 63427878715e..8a85768f6202 100644
> --- a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml
> @@ -17,8 +17,8 @@ properties:
>- ti,j721e-mhdp8546
>
>reg:
> -minItems: 1
> -maxItems: 2
> +minItems: 2
> +maxItems: 3
> items:
>- description:
>Register block of mhdptx apb registers up to PHY mapped area
> (AUX_CONFIG_P).
> @@ -26,13 +26,16 @@ properties:
>included in the associated PHY.
>- description:
>Register block for DSS_EDP0_INTG_CFG_VP registers in case of TI J7
> SoCs.
> + - description:
> + Register block of mhdptx sapb registers.
>
>reg-names:
> -minItems: 1
> -maxItems: 2
> +minItems: 2
> +maxItems: 3
> items:
>- const: mhdptx
>- const: j721e-intg
> + - const: mhdptx-sapb
>
>clocks:
> maxItems: 1
> @@ -98,15 +101,15 @@ allOf:
> then:
>properties:
> reg:
> - minItems: 2
> + minItems: 3
> reg-names:
> - minItems: 2
> + minItems: 3
> else:
>properties:
> reg:
> - maxItems: 1
> + maxItems: 2
> reg-names:
> - maxItems: 1
> + maxItems: 2
>
> required:
>- compatible
> @@ -129,8 +132,9 @@ examples:
>
> mhdp: dp-bridge@f0fb00 {
> compatible = "cdns,mhdp8546";
> -reg = <0xf0 0xfb00 0x0 0x100>;
> -reg-names = "mhdptx";
> +reg = <0xf0 0xfb00 0x0 0x100>,
> + <0x0 0x4f48000 0x0 0x74>;
> +reg-names = "mhdptx", "mhdptx-sapb";
Running
make dt_binding_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml
produces
LINTDocumentation/devicetree/bindings
CHKDT Documentation/devicetree/bindings/processed-schema-examples.json
SCHEMA Documentation/devicetree/bindings/processed-schema-examples.json
DTEX
Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.example.dts
DTC
Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.example.dt.yaml
CHECK
Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.example.dt.yaml
Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.example.dt.yaml:
dp-bridge@f0fb00: reg-names:1: 'j721e-intg' was expected
From schema:
Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml
This is caused by the fact that reg-names is correctly limited to two
elements, but then expects the second element to be "j721e-intg". The
example is good, so it's the bindings that need to be fixed.
> clocks = <_clock>;
> phys = <_phy>;
> phy-names = "dpphy";
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amdgpu: Fix a typo
s/proces/process/
Signed-off-by: Bhaskar Chowdhury
---
drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
b/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
index bf3857867f51..c1d5a3085bae 100644
--- a/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
@@ -598,7 +598,7 @@ static int psp_v11_0_memory_training_send_msg(struct
psp_context *psp, int msg)
}
/*
- * save and restore proces
+ * save and restore process
*/
static int psp_v11_0_memory_training(struct psp_context *psp, uint32_t ops)
{
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/dp_mst: Enhance DP MST topology logging
(going to try to take a look at this tomorrow JFYI)
On Thu, 2021-03-18 at 11:55 -0400, Eryk Brol wrote:
> [why]
> MST topology print was missing fec logging and pdt printed
> as an int wasn't clear. vcpi and payload info were also logged as an
> arbitrary series of ints which require the user to know the ordering
> of the prints, making the logs difficult to use.
>
> [how]
> -add fec logging
> -add pdt parsing into strings
> -format vcpi and payload info into tables with headings
> -clean up topology prints
>
> Signed-off-by: Eryk Brol
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 67 ---
> 1 file changed, 51 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 932c4641ec3e..3afeaa59cbaa 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -4720,6 +4720,24 @@ static void drm_dp_mst_kick_tx(struct
> drm_dp_mst_topology_mgr *mgr)
> queue_work(system_long_wq, >tx_work);
> }
>
> +static char *pdt_to_string(u8 pdt)
> +{
> + switch (pdt) {
> + case DP_PEER_DEVICE_NONE:
> + return "NONE";
> + case DP_PEER_DEVICE_SOURCE_OR_SST:
> + return "SOURCE OR SST";
> + case DP_PEER_DEVICE_MST_BRANCHING:
> + return "MST BRANCHING";
> + case DP_PEER_DEVICE_SST_SINK:
> + return "SST SINK";
> + case DP_PEER_DEVICE_DP_LEGACY_CONV:
> + return "DP LEGACY CONV";
> + default:
> + return "ERR";
> + }
> +}
> +
> static void drm_dp_mst_dump_mstb(struct seq_file *m,
> struct drm_dp_mst_branch *mstb)
> {
> @@ -4732,9 +4750,20 @@ static void drm_dp_mst_dump_mstb(struct seq_file *m,
> prefix[i] = '\t';
> prefix[i] = '\0';
>
> - seq_printf(m, "%smst: %p, %d\n", prefix, mstb, mstb->num_ports);
> + seq_printf(m, "%smstb - [%p]: num_ports: %d\n", prefix, mstb, mstb-
> >num_ports);
> list_for_each_entry(port, >ports, next) {
> - seq_printf(m, "%sport: %d: input: %d: pdt: %d, ddps: %d ldps:
> %d, sdp: %d/%d, %p, conn: %p\n", prefix, port->port_num, port->input, port-
> >pdt, port->ddps, port->ldps, port->num_sdp_streams, port-
> >num_sdp_stream_sinks, port, port->connector);
> + seq_printf(m, "%sport %d - [%p] (%s - %s): ddps: %d, ldps: %d,
> sdp: %d/%d, fec: %s, conn: %p\n",
> + prefix,
> + port->port_num,
> + port,
> + port->input ? "input" : "output",
> + pdt_to_string(port->pdt),
> + port->ddps,
> + port->ldps,
> + port->num_sdp_streams,
> + port->num_sdp_stream_sinks,
> + port->fec_capable ? "true" : "false",
> + port->connector);
> if (port->mstb)
> drm_dp_mst_dump_mstb(m, port->mstb);
> }
> @@ -4787,33 +4816,39 @@ void drm_dp_mst_dump_topology(struct seq_file *m,
> mutex_unlock(>lock);
>
> mutex_lock(>payload_lock);
> - seq_printf(m, "vcpi: %lx %lx %d\n", mgr->payload_mask, mgr->vcpi_mask,
> - mgr->max_payloads);
> + seq_printf(m, "\n *** VCPI Info ***\npayload_mask: %lx, vcpi_mask:
> %lx, max_payloads: %d\n",
> + mgr->payload_mask,
> + mgr->vcpi_mask,
> + mgr->max_payloads);
>
> + seq_printf(m, "\n| idx | port # | vcp_id | # slots | sink
> name |\n");
> for (i = 0; i < mgr->max_payloads; i++) {
> if (mgr->proposed_vcpis[i]) {
> char name[14];
>
> port = container_of(mgr->proposed_vcpis[i], struct
> drm_dp_mst_port, vcpi);
> fetch_monitor_name(mgr, port, name, sizeof(name));
> - seq_printf(m, "vcpi %d: %d %d %d sink name: %s\n", i,
> - port->port_num, port->vcpi.vcpi,
> - port->vcpi.num_slots,
> - (*name != 0) ? name : "Unknown");
> + seq_printf(m, "%10d%10d%10d%10d%20s\n",
> + i,
> + port->port_num,
> + port->vcpi.vcpi,
> + port->vcpi.num_slots,
> + (*name != 0) ? name : "Unknown");
> } else
> - seq_printf(m, "vcpi %d:unused\n", i);
> + seq_printf(m, "%6d - Unused\n", i);
> }
> + seq_printf(m, "\n *** Payload Info ***\n");
> +
[PATCH v2] drm/nouveau/kms/nv50-: Correct size checks for cursors
Found this while trying to make some changes to the kms_cursor_crc test.
curs507a_acquire checks that the width and height of the cursor framebuffer
are equal (asyw->image.{w,h}). This isn't entirely correct though, as the
height of the cursor can be larger than the size of the cursor, as long as
the width is the same as the cursor size and there's no framebuffer offset.
Note that I'm not entirely sure why this wasn't previously breaking
kms_cursor_crc tests - they all set up cursors with the height being one
pixel larger than the actual size of the cursor. But this seems to fix
things, and the code before was definitely incorrect - so it's not really
worth looking into further imho.
Changes since v1:
* Don't use crtc_w everywhere for determining cursor layout, just use fb
size again
* Change check so that we only check that the w/h of the cursor plane is
the same, the width of the scanout surface is the same as the framebuffer
width, and that there's no offset being used for the cursor surface.
Signed-off-by: Lyude Paul
Cc: Martin Peres
Cc: Jeremy Cline
---
drivers/gpu/drm/nouveau/dispnv50/curs507a.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/curs507a.c
b/drivers/gpu/drm/nouveau/dispnv50/curs507a.c
index 54fbd6fe751d..00e19fd959ea 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/curs507a.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/curs507a.c
@@ -98,6 +98,7 @@ static int
curs507a_acquire(struct nv50_wndw *wndw, struct nv50_wndw_atom *asyw,
struct nv50_head_atom *asyh)
{
+ struct nouveau_drm *drm = nouveau_drm(wndw->plane.dev);
struct nv50_head *head = nv50_head(asyw->state.crtc);
int ret;
@@ -109,8 +110,20 @@ curs507a_acquire(struct nv50_wndw *wndw, struct
nv50_wndw_atom *asyw,
if (ret || !asyh->curs.visible)
return ret;
- if (asyw->image.w != asyw->image.h)
+ if (asyw->state.crtc_w != asyw->state.crtc_h) {
+ NV_ATOMIC(drm, "Plane width/height must be equal for
cursors\n");
return -EINVAL;
+ }
+
+ if (asyw->image.w != asyw->state.crtc_w) {
+ NV_ATOMIC(drm, "Plane width must be equal to fb width for
cursors (height can be larger though)\n");
+ return -EINVAL;
+ }
+
+ if (asyw->state.src_x || asyw->state.src_y) {
+ NV_ATOMIC(drm, "Cursor planes do not support framebuffer
offsets\n");
+ return -EINVAL;
+ }
ret = head->func->curs_layout(head, asyw, asyh);
if (ret)
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/atomic: Add the crtc to affected crtc only if uapi.enable = true
So basically we see this warning only in case of bigjoiner when drm_atomic_check gets called without setting the state->allow_modeset flag. So do you think that in i915, in intel_atomic_check_bigjoiner() we should only steal the crtc when allow_modeset flag is set in state? If we add this check there then the affected crtc wont count the slave crtc and we wont get this warning. Ville, Danvet? Manasi On Tue, Mar 16, 2021 at 10:35:09PM +0100, Daniel Vetter wrote: > On Tue, Mar 9, 2021 at 10:14 AM Pekka Paalanen wrote: > > > > On Mon, 8 Mar 2021 16:52:58 -0800 > > "Navare, Manasi" wrote: > > > > > On Thu, Mar 04, 2021 at 10:42:23AM +0200, Pekka Paalanen wrote: > > > > On Wed, 3 Mar 2021 12:44:33 -0800 > > > > "Navare, Manasi" wrote: > > > > > > > > > On Wed, Mar 03, 2021 at 10:47:44AM +0200, Pekka Paalanen wrote: > > > > > > On Tue, 2 Mar 2021 12:41:32 -0800 > > > > > > Manasi Navare wrote: > > > > > > > > > > > > > In case of a modeset where a mode gets split across mutiple CRTCs > > > > > > > in the driver specific implementation (bigjoiner in i915) we > > > > > > > wrongly count > > > > > > > the affected CRTCs based on the drm_crtc_mask and indicate the > > > > > > > stolen CRTC as > > > > > > > an affected CRTC in atomic_check_only(). > > > > > > > This triggers a warning since affected CRTCs doent match > > > > > > > requested CRTC. > > > > > > > > > > > > > > To fix this in such bigjoiner configurations, we should only > > > > > > > increment affected crtcs if that CRTC is enabled in UAPI not > > > > > > > if it is just used internally in the driver to split the mode. > > > > > > > > > > > > Hi, > > > > > > > > > > > > I think that makes sense to me. Stealing CRTCs that are not > > > > > > currently > > > > > > used by the userspace (display server) should be ok, as long as that > > > > > > is completely invisible to userspace: meaning that it does not cause > > > > > > userspace to unexpectedly e.g. receive or miss per-crtc atomic > > > > > > completion events. > > > > > > > > > > Yes since we are only doing atomic_check_only() here, the stolen > > > > > > > > But the real not-test-only commit will follow if this test-only commit > > > > succeeds, and keeping the guarantees for the real commit are important. > > > > > > Hmm well after the actual real commit, since the second crtc is stolen > > > even though it is not being used for the display output, it is > > > used for joiner so the uapi.enable will be true after the real commit. > > > > > > so actually the assertion would fail in this case. > > > > > > @Ville @Danvet any suggestions here in that case? > > That is very bad. We can't frob uapi state like that. I think that > calls for even more checks to make sure kms drivers who try to play > clever games don't get it wrong, so we probably need to check uapi > enable and active state in another mask before/after ->atomic_check > too. Or something like that. > > > Hi, > > > > that is not what I was talking about, but sounds like you found a > > different problem. It seems like the problem you are talking about > > would be guaranteed to be hit if bigjoiner was used. Have you not > > tested this? > > > > However, I was talking about the real commit itself, not what happens > > on commits after it, see below. > > > > > > > crtc is completely invisible to the userspace and hence that is > > > > > indicated by uapi.enable which is not true for this stolen > > > > > crtc. However if allow modeset flag set, then it will do a full > > > > > modeset and indicate the uapi.enable for this stolen crtc as well > > > > > since that cannot be used for other modeset requested by userspace. > > > > > > > > > > > > > > > > > Can that also be asserted somehow, or does this already do that? > > > > > > > > > > Not clear what you want the assertion for? Could you elaborate > > > > > > > > As assertion that when the real atomic commit happens and then > > > > completion events are fired, they match exactly the affected crtcs mask. > > > > This is my concern and a question, although like I say below, only > > tangential to this patch. > > > > However, as this patch aims to allow bigjoiner usage, naturally the > > question will arise whether the completion events then match what > > userspace expects or not. Userspace does not expect completion events > > referring to the stolen CRTCs. > > Yeah we also must make sure that we don't send out events for these > additional crtc in bigjoiner usage. Sounds like igt testing didn't > catch this, I think we need a lot more igts here to make sure all > these surprises don't happen. > > Plus maybe triple-checking that drm_atomic_uapi.c makes sure we can't > send out events for stuff that userspace didn't ask for. > -Daniel > > > > > > > I understand this may be off-topic for this particular patch, but since > > > > we are discussing the topic, such checks would be really nice. I'm > > > > curious if such checks already exist. > > > > > > Thanks, > > pq > > > > >
Re: [Nouveau] [PATCH] drm/nouveau/kms/nv50-: Check plane size for cursors, not fb size
On Thu, 2021-03-18 at 18:13 -0400, Ilia Mirkin wrote:
> On Thu, Mar 18, 2021 at 5:56 PM Lyude Paul wrote:
> >
> > Found this while trying to make some changes to the kms_cursor_crc test.
> > curs507a_acquire checks that the width and height of the cursor framebuffer
> > are equal (asyw->image.{w,h}). This is actually wrong though, as we only
> > want to be concerned that the actual width/height of the plane are the
> > same. It's fine if we scan out from an fb that's slightly larger than the
> > cursor plane (in fact, some igt tests actually do this).
>
> How so? The scanout engine expects the data to be packed. Height can
> be larger, but width has to match.
Huh - wasn't expecting that, nice catch. I'll fix this up in a moment
>
> -ilia
>
--
Sincerely,
Lyude Paul (she/her)
Software Engineer at Red Hat
Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've
asked me a question, are waiting for a review/merge on a patch, etc. and I
haven't responded in a while, please feel free to send me another email to check
on my status. I don't bite!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Nouveau] [PATCH] drm/nouveau/kms/nv50-: Check plane size for cursors, not fb size
On Thu, Mar 18, 2021 at 5:56 PM Lyude Paul wrote:
>
> Found this while trying to make some changes to the kms_cursor_crc test.
> curs507a_acquire checks that the width and height of the cursor framebuffer
> are equal (asyw->image.{w,h}). This is actually wrong though, as we only
> want to be concerned that the actual width/height of the plane are the
> same. It's fine if we scan out from an fb that's slightly larger than the
> cursor plane (in fact, some igt tests actually do this).
How so? The scanout engine expects the data to be packed. Height can
be larger, but width has to match.
-ilia
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nouveau/kms/nv50-: Check plane size for cursors, not fb size
Found this while trying to make some changes to the kms_cursor_crc test.
curs507a_acquire checks that the width and height of the cursor framebuffer
are equal (asyw->image.{w,h}). This is actually wrong though, as we only
want to be concerned that the actual width/height of the plane are the
same. It's fine if we scan out from an fb that's slightly larger than the
cursor plane (in fact, some igt tests actually do this).
Note that I'm not entirely sure why this wasn't previously breaking
kms_cursor_crc tests - they all set up cursors with the height being one
pixel larger than the actual size of the cursor. But this seems to fix
things, and the code before was definitely incorrect - so it's not really
worth looking into further imho.
Signed-off-by: Lyude Paul
Cc: Martin Peres
Cc: Jeremy Cline
---
drivers/gpu/drm/nouveau/dispnv50/curs507a.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/head507d.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/head917d.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/curs507a.c
b/drivers/gpu/drm/nouveau/dispnv50/curs507a.c
index 54fbd6fe751d..7a7f80e51ec0 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/curs507a.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/curs507a.c
@@ -109,7 +109,7 @@ curs507a_acquire(struct nv50_wndw *wndw, struct
nv50_wndw_atom *asyw,
if (ret || !asyh->curs.visible)
return ret;
- if (asyw->image.w != asyw->image.h)
+ if (asyw->state.crtc_w != asyw->state.crtc_h)
return -EINVAL;
ret = head->func->curs_layout(head, asyw, asyh);
diff --git a/drivers/gpu/drm/nouveau/dispnv50/head507d.c
b/drivers/gpu/drm/nouveau/dispnv50/head507d.c
index 09b89983864b..3d230ca488c9 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/head507d.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/head507d.c
@@ -176,7 +176,7 @@ int
head507d_curs_layout(struct nv50_head *head, struct nv50_wndw_atom *asyw,
struct nv50_head_atom *asyh)
{
- switch (asyw->image.w) {
+ switch (asyw->state.crtc_w) {
case 32: asyh->curs.layout =
NV507D_HEAD_SET_CONTROL_CURSOR_SIZE_W32_H32; break;
case 64: asyh->curs.layout =
NV507D_HEAD_SET_CONTROL_CURSOR_SIZE_W64_H64; break;
default:
diff --git a/drivers/gpu/drm/nouveau/dispnv50/head917d.c
b/drivers/gpu/drm/nouveau/dispnv50/head917d.c
index 4ce47b55f72c..caa7d633691b 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/head917d.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/head917d.c
@@ -103,7 +103,7 @@ int
head917d_curs_layout(struct nv50_head *head, struct nv50_wndw_atom *asyw,
struct nv50_head_atom *asyh)
{
- switch (asyw->state.fb->width) {
+ switch (asyw->state.crtc_w) {
case 32: asyh->curs.layout =
NV917D_HEAD_SET_CONTROL_CURSOR_SIZE_W32_H32; break;
case 64: asyh->curs.layout =
NV917D_HEAD_SET_CONTROL_CURSOR_SIZE_W64_H64; break;
case 128: asyh->curs.layout =
NV917D_HEAD_SET_CONTROL_CURSOR_SIZE_W128_H128; break;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V2] drm/amdgpu: Fix a typo
s/traing/training/
...Plus the entire sentence construction for better readability.
Signed-off-by: Bhaskar Chowdhury
---
Changes from V1:
Alex and Randy's suggestions incorporated.
drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
b/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
index c325d6f53a71..bf3857867f51 100644
--- a/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
@@ -661,10 +661,10 @@ static int psp_v11_0_memory_training(struct psp_context
*psp, uint32_t ops)
if (ops & PSP_MEM_TRAIN_SEND_LONG_MSG) {
/*
-* Long traing will encroach certain mount of bottom VRAM,
-* saving the content of this bottom VRAM to system memory
-* before training, and restoring it after training to avoid
-* VRAM corruption.
+* Long training will encroach a certain amount on the bottom
of VRAM;
+ * save the content from the bottom VRAM to system memory
+ * before training, and restore it after training to avoid
+ * VRAM corruption.
*/
sz = GDDR6_MEM_TRAINING_ENCROACHED_SIZE;
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu: Fix a typo
On 14:12 Thu 18 Mar 2021, Alex Deucher wrote:
On Thu, Mar 18, 2021 at 2:08 PM Randy Dunlap wrote:
On 3/18/21 4:33 AM, Bhaskar Chowdhury wrote:
>
> s/traing/training/
>
> Signed-off-by: Bhaskar Chowdhury
> ---
> drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
b/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
> index c325d6f53a71..db18e4f6cf5f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
> @@ -661,7 +661,7 @@ static int psp_v11_0_memory_training(struct psp_context
*psp, uint32_t ops)
>
> if (ops & PSP_MEM_TRAIN_SEND_LONG_MSG) {
> /*
> - * Long traing will encroach certain mount of bottom VRAM,
> + * Long training will encroach certain mount of bottom VRAM,
amount
I think.
Yeah, I think it should read something like:
Long training will encroach a certain amount on the bottom of VRAM;
save the content from the bottom VRAM to system memory
before training, and restore it after training to avoid
VRAM corruption.
Alex
>* saving the content of this bottom VRAM to system memory
>* before training, and restoring it after training to avoid
>* VRAM corruption.
Thanks.
> --
> 2.26.2
>
--
~Randy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] gpu/drm/msm: fix shutdown hook in case GPU components failed to bind
if GPU components have failed to bind, shutdown callback would fail with
the following backtrace. Add safeguard check to stop that oops from
happening and allow the board to reboot.
[ 66.617046] Unable to handle kernel NULL pointer dereference at virtual
address
[ 66.626066] Mem abort info:
[ 66.628939] ESR = 0x9606
[ 66.632088] EC = 0x25: DABT (current EL), IL = 32 bits
[ 66.637542] SET = 0, FnV = 0
[ 66.640688] EA = 0, S1PTW = 0
[ 66.643924] Data abort info:
[ 66.646889] ISV = 0, ISS = 0x0006
[ 66.650832] CM = 0, WnR = 0
[ 66.653890] user pgtable: 4k pages, 48-bit VAs, pgdp=000107f81000
[ 66.660505] [] pgd=000100bb2003, p4d=000100bb2003,
pud=000100897003, pmd=
[ 66.671398] Internal error: Oops: 9606 [#1] PREEMPT SMP
[ 66.677115] Modules linked in:
[ 66.680261] CPU: 6 PID: 352 Comm: reboot Not tainted
5.11.0-rc2-00309-g79e3faa756b2 #38
[ 66.688473] Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)
[ 66.695347] pstate: 6045 (nZCv daif +PAN -UAO -TCO BTYPE=--)
[ 66.701507] pc : msm_atomic_commit_tail+0x78/0x4e0
[ 66.706437] lr : commit_tail+0xa4/0x184
[ 66.710381] sp : 8000108f3af0
[ 66.713791] x29: 8000108f3af0 x28: 418c44337000
[ 66.719242] x27: x26: 418c40a24490
[ 66.724693] x25: d3a842a4f1a0 x24: 0008
[ 66.730146] x23: d3a84313f030 x22: 418c444ce000
[ 66.735598] x21: 418c408a4980 x20:
[ 66.741049] x19: x18: 800010710fbc
[ 66.746500] x17: 000c x16: 0001
[ 66.751954] x15: 00010008 x14: 0068
[ 66.757405] x13: 0001 x12:
[ 66.762855] x11: 0001 x10: 09b0
[ 66.768306] x9 : d3a843192000 x8 : 418c44337000
[ 66.773757] x7 : x6 : a401b34e
[ 66.779210] x5 : 00ff x4 :
[ 66.784660] x3 : x2 : 418c444ce000
[ 66.790111] x1 : d3a841dce530 x0 : 418c444cf000
[ 66.795563] Call trace:
[ 66.798075] msm_atomic_commit_tail+0x78/0x4e0
[ 66.802633] commit_tail+0xa4/0x184
[ 66.806217] drm_atomic_helper_commit+0x160/0x390
[ 66.811051] drm_atomic_commit+0x4c/0x60
[ 66.815082] drm_atomic_helper_disable_all+0x1f4/0x210
[ 66.820355] drm_atomic_helper_shutdown+0x80/0x130
[ 66.825276] msm_pdev_shutdown+0x14/0x20
[ 66.829303] platform_shutdown+0x28/0x40
[ 66.80] device_shutdown+0x158/0x330
[ 66.837357] kernel_restart+0x40/0xa0
[ 66.841122] __do_sys_reboot+0x228/0x250
[ 66.845148] __arm64_sys_reboot+0x28/0x34
[ 66.849264] el0_svc_common.constprop.0+0x74/0x190
[ 66.854187] do_el0_svc+0x24/0x90
[ 66.857595] el0_svc+0x14/0x20
[ 66.860739] el0_sync_handler+0x1a4/0x1b0
[ 66.864858] el0_sync+0x174/0x180
[ 66.868269] Code: 1ac020a0 2a000273 eb02007f 5401 (f9400285)
[ 66.874525] ---[ end trace 20dedb2a3229fec8 ]---
Fixes: 9d5cbf5fe46e ("drm/msm: add shutdown support for display
platform_driver")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_drv.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 94525ac76d4e..fd2ac54caf9f 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1311,6 +1311,10 @@ static int msm_pdev_remove(struct platform_device *pdev)
static void msm_pdev_shutdown(struct platform_device *pdev)
{
struct drm_device *drm = platform_get_drvdata(pdev);
+ struct msm_drm_private *priv = drm ? drm->dev_private : NULL;
+
+ if (!priv || !priv->kms)
+ return;
drm_atomic_helper_shutdown(drm);
}
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] gpu/drm/msm: fix shutdown hook in case GPU components failed to bind
if GPU components have failed to bind, shutdown callback would fail with
the following backtrace. Add safeguard check to stop that oops from
happening and allow the board to reboot.
[ 66.617046] Unable to handle kernel NULL pointer dereference at virtual
address
[ 66.626066] Mem abort info:
[ 66.628939] ESR = 0x9606
[ 66.632088] EC = 0x25: DABT (current EL), IL = 32 bits
[ 66.637542] SET = 0, FnV = 0
[ 66.640688] EA = 0, S1PTW = 0
[ 66.643924] Data abort info:
[ 66.646889] ISV = 0, ISS = 0x0006
[ 66.650832] CM = 0, WnR = 0
[ 66.653890] user pgtable: 4k pages, 48-bit VAs, pgdp=000107f81000
[ 66.660505] [] pgd=000100bb2003, p4d=000100bb2003,
pud=000100897003, pmd=
[ 66.671398] Internal error: Oops: 9606 [#1] PREEMPT SMP
[ 66.677115] Modules linked in:
[ 66.680261] CPU: 6 PID: 352 Comm: reboot Not tainted
5.11.0-rc2-00309-g79e3faa756b2 #38
[ 66.688473] Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)
[ 66.695347] pstate: 6045 (nZCv daif +PAN -UAO -TCO BTYPE=--)
[ 66.701507] pc : msm_atomic_commit_tail+0x78/0x4e0
[ 66.706437] lr : commit_tail+0xa4/0x184
[ 66.710381] sp : 8000108f3af0
[ 66.713791] x29: 8000108f3af0 x28: 418c44337000
[ 66.719242] x27: x26: 418c40a24490
[ 66.724693] x25: d3a842a4f1a0 x24: 0008
[ 66.730146] x23: d3a84313f030 x22: 418c444ce000
[ 66.735598] x21: 418c408a4980 x20:
[ 66.741049] x19: x18: 800010710fbc
[ 66.746500] x17: 000c x16: 0001
[ 66.751954] x15: 00010008 x14: 0068
[ 66.757405] x13: 0001 x12:
[ 66.762855] x11: 0001 x10: 09b0
[ 66.768306] x9 : d3a843192000 x8 : 418c44337000
[ 66.773757] x7 : x6 : a401b34e
[ 66.779210] x5 : 00ff x4 :
[ 66.784660] x3 : x2 : 418c444ce000
[ 66.790111] x1 : d3a841dce530 x0 : 418c444cf000
[ 66.795563] Call trace:
[ 66.798075] msm_atomic_commit_tail+0x78/0x4e0
[ 66.802633] commit_tail+0xa4/0x184
[ 66.806217] drm_atomic_helper_commit+0x160/0x390
[ 66.811051] drm_atomic_commit+0x4c/0x60
[ 66.815082] drm_atomic_helper_disable_all+0x1f4/0x210
[ 66.820355] drm_atomic_helper_shutdown+0x80/0x130
[ 66.825276] msm_pdev_shutdown+0x14/0x20
[ 66.829303] platform_shutdown+0x28/0x40
[ 66.80] device_shutdown+0x158/0x330
[ 66.837357] kernel_restart+0x40/0xa0
[ 66.841122] __do_sys_reboot+0x228/0x250
[ 66.845148] __arm64_sys_reboot+0x28/0x34
[ 66.849264] el0_svc_common.constprop.0+0x74/0x190
[ 66.854187] do_el0_svc+0x24/0x90
[ 66.857595] el0_svc+0x14/0x20
[ 66.860739] el0_sync_handler+0x1a4/0x1b0
[ 66.864858] el0_sync+0x174/0x180
[ 66.868269] Code: 1ac020a0 2a000273 eb02007f 5401 (f9400285)
[ 66.874525] ---[ end trace 20dedb2a3229fec8 ]---
Fixes: 9d5cbf5fe46e ("drm/msm: add shutdown support for display
platform_driver")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_drv.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 94525ac76d4e..fd2ac54caf9f 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1311,6 +1311,10 @@ static int msm_pdev_remove(struct platform_device *pdev)
static void msm_pdev_shutdown(struct platform_device *pdev)
{
struct drm_device *drm = platform_get_drvdata(pdev);
+ struct msm_drm_private *priv = drm ? drm->dev_private : NULL;
+
+ if (!priv || !priv->kms)
+ return;
drm_atomic_helper_shutdown(drm);
}
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu/drm/msm: fix shutdown hook in case GPU components failed to bind
On 17/03/2021 19:25, Rob Clark wrote: On Mon, Mar 1, 2021 at 1:41 PM Dmitry Baryshkov wrote: if GPU components have failed to bind, shutdown callback would fail with the following backtrace. Add safeguard check to stop that oops from happening and allow the board to reboot. [skipped] diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c index 6a326761dc4a..2fd0cf6421ad 100644 --- a/drivers/gpu/drm/msm/msm_atomic.c +++ b/drivers/gpu/drm/msm/msm_atomic.c @@ -207,7 +207,12 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state) struct msm_kms *kms = priv->kms; struct drm_crtc *async_crtc = NULL; unsigned crtc_mask = get_crtc_mask(state); - bool async = kms->funcs->vsync_time && + bool async; + + if (!kms) + return; I think we could instead just check for null priv->kms in msm_pdev_shutdown() and not call drm_atomic_helper_shutdown()? Good idea. Sending v2. BR, -R + + async = kms->funcs->vsync_time && can_do_async(state, _crtc); trace_msm_atomic_commit_tail_start(async, crtc_mask); -- 2.30.1 -- With best wishes Dmitry ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/ttm: move swapout logic around v2
On 3/18/21 4:26 PM, Christian König wrote:
Am 18.03.21 um 15:43 schrieb Nirmoy:
Hi Christian,
On 3/18/21 1:47 PM, Christian König wrote:
/**
* ttm_bo_uses_embedded_gem_object - check if the given bo uses the
diff --git a/include/drm/ttm/ttm_device.h
b/include/drm/ttm/ttm_device.h
index 035bbc044a3b..6a0b267d4fe6 100644
--- a/include/drm/ttm/ttm_device.h
+++ b/include/drm/ttm/ttm_device.h
@@ -297,6 +297,8 @@ struct ttm_device {
struct delayed_work wq;
};
+long ttm_global_swapout(struct ttm_operation_ctx *ctx, gfp_t
gfp_flags);
There is a typo here, long -> int.
Ah, yes. I missed to add the change to the header file.
I have tested the patch series on qxl and vmwgfx.
With that typo fixed, the series is Tested-by: Nirmoy Das
Thanks for pointing that out,
Christian.
Thanks,
Nirmoy
+
static inline struct ttm_resource_manager *
ttm_manager_type(struct ttm_device *bdev, int mem_type)
{
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 8/9] drm/gem: Associate GEM objects with drm cgroup
On 3/18/2021 3:16 AM, Daniel Vetter wrote: > On Sat, Mar 6, 2021 at 1:44 AM Brian Welty wrote: >> >> >> On 2/11/2021 7:34 AM, Daniel Vetter wrote: >>> On Wed, Feb 10, 2021 at 02:00:57PM -0800, Brian Welty wrote: On 2/9/2021 2:54 AM, Daniel Vetter wrote: > On Tue, Jan 26, 2021 at 01:46:25PM -0800, Brian Welty wrote: >> This patch adds tracking of which cgroup to make charges against for a >> given GEM object. We associate the current task's cgroup with GEM >> objects >> as they are created. First user of this is for charging DRM cgroup for >> device memory allocations. The intended behavior is for device drivers >> to >> make the cgroup charging calls at the time that backing store is >> allocated >> or deallocated for the object. >> >> Exported functions are provided for charging memory allocations for a >> GEM object to DRM cgroup. To aid in debugging, we store how many bytes >> have been charged inside the GEM object. Add helpers for setting and >> clearing the object's associated cgroup which will check that charges are >> not being leaked. >> >> For shared objects, this may make the charge against a cgroup that is >> potentially not the same cgroup as the process using the memory. Based >> on the memory cgroup's discussion of "memory ownership", this seems >> acceptable [1]. >> >> [1] https://www.kernel.org/doc/Documentation/cgroup-v2.txt, "Memory >> Ownership" >> >> Signed-off-by: Brian Welty > > Since for now we only have the generic gpu/xpu/bikeshed.memory bucket that > counts everything, why don't we also charge in these gem functions? I'm not sure what you mean exactly. You want to merge/move the charging logic proposed in patch #5 (drm_cgroup_try_charge in kernel/cgroup/drm.c) into drm_gem_object_charge_mem() ? Or reading below, I think you are okay keeping the logic separated as is, but you want much of the code in kernel/cgroup/drm.c moved to drivers/gpu/cgroup ? Yes, I see that should allow to reduce number of exported functions. >>> >>> Both. I mean we'd need to look at the code again when it's shuffled, but >>> I'd say: >>> >>> - cgroup code and the charging for general gpu memory moves to >>> drivers/gpu/cgroup, so dma-buf heaps can use it too. >>> >>> - the charging for gem buffers moves into core gem code, so it happens for >>> all gpu drivers and all gem buffer allocations. >> >> Daniel, I'm not sure we're in sync on what 'charging for general gpu memory' >> means. Thus far, I have been proposing to charge/uncharge when backing >> store is >> allocated/freed. And thus, this would be done in DRM driver (so then also in >> the dma-buf exporter). >> I can't see how we'd hoist this part into drm gem code. >> The memory limit in this series is for VRAM usage/limit not GEM buffers... > > Yes this would be at gem buffer creation time. And just to get cgroups > for drm up Okay, but it's not of the ones in Tejun's list to start with: https://lists.freedesktop.org/archives/dri-devel/2020-April/262141.html I hoped we would start by pursuing those (gpu.weight and gpu.memory.high) as first step. Limiting GEM buffers is essentially controlling virtual memory size, which tend to just always get set to unlimited. Would be nice to get consensus from maintainers before proceeding to implement this. > >> Unless you are talking about charging for GEM buffer creation? But this is >> more of a 'soft resource' more along lines of Kenny's earlier GEM buffer >> limit >> control. >> I raised issue with this then, and at the time, Tejun agreed we should keep >> to >> 'hard resource' controls, see [1] and [2]. >> >> [1] https://lists.freedesktop.org/archives/dri-devel/2019-May/218071.html >> [2] https://lists.freedesktop.org/archives/dri-devel/2020-April/262141.html >> >>> >>> - this might or might not mean a bunch less exported stuff from the >>> cgroups files (since you don't need separate steps for linking a gem >>> object to a cgroup from the actual charging), and probably no exports >>> anymore for drivers (since they charge nothing). That will change >>> when we add charging for specific memory pools I guess, but we add that >>> when we add tha functionality. >> >> ... so considering VRAM charging, then yes, we very much need to have >> exported >> functions for drivers to do the charging. >> But these can be exported from drm.ko (or new .ko?) instead of kernel. Is >> that still preference? Also, if number of exported functions is concern, we >> can replace some of it with use of function pointers. > > So the reason I suggested we drop all this is because we won't charge > in drivers, we'll charge in ttm buffer management code. Which we'll > adopt for dg1 in upstream. But it will take some time. Okay, thanks for clarifying. I'm not familiar with where try_charge/uncharge would
Re: Re: [PATCH 02/18] drm/bridge: Add HDMI output fmt helper
Dne sreda, 17. marec 2021 ob 17:08:07 CET je Neil Armstrong napisal(a): > On 17/03/2021 16:43, Maxime Ripard wrote: > > The atomic_get_output_bus_fmts bridge callback is there to list the > > available formats for output by decreasing order of preference. > > > > On HDMI controllers, we have a fairly static list that will depend on > > what the HDMI sink is capable of and the BPC our controller can output. > > > > The dw-hdmi driver already has that code done in a fairly generic > > manner, so let's turn that code into an helper for all the HDMI > > controllers to reuse. > > This code was based on the capabilities of the DW-HDMI IP, copying it as-is > doesn't make much sense, we should be able to filter out formats the HDMI IP > doesn't support. HDMI standard has pretty strict requirements which formats should be supported, so cores should have very similar capabilities. Best regards, Jernej ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm/dp: Fixed couple of typos
On 3/17/21 11:26 PM, Bhaskar Chowdhury wrote: > s/modueles/modules/ two different places > > Signed-off-by: Bhaskar Chowdhury Acked-by: Randy Dunlap > --- > drivers/gpu/drm/msm/dp/dp_power.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/msm/dp/dp_power.h > b/drivers/gpu/drm/msm/dp/dp_power.h > index 7d0327bbc0d5..e3f959ffae12 100644 > --- a/drivers/gpu/drm/msm/dp/dp_power.h > +++ b/drivers/gpu/drm/msm/dp/dp_power.h > @@ -88,7 +88,7 @@ int dp_power_client_init(struct dp_power *power); > * return: 0 for success, error for failure. > * > * This API will de-initialize the DisplayPort's clocks and regulator > - * modueles. > + * modules. > */ > void dp_power_client_deinit(struct dp_power *power); > > @@ -100,7 +100,7 @@ void dp_power_client_deinit(struct dp_power *power); > * > * This API will configure the DisplayPort's power module and provides > * methods to be called by the client to configure the power related > - * modueles. > + * modules. > */ > struct dp_power *dp_power_get(struct device *dev, struct dp_parser *parser); > > -- -- ~Randy ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/meson: Fix few typo
On 3/18/21 4:00 AM, Bhaskar Chowdhury wrote: > > s/initialy/initially/ > s/desined/designed/ > > Signed-off-by: Bhaskar Chowdhury Acked-by: Randy Dunlap > --- > drivers/gpu/drm/meson/meson_venc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/meson/meson_venc.c > b/drivers/gpu/drm/meson/meson_venc.c > index 5e2236ec189f..3c55ed003359 100644 > --- a/drivers/gpu/drm/meson/meson_venc.c > +++ b/drivers/gpu/drm/meson/meson_venc.c > @@ -45,7 +45,7 @@ > * The ENCI is designed for PAl or NTSC encoding and can go through the VDAC > * directly for CVBS encoding or through the ENCI_DVI encoder for HDMI. > * The ENCP is designed for Progressive encoding but can also generate > - * 1080i interlaced pixels, and was initialy desined to encode pixels for > + * 1080i interlaced pixels, and was initially designed to encode pixels for > * VDAC to output RGB ou YUV analog outputs. > * It's output is only used through the ENCP_DVI encoder for HDMI. > * The ENCL LVDS encoder is not implemented. > -- -- ~Randy ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/18] drm/vc4: hdmi: Add Support for the YUV output
Hi! Dne sreda, 17. marec 2021 ob 16:43:34 CET je Maxime Ripard napisal(a): > Hi, > > Here's an attempt at support the HDMI YUV output on the BCM2711 SoC found on > the RaspberryPi4. > > I took the same approach than what dw-hdmi did already, turning a bunch of > functions found in that driver into helpers since they were fairly generic. > > However, it feels a bit clunky overall and there's a few rough edges that > should be addressed in a generic manner: > > - while the format negociation makes sense for a bridge, it feels a bit > over-engineered for a simple encoder where that setting could be a simple > switch (and possibly a property?) Property could work, but possible values should be then limited to cross section of HW and connected display capabilities. > > - more importantly, whether we're choosing an YUV output or not is completely > hidden away from the userspace even though it might have some effect on the > visual quality output (thinking about YUV420 and YUV422 here mostly). IMO driver should select highest achievable quality. So in case of YUV420 and YUV422, later should be selected. This should be the case even if the property is implemented. Best regards, Jernej > > - Similarly, the list we report is static and the userspace cannot change or > force one mode over the other. We will always pick YUV444 over RGB444 if > both are available for example. > > While the first one might just be due to a lack of helpers, the second and > third ones are also feeling a bit inconsistent with how we're handling the > 10/12 bit output for example > > Let me know what you think, > Maxime > > Maxime Ripard (18): > drm: Introduce new HDMI helpers > drm/bridge: Add HDMI output fmt helper > drm/bridge: dw-hdmi: Use helpers > drm/vc4: txp: Properly set the possible_crtcs mask > drm/vc4: crtc: Skip the TXP > drm/vc4: Rework the encoder retrieval code > drm/vc4: hdmi: Add full range RGB helper > drm/vc4: hdmi: Use full range helper in csc functions > drm/vc4: hdmi: Remove limited_rgb_range > drm/vc4: hdmi: Convert to bridge > drm/vc4: hdmi: Move XBAR setup to csc_setup > drm/vc4: hdmi: Replace CSC_CTL hardcoded value by defines > drm/vc4: hdmi: Define colorspace matrices > drm/vc4: hdmi: Change CSC callback prototype > drm/vc4: hdmi: Rework the infoframe prototype > drm/vc4: hdmi: Support HDMI YUV output > drm/vc4: hdmi: Move the pixel rate calculation to a helper > drm/vc4: hdmi: Force YUV422 if the rate is too high > > drivers/gpu/drm/Makefile | 2 +- > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 268 ++- > drivers/gpu/drm/drm_bridge.c | 118 +++ > drivers/gpu/drm/drm_hdmi.c| 170 + > drivers/gpu/drm/vc4/vc4_crtc.c| 59 +++- > drivers/gpu/drm/vc4/vc4_drv.c | 41 +++ > drivers/gpu/drm/vc4/vc4_drv.h | 26 +- > drivers/gpu/drm/vc4/vc4_hdmi.c| 399 +++--- > drivers/gpu/drm/vc4/vc4_hdmi.h| 13 +- > drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 6 + > drivers/gpu/drm/vc4/vc4_regs.h| 19 ++ > drivers/gpu/drm/vc4/vc4_txp.c | 2 +- > include/drm/drm_bridge.h | 6 + > include/drm/drm_hdmi.h| 24 ++ > 14 files changed, 770 insertions(+), 383 deletions(-) > create mode 100644 drivers/gpu/drm/drm_hdmi.c > create mode 100644 include/drm/drm_hdmi.h > > -- > 2.30.2 > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915/gt: A typo fix
On 3/18/21 3:19 AM, Bhaskar Chowdhury wrote: > > s/bariers/barriers/ > > Signed-off-by: Bhaskar Chowdhury Acked-by: Randy Dunlap > --- > drivers/gpu/drm/i915/gt/intel_timeline.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.c > b/drivers/gpu/drm/i915/gt/intel_timeline.c > index 037b0e3ccbed..25fc7f44fee0 100644 > --- a/drivers/gpu/drm/i915/gt/intel_timeline.c > +++ b/drivers/gpu/drm/i915/gt/intel_timeline.c > @@ -435,7 +435,7 @@ void intel_timeline_exit(struct intel_timeline *tl) > spin_unlock(>lock); > > /* > - * Since this timeline is idle, all bariers upon which we were waiting > + * Since this timeline is idle, all barriers upon which we were waiting >* must also be complete and so we can discard the last used barriers >* without loss of information. >*/ > -- > 2.26.2 > -- ~Randy ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/ttm: move swapout logic around v2
Hi "Christian,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
[also build test ERROR on next-20210318]
[cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next
linus/master v5.12-rc3]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Christian-K-nig/drm-ttm-move-swapout-logic-around-v2/20210318-204848
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: x86_64-randconfig-a005-20210318 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project
6db3ab2903f42712f44000afb5aa467efbd25f35)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
#
https://github.com/0day-ci/linux/commit/a454d56ea061b53d24a62a700743e4508dd6c9b1
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Christian-K-nig/drm-ttm-move-swapout-logic-around-v2/20210318-204848
git checkout a454d56ea061b53d24a62a700743e4508dd6c9b1
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> drivers/gpu/drm/ttm/ttm_device.c:109:5: error: conflicting types for
>> 'ttm_global_swapout'
int ttm_global_swapout(struct ttm_operation_ctx *ctx, gfp_t gfp_flags)
^
include/drm/ttm/ttm_device.h:300:6: note: previous declaration is here
long ttm_global_swapout(struct ttm_operation_ctx *ctx, gfp_t gfp_flags);
^
1 error generated.
vim +/ttm_global_swapout +109 drivers/gpu/drm/ttm/ttm_device.c
104
105 /**
106 * A buffer object shrink method that tries to swap out the first
107 * buffer object on the global::swap_lru list.
108 */
> 109 int ttm_global_swapout(struct ttm_operation_ctx *ctx, gfp_t gfp_flags)
110 {
111 struct ttm_global *glob = _glob;
112 struct ttm_buffer_object *bo;
113 unsigned i;
114 int ret;
115
116 spin_lock(>lru_lock);
117 for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
118 list_for_each_entry(bo, >swap_lru[i], swap) {
119 uint32_t num_pages = bo->ttm->num_pages;
120
121 ret = ttm_bo_swapout(bo, ctx, gfp_flags);
122 /* ttm_bo_swapout has dropped the lru_lock */
123 if (!ret)
124 return num_pages;
125 if (ret != -EBUSY)
126 return ret;
127 }
128 }
129 spin_unlock(>lru_lock);
130 return 0;
131 }
132 EXPORT_SYMBOL(ttm_global_swapout);
133
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu: Fix a typo
On Thu, Mar 18, 2021 at 2:08 PM Randy Dunlap wrote:
>
> On 3/18/21 4:33 AM, Bhaskar Chowdhury wrote:
> >
> > s/traing/training/
> >
> > Signed-off-by: Bhaskar Chowdhury
> > ---
> > drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
> > b/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
> > index c325d6f53a71..db18e4f6cf5f 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
> > @@ -661,7 +661,7 @@ static int psp_v11_0_memory_training(struct psp_context
> > *psp, uint32_t ops)
> >
> > if (ops & PSP_MEM_TRAIN_SEND_LONG_MSG) {
> > /*
> > - * Long traing will encroach certain mount of bottom VRAM,
> > + * Long training will encroach certain mount of bottom VRAM,
>
>amount
> I think.
Yeah, I think it should read something like:
Long training will encroach a certain amount on the bottom of VRAM;
save the content from the bottom VRAM to system memory
before training, and restore it after training to avoid
VRAM corruption.
Alex
>
> >* saving the content of this bottom VRAM to system memory
> >* before training, and restoring it after training to avoid
> >* VRAM corruption.
> > --
> > 2.26.2
> >
>
>
> --
> ~Randy
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu: Fix a typo
On 3/18/21 4:33 AM, Bhaskar Chowdhury wrote:
>
> s/traing/training/
>
> Signed-off-by: Bhaskar Chowdhury
> ---
> drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
> b/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
> index c325d6f53a71..db18e4f6cf5f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
> @@ -661,7 +661,7 @@ static int psp_v11_0_memory_training(struct psp_context
> *psp, uint32_t ops)
>
> if (ops & PSP_MEM_TRAIN_SEND_LONG_MSG) {
> /*
> - * Long traing will encroach certain mount of bottom VRAM,
> + * Long training will encroach certain mount of bottom VRAM,
amount
I think.
>* saving the content of this bottom VRAM to system memory
>* before training, and restoring it after training to avoid
>* VRAM corruption.
> --
> 2.26.2
>
--
~Randy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Few typo fixes
On 3/18/21 7:25 AM, Joe Perches wrote: > On Thu, 2021-03-18 at 16:07 +0530, Bhaskar Chowdhury wrote: >> s/instatiated/instantiated/ >> s/unreference/unreferenced/ > > []> diff --git a/drivers/gpu/drm/drm_property.c > b/drivers/gpu/drm/drm_property.c > [] >> @@ -644,7 +644,7 @@ EXPORT_SYMBOL(drm_property_blob_get); >> * @id: id of the blob property >> * >> * If successful, this takes an additional reference to the blob property. >> - * callers need to make sure to eventually unreference the returned property >> + * callers need to make sure to eventually unreferenced the returned >> property > > I think this is worse. Agreed -- not good. -- ~Randy ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915/dpcd_bl: Don't try vesa interface unless specified by VBT
Actually-NAK this. I just realized I've been misreading the bug and that this
doesn't actually seem to be fixed. Will resend once I figure out what's going on
On Thu, 2021-03-18 at 13:02 -0400, Lyude Paul wrote:
> Looks like that there actually are another subset of laptops on the market
> that don't support the Intel HDR backlight interface, but do advertise
> support for the VESA DPCD backlight interface despite the fact it doesn't
> seem to work.
>
> Note though I'm not entirely clear on this - on one of the machines where
> this issue was observed, I also noticed that we appeared to be rejecting
> the VBT defined backlight frequency in
> intel_dp_aux_vesa_calc_max_backlight(). It's noted in this function that:
>
> /* Use highest possible value of Pn for more granularity of brightness
> * adjustment while satifying the conditions below.
> * ...
> * - FxP is within 25% of desired value.
> * Note: 25% is arbitrary value and may need some tweak.
> */
>
> So it's possible that this value might just need to be tweaked, but for now
> let's just disable the VESA backlight interface unless it's specified in
> the VBT just to be safe. We might be able to try enabling this again by
> default in the future.
>
> Fixes: 2227816e647a ("drm/i915/dp: Allow forcing specific interfaces through
> enable_dpcd_backlight")
> Cc: Jani Nikula
> Cc: Rodrigo Vivi
> Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/3169
> Signed-off-by: Lyude Paul
> ---
> drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> index 651884390137..4f8337c7fd2e 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> @@ -646,7 +646,6 @@ int intel_dp_aux_init_backlight_funcs(struct
> intel_connector *connector)
> break;
> case INTEL_BACKLIGHT_DISPLAY_DDI:
> try_intel_interface = true;
> - try_vesa_interface = true;
> break;
> default:
> return -ENODEV;
--
Sincerely,
Lyude Paul (she/her)
Software Engineer at Red Hat
Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've
asked me a question, are waiting for a review/merge on a patch, etc. and I
haven't responded in a while, please feel free to send me another email to check
on my status. I don't bite!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/6] drm/i915: Allow configuring default request expiry via modparam
From: Tvrtko Ursulin Module parameter is added (request_timeout_ms) to allow configuring the default request/fence expiry. Default value is inherited from CONFIG_DRM_I915_REQUEST_TIMEOUT. Signed-off-by: Tvrtko Ursulin Cc: Daniel Vetter Acked-by: Daniel Vetter --- drivers/gpu/drm/i915/gem/i915_gem_context.c | 5 +++-- drivers/gpu/drm/i915/i915_params.c | 5 + drivers/gpu/drm/i915/i915_params.h | 1 + 3 files changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c b/drivers/gpu/drm/i915/gem/i915_gem_context.c index be71be21800b..cf5b706a39b8 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c @@ -877,11 +877,12 @@ static void __set_default_fence_expiry(struct i915_gem_context *ctx) struct drm_i915_private *i915 = ctx->i915; int ret; - if (!IS_ACTIVE(CONFIG_DRM_I915_REQUEST_TIMEOUT)) + if (!IS_ACTIVE(CONFIG_DRM_I915_REQUEST_TIMEOUT) || + !i915->params.request_timeout_ms) return; /* Default expiry for user fences. */ - ret = __set_watchdog(ctx, CONFIG_DRM_I915_REQUEST_TIMEOUT * 1000); + ret = __set_watchdog(ctx, i915->params.request_timeout_ms * 1000); if (ret) drm_notice(>drm, "Failed to configure default fence expiry! (%d)", diff --git a/drivers/gpu/drm/i915/i915_params.c b/drivers/gpu/drm/i915/i915_params.c index 6939634e56ed..0320878d96b0 100644 --- a/drivers/gpu/drm/i915/i915_params.c +++ b/drivers/gpu/drm/i915/i915_params.c @@ -197,6 +197,11 @@ i915_param_named_unsafe(fake_lmem_start, ulong, 0400, "Fake LMEM start offset (default: 0)"); #endif +#if CONFIG_DRM_I915_REQUEST_TIMEOUT +i915_param_named_unsafe(request_timeout_ms, uint, 0600, + "Default request/fence/batch buffer expiration timeout."); +#endif + static __always_inline void _print_param(struct drm_printer *p, const char *name, const char *type, diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index 48f47e44e848..34ebb0662547 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++ b/drivers/gpu/drm/i915/i915_params.h @@ -72,6 +72,7 @@ struct drm_printer; param(int, enable_dpcd_backlight, -1, 0600) \ param(char *, force_probe, CONFIG_DRM_I915_FORCE_PROBE, 0400) \ param(unsigned long, fake_lmem_start, 0, 0400) \ + param(unsigned int, request_timeout_ms, CONFIG_DRM_I915_REQUEST_TIMEOUT, 0600) \ /* leave bools at the end to not create holes */ \ param(bool, enable_hangcheck, true, 0600) \ param(bool, load_detect_test, false, 0600) \ -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/6] drm/i915: Fail too long user submissions by default
From: Tvrtko Ursulin
A new Kconfig option CONFIG_DRM_I915_REQUEST_TIMEOUT is added, defaulting
to 20s, and this timeout is applied to all users contexts using the
previously added watchdog facility.
Result of this is that any user submission will simply fail after this
timeout, either causing a reset (for non-preemptable), or incomplete
results.
This can have an effect that workloads which used to work fine will
suddenly start failing. Even workloads comprised of short batches but in
long dependency chains can be terminated.
And becuase of lack of agreement on usefulness and safety of fence error
propagation this partial execution can be invisible to userspace even if
it is "listening" to returned fence status.
Another interaction is with hangcheck where care needs to be taken timeout
is not set lower or close to three times the heartbeat interval. Otherwise
a hang in any application can cause complete termination of all
submissions from unrelated clients. Any users modifying the per engine
heartbeat intervals therefore need to be aware of this potential denial of
service to avoid inadvertently enabling it.
Given all this I am personally not convinced the scheme is a good idea.
Intuitively it feels object importers would be better positioned to
enforce the time they are willing to wait for something to complete.
v2:
* Improved commit message and Kconfig text.
* Pull in some helper code from patch which got dropped.
v3:
* Bump timeout to 20s to see if it helps Tigerlake.
Signed-off-by: Tvrtko Ursulin
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/Kconfig.profile | 14 +++
drivers/gpu/drm/i915/gem/i915_gem_context.c | 38 +++
.../gpu/drm/i915/gem/i915_gem_context_types.h | 4 ++
drivers/gpu/drm/i915/gt/intel_context_param.h | 11 +-
4 files changed, 66 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/Kconfig.profile
b/drivers/gpu/drm/i915/Kconfig.profile
index 35bbe2b80596..39328567c200 100644
--- a/drivers/gpu/drm/i915/Kconfig.profile
+++ b/drivers/gpu/drm/i915/Kconfig.profile
@@ -1,3 +1,17 @@
+config DRM_I915_REQUEST_TIMEOUT
+ int "Default timeout for requests (ms)"
+ default 2 # milliseconds
+ help
+ Configures the default timeout after which any user submissions will
+ be forcefully terminated.
+
+ Beware setting this value lower, or close to heartbeat interval
+ rounded to whole seconds times three, in order to avoid allowing
+ misbehaving applications causing total rendering failure in unrelated
+ clients.
+
+ May be 0 to disable the timeout.
+
config DRM_I915_FENCE_TIMEOUT
int "Timeout for unsignaled foreign fences (ms, jiffy granularity)"
default 1 # milliseconds
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index ca37d93ef5e7..be71be21800b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -233,6 +233,8 @@ static void intel_context_set_gem(struct intel_context *ce,
if (ctx->sched.priority >= I915_PRIORITY_NORMAL &&
intel_engine_has_timeslices(ce->engine))
__set_bit(CONTEXT_USE_SEMAPHORES, >flags);
+
+ intel_context_set_watchdog_us(ce, ctx->watchdog.timeout_us);
}
static void __free_engines(struct i915_gem_engines *e, unsigned int count)
@@ -852,6 +854,40 @@ static void __assign_timeline(struct i915_gem_context *ctx,
context_apply_all(ctx, __apply_timeline, timeline);
}
+static int __apply_watchdog(struct intel_context *ce, void *timeout_us)
+{
+ return intel_context_set_watchdog_us(ce, (uintptr_t)timeout_us);
+}
+
+static int
+__set_watchdog(struct i915_gem_context *ctx, unsigned long timeout_us)
+{
+ int ret;
+
+ ret = context_apply_all(ctx, __apply_watchdog,
+ (void *)(uintptr_t)timeout_us);
+ if (!ret)
+ ctx->watchdog.timeout_us = timeout_us;
+
+ return ret;
+}
+
+static void __set_default_fence_expiry(struct i915_gem_context *ctx)
+{
+ struct drm_i915_private *i915 = ctx->i915;
+ int ret;
+
+ if (!IS_ACTIVE(CONFIG_DRM_I915_REQUEST_TIMEOUT))
+ return;
+
+ /* Default expiry for user fences. */
+ ret = __set_watchdog(ctx, CONFIG_DRM_I915_REQUEST_TIMEOUT * 1000);
+ if (ret)
+ drm_notice(>drm,
+ "Failed to configure default fence expiry! (%d)",
+ ret);
+}
+
static struct i915_gem_context *
i915_gem_create_context(struct drm_i915_private *i915, unsigned int flags)
{
@@ -896,6 +932,8 @@ i915_gem_create_context(struct drm_i915_private *i915,
unsigned int flags)
intel_timeline_put(timeline);
}
+ __set_default_fence_expiry(ctx);
+
trace_i915_context_create(ctx);
return ctx;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
[PATCH 4/6] drm/i915: Request watchdog infrastructure
From: Tvrtko Ursulin
Prepares the plumbing for setting request/fence expiration time. All code
is put in place but is never activeted due yet missing ability to actually
configure the timer.
Outline of the basic operation:
A timer is started when request is ready for execution. If the request
completes (retires) before the timer fires, timer is cancelled and nothing
further happens.
If the timer fires request is added to a lockless list and worker queued.
Purpose of this is twofold: a) It allows request cancellation from a more
friendly context and b) coalesces multiple expirations into a single event
of consuming the list.
Worker locklessly consumes the list of expired requests and cancels them
all using previous added i915_request_cancel().
Associated timeout value is stored in rq->context.watchdog.timeout_us.
v2:
* Log expiration.
Signed-off-by: Tvrtko Ursulin
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 4 ++
.../drm/i915/gt/intel_execlists_submission.h | 2 +
drivers/gpu/drm/i915/gt/intel_gt.c| 3 +
drivers/gpu/drm/i915/gt/intel_gt.h| 2 +
drivers/gpu/drm/i915/gt/intel_gt_requests.c | 26 +
drivers/gpu/drm/i915/gt/intel_gt_types.h | 7 +++
drivers/gpu/drm/i915/i915_request.c | 56 +++
drivers/gpu/drm/i915/i915_request.h | 8 +++
8 files changed, 108 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 0ea18c9e2aca..65a5730a4f5b 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -99,6 +99,10 @@ struct intel_context {
#define CONTEXT_FORCE_SINGLE_SUBMISSION7
#define CONTEXT_NOPREEMPT 8
+ struct {
+ u64 timeout_us;
+ } watchdog;
+
u32 *lrc_reg_state;
union {
struct {
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.h
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.h
index f7bd3fccfee8..4ca9b475e252 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.h
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.h
@@ -6,6 +6,7 @@
#ifndef __INTEL_EXECLISTS_SUBMISSION_H__
#define __INTEL_EXECLISTS_SUBMISSION_H__
+#include
#include
struct drm_printer;
@@ -13,6 +14,7 @@ struct drm_printer;
struct i915_request;
struct intel_context;
struct intel_engine_cs;
+struct intel_gt;
enum {
INTEL_CONTEXT_SCHEDULE_IN = 0,
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index ca76f93bc03d..8d77dcbad059 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -31,6 +31,9 @@ void intel_gt_init_early(struct intel_gt *gt, struct
drm_i915_private *i915)
INIT_LIST_HEAD(>closed_vma);
spin_lock_init(>closed_lock);
+ init_llist_head(>watchdog.list);
+ INIT_WORK(>watchdog.work, intel_gt_watchdog_work);
+
intel_gt_init_buffer_pool(gt);
intel_gt_init_reset(gt);
intel_gt_init_requests(gt);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
b/drivers/gpu/drm/i915/gt/intel_gt.h
index a17bd8b3195f..7ec395cace69 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -78,4 +78,6 @@ static inline bool intel_gt_is_wedged(const struct intel_gt
*gt)
void intel_gt_info_print(const struct intel_gt_info *info,
struct drm_printer *p);
+void intel_gt_watchdog_work(struct work_struct *work);
+
#endif /* __INTEL_GT_H__ */
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
index 36ec97f79174..a7f7bd662fb7 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
@@ -8,6 +8,7 @@
#include "i915_drv.h" /* for_each_engine() */
#include "i915_request.h"
#include "intel_engine_heartbeat.h"
+#include "intel_execlists_submission.h"
#include "intel_gt.h"
#include "intel_gt_pm.h"
#include "intel_gt_requests.h"
@@ -242,4 +243,29 @@ void intel_gt_fini_requests(struct intel_gt *gt)
{
/* Wait until the work is marked as finished before unloading! */
cancel_delayed_work_sync(>requests.retire_work);
+
+ flush_work(>watchdog.work);
+}
+
+void intel_gt_watchdog_work(struct work_struct *work)
+{
+ struct intel_gt *gt =
+ container_of(work, typeof(*gt), watchdog.work);
+ struct i915_request *rq, *rn;
+ struct llist_node *first;
+
+ first = llist_del_all(>watchdog.list);
+ if (!first)
+ return;
+
+ llist_for_each_entry_safe(rq, rn, first, watchdog.link) {
+ if (!i915_request_completed(rq)) {
+ drm_notice(>i915->drm,
+ "Fence expiration time out %llx:%llu!\n",
+ rq->fence.context,
+
[PATCH 3/6] drm/i915: Handle async cancellation in sentinel assert
From: Tvrtko Ursulin With the watchdog cancelling requests asynchronously to preempt-to-busy we need to relax one assert making it apply only to requests not in error. v2: * Check against the correct request! Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c index 4b870eca9693..bf557290173a 100644 --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c @@ -815,6 +815,13 @@ assert_pending_valid(const struct intel_engine_execlists *execlists, spin_unlock_irqrestore(>lock, flags); if (!ok) return false; + + /* +* Due async nature of preempt-to-busy and request cancellation +* we need to skip further asserts for cancelled requests. +*/ + if (READ_ONCE(rq->fence.error)) + break; } return ce; -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/6] drm/i915: Restrict sentinel requests further
From: Tvrtko Ursulin Disallow sentinel requests follow previous sentinels to make request cancellation work better when faced with a chain of requests which have all been marked as in error. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c index 4c2acb5a6c0a..4b870eca9693 100644 --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c @@ -896,7 +896,7 @@ static bool can_merge_rq(const struct i915_request *prev, if (__i915_request_is_complete(next)) return true; - if (unlikely((i915_request_flags(prev) ^ i915_request_flags(next)) & + if (unlikely((i915_request_flags(prev) | i915_request_flags(next)) & (BIT(I915_FENCE_FLAG_NOPREEMPT) | BIT(I915_FENCE_FLAG_SENTINEL return false; -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/6] drm/i915: Individual request cancellation
From: Chris Wilson
Currently, we cancel outstanding requests within a context when the
context is closed. We may also want to cancel individual requests using
the same graceful preemption mechanism.
v2 (Tvrtko):
* Cancel waiters carefully considering no timeline lock and RCU.
* Fixed selftests.
v3 (Tvrtko):
* Remove error propagation to waiters for now.
Signed-off-by: Chris Wilson
Signed-off-by: Tvrtko Ursulin
---
.../gpu/drm/i915/gt/intel_engine_heartbeat.c | 1 +
.../drm/i915/gt/intel_execlists_submission.c | 9 +-
drivers/gpu/drm/i915/i915_request.c | 52 -
drivers/gpu/drm/i915/i915_request.h | 4 +-
drivers/gpu/drm/i915/selftests/i915_request.c | 201 ++
5 files changed, 261 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
index 0b062fad1837..e2fb3ae2aaf3 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
@@ -314,6 +314,7 @@ int intel_engine_pulse(struct intel_engine_cs *engine)
mutex_unlock(>timeline->mutex);
}
+ intel_engine_flush_scheduler(engine);
intel_engine_pm_put(engine);
return err;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 85ff5fe861b4..4c2acb5a6c0a 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -421,6 +421,11 @@ static void reset_active(struct i915_request *rq,
ce->lrc.lrca = lrc_update_regs(ce, engine, head);
}
+static bool bad_request(const struct i915_request *rq)
+{
+ return rq->fence.error && i915_request_started(rq);
+}
+
static struct intel_engine_cs *
__execlists_schedule_in(struct i915_request *rq)
{
@@ -433,7 +438,7 @@ __execlists_schedule_in(struct i915_request *rq)
!intel_engine_has_heartbeat(engine)))
intel_context_set_banned(ce);
- if (unlikely(intel_context_is_banned(ce)))
+ if (unlikely(intel_context_is_banned(ce) || bad_request(rq)))
reset_active(rq, engine);
if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
@@ -1112,7 +1117,7 @@ static unsigned long active_preempt_timeout(struct
intel_engine_cs *engine,
return 0;
/* Force a fast reset for terminated contexts (ignoring sysfs!) */
- if (unlikely(intel_context_is_banned(rq->context)))
+ if (unlikely(intel_context_is_banned(rq->context) || bad_request(rq)))
return 1;
return READ_ONCE(engine->props.preempt_timeout_ms);
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index e7b4c4bc41a6..b4511ac05e9a 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -33,7 +33,10 @@
#include "gem/i915_gem_context.h"
#include "gt/intel_breadcrumbs.h"
#include "gt/intel_context.h"
+#include "gt/intel_engine.h"
+#include "gt/intel_engine_heartbeat.h"
#include "gt/intel_gpu_commands.h"
+#include "gt/intel_reset.h"
#include "gt/intel_ring.h"
#include "gt/intel_rps.h"
@@ -429,20 +432,22 @@ void __i915_request_skip(struct i915_request *rq)
rq->infix = rq->postfix;
}
-void i915_request_set_error_once(struct i915_request *rq, int error)
+bool i915_request_set_error_once(struct i915_request *rq, int error)
{
int old;
GEM_BUG_ON(!IS_ERR_VALUE((long)error));
if (i915_request_signaled(rq))
- return;
+ return false;
old = READ_ONCE(rq->fence.error);
do {
if (fatal_error(old))
- return;
+ return false;
} while (!try_cmpxchg(>fence.error, , error));
+
+ return true;
}
struct i915_request *i915_request_mark_eio(struct i915_request *rq)
@@ -609,6 +614,47 @@ void i915_request_unsubmit(struct i915_request *request)
spin_unlock_irqrestore(>lock, flags);
}
+static struct intel_engine_cs *active_engine(struct i915_request *rq)
+{
+ struct intel_engine_cs *engine, *locked;
+
+ locked = READ_ONCE(rq->engine);
+ spin_lock_irq(>sched.lock);
+ while (unlikely(locked != (engine = READ_ONCE(rq->engine {
+ spin_unlock(>sched.lock);
+ locked = engine;
+ spin_lock(>sched.lock);
+ }
+
+ engine = NULL;
+ if (i915_request_is_active(rq) && !__i915_request_is_complete(rq))
+ engine = locked;
+
+ spin_unlock_irq(>sched.lock);
+
+ return engine;
+}
+
+static void __cancel_request(struct i915_request *rq)
+{
+ struct intel_engine_cs *engine = active_engine(rq);
+
+ if (engine && intel_engine_pulse(engine))
+ intel_gt_handle_error(engine->gt, engine->mask, 0,
+ "request
[PATCH v3 0/6] Default request/fence expiry + watchdog
From: Tvrtko Ursulin "Watchdog" aka "restoring hangcheck" aka default request/fence expiry - second post of a somewhat controversial feature, now upgraded to patch status. I quote the "watchdog" becuase in classical sense watchdog would allow userspace to ping it and so remain alive. I quote "restoring hangcheck" because this series, contrary to the old hangcheck, is not looking at whether the workload is making any progress from the kernel side either. (Although disclaimer my memory may be leaky - Daniel suspects old hangcheck had some stricter, more indiscriminatory, angles to it. But apart from being prone to both false negatives and false positives I can't remember that myself.) Short version - ask is to fail any user submissions after a set time period. In this RFC that time is twelve seconds. Time counts from the moment user submission is "runnable" (implicit and explicit dependencies have been cleared) and keeps counting regardless of the GPU contetion caused by other users of the system. So semantics are really a bit weak, but again, I understand this is really really wanted by the DRM core even if I am not convinced it is a good idea. There are some dangers with doing this - text borrowed from a patch in the series: This can have an effect that workloads which used to work fine will suddenly start failing. Even workloads comprised of short batches but in long dependency chains can be terminated. And becuase of lack of agreement on usefulness and safety of fence error propagation this partial execution can be invisible to userspace even if it is "listening" to returned fence status. Another interaction is with hangcheck where care needs to be taken timeout is not set lower or close to three times the heartbeat interval. Otherwise a hang in any application can cause complete termination of all submissions from unrelated clients. Any users modifying the per engine heartbeat intervals therefore need to be aware of this potential denial of service to avoid inadvertently enabling it. Given all this I am personally not convinced the scheme is a good idea. Intuitively it feels object importers would be better positioned to enforce the time they are willing to wait for something to complete. v2: * Dropped context param. * Improved commit messages and Kconfig text. v3: * Log timeouts. * Bump timeout to 20s to see if it helps Tigerlake. * Fix sentinel assert. Test-with: 20210318162400.2065097-1-tvrtko.ursu...@linux.intel.com Cc: Daniel Vetter https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915/dpcd_bl: Don't try vesa interface unless specified by VBT
Looks like that there actually are another subset of laptops on the market
that don't support the Intel HDR backlight interface, but do advertise
support for the VESA DPCD backlight interface despite the fact it doesn't
seem to work.
Note though I'm not entirely clear on this - on one of the machines where
this issue was observed, I also noticed that we appeared to be rejecting
the VBT defined backlight frequency in
intel_dp_aux_vesa_calc_max_backlight(). It's noted in this function that:
/* Use highest possible value of Pn for more granularity of brightness
* adjustment while satifying the conditions below.
* ...
* - FxP is within 25% of desired value.
* Note: 25% is arbitrary value and may need some tweak.
*/
So it's possible that this value might just need to be tweaked, but for now
let's just disable the VESA backlight interface unless it's specified in
the VBT just to be safe. We might be able to try enabling this again by
default in the future.
Fixes: 2227816e647a ("drm/i915/dp: Allow forcing specific interfaces through
enable_dpcd_backlight")
Cc: Jani Nikula
Cc: Rodrigo Vivi
Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/3169
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 651884390137..4f8337c7fd2e 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -646,7 +646,6 @@ int intel_dp_aux_init_backlight_funcs(struct
intel_connector *connector)
break;
case INTEL_BACKLIGHT_DISPLAY_DDI:
try_intel_interface = true;
- try_vesa_interface = true;
break;
default:
return -ENODEV;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 212333] Bisected: 5.11.7 breaks amdgpu resume from S3
https://bugzilla.kernel.org/show_bug.cgi?id=212333 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #3 from Alex Deucher (alexdeuc...@gmail.com) --- See this page for more info on getting S0ix working: https://gitlab.freedesktop.org/drm/amd/-/issues/1230 -- You may reply to this email to add a comment. 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 212333] Bisected: 5.11.7 breaks amdgpu resume from S3
https://bugzilla.kernel.org/show_bug.cgi?id=212333 --- Comment #2 from Timo Valtoaho (timo.valto...@gmail.com) --- Created attachment 295927 --> https://bugzilla.kernel.org/attachment.cgi?id=295927=edit lspci -- You may reply to this email to add a comment. 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 212333] Bisected: 5.11.7 breaks amdgpu resume from S3
https://bugzilla.kernel.org/show_bug.cgi?id=212333 --- Comment #1 from Timo Valtoaho (timo.valto...@gmail.com) --- Created attachment 295923 --> https://bugzilla.kernel.org/attachment.cgi?id=295923=edit git bisect log -- You may reply to this email to add a comment. 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 212333] New: Bisected: 5.11.7 breaks amdgpu resume from S3
https://bugzilla.kernel.org/show_bug.cgi?id=212333 Bug ID: 212333 Summary: Bisected: 5.11.7 breaks amdgpu resume from S3 Product: Drivers Version: 2.5 Kernel Version: 5.11.7 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: timo.valto...@gmail.com Regression: No Created attachment 295921 --> https://bugzilla.kernel.org/attachment.cgi?id=295921=edit Working kernel config with CONFIG_AMD_PMC is not set After upgrading kernel 5.11.6 => 5.11.7 my Asus Vivobook S14 (Model M433I, Ryzen 5 4500U), resume from S3 suspend is broken. Asus has disabled S3 completely, it is not shown in BIOS/UEFI at all. I have modified DSDT table which works fine providing working S3. Now, after upgrade, suspend seems to happen just fine but resume gives me scrambled screen for few seconds, then screen goes completely black and mouse cursor shows up and is fully alive.I have to do a hard reboot to get away. Bisecting led to this: # first bad commit: [084b4f3304f923e39e64216a818a8bbf398dd896] drm/amdgpu: fix S0ix handling when the CONFIG_AMD_PMC=m When I change "CONFIG_AMD_PMC is not set" all is working again. CONFIG_AMD_PMC=y also breaks resume. All of this applies also to 5.12-rc3 which I tested too. Also, removing modified DSDT and using S2idle instead of deep, is broken too. It has never worked on this laptop. Now s2idle suspends, but resume scrambles screen for few seconds, then it works fine on first round. Suspending second time will end up on black screen on resume and I have to hard reboot. OS is Kubuntu 20.10 and firmware is the latest (linux-firmware package v1.195) taken from next release. -- You may reply to this email to add a comment. 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 v3] drm/scheduler re-insert Bailing job to avoid memleak
On 2021-03-18 6:41 a.m., Zhang, Jack (Jian) wrote:
[AMD Official Use Only - Internal Distribution Only]
Hi, Andrey
Let me summarize the background of this patch:
In TDR resubmit step “amdgpu_device_recheck_guilty_jobs,
It will submit first jobs of each ring and do guilty job re-check.
At that point, We had to make sure each job is in the mirror list(or
re-inserted back already).
But we found the current code never re-insert the job to mirror list
in the 2^nd , 3^rd job_timeout thread(Bailing TDR thread).
This not only will cause memleak of the bailing jobs. What’s more
important, the 1^st tdr thread can never iterate the bailing job and
set its guilty status to a correct status.
Therefore, we had to re-insert the job(or even not delete node) for
bailing job.
For the above V3 patch, the racing condition in my mind is:
we cannot make sure all bailing jobs are finished before we do
amdgpu_device_recheck_guilty_jobs.
Yes,that race i missed - so you say that for 2nd, baling thread who
extracted the job, even if he reinsert it right away back after driver
callback return DRM_GPU_SCHED_STAT_BAILING, there is small time slot
where the job is not in mirror list and so the 1st TDR might miss it and
not find that 2nd job is the actual guilty job, right ? But, still this
job will get back into mirror list, and since it's really the bad job,
it will never signal completion and so on the next timeout cycle it will
be caught (of course there is a starvation scenario here if more TDRs
kick in and it bails out again but this is really unlikely).
Based on this insight, I think we have two options to solve this issue:
1. Skip delete node in tdr thread2, thread3, 4 … (using mutex or
atomic variable)
2. Re-insert back bailing job, and meanwhile use semaphore in each
tdr thread to keep the sequence as expected and ensure each job is
in the mirror list when do resubmit step.
For Option1, logic is simpler and we need only one global atomic variable:
What do you think about this plan?
Option1 should look like the following logic:
+static atomic_t in_reset; //a global atomic var for synchronization
static void drm_sched_process_job(struct dma_fence *f, struct
dma_fence_cb *cb);
/**
@@ -295,6 +296,12 @@ static void drm_sched_job_timedout(struct
work_struct *work)
* drm_sched_cleanup_jobs. It will be reinserted back
after sched->thread
* is parked at which point it's safe.
*/
+ if (atomic_cmpxchg(_reset, 0, 1) != 0) { //skip
delete node if it’s thead1,2,3,….
+ spin_unlock(>job_list_lock);
+ drm_sched_start_timeout(sched);
+ return;
+ }
+
list_del_init(>node);
spin_unlock(>job_list_lock);
@@ -320,6 +327,7 @@ static void drm_sched_job_timedout(struct
work_struct *work)
spin_lock(>job_list_lock);
drm_sched_start_timeout(sched);
spin_unlock(>job_list_lock);
+ atomic_set(_reset, 0); //reset in_reset when the first
thread finished tdr
}
Technically looks like it should work as you don't access the job
pointer any longer and so no risk that if signaled it will be freed by
drm_sched_get_cleanup_job but,you can't just use one global variable an
by this bailing from TDR when different drivers run their TDR threads in
parallel, and even for amdgpu, if devices in different XGMI hives or 2
independent devices in non XGMI setup. There should be defined some kind
of GPU reset group structure on drm_scheduler level for which this
variable would be used.
P.S I wonder why we can't just ref-count the job so that even if
drm_sched_get_cleanup_job would delete it before we had a chance to stop
the scheduler thread, we wouldn't crash. This would avoid all the dance
with deletion and reinsertion.
Andrey
Thanks,
Jack
*From:* amd-gfx *On Behalf Of
*Zhang, Jack (Jian)
*Sent:* Wednesday, March 17, 2021 11:11 PM
*To:* Christian König ;
dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org;
Koenig, Christian ; Liu, Monk
; Deng, Emily ; Rob Herring
; Tomeu Vizoso ; Steven
Price ; Grodzovsky, Andrey
*Subject:* Re: [PATCH v3] drm/scheduler re-insert Bailing job to avoid
memleak
[AMD Official Use Only - Internal Distribution Only]
[AMD Official Use Only - Internal Distribution Only]
Hi，Andrey，
Good catch，I will expore this corner case and give feedback soon～
Best，
Jack
*From:*Grodzovsky, Andrey >
*Sent:* Wednesday, March 17, 2021 10:50:59 PM
*To:* Christian König >; Zhang, Jack (Jian)
mailto:jack.zha...@amd.com>>;
dri-devel@lists.freedesktop.org
>;
amd-...@lists.freedesktop.org
>; Koenig, Christian
[PATCH 1/3] drm/vc4: plane: Fix typo in scaler width and height
The vc4_plane_mode_set function still accesses the scaler target width
and height using the older register layout while it was updated with the
BCM2711, and the proper defines got introduced when we started to
support it.
Fixes: c54619b0bfb3 ("drm/vc4: Add support for the BCM2711 HVS5")
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_plane.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index eb37d7f8a118..3fdc32244b59 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -912,9 +912,9 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
if (!vc4_state->is_unity) {
vc4_dlist_write(vc4_state,
VC4_SET_FIELD(vc4_state->crtc_w,
- SCALER_POS1_SCL_WIDTH) |
+ SCALER5_POS1_SCL_WIDTH) |
VC4_SET_FIELD(vc4_state->crtc_h,
- SCALER_POS1_SCL_HEIGHT));
+ SCALER5_POS1_SCL_HEIGHT));
}
/* Position Word 2: Source Image Size */
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/vc4: crtc: Reduce PV fifo threshold on hvs4
From: Dom Cobley
Experimentally have found PV on hvs4 reports fifo full
error with expected settings and does not with one less
This appears as:
[drm:drm_atomic_helper_wait_for_flip_done] *ERROR* [CRTC:82:crtc-3] flip_done
timed out
with bit 10 of PV_STAT set "HVS driving pixels when the PV FIFO is full"
Fixes: c8b75bca92cb ("drm/vc4: Add KMS support for Raspberry Pi.")
Signed-off-by: Dom Cobley
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 269390bc586e..76657dcdf9b0 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -210,6 +210,7 @@ static u32 vc4_get_fifo_full_level(struct vc4_crtc
*vc4_crtc, u32 format)
{
const struct vc4_crtc_data *crtc_data =
vc4_crtc_to_vc4_crtc_data(vc4_crtc);
const struct vc4_pv_data *pv_data = vc4_crtc_to_vc4_pv_data(vc4_crtc);
+ struct vc4_dev *vc4 = to_vc4_dev(vc4_crtc->base.dev);
u32 fifo_len_bytes = pv_data->fifo_depth;
/*
@@ -238,6 +239,22 @@ static u32 vc4_get_fifo_full_level(struct vc4_crtc
*vc4_crtc, u32 format)
if (crtc_data->hvs_output == 5)
return 32;
+ /*
+* It looks like in some situations, we will overflow
+* the PixelValve FIFO (with the bit 10 of PV stat being
+* set) and stall the HVS / PV, eventually resulting in
+* a page flip timeout.
+*
+* Displaying the video overlay during a playback with
+* Kodi on an RPi3 seems to be a great solution with a
+* failure rate around 50%.
+*
+* Removing 1 from the FIFO full level however
+* seems to completely remove that issue.
+*/
+ if (!vc4->hvs->hvs5)
+ return fifo_len_bytes - 3 * HVS_FIFO_LATENCY_PIX - 1;
+
return fifo_len_bytes - 3 * HVS_FIFO_LATENCY_PIX;
}
}
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/vc4: plane: Remove redundant assignment
The vc4_plane_atomic_async_update function assigns twice in a row the src_h field in the drm_plane_state structure to the same value. Remove the second one. Reviewed-by: Dave Stevenson Signed-off-by: Maxime Ripard --- drivers/gpu/drm/vc4/vc4_plane.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c index 3fdc32244b59..0ad1862c5ad8 100644 --- a/drivers/gpu/drm/vc4/vc4_plane.c +++ b/drivers/gpu/drm/vc4/vc4_plane.c @@ -1135,7 +1135,6 @@ static void vc4_plane_atomic_async_update(struct drm_plane *plane, plane->state->src_y = new_plane_state->src_y; plane->state->src_w = new_plane_state->src_w; plane->state->src_h = new_plane_state->src_h; - plane->state->src_h = new_plane_state->src_h; plane->state->alpha = new_plane_state->alpha; plane->state->pixel_blend_mode = new_plane_state->pixel_blend_mode; plane->state->rotation = new_plane_state->rotation; -- 2.30.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/dp_mst: Enhance DP MST topology logging
[why]
MST topology print was missing fec logging and pdt printed
as an int wasn't clear. vcpi and payload info were also logged as an
arbitrary series of ints which require the user to know the ordering
of the prints, making the logs difficult to use.
[how]
-add fec logging
-add pdt parsing into strings
-format vcpi and payload info into tables with headings
-clean up topology prints
Signed-off-by: Eryk Brol
---
drivers/gpu/drm/drm_dp_mst_topology.c | 67 ---
1 file changed, 51 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 932c4641ec3e..3afeaa59cbaa 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -4720,6 +4720,24 @@ static void drm_dp_mst_kick_tx(struct
drm_dp_mst_topology_mgr *mgr)
queue_work(system_long_wq, >tx_work);
}
+static char *pdt_to_string(u8 pdt)
+{
+ switch (pdt) {
+ case DP_PEER_DEVICE_NONE:
+ return "NONE";
+ case DP_PEER_DEVICE_SOURCE_OR_SST:
+ return "SOURCE OR SST";
+ case DP_PEER_DEVICE_MST_BRANCHING:
+ return "MST BRANCHING";
+ case DP_PEER_DEVICE_SST_SINK:
+ return "SST SINK";
+ case DP_PEER_DEVICE_DP_LEGACY_CONV:
+ return "DP LEGACY CONV";
+ default:
+ return "ERR";
+ }
+}
+
static void drm_dp_mst_dump_mstb(struct seq_file *m,
struct drm_dp_mst_branch *mstb)
{
@@ -4732,9 +4750,20 @@ static void drm_dp_mst_dump_mstb(struct seq_file *m,
prefix[i] = '\t';
prefix[i] = '\0';
- seq_printf(m, "%smst: %p, %d\n", prefix, mstb, mstb->num_ports);
+ seq_printf(m, "%smstb - [%p]: num_ports: %d\n", prefix, mstb,
mstb->num_ports);
list_for_each_entry(port, >ports, next) {
- seq_printf(m, "%sport: %d: input: %d: pdt: %d, ddps: %d ldps:
%d, sdp: %d/%d, %p, conn: %p\n", prefix, port->port_num, port->input,
port->pdt, port->ddps, port->ldps, port->num_sdp_streams,
port->num_sdp_stream_sinks, port, port->connector);
+ seq_printf(m, "%sport %d - [%p] (%s - %s): ddps: %d, ldps: %d,
sdp: %d/%d, fec: %s, conn: %p\n",
+ prefix,
+ port->port_num,
+ port,
+ port->input ? "input" : "output",
+ pdt_to_string(port->pdt),
+ port->ddps,
+ port->ldps,
+ port->num_sdp_streams,
+ port->num_sdp_stream_sinks,
+ port->fec_capable ? "true" : "false",
+ port->connector);
if (port->mstb)
drm_dp_mst_dump_mstb(m, port->mstb);
}
@@ -4787,33 +4816,39 @@ void drm_dp_mst_dump_topology(struct seq_file *m,
mutex_unlock(>lock);
mutex_lock(>payload_lock);
- seq_printf(m, "vcpi: %lx %lx %d\n", mgr->payload_mask, mgr->vcpi_mask,
- mgr->max_payloads);
+ seq_printf(m, "\n *** VCPI Info ***\npayload_mask: %lx, vcpi_mask: %lx,
max_payloads: %d\n",
+ mgr->payload_mask,
+ mgr->vcpi_mask,
+ mgr->max_payloads);
+ seq_printf(m, "\n| idx | port # | vcp_id | # slots | sink
name |\n");
for (i = 0; i < mgr->max_payloads; i++) {
if (mgr->proposed_vcpis[i]) {
char name[14];
port = container_of(mgr->proposed_vcpis[i], struct
drm_dp_mst_port, vcpi);
fetch_monitor_name(mgr, port, name, sizeof(name));
- seq_printf(m, "vcpi %d: %d %d %d sink name: %s\n", i,
- port->port_num, port->vcpi.vcpi,
- port->vcpi.num_slots,
- (*name != 0) ? name : "Unknown");
+ seq_printf(m, "%10d%10d%10d%10d%20s\n",
+ i,
+ port->port_num,
+ port->vcpi.vcpi,
+ port->vcpi.num_slots,
+ (*name != 0) ? name : "Unknown");
} else
- seq_printf(m, "vcpi %d:unused\n", i);
+ seq_printf(m, "%6d - Unused\n", i);
}
+ seq_printf(m, "\n *** Payload Info ***\n");
+ seq_printf(m, "| idx | state | start slot | # slots |\n");
for (i = 0; i < mgr->max_payloads; i++) {
- seq_printf(m, "payload %d: %d, %d, %d\n",
- i,
- mgr->payloads[i].payload_state,
- mgr->payloads[i].start_slot,
Re: [PULL] drm-misc-fixes
Op 18-03-2021 om 13:31 schreef Daniel Vetter: > On Thu, Mar 18, 2021 at 12:33 PM Maarten Lankhorst > wrote: >> drm-misc-fixes-2021-03-18: >> drm-misc-fixes for v5.12-rc4: >> - Make ttm_bo_unpin() not wraparound on too many unpins. >> - Fix coccicheck warning in omap. > Still missing the 2 patches from drm-misc-next-fixes, and those being > left out also means drm-misc-next isn't pushed to for-linux-next > branch, which is causing a ton of confusion itself. > -Daniel We had a discussion on irc, those patches were part of the previous pull. I've reset drm-misc-next-fixes to v5.12-rc1-dontuse, to unplug drm-misc-next. >> The following changes since commit de066e116306baf3a6a62691ac63cfc0b1dabddb: >> >> drm/compat: Clear bounce structures (2021-03-11 11:11:33 +0100) >> >> are available in the Git repository at: >> >> git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2021-03-18 >> >> for you to fetch changes up to 6909115442759efef3d4bc5d9c54d7943f1afc14: >> >> drm/omap: dsi: fix unsigned expression compared with zero (2021-03-17 >> 13:59:23 +0200) >> >> >> drm-misc-fixes for v5.12-rc4: >> - Make ttm_bo_unpin() not wraparound on too many unpins. >> - Fix coccicheck warning in omap. >> >> >> Christian König (1): >> drm/ttm: make ttm_bo_unpin more defensive >> >> Junlin Yang (1): >> drm/omap: dsi: fix unsigned expression compared with zero >> >> drivers/gpu/drm/omapdrm/dss/dsi.c | 7 --- >> include/drm/ttm/ttm_bo_api.h | 6 -- >> 2 files changed, 8 insertions(+), 5 deletions(-) > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/ttm: move swapout logic around v2
Am 18.03.21 um 15:43 schrieb Nirmoy:
Hi Christian,
On 3/18/21 1:47 PM, Christian König wrote:
/**
* ttm_bo_uses_embedded_gem_object - check if the given bo uses the
diff --git a/include/drm/ttm/ttm_device.h b/include/drm/ttm/ttm_device.h
index 035bbc044a3b..6a0b267d4fe6 100644
--- a/include/drm/ttm/ttm_device.h
+++ b/include/drm/ttm/ttm_device.h
@@ -297,6 +297,8 @@ struct ttm_device {
struct delayed_work wq;
};
+long ttm_global_swapout(struct ttm_operation_ctx *ctx, gfp_t
gfp_flags);
There is a typo here, long -> int.
Ah, yes. I missed to add the change to the header file.
Thanks for pointing that out,
Christian.
Thanks,
Nirmoy
+
static inline struct ttm_resource_manager *
ttm_manager_type(struct ttm_device *bdev, int mem_type)
{
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/ttm: move swapout logic around v2
Hi "Christian,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
[also build test ERROR on next-20210318]
[cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next linus/master drm/drm-next v5.12-rc3]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Christian-K-nig/drm-ttm-move-swapout-logic-around-v2/20210318-204848
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: i386-randconfig-m021-20210318 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
#
https://github.com/0day-ci/linux/commit/a454d56ea061b53d24a62a700743e4508dd6c9b1
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Christian-K-nig/drm-ttm-move-swapout-logic-around-v2/20210318-204848
git checkout a454d56ea061b53d24a62a700743e4508dd6c9b1
# save the attached .config to linux build tree
make W=1 ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> drivers/gpu/drm/ttm/ttm_device.c:109:5: error: conflicting types for
>> 'ttm_global_swapout'
109 | int ttm_global_swapout(struct ttm_operation_ctx *ctx, gfp_t
gfp_flags)
| ^~
In file included from drivers/gpu/drm/ttm/ttm_device.c:32:
include/drm/ttm/ttm_device.h:300:6: note: previous declaration of
'ttm_global_swapout' was here
300 | long ttm_global_swapout(struct ttm_operation_ctx *ctx, gfp_t
gfp_flags);
| ^~
In file included from include/linux/linkage.h:7,
from include/linux/kernel.h:7,
from include/asm-generic/bug.h:20,
from arch/x86/include/asm/bug.h:93,
from include/linux/bug.h:5,
from include/linux/mmdebug.h:5,
from include/linux/mm.h:9,
from drivers/gpu/drm/ttm/ttm_device.c:30:
drivers/gpu/drm/ttm/ttm_device.c:132:15: error: conflicting types for
'ttm_global_swapout'
132 | EXPORT_SYMBOL(ttm_global_swapout);
| ^~
include/linux/export.h:98:21: note: in definition of macro '___EXPORT_SYMBOL'
98 | extern typeof(sym) sym; \
| ^~~
include/linux/export.h:155:34: note: in expansion of macro '__EXPORT_SYMBOL'
155 | #define _EXPORT_SYMBOL(sym, sec) __EXPORT_SYMBOL(sym, sec, "")
| ^~~
include/linux/export.h:158:29: note: in expansion of macro '_EXPORT_SYMBOL'
158 | #define EXPORT_SYMBOL(sym) _EXPORT_SYMBOL(sym, "")
| ^~
drivers/gpu/drm/ttm/ttm_device.c:132:1: note: in expansion of macro
'EXPORT_SYMBOL'
132 | EXPORT_SYMBOL(ttm_global_swapout);
| ^
In file included from drivers/gpu/drm/ttm/ttm_device.c:32:
include/drm/ttm/ttm_device.h:300:6: note: previous declaration of
'ttm_global_swapout' was here
300 | long ttm_global_swapout(struct ttm_operation_ctx *ctx, gfp_t
gfp_flags);
| ^~
vim +/ttm_global_swapout +109 drivers/gpu/drm/ttm/ttm_device.c
104
105 /**
106 * A buffer object shrink method that tries to swap out the first
107 * buffer object on the global::swap_lru list.
108 */
> 109 int ttm_global_swapout(struct ttm_operation_ctx *ctx, gfp_t gfp_flags)
110 {
111 struct ttm_global *glob = _glob;
112 struct ttm_buffer_object *bo;
113 unsigned i;
114 int ret;
115
116 spin_lock(>lru_lock);
117 for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
118 list_for_each_entry(bo, >swap_lru[i], swap) {
119 uint32_t num_pages = bo->ttm->num_pages;
120
121 ret = ttm_bo_swapout(bo, ctx, gfp_flags);
122 /* ttm_bo_swapout has dropped the lru_lock */
123 if (!ret)
124 return num_pages;
125 if (ret != -EBUSY)
126 return ret;
127 }
128 }
129 spin_unlock(>lru_lock);
130 return 0;
131 }
132 EXPORT_SYMBOL(ttm_global_swapout);
133
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-d
[Bug 212281] AMDGPU warning stack trace in dmesg (dcn20_validate_bandwidth_fp)
https://bugzilla.kernel.org/show_bug.cgi?id=212281 --- Comment #3 from Tomas Sandven (tomas@sandven.email) --- (In reply to Alex Deucher from comment #1) > Please attach your full dmesg output and xorg log (if using X). I added full dmesg output. I have rebooted since the first error, so the two stack traces you see in the dmesg output now are unrelated to the issue I had the first time, but the look the same. I haven't noticed any negative consequences of the errors. -- You may reply to this email to add a comment. 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 212281] AMDGPU warning stack trace in dmesg (dcn20_validate_bandwidth_fp)
https://bugzilla.kernel.org/show_bug.cgi?id=212281 --- Comment #2 from Tomas Sandven (tomas@sandven.email) --- Created attachment 295919 --> https://bugzilla.kernel.org/attachment.cgi?id=295919=edit Full dmesg output -- You may reply to this email to add a comment. 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 1/3] drm/ttm: move swapout logic around v2
Hi Christian,
On 3/18/21 1:47 PM, Christian König wrote:
/**
* ttm_bo_uses_embedded_gem_object - check if the given bo uses the
diff --git a/include/drm/ttm/ttm_device.h b/include/drm/ttm/ttm_device.h
index 035bbc044a3b..6a0b267d4fe6 100644
--- a/include/drm/ttm/ttm_device.h
+++ b/include/drm/ttm/ttm_device.h
@@ -297,6 +297,8 @@ struct ttm_device {
struct delayed_work wq;
};
+long ttm_global_swapout(struct ttm_operation_ctx *ctx, gfp_t gfp_flags);
There is a typo here, long -> int.
Thanks,
Nirmoy
+
static inline struct ttm_resource_manager *
ttm_manager_type(struct ttm_device *bdev, int mem_type)
{
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 212137] kernel NULL pointer dereference, black screen when using two graphics cards
https://bugzilla.kernel.org/show_bug.cgi?id=212137 Dennis Foster (m...@dennisfoster.us) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |CODE_FIX --- Comment #4 from Dennis Foster (m...@dennisfoster.us) --- I can confirm now that the issue is fixed in recent 5.11.7 kernel. -- You may reply to this email to add a comment. 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] drm: Few typo fixes
On Thu, 2021-03-18 at 16:07 +0530, Bhaskar Chowdhury wrote: > s/instatiated/instantiated/ > s/unreference/unreferenced/ []> diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c [] > @@ -644,7 +644,7 @@ EXPORT_SYMBOL(drm_property_blob_get); > * @id: id of the blob property > * > * If successful, this takes an additional reference to the blob property. > - * callers need to make sure to eventually unreference the returned property > + * callers need to make sure to eventually unreferenced the returned property I think this is worse. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 212327] i915 / Kernel Mode Setting - Distorts Screen
https://bugzilla.kernel.org/show_bug.cgi?id=212327 --- Comment #1 from RK (ros...@rkarim.xyz) --- Created attachment 295915 --> https://bugzilla.kernel.org/attachment.cgi?id=295915=edit image of screen issue -- You may reply to this email to add a comment. 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 212327] New: i915 / Kernel Mode Setting - Distorts Screen
https://bugzilla.kernel.org/show_bug.cgi?id=212327 Bug ID: 212327 Summary: i915 / Kernel Mode Setting - Distorts Screen Product: Drivers Version: 2.5 Kernel Version: 5.12.0-rc3 Hardware: Intel OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: ros...@rkarim.xyz Regression: No Created attachment 295913 --> https://bugzilla.kernel.org/attachment.cgi?id=295913=edit dmesg output Hello, I have this problem seemingly with the i915 driver. When kernel mode setting is active, only half of my screen attempts to display all of the pixels, with the other half turning all various shades of colours, but not working. Will attach an image below. Not totally sure what information to provide for this, so I've provided my dmesg output. Thanks, RK -- You may reply to this email to add a comment. 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: [Intel-gfx] [PATCH 3/5] drm/i915: Disable pread/pwrite ioctl's for future platforms (v3)
On Wed, Mar 17, 2021 at 06:40:12PM -0500, Jason Ekstrand wrote:
> From: Ashutosh Dixit
>
> The rationale for this change is roughly as follows:
>
> 1. The functionality can be done entirely in userspace with a
> combination of mmap + memcpy
>
> 2. The only reason anyone in userspace is still using it is because
> someone implemented bo_subdata that way in libdrm ages ago and
> they're all too lazy to write the 5 lines of code to do a map.
>
> 3. This falls cleanly into the category of things which will only get
> more painful with local memory support.
>
> These ioctls aren't used much anymore by "real" userspace drivers.
> Vulkan has never used them and neither has the iris GL driver. The old
> i965 GL driver does use PWRITE for glBufferSubData but it only supports
> up through Gen11; Gen12 was never enabled in i965. The compute driver
> has never used PREAD/PWRITE. The only remaining user is the media
> driver which uses it exactly twice and they're easily removed [1] so
> expecting them to drop it going forward is reasonable.
>
> IGT changes which handle this kernel change have also been submitted [2].
>
> [1] https://github.com/intel/media-driver/pull/1160
> [2] https://patchwork.freedesktop.org/series/81384/
>
> v2 (Jason Ekstrand):
> - Improved commit message with the status of all usermode drivers
> - A more future-proof platform check
>
> v3 (Jason Ekstrand):
> - Drop the HAS_LMEM checks as they're already covered by the version
>checks
>
> Signed-off-by: Ashutosh Dixit
> Signed-off-by: Jason Ekstrand
> Reviewed-by: Jason Ekstrand
Merged the first three here. For the scheduler/context stuff I think we
should go back to normal due process with kernel patch + igt patches
tested together, then land igt first, then kernel, just to avoid hiccups
in CI.
Thanks, Daniel
> ---
> drivers/gpu/drm/i915/i915_gem.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index b2e3b5cfccb4a..80915467e0d84 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -374,10 +374,17 @@ int
> i915_gem_pread_ioctl(struct drm_device *dev, void *data,
>struct drm_file *file)
> {
> + struct drm_i915_private *i915 = to_i915(dev);
> struct drm_i915_gem_pread *args = data;
> struct drm_i915_gem_object *obj;
> int ret;
>
> + /* PREAD is disallowed for all platforms after TGL-LP. This also
> + * covers all platforms with local memory.
> + */
> + if (INTEL_GEN(i915) >= 12 && !IS_TIGERLAKE(i915))
> + return -EOPNOTSUPP;
> +
> if (args->size == 0)
> return 0;
>
> @@ -675,10 +682,17 @@ int
> i915_gem_pwrite_ioctl(struct drm_device *dev, void *data,
> struct drm_file *file)
> {
> + struct drm_i915_private *i915 = to_i915(dev);
> struct drm_i915_gem_pwrite *args = data;
> struct drm_i915_gem_object *obj;
> int ret;
>
> + /* PWRITE is disallowed for all platforms after TGL-LP. This also
> + * covers all platforms with local memory.
> + */
> + if (INTEL_GEN(i915) >= 12 && !IS_TIGERLAKE(i915))
> + return -EOPNOTSUPP;
> +
> if (args->size == 0)
> return 0;
>
> --
> 2.29.2
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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
Re: [PATCH] drm: Few typo fixes
On Thu, Mar 18, 2021 at 04:07:39PM +0530, Bhaskar Chowdhury wrote: > > s/instatiated/instantiated/ > s/unreference/unreferenced/ > > Signed-off-by: Bhaskar Chowdhury Queued for 5.13 in drm-misc-next, thanks for your patch. -Daniel > --- > drivers/gpu/drm/drm_property.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c > index 6ee04803c362..27c824a6eb60 100644 > --- a/drivers/gpu/drm/drm_property.c > +++ b/drivers/gpu/drm/drm_property.c > @@ -43,7 +43,7 @@ > * property types and ranges. > * > * Properties don't store the current value directly, but need to be > - * instatiated by attaching them to a _mode_object with > + * instantiated by attaching them to a _mode_object with > * drm_object_attach_property(). > * > * Property values are only 64bit. To support bigger piles of data (like > gamma > @@ -644,7 +644,7 @@ EXPORT_SYMBOL(drm_property_blob_get); > * @id: id of the blob property > * > * If successful, this takes an additional reference to the blob property. > - * callers need to make sure to eventually unreference the returned property > + * callers need to make sure to eventually unreferenced the returned property > * again, using drm_property_blob_put(). > * > * Return: > -- > 2.26.2 > -- 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
Re: [RESEND 00/53] Rid GPU from W=1 warnings
On Wed, Mar 17, 2021 at 9:32 PM Daniel Vetter wrote: > > On Wed, Mar 17, 2021 at 9:17 AM Lee Jones wrote: > > > > On Thu, 11 Mar 2021, Lee Jones wrote: > > > > > On Thu, 11 Mar 2021, Daniel Vetter wrote: > > > > > > > On Mon, Mar 08, 2021 at 09:19:32AM +, Lee Jones wrote: > > > > > On Fri, 05 Mar 2021, Roland Scheidegger wrote: > > > > > > > > > > > The vmwgfx ones look all good to me, so for > > > > > > 23-53: Reviewed-by: Roland Scheidegger > > > > > > That said, they were already signed off by Zack, so not sure what > > > > > > happened here. > > > > > > > > > > Yes, they were accepted at one point, then dropped without a reason. > > > > > > > > > > Since I rebased onto the latest -next, I had to pluck them back out of > > > > > a previous one. > > > > > > > > They should show up in linux-next again. We merge patches for next merge > > > > window even during the current merge window, but need to make sure they > > > > don't pollute linux-next. Occasionally the cut off is wrong so patches > > > > show up, and then get pulled again. > > > > > > > > Unfortunately especially the 5.12 merge cycle was very wobbly due to > > > > some > > > > confusion here. But your patches should all be in linux-next again (they > > > > are queued up for 5.13 in drm-misc-next, I checked that). > > > > > > > > Sorry for the confusion here. > > > > > > Oh, I see. Well so long as they don't get dropped, I'll be happy. > > > > > > Thanks for the explanation Daniel > > > > After rebasing today, all of my GPU patches have remained. Would > > someone be kind enough to check that everything is still in order > > please? > > It's still broken somehow. I've kiced Maxime and Maarten again, > they're also on this thread. You're patches have made it into drm-next meanwhile, so they should show up in linux-next through that tree at least. Except if that one also has some trouble. -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
Re: [PATCH 1/3] dma-buf: add dma_fence_array_for_each (v2)
On Thu, Mar 18, 2021 at 10:38:11AM +0100, Christian König wrote:
> Am 17.03.21 um 23:19 schrieb Jason Ekstrand:
> > From: Christian König
> >
> > Add a helper to iterate over all fences in a dma_fence_array object.
> >
> > v2 (Jason Ekstrand)
> > - Return NULL from dma_fence_array_first if head == NULL. This matches
> > the iterator behavior of dma_fence_chain_for_each in that it iterates
> > zero times if head == NULL.
> > - Return NULL from dma_fence_array_next if index > array->num_fences.
>
> Is there any reason you send this patch alone out once more?
>
> I don't see any changes compared to the last version.
Last patch has changed. Also I think mail delivery is a bit wobbly right
now.
-Daniel
>
> Christian.
>
> >
> > Signed-off-by: Jason Ekstrand
> > ---
> > drivers/dma-buf/dma-fence-array.c | 27 +++
> > include/linux/dma-fence-array.h | 17 +
> > 2 files changed, 44 insertions(+)
> >
> > diff --git a/drivers/dma-buf/dma-fence-array.c
> > b/drivers/dma-buf/dma-fence-array.c
> > index d3fbd950be944..2ac1afc697d0f 100644
> > --- a/drivers/dma-buf/dma-fence-array.c
> > +++ b/drivers/dma-buf/dma-fence-array.c
> > @@ -201,3 +201,30 @@ bool dma_fence_match_context(struct dma_fence *fence,
> > u64 context)
> > return true;
> > }
> > EXPORT_SYMBOL(dma_fence_match_context);
> > +
> > +struct dma_fence *dma_fence_array_first(struct dma_fence *head)
> > +{
> > + struct dma_fence_array *array;
> > +
> > + if (!head)
> > + return NULL;
> > +
> > + array = to_dma_fence_array(head);
> > + if (!array)
> > + return head;
> > +
> > + return array->fences[0];
> > +}
> > +EXPORT_SYMBOL(dma_fence_array_first);
> > +
> > +struct dma_fence *dma_fence_array_next(struct dma_fence *head,
> > + unsigned int index)
> > +{
> > + struct dma_fence_array *array = to_dma_fence_array(head);
> > +
> > + if (!array || index >= array->num_fences)
> > + return NULL;
> > +
> > + return array->fences[index];
> > +}
> > +EXPORT_SYMBOL(dma_fence_array_next);
> > diff --git a/include/linux/dma-fence-array.h
> > b/include/linux/dma-fence-array.h
> > index 303dd712220fd..588ac8089dd61 100644
> > --- a/include/linux/dma-fence-array.h
> > +++ b/include/linux/dma-fence-array.h
> > @@ -74,6 +74,19 @@ to_dma_fence_array(struct dma_fence *fence)
> > return container_of(fence, struct dma_fence_array, base);
> > }
> > +/**
> > + * dma_fence_array_for_each - iterate over all fences in array
> > + * @fence: current fence
> > + * @index: index into the array
> > + * @head: potential dma_fence_array object
> > + *
> > + * Test if @array is a dma_fence_array object and if yes iterate over all
> > fences
> > + * in the array. If not just iterate over the fence in @array itself.
> > + */
> > +#define dma_fence_array_for_each(fence, index, head)
> > \
> > + for (index = 0, fence = dma_fence_array_first(head); fence; \
> > +++(index), fence = dma_fence_array_next(head, index))
> > +
> > struct dma_fence_array *dma_fence_array_create(int num_fences,
> >struct dma_fence **fences,
> >u64 context, unsigned seqno,
> > @@ -81,4 +94,8 @@ struct dma_fence_array *dma_fence_array_create(int
> > num_fences,
> > bool dma_fence_match_context(struct dma_fence *fence, u64 context);
> > +struct dma_fence *dma_fence_array_first(struct dma_fence *head);
> > +struct dma_fence *dma_fence_array_next(struct dma_fence *head,
> > + unsigned int index);
> > +
> > #endif /* __LINUX_DMA_FENCE_ARRAY_H */
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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 2/3] drm/ttm: remove swap LRU v3
Instead evict round robin from each devices SYSTEM and TT domain.
v2: reorder num_pages access reported by Dan's script
v3: fix rebase fallout, num_pages should be 32bit
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c| 29 --
drivers/gpu/drm/ttm/ttm_bo_util.c | 1 -
drivers/gpu/drm/ttm/ttm_device.c| 60 +
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
include/drm/ttm/ttm_bo_api.h| 1 -
include/drm/ttm/ttm_bo_driver.h | 1 -
include/drm/ttm/ttm_device.h| 7 +---
7 files changed, 48 insertions(+), 53 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 66e00b404ec3..3673157527ff 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -73,7 +73,6 @@ static void ttm_bo_del_from_lru(struct ttm_buffer_object *bo)
{
struct ttm_device *bdev = bo->bdev;
- list_del_init(>swap);
list_del_init(>lru);
if (bdev->funcs->del_from_lru_notify)
@@ -105,16 +104,6 @@ void ttm_bo_move_to_lru_tail(struct ttm_buffer_object *bo,
man = ttm_manager_type(bdev, mem->mem_type);
list_move_tail(>lru, >lru[bo->priority]);
- if (man->use_tt && bo->ttm &&
- !(bo->ttm->page_flags & (TTM_PAGE_FLAG_SG |
-TTM_PAGE_FLAG_SWAPPED))) {
- struct list_head *swap;
-
- swap = _glob.swap_lru[bo->priority];
- list_move_tail(>swap, swap);
- } else {
- list_del_init(>swap);
- }
if (bdev->funcs->del_from_lru_notify)
bdev->funcs->del_from_lru_notify(bo);
@@ -129,9 +118,6 @@ void ttm_bo_move_to_lru_tail(struct ttm_buffer_object *bo,
ttm_bo_bulk_move_set_pos(>vram[bo->priority], bo);
break;
}
- if (bo->ttm && !(bo->ttm->page_flags &
-(TTM_PAGE_FLAG_SG | TTM_PAGE_FLAG_SWAPPED)))
- ttm_bo_bulk_move_set_pos(>swap[bo->priority], bo);
}
}
EXPORT_SYMBOL(ttm_bo_move_to_lru_tail);
@@ -169,20 +155,6 @@ void ttm_bo_bulk_move_lru_tail(struct ttm_lru_bulk_move
*bulk)
list_bulk_move_tail(>lru[i], >first->lru,
>last->lru);
}
-
- for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
- struct ttm_lru_bulk_move_pos *pos = >swap[i];
- struct list_head *lru;
-
- if (!pos->first)
- continue;
-
- dma_resv_assert_held(pos->first->base.resv);
- dma_resv_assert_held(pos->last->base.resv);
-
- lru = _glob.swap_lru[i];
- list_bulk_move_tail(lru, >first->swap, >last->swap);
- }
}
EXPORT_SYMBOL(ttm_bo_bulk_move_lru_tail);
@@ -1065,7 +1037,6 @@ int ttm_bo_init_reserved(struct ttm_device *bdev,
kref_init(>kref);
INIT_LIST_HEAD(>lru);
INIT_LIST_HEAD(>ddestroy);
- INIT_LIST_HEAD(>swap);
bo->bdev = bdev;
bo->type = type;
bo->mem.mem_type = TTM_PL_SYSTEM;
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 031e5819fec4..a2a17c84ceb3 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -303,7 +303,6 @@ static int ttm_buffer_object_transfer(struct
ttm_buffer_object *bo,
atomic_inc(_glob.bo_count);
INIT_LIST_HEAD(>base.ddestroy);
INIT_LIST_HEAD(>base.lru);
- INIT_LIST_HEAD(>base.swap);
fbo->base.moving = NULL;
drm_vma_node_reset(>base.base.vma_node);
diff --git a/drivers/gpu/drm/ttm/ttm_device.c b/drivers/gpu/drm/ttm/ttm_device.c
index b1424189fdfb..2096a0fd9c35 100644
--- a/drivers/gpu/drm/ttm/ttm_device.c
+++ b/drivers/gpu/drm/ttm/ttm_device.c
@@ -67,7 +67,6 @@ static int ttm_global_init(void)
unsigned long num_pages;
struct sysinfo si;
int ret = 0;
- unsigned i;
mutex_lock(_global_mutex);
if (++ttm_glob_use_count > 1)
@@ -90,8 +89,6 @@ static int ttm_global_init(void)
goto out;
}
- for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i)
- INIT_LIST_HEAD(>swap_lru[i]);
INIT_LIST_HEAD(>device_list);
atomic_set(>bo_count, 0);
@@ -109,27 +106,60 @@ static int ttm_global_init(void)
int ttm_global_swapout(struct ttm_operation_ctx *ctx, gfp_t gfp_flags)
{
struct ttm_global *glob = _glob;
+ struct ttm_device *bdev;
+ int ret = -EBUSY;
+
+ mutex_lock(_global_mutex);
+ list_for_each_entry(bdev, >device_list, device_list) {
+ ret = ttm_device_swapout(bdev, ctx, gfp_flags);
+ if (ret > 0) {
+ list_move_tail(>device_list, >device_list);
+ break;
+ }
+ }
+ mutex_unlock(_global_mutex);
+ return ret;
+}
[PATCH 3/3] drm/ttm: switch to per device LRU lock
Instead of having a global lock.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 8 ++---
drivers/gpu/drm/qxl/qxl_release.c | 5 +--
drivers/gpu/drm/ttm/ttm_bo.c | 49 --
drivers/gpu/drm/ttm/ttm_device.c | 12 +++
drivers/gpu/drm/ttm/ttm_execbuf_util.c | 8 ++---
drivers/gpu/drm/ttm/ttm_resource.c | 9 +++--
include/drm/ttm/ttm_bo_driver.h| 4 +--
include/drm/ttm/ttm_device.h | 4 +--
8 files changed, 43 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 9d19078246c8..ae18c0e32347 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -638,15 +638,15 @@ void amdgpu_vm_move_to_lru_tail(struct amdgpu_device
*adev,
struct amdgpu_vm_bo_base *bo_base;
if (vm->bulk_moveable) {
- spin_lock(_glob.lru_lock);
+ spin_lock(>mman.bdev.lru_lock);
ttm_bo_bulk_move_lru_tail(>lru_bulk_move);
- spin_unlock(_glob.lru_lock);
+ spin_unlock(>mman.bdev.lru_lock);
return;
}
memset(>lru_bulk_move, 0, sizeof(vm->lru_bulk_move));
- spin_lock(_glob.lru_lock);
+ spin_lock(>mman.bdev.lru_lock);
list_for_each_entry(bo_base, >idle, vm_status) {
struct amdgpu_bo *bo = bo_base->bo;
@@ -660,7 +660,7 @@ void amdgpu_vm_move_to_lru_tail(struct amdgpu_device *adev,
>shadow->tbo.mem,
>lru_bulk_move);
}
- spin_unlock(_glob.lru_lock);
+ spin_unlock(>mman.bdev.lru_lock);
vm->bulk_moveable = true;
}
diff --git a/drivers/gpu/drm/qxl/qxl_release.c
b/drivers/gpu/drm/qxl/qxl_release.c
index f5845c96d414..b19f2f00b215 100644
--- a/drivers/gpu/drm/qxl/qxl_release.c
+++ b/drivers/gpu/drm/qxl/qxl_release.c
@@ -426,16 +426,13 @@ void qxl_release_fence_buffer_objects(struct qxl_release
*release)
release->id | 0xf000, release->base.seqno);
trace_dma_fence_emit(>base);
- spin_lock(_glob.lru_lock);
-
list_for_each_entry(entry, >bos, head) {
bo = entry->bo;
dma_resv_add_shared_fence(bo->base.resv, >base);
- ttm_bo_move_to_lru_tail(bo, >mem, NULL);
+ ttm_bo_move_to_lru_tail_unlocked(bo);
dma_resv_unlock(bo->base.resv);
}
- spin_unlock(_glob.lru_lock);
ww_acquire_fini(>ticket);
}
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 3673157527ff..2d2ac532987e 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -243,9 +243,9 @@ static int ttm_bo_individualize_resv(struct
ttm_buffer_object *bo)
* reference it any more. The only tricky case is the trylock on
* the resv object while holding the lru_lock.
*/
- spin_lock(_glob.lru_lock);
+ spin_lock(>bdev->lru_lock);
bo->base.resv = >base._resv;
- spin_unlock(_glob.lru_lock);
+ spin_unlock(>bdev->lru_lock);
}
return r;
@@ -304,7 +304,7 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object *bo,
if (unlock_resv)
dma_resv_unlock(bo->base.resv);
- spin_unlock(_glob.lru_lock);
+ spin_unlock(>bdev->lru_lock);
lret = dma_resv_wait_timeout_rcu(resv, true, interruptible,
30 * HZ);
@@ -314,7 +314,7 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object *bo,
else if (lret == 0)
return -EBUSY;
- spin_lock(_glob.lru_lock);
+ spin_lock(>bdev->lru_lock);
if (unlock_resv && !dma_resv_trylock(bo->base.resv)) {
/*
* We raced, and lost, someone else holds the
reservation now,
@@ -324,7 +324,7 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object *bo,
* delayed destruction would succeed, so just return
success
* here.
*/
- spin_unlock(_glob.lru_lock);
+ spin_unlock(>bdev->lru_lock);
return 0;
}
ret = 0;
@@ -333,13 +333,13 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object
*bo,
if (ret || unlikely(list_empty(>ddestroy))) {
if (unlock_resv)
dma_resv_unlock(bo->base.resv);
- spin_unlock(_glob.lru_lock);
+ spin_unlock(>bdev->lru_lock);
return ret;
}
ttm_bo_del_from_lru(bo);
list_del_init(>ddestroy);
-
[PATCH 1/3] drm/ttm: move swapout logic around v2
Move the iteration of the global lru into the new function
ttm_global_swapout() and use that instead in drivers.
v2: consistently return int
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c| 57 -
drivers/gpu/drm/ttm/ttm_device.c| 29 +++
drivers/gpu/drm/ttm/ttm_tt.c| 2 +-
drivers/gpu/drm/vmwgfx/ttm_memory.c | 3 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
include/drm/ttm/ttm_bo_api.h| 3 +-
include/drm/ttm/ttm_device.h| 2 +
7 files changed, 53 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 3c23e863a3f0..66e00b404ec3 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1193,56 +1193,35 @@ int ttm_bo_wait(struct ttm_buffer_object *bo,
}
EXPORT_SYMBOL(ttm_bo_wait);
-/*
- * A buffer object shrink method that tries to swap out the first
- * buffer object on the bo_global::swap_lru list.
- */
-int ttm_bo_swapout(struct ttm_operation_ctx *ctx, gfp_t gfp_flags)
+int ttm_bo_swapout(struct ttm_buffer_object *bo, struct ttm_operation_ctx *ctx,
+ gfp_t gfp_flags)
{
struct ttm_global *glob = _glob;
- struct ttm_buffer_object *bo;
- int ret = -EBUSY;
bool locked;
- unsigned i;
-
- spin_lock(>lru_lock);
- for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
- list_for_each_entry(bo, >swap_lru[i], swap) {
- if (!ttm_bo_evict_swapout_allowable(bo, ctx, ,
- NULL))
- continue;
-
- if (!ttm_bo_get_unless_zero(bo)) {
- if (locked)
- dma_resv_unlock(bo->base.resv);
- continue;
- }
+ int ret;
- ret = 0;
- break;
- }
- if (!ret)
- break;
- }
+ if (!ttm_bo_evict_swapout_allowable(bo, ctx, , NULL))
+ return -EBUSY;
- if (ret) {
- spin_unlock(>lru_lock);
- return ret;
+ if (!ttm_bo_get_unless_zero(bo)) {
+ if (locked)
+ dma_resv_unlock(bo->base.resv);
+ return -EBUSY;
}
if (bo->deleted) {
- ret = ttm_bo_cleanup_refs(bo, false, false, locked);
+ ttm_bo_cleanup_refs(bo, false, false, locked);
ttm_bo_put(bo);
- return ret;
+ return 0;
}
ttm_bo_del_from_lru(bo);
+ /* TODO: Cleanup the locking */
spin_unlock(>lru_lock);
- /**
+ /*
* Move to system cached
*/
-
if (bo->mem.mem_type != TTM_PL_SYSTEM) {
struct ttm_operation_ctx ctx = { false, false };
struct ttm_resource evict_mem;
@@ -1262,29 +1241,26 @@ int ttm_bo_swapout(struct ttm_operation_ctx *ctx, gfp_t
gfp_flags)
}
}
- /**
+ /*
* Make sure BO is idle.
*/
-
ret = ttm_bo_wait(bo, false, false);
if (unlikely(ret != 0))
goto out;
ttm_bo_unmap_virtual(bo);
- /**
+ /*
* Swap out. Buffer will be swapped in again as soon as
* anyone tries to access a ttm page.
*/
-
if (bo->bdev->funcs->swap_notify)
bo->bdev->funcs->swap_notify(bo);
ret = ttm_tt_swapout(bo->bdev, bo->ttm, gfp_flags);
out:
- /**
-*
+ /*
* Unreserve without putting on LRU to avoid swapping out an
* already swapped buffer.
*/
@@ -1293,7 +1269,6 @@ int ttm_bo_swapout(struct ttm_operation_ctx *ctx, gfp_t
gfp_flags)
ttm_bo_put(bo);
return ret;
}
-EXPORT_SYMBOL(ttm_bo_swapout);
void ttm_bo_tt_destroy(struct ttm_buffer_object *bo)
{
diff --git a/drivers/gpu/drm/ttm/ttm_device.c b/drivers/gpu/drm/ttm/ttm_device.c
index 95e1b7b1f2e6..b1424189fdfb 100644
--- a/drivers/gpu/drm/ttm/ttm_device.c
+++ b/drivers/gpu/drm/ttm/ttm_device.c
@@ -102,6 +102,35 @@ static int ttm_global_init(void)
return ret;
}
+/**
+ * A buffer object shrink method that tries to swap out the first
+ * buffer object on the global::swap_lru list.
+ */
+int ttm_global_swapout(struct ttm_operation_ctx *ctx, gfp_t gfp_flags)
+{
+ struct ttm_global *glob = _glob;
+ struct ttm_buffer_object *bo;
+ unsigned i;
+ int ret;
+
+ spin_lock(>lru_lock);
+ for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
+ list_for_each_entry(bo, >swap_lru[i], swap) {
+ uint32_t num_pages = bo->ttm->num_pages;
+
+ ret = ttm_bo_swapout(bo, ctx, gfp_flags);
+ /* ttm_bo_swapout has dropped the lru_lock */
+
[PATCH V5 1/2] backlight: qcom-wled: Fix FSC update issue for WLED5
Currently, for WLED5, the FSC (Full scale current) setting is not
updated properly due to driver toggling the wrong register after
an FSC update.
On WLED5 we should only toggle the MOD_SYNC bit after a brightness
update. For an FSC update we need to toggle the SYNC bits instead.
Fix it by adopting the common wled3_sync_toggle() for WLED5 and
introducing new code to the brightness update path to compensate.
Signed-off-by: Kiran Gunda
Reviewed-by: Daniel Thompson
---
drivers/video/backlight/qcom-wled.c | 25 +++--
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/drivers/video/backlight/qcom-wled.c
b/drivers/video/backlight/qcom-wled.c
index fc8b443..e9fbe24 100644
--- a/drivers/video/backlight/qcom-wled.c
+++ b/drivers/video/backlight/qcom-wled.c
@@ -348,7 +348,7 @@ static int wled3_sync_toggle(struct wled *wled)
return rc;
}
-static int wled5_sync_toggle(struct wled *wled)
+static int wled5_mod_sync_toggle(struct wled *wled)
{
int rc;
u8 val;
@@ -445,10 +445,23 @@ static int wled_update_status(struct backlight_device *bl)
goto unlock_mutex;
}
- rc = wled->wled_sync_toggle(wled);
- if (rc < 0) {
- dev_err(wled->dev, "wled sync failed rc:%d\n", rc);
- goto unlock_mutex;
+ if (wled->version < 5) {
+ rc = wled->wled_sync_toggle(wled);
+ if (rc < 0) {
+ dev_err(wled->dev, "wled sync failed rc:%d\n",
rc);
+ goto unlock_mutex;
+ }
+ } else {
+ /*
+* For WLED5 toggling the MOD_SYNC_BIT updates the
+* brightness
+*/
+ rc = wled5_mod_sync_toggle(wled);
+ if (rc < 0) {
+ dev_err(wled->dev, "wled mod sync failed
rc:%d\n",
+ rc);
+ goto unlock_mutex;
+ }
}
}
@@ -1459,7 +1472,7 @@ static int wled_configure(struct wled *wled)
size = ARRAY_SIZE(wled5_opts);
*cfg = wled5_config_defaults;
wled->wled_set_brightness = wled5_set_brightness;
- wled->wled_sync_toggle = wled5_sync_toggle;
+ wled->wled_sync_toggle = wled3_sync_toggle;
wled->wled_cabc_config = wled5_cabc_config;
wled->wled_ovp_delay = wled5_ovp_delay;
wled->wled_auto_detection_required =
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V5 0/2] Fix WLED FSC Sync and brightness Sync settings
This patch series has the following two WLED fixes 1. As per the current implementation, for WLED5, after the FSC (Full Scale Current) update the driver is incorrectly toggling the MOD_SYNC register instead of toggling the SYNC register. The patch 1/2 fixes this by toggling the SYNC register after FSC update. 2. Currently, the sync bits are set-then-cleared after FSC and brightness update. As per hardware team recommendation the FSC and brightness sync takes place from clear-then-set transition of the sync bits. The patch 2/2 fies this issue. changes from V4: 1. Rebased this patch series on the below patch. "backlight-qcom-wled-Use-sink_addr-for-sync-toggle.patch". Changes from V3: 1. Updated the patch description as per Daneil's suggestion. 2. Added Daniel's "Reviewed-by" tag for patch 2/2. 3. Updated the cover letter to use "set" and "clear" properly. Changes from V2: 1. Added Daniel's "Reviewed-by" tag for patch 1/2. 2. Updated the patch 2/2 description with "set" and "clear" terminology instead of "1" and "0". 3. Updated the cover letter with "set" and "clear" terminology instead of "1" and "0". Changes from V1: 1. Updated the cover letter. 2. Updated the description of the patches as per Daniel's suggestion. Kiran Gunda (2): backlight: qcom-wled: Fix FSC update issue for WLED5 backlight: qcom-wled: Correct the sync_toggle sequence drivers/video/backlight/qcom-wled.c | 37 + 1 file changed, 25 insertions(+), 12 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V5 2/2] backlight: qcom-wled: Correct the sync_toggle sequence
As per the current implementation, after FSC (Full Scale Current) and brightness update the sync bits are set-then-cleared. But, the FSC and brightness sync takes place when the sync bits are set (e.g. on a rising edge). So the hardware team recommends a clear-then-set approach in order to guarantee such a transition regardless of the previous register state. Signed-off-by: Kiran Gunda Reviewed-by: Daniel Thompson --- drivers/video/backlight/qcom-wled.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/video/backlight/qcom-wled.c b/drivers/video/backlight/qcom-wled.c index e9fbe24..7c02f87 100644 --- a/drivers/video/backlight/qcom-wled.c +++ b/drivers/video/backlight/qcom-wled.c @@ -337,13 +337,13 @@ static int wled3_sync_toggle(struct wled *wled) rc = regmap_update_bits(wled->regmap, wled->sink_addr + WLED3_SINK_REG_SYNC, - mask, mask); + mask, WLED3_SINK_REG_SYNC_CLEAR); if (rc < 0) return rc; rc = regmap_update_bits(wled->regmap, wled->sink_addr + WLED3_SINK_REG_SYNC, - mask, WLED3_SINK_REG_SYNC_CLEAR); + mask, mask); return rc; } @@ -353,17 +353,17 @@ static int wled5_mod_sync_toggle(struct wled *wled) int rc; u8 val; - val = (wled->cfg.mod_sel == MOD_A) ? WLED5_SINK_REG_SYNC_MOD_A_BIT : -WLED5_SINK_REG_SYNC_MOD_B_BIT; rc = regmap_update_bits(wled->regmap, wled->sink_addr + WLED5_SINK_REG_MOD_SYNC_BIT, - WLED5_SINK_REG_SYNC_MASK, val); + WLED5_SINK_REG_SYNC_MASK, 0); if (rc < 0) return rc; + val = (wled->cfg.mod_sel == MOD_A) ? WLED5_SINK_REG_SYNC_MOD_A_BIT : +WLED5_SINK_REG_SYNC_MOD_B_BIT; return regmap_update_bits(wled->regmap, wled->sink_addr + WLED5_SINK_REG_MOD_SYNC_BIT, - WLED5_SINK_REG_SYNC_MASK, 0); + WLED5_SINK_REG_SYNC_MASK, val); } static int wled_ovp_fault_status(struct wled *wled, bool *fault_set) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] drm-misc-fixes
On Thu, Mar 18, 2021 at 12:33 PM Maarten Lankhorst wrote: > > drm-misc-fixes-2021-03-18: > drm-misc-fixes for v5.12-rc4: > - Make ttm_bo_unpin() not wraparound on too many unpins. > - Fix coccicheck warning in omap. Still missing the 2 patches from drm-misc-next-fixes, and those being left out also means drm-misc-next isn't pushed to for-linux-next branch, which is causing a ton of confusion itself. -Daniel > The following changes since commit de066e116306baf3a6a62691ac63cfc0b1dabddb: > > drm/compat: Clear bounce structures (2021-03-11 11:11:33 +0100) > > are available in the Git repository at: > > git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2021-03-18 > > for you to fetch changes up to 6909115442759efef3d4bc5d9c54d7943f1afc14: > > drm/omap: dsi: fix unsigned expression compared with zero (2021-03-17 > 13:59:23 +0200) > > > drm-misc-fixes for v5.12-rc4: > - Make ttm_bo_unpin() not wraparound on too many unpins. > - Fix coccicheck warning in omap. > > > Christian König (1): > drm/ttm: make ttm_bo_unpin more defensive > > Junlin Yang (1): > drm/omap: dsi: fix unsigned expression compared with zero > > drivers/gpu/drm/omapdrm/dss/dsi.c | 7 --- > include/drm/ttm/ttm_bo_api.h | 6 -- > 2 files changed, 8 insertions(+), 5 deletions(-) -- 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
[PULL] drm-intel-fixes
Hi Dave & Daniel - Covering for Rodrigo during his absence this week. drm-intel-fixes-2021-03-18: drm/i915 fixes for v5.12-rc4: - Workaround async flip + VT-d frame corruption on HSW/BDW - Fix NMI watchdog crash due to uninitialized OA buffer use on gen12+ BR, Jani. The following changes since commit 1e28eed17697bcf343c6743f0028cc3b5dd88bf0: Linux 5.12-rc3 (2021-03-14 14:41:02 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2021-03-18 for you to fetch changes up to 6a77c6bb7260bd5000f95df454d9f8cdb1af7132: i915/perf: Start hrtimer only if sampling the OA buffer (2021-03-17 12:51:37 +0200) drm/i915 fixes for v5.12-rc4: - Workaround async flip + VT-d frame corruption on HSW/BDW - Fix NMI watchdog crash due to uninitialized OA buffer use on gen12+ Umesh Nerlige Ramappa (1): i915/perf: Start hrtimer only if sampling the OA buffer Ville Syrjälä (1): drm/i915: Workaround async flip + VT-d corruption on HSW/BDW drivers/gpu/drm/i915/i915_perf.c | 13 + drivers/gpu/drm/i915/i915_reg.h | 23 ++- drivers/gpu/drm/i915/intel_pm.c | 16 +++- 3 files changed, 42 insertions(+), 10 deletions(-) -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amdgpu: Fix a typo
s/traing/training/
Signed-off-by: Bhaskar Chowdhury
---
drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
b/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
index c325d6f53a71..db18e4f6cf5f 100644
--- a/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
@@ -661,7 +661,7 @@ static int psp_v11_0_memory_training(struct psp_context
*psp, uint32_t ops)
if (ops & PSP_MEM_TRAIN_SEND_LONG_MSG) {
/*
-* Long traing will encroach certain mount of bottom VRAM,
+* Long training will encroach certain mount of bottom VRAM,
* saving the content of this bottom VRAM to system memory
* before training, and restoring it after training to avoid
* VRAM corruption.
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-misc-fixes
drm-misc-fixes-2021-03-18: drm-misc-fixes for v5.12-rc4: - Make ttm_bo_unpin() not wraparound on too many unpins. - Fix coccicheck warning in omap. The following changes since commit de066e116306baf3a6a62691ac63cfc0b1dabddb: drm/compat: Clear bounce structures (2021-03-11 11:11:33 +0100) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2021-03-18 for you to fetch changes up to 6909115442759efef3d4bc5d9c54d7943f1afc14: drm/omap: dsi: fix unsigned expression compared with zero (2021-03-17 13:59:23 +0200) drm-misc-fixes for v5.12-rc4: - Make ttm_bo_unpin() not wraparound on too many unpins. - Fix coccicheck warning in omap. Christian König (1): drm/ttm: make ttm_bo_unpin more defensive Junlin Yang (1): drm/omap: dsi: fix unsigned expression compared with zero drivers/gpu/drm/omapdrm/dss/dsi.c | 7 --- include/drm/ttm/ttm_bo_api.h | 6 -- 2 files changed, 8 insertions(+), 5 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/meson: Fix few typo
s/initialy/initially/ s/desined/designed/ Signed-off-by: Bhaskar Chowdhury --- drivers/gpu/drm/meson/meson_venc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/meson/meson_venc.c b/drivers/gpu/drm/meson/meson_venc.c index 5e2236ec189f..3c55ed003359 100644 --- a/drivers/gpu/drm/meson/meson_venc.c +++ b/drivers/gpu/drm/meson/meson_venc.c @@ -45,7 +45,7 @@ * The ENCI is designed for PAl or NTSC encoding and can go through the VDAC * directly for CVBS encoding or through the ENCI_DVI encoder for HDMI. * The ENCP is designed for Progressive encoding but can also generate - * 1080i interlaced pixels, and was initialy desined to encode pixels for + * 1080i interlaced pixels, and was initially designed to encode pixels for * VDAC to output RGB ou YUV analog outputs. * It's output is only used through the ENCP_DVI encoder for HDMI. * The ENCL LVDS encoder is not implemented. -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 08/10] drm/simpledrm: Acquire clocks from DT device node
Hi
Am 18.03.21 um 11:39 schrieb Geert Uytterhoeven:
Hi Thomas,
On Thu, Mar 18, 2021 at 11:29 AM Thomas Zimmermann wrote:
Make sure required hardware clocks are enabled while the firmware
framebuffer is in use.
The basic code has been taken from the simplefb driver and adapted
to DRM. Clocks are released automatically via devres helpers.
Signed-off-by: Thomas Zimmermann
Tested-by: nerdopolis
Thanks for your patch!
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
+static int simpledrm_device_init_clocks(struct simpledrm_device *sdev)
+{
+ struct drm_device *dev = >dev;
+ struct platform_device *pdev = sdev->pdev;
+ struct device_node *of_node = pdev->dev.of_node;
+ struct clk *clock;
+ unsigned int i;
+ int ret;
+
+ if (dev_get_platdata(>dev) || !of_node)
+ return 0;
+
+ sdev->clk_count = of_clk_get_parent_count(of_node);
+ if (!sdev->clk_count)
+ return 0;
+
+ sdev->clks = drmm_kzalloc(dev, sdev->clk_count * sizeof(sdev->clks[0]),
+ GFP_KERNEL);
+ if (!sdev->clks)
+ return -ENOMEM;
+
+ for (i = 0; i < sdev->clk_count; ++i) {
+ clock = of_clk_get(of_node, i);
+ if (IS_ERR(clock)) {
+ ret = PTR_ERR(clock);
+ if (ret == -EPROBE_DEFER)
+ goto err;
+ drm_err(dev, "clock %u not found: %d\n", i, ret);
+ continue;
+ }
+ ret = clk_prepare_enable(clock);
+ if (ret) {
+ drm_err(dev, "failed to enable clock %u: %d\n",
+ i, ret);
+ clk_put(clock);
+ }
+ sdev->clks[i] = clock;
+ }
of_clk_bulk_get_all() + clk_bulk_prepare_enable()?
There's also devm_clk_bulk_get_all(), but not for the OF variant.
Right, you mentioned this on the original patch set. I tried to use the
functions, but TBH I found them to obfuscate the overall logic of the
function. So I went back to the original code. Hopefully this is not too
much of an issue.
Best regards
Thomas
Gr{oetje,eeting}s,
Geert
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm/dpu: enable DPU_SSPP_QOS_8LVL for SM8250
SM8250 platform has a 8-Levels VIG QoS setting. This setting was missed
due to bad interaction with b8dab65b5ac3 ("drm/msm/dpu: Move
DPU_SSPP_QOS_8LVL bit to SDM845 and SC7180 masks"), which was applied in
parallel.
Fixes: d21fc5dfc3df ("drm/msm/dpu1: add support for qseed3lite used on sm8250")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index bffe5969ed7e..f21f630af476 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -22,7 +22,7 @@
(VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED4))
#define VIG_SM8250_MASK \
- (VIG_MASK | BIT(DPU_SSPP_SCALER_QSEED3LITE))
+ (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED3LITE))
#define DMA_SDM845_MASK \
(BIT(DPU_SSPP_SRC) | BIT(DPU_SSPP_QOS) | BIT(DPU_SSPP_QOS_8LVL) |\
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v3] drm/scheduler re-insert Bailing job to avoid memleak
[AMD Official Use Only - Internal Distribution Only]
Hi, Andrey
Let me summarize the background of this patch:
In TDR resubmit step “amdgpu_device_recheck_guilty_jobs,
It will submit first jobs of each ring and do guilty job re-check.
At that point, We had to make sure each job is in the mirror list(or
re-inserted back already).
But we found the current code never re-insert the job to mirror list in the
2nd, 3rd job_timeout thread(Bailing TDR thread).
This not only will cause memleak of the bailing jobs. What’s more important,
the 1st tdr thread can never iterate the bailing job and set its guilty status
to a correct status.
Therefore, we had to re-insert the job(or even not delete node) for bailing job.
For the above V3 patch, the racing condition in my mind is:
we cannot make sure all bailing jobs are finished before we do
amdgpu_device_recheck_guilty_jobs.
Based on this insight, I think we have two options to solve this issue:
1. Skip delete node in tdr thread2, thread3, 4 … (using mutex or atomic
variable)
2. Re-insert back bailing job, and meanwhile use semaphore in each tdr
thread to keep the sequence as expected and ensure each job is in the mirror
list when do resubmit step.
For Option1, logic is simpler and we need only one global atomic variable:
What do you think about this plan?
Option1 should look like the following logic:
+static atomic_t in_reset; //a global atomic var for synchronization
static void drm_sched_process_job(struct dma_fence *f, struct dma_fence_cb *cb);
/**
@@ -295,6 +296,12 @@ static void drm_sched_job_timedout(struct work_struct
*work)
* drm_sched_cleanup_jobs. It will be reinserted back after
sched->thread
* is parked at which point it's safe.
*/
+ if (atomic_cmpxchg(_reset, 0, 1) != 0) { //skip delete node
if it’s thead1,2,3,….
+ spin_unlock(>job_list_lock);
+ drm_sched_start_timeout(sched);
+ return;
+ }
+
list_del_init(>node);
spin_unlock(>job_list_lock);
@@ -320,6 +327,7 @@ static void drm_sched_job_timedout(struct work_struct *work)
spin_lock(>job_list_lock);
drm_sched_start_timeout(sched);
spin_unlock(>job_list_lock);
+ atomic_set(_reset, 0); //reset in_reset when the first thread
finished tdr
}
Thanks,
Jack
From: amd-gfx On Behalf Of Zhang, Jack
(Jian)
Sent: Wednesday, March 17, 2021 11:11 PM
To: Christian König ;
dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org; Koenig,
Christian ; Liu, Monk ; Deng, Emily
; Rob Herring ; Tomeu Vizoso
; Steven Price ; Grodzovsky,
Andrey
Subject: Re: [PATCH v3] drm/scheduler re-insert Bailing job to avoid memleak
[AMD Official Use Only - Internal Distribution Only]
[AMD Official Use Only - Internal Distribution Only]
Hi，Andrey，
Good catch，I will expore this corner case and give feedback soon～
Best，
Jack
From: Grodzovsky, Andrey
mailto:andrey.grodzov...@amd.com>>
Sent: Wednesday, March 17, 2021 10:50:59 PM
To: Christian König
mailto:ckoenig.leichtzumer...@gmail.com>>;
Zhang, Jack (Jian) mailto:jack.zha...@amd.com>>;
dri-devel@lists.freedesktop.org
mailto:dri-devel@lists.freedesktop.org>>;
amd-...@lists.freedesktop.org
mailto:amd-...@lists.freedesktop.org>>; Koenig,
Christian mailto:christian.koe...@amd.com>>; Liu,
Monk mailto:monk@amd.com>>; Deng, Emily
mailto:emily.d...@amd.com>>; Rob Herring
mailto:r...@kernel.org>>; Tomeu Vizoso
mailto:tomeu.viz...@collabora.com>>; Steven Price
mailto:steven.pr...@arm.com>>
Subject: Re: [PATCH v3] drm/scheduler re-insert Bailing job to avoid memleak
I actually have a race condition concern here - see bellow -
On 2021-03-17 3:43 a.m., Christian König wrote:
> I was hoping Andrey would take a look since I'm really busy with other
> work right now.
>
> Regards,
> Christian.
>
> Am 17.03.21 um 07:46 schrieb Zhang, Jack (Jian):
>> Hi, Andrey/Crhistian and Team,
>>
>> I didn't receive the reviewer's message from maintainers on panfrost
>> driver for several days.
>> Due to this patch is urgent for my current working project.
>> Would you please help to give some review ideas?
>>
>> Many Thanks,
>> Jack
>> -Original Message-
>> From: Zhang, Jack (Jian)
>> Sent: Tuesday, March 16, 2021 3:20 PM
>> To: dri-devel@lists.freedesktop.org;
>> amd-...@lists.freedesktop.org;
>> Koenig, Christian
>> mailto:christian.koe...@amd.com>>; Grodzovsky,
>> Andrey
>> mailto:andrey.grodzov...@amd.com>>; Liu, Monk
>> mailto:monk@amd.com>>; Deng,
>> Emily mailto:emily.d...@amd.com>>; Rob Herring
>> mailto:r...@kernel.org>>; Tomeu
>> Vizoso mailto:tomeu.viz...@collabora.com>>;
>> Steven Price mailto:steven.pr...@arm.com>>
>>
[PATCH] drm: Few typo fixes
s/instatiated/instantiated/ s/unreference/unreferenced/ Signed-off-by: Bhaskar Chowdhury --- drivers/gpu/drm/drm_property.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c index 6ee04803c362..27c824a6eb60 100644 --- a/drivers/gpu/drm/drm_property.c +++ b/drivers/gpu/drm/drm_property.c @@ -43,7 +43,7 @@ * property types and ranges. * * Properties don't store the current value directly, but need to be - * instatiated by attaching them to a _mode_object with + * instantiated by attaching them to a _mode_object with * drm_object_attach_property(). * * Property values are only 64bit. To support bigger piles of data (like gamma @@ -644,7 +644,7 @@ EXPORT_SYMBOL(drm_property_blob_get); * @id: id of the blob property * * If successful, this takes an additional reference to the blob property. - * callers need to make sure to eventually unreference the returned property + * callers need to make sure to eventually unreferenced the returned property * again, using drm_property_blob_put(). * * Return: -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 08/10] drm/simpledrm: Acquire clocks from DT device node
Hi Thomas,
On Thu, Mar 18, 2021 at 11:29 AM Thomas Zimmermann wrote:
> Make sure required hardware clocks are enabled while the firmware
> framebuffer is in use.
>
> The basic code has been taken from the simplefb driver and adapted
> to DRM. Clocks are released automatically via devres helpers.
>
> Signed-off-by: Thomas Zimmermann
> Tested-by: nerdopolis
Thanks for your patch!
> --- a/drivers/gpu/drm/tiny/simpledrm.c
> +++ b/drivers/gpu/drm/tiny/simpledrm.c
> +static int simpledrm_device_init_clocks(struct simpledrm_device *sdev)
> +{
> + struct drm_device *dev = >dev;
> + struct platform_device *pdev = sdev->pdev;
> + struct device_node *of_node = pdev->dev.of_node;
> + struct clk *clock;
> + unsigned int i;
> + int ret;
> +
> + if (dev_get_platdata(>dev) || !of_node)
> + return 0;
> +
> + sdev->clk_count = of_clk_get_parent_count(of_node);
> + if (!sdev->clk_count)
> + return 0;
> +
> + sdev->clks = drmm_kzalloc(dev, sdev->clk_count *
> sizeof(sdev->clks[0]),
> + GFP_KERNEL);
> + if (!sdev->clks)
> + return -ENOMEM;
> +
> + for (i = 0; i < sdev->clk_count; ++i) {
> + clock = of_clk_get(of_node, i);
> + if (IS_ERR(clock)) {
> + ret = PTR_ERR(clock);
> + if (ret == -EPROBE_DEFER)
> + goto err;
> + drm_err(dev, "clock %u not found: %d\n", i, ret);
> + continue;
> + }
> + ret = clk_prepare_enable(clock);
> + if (ret) {
> + drm_err(dev, "failed to enable clock %u: %d\n",
> + i, ret);
> + clk_put(clock);
> + }
> + sdev->clks[i] = clock;
> + }
of_clk_bulk_get_all() + clk_bulk_prepare_enable()?
There's also devm_clk_bulk_get_all(), but not for the OF variant.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v16 1/2] drm/tegra: dc: Support memory bandwidth management
18.03.2021 12:31, Michał Mirosław пишет:
>> static const struct tegra_windowgroup_soc tegra194_dc_wgrps[] = {
>> @@ -2430,6 +2781,7 @@ static const struct tegra_dc_soc_info
>> tegra194_dc_soc_info = {
>> .has_nvdisplay = true,
>> .wgrps = tegra194_dc_wgrps,
>> .num_wgrps = ARRAY_SIZE(tegra194_dc_wgrps),
>> +.plane_tiled_memory_bandwidth_x2 = false,
>> };
> For globals you will have .x = false by default; I'm not sure those entries
> add much value.
>
> Reviewed-by: Michał Mirosław
IIRC, in the past Thierry preferred to add the defaults to this driver
in order to ease reading/understanding of the code. So I added them for
consistency.
Thank you very much for helping with the review!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 09/10] drm/simpledrm: Acquire regulators from DT device node
Make sure required hardware regulators are enabled while the firmware
framebuffer is in use.
The basic code has been taken from the simplefb driver and adapted
to DRM. Regulators are released automatically via devres helpers.
v2:
* use strscpy()
Signed-off-by: Thomas Zimmermann
Tested-by: nerdopolis
---
drivers/gpu/drm/tiny/simpledrm.c | 128 +++
1 file changed, 128 insertions(+)
diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index 10ca3373b61f..2e27eeb791a1 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -4,6 +4,7 @@
#include
#include
#include
+#include
#include
#include
@@ -197,6 +198,11 @@ struct simpledrm_device {
unsigned int clk_count;
struct clk **clks;
#endif
+ /* regulators */
+#if defined CONFIG_OF && defined CONFIG_REGULATOR
+ unsigned int regulator_count;
+ struct regulator **regulators;
+#endif
/* simplefb settings */
struct drm_display_mode mode;
@@ -316,6 +322,125 @@ static int simpledrm_device_init_clocks(struct
simpledrm_device *sdev)
}
#endif
+#if defined CONFIG_OF && defined CONFIG_REGULATOR
+
+#define SUPPLY_SUFFIX "-supply"
+
+/*
+ * Regulator handling code.
+ *
+ * Here we handle the num-supplies and vin*-supply properties of our
+ * "simple-framebuffer" dt node. This is necessary so that we can make sure
+ * that any regulators needed by the display hardware that the bootloader
+ * set up for us (and for which it provided a simplefb dt node), stay up,
+ * for the life of the simplefb driver.
+ *
+ * When the driver unloads, we cleanly disable, and then release the
+ * regulators.
+ *
+ * We only complain about errors here, no action is taken as the most likely
+ * error can only happen due to a mismatch between the bootloader which set
+ * up simplefb, and the regulator definitions in the device tree. Chances are
+ * that there are no adverse effects, and if there are, a clean teardown of
+ * the fb probe will not help us much either. So just complain and carry on,
+ * and hope that the user actually gets a working fb at the end of things.
+ */
+
+static void simpledrm_device_release_regulators(void *res)
+{
+ struct simpledrm_device *sdev = simpledrm_device_of_dev(res);
+ unsigned int i;
+
+ for (i = 0; i < sdev->regulator_count; ++i) {
+ if (sdev->regulators[i]) {
+ regulator_disable(sdev->regulators[i]);
+ regulator_put(sdev->regulators[i]);
+ }
+ }
+}
+
+static int simpledrm_device_init_regulators(struct simpledrm_device *sdev)
+{
+ struct drm_device *dev = >dev;
+ struct platform_device *pdev = sdev->pdev;
+ struct device_node *of_node = pdev->dev.of_node;
+ struct property *prop;
+ struct regulator *regulator;
+ const char *p;
+ unsigned int count = 0, i = 0;
+ int ret;
+
+ if (dev_get_platdata(>dev) || !of_node)
+ return 0;
+
+ /* Count the number of regulator supplies */
+ for_each_property_of_node(of_node, prop) {
+ p = strstr(prop->name, SUPPLY_SUFFIX);
+ if (p && p != prop->name)
+ ++count;
+ }
+
+ if (!count)
+ return 0;
+
+ sdev->regulators = drmm_kzalloc(dev,
+ count * sizeof(sdev->regulators[0]),
+ GFP_KERNEL);
+ if (!sdev->regulators)
+ return -ENOMEM;
+
+ for_each_property_of_node(of_node, prop) {
+ char name[32]; /* 32 is max size of property name */
+ size_t len;
+
+ p = strstr(prop->name, SUPPLY_SUFFIX);
+ if (!p || p == prop->name)
+ continue;
+ len = strlen(prop->name) - strlen(SUPPLY_SUFFIX) + 1;
+ strscpy(name, prop->name, min(sizeof(name), len));
+
+ regulator = regulator_get_optional(>dev, name);
+ if (IS_ERR(regulator)) {
+ ret = PTR_ERR(regulator);
+ if (ret == -EPROBE_DEFER)
+ goto err;
+ drm_err(dev, "regulator %s not found: %d\n",
+ name, ret);
+ continue;
+ }
+
+ ret = regulator_enable(regulator);
+ if (ret) {
+ drm_err(dev, "failed to enable regulator %u: %d\n",
+ i, ret);
+ regulator_put(regulator);
+ }
+
+ sdev->regulators[i++] = regulator;
+ }
+ sdev->regulator_count = i;
+
+ return devm_add_action_or_reset(>dev,
+ simpledrm_device_release_regulators,
+ sdev);
+
+err:
+ while (i) {
+
[PATCH v2 07/10] drm/simpledrm: Initialize framebuffer data from device-tree node
A firmware framebuffer might also be specified via device-tree files. If
no device platform data is given, try the DT device node.
v2:
* add Device Tree match table
* clean-up parser wrappers
Signed-off-by: Thomas Zimmermann
Tested-by: nerdopolis
---
drivers/gpu/drm/tiny/simpledrm.c | 89
1 file changed, 89 insertions(+)
diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index 4f0d4ec0b432..c9cef2b50de6 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -114,6 +114,74 @@ simplefb_get_format_pd(struct drm_device *dev,
return simplefb_get_validated_format(dev, pd->format);
}
+static int
+simplefb_read_u32_of(struct drm_device *dev, struct device_node *of_node,
+const char *name, u32 *value)
+{
+ int ret = of_property_read_u32(of_node, name, value);
+
+ if (ret)
+ drm_err(dev, "simplefb: cannot parse framebuffer %s: error
%d\n",
+ name, ret);
+ return ret;
+}
+
+static int
+simplefb_read_string_of(struct drm_device *dev, struct device_node *of_node,
+ const char *name, const char **value)
+{
+ int ret = of_property_read_string(of_node, name, value);
+
+ if (ret)
+ drm_err(dev, "simplefb: cannot parse framebuffer %s: error
%d\n",
+ name, ret);
+ return ret;
+}
+
+static int
+simplefb_get_width_of(struct drm_device *dev, struct device_node *of_node)
+{
+ u32 width;
+ int ret = simplefb_read_u32_of(dev, of_node, "width", );
+
+ if (ret)
+ return ret;
+ return simplefb_get_validated_int0(dev, "width", width);
+}
+
+static int
+simplefb_get_height_of(struct drm_device *dev, struct device_node *of_node)
+{
+ u32 height;
+ int ret = simplefb_read_u32_of(dev, of_node, "height", );
+
+ if (ret)
+ return ret;
+ return simplefb_get_validated_int0(dev, "height", height);
+}
+
+static int
+simplefb_get_stride_of(struct drm_device *dev, struct device_node *of_node)
+{
+ u32 stride;
+ int ret = simplefb_read_u32_of(dev, of_node, "stride", );
+
+ if (ret)
+ return ret;
+ return simplefb_get_validated_int(dev, "stride", stride);
+}
+
+static const struct drm_format_info *
+simplefb_get_format_of(struct drm_device *dev, struct device_node *of_node)
+{
+ const char *format;
+ int ret = simplefb_read_string_of(dev, of_node, "format", );
+
+ if (ret)
+ return ERR_PTR(ret);
+ return simplefb_get_validated_format(dev, format);
+}
+
/*
* Simple Framebuffer device
*/
@@ -166,6 +234,7 @@ static int simpledrm_device_init_fb(struct simpledrm_device
*sdev)
struct drm_device *dev = >dev;
struct platform_device *pdev = sdev->pdev;
const struct simplefb_platform_data *pd = dev_get_platdata(>dev);
+ struct device_node *of_node = pdev->dev.of_node;
if (pd) {
width = simplefb_get_width_pd(dev, pd);
@@ -180,6 +249,19 @@ static int simpledrm_device_init_fb(struct
simpledrm_device *sdev)
format = simplefb_get_format_pd(dev, pd);
if (IS_ERR(format))
return PTR_ERR(format);
+ } else if (of_node) {
+ width = simplefb_get_width_of(dev, of_node);
+ if (width < 0)
+ return width;
+ height = simplefb_get_height_of(dev, of_node);
+ if (height < 0)
+ return height;
+ stride = simplefb_get_stride_of(dev, of_node);
+ if (stride < 0)
+ return stride;
+ format = simplefb_get_format_of(dev, of_node);
+ if (IS_ERR(format))
+ return PTR_ERR(format);
} else {
drm_err(dev, "no simplefb configuration found\n");
return -ENODEV;
@@ -516,9 +598,16 @@ static int simpledrm_remove(struct platform_device *pdev)
return 0;
}
+static const struct of_device_id simpledrm_of_match_table[] = {
+ { .compatible = "simple-framebuffer", },
+ { },
+};
+MODULE_DEVICE_TABLE(of, simpledrm_of_match_table);
+
static struct platform_driver simpledrm_platform_driver = {
.driver = {
.name = "simple-framebuffer", /* connect to sysfb */
+ .of_match_table = simpledrm_of_match_table,
},
.probe = simpledrm_probe,
.remove = simpledrm_remove,
--
2.30.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 10/10] drm/simpledrm: Acquire memory aperture for framebuffer
We register the simplekms device with the DRM platform helpers. A
native driver for the graphics hardware will kick-out the simpledrm
driver before taking over the device.
v2:
* adapt to aperture changes
* use drm_dev_unplug() and drm_dev_enter/exit()
* don't split error string
Signed-off-by: Thomas Zimmermann
Tested-by: nerdopolis
---
drivers/gpu/drm/tiny/Kconfig | 1 +
drivers/gpu/drm/tiny/simpledrm.c | 83 ++--
2 files changed, 81 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
index d46f95d9196d..5b72dd8e93f9 100644
--- a/drivers/gpu/drm/tiny/Kconfig
+++ b/drivers/gpu/drm/tiny/Kconfig
@@ -41,6 +41,7 @@ config DRM_GM12U320
config DRM_SIMPLEDRM
tristate "Simple framebuffer driver"
depends on DRM
+ select DRM_APERTURE
select DRM_GEM_SHMEM_HELPER
select DRM_KMS_HELPER
help
diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index 2e27eeb791a1..67d33af19086 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -5,7 +5,9 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -37,6 +39,12 @@
#define SIMPLEDRM_MODE(hd, vd) \
DRM_SIMPLE_MODE(hd, vd, RES_MM(hd), RES_MM(vd))
+/*
+ * Protects the platform device's drvdata against
+ * concurrent manipulation.
+ */
+static DEFINE_SPINLOCK(simpledrm_drvdata_lock);
+
/*
* Helpers for simplefb
*/
@@ -515,16 +523,53 @@ static int simpledrm_device_init_fb(struct
simpledrm_device *sdev)
* Memory management
*/
+static void simpledrm_aperture_detach(struct drm_device *dev, resource_size_t
base,
+ resource_size_t size)
+{
+ struct simpledrm_device *sdev = simpledrm_device_of_dev(dev);
+ struct platform_device *pdev = sdev->pdev;
+
+ if (WARN_ON(drm_dev_is_unplugged(dev)))
+ return; /* BUG: driver already got detached */
+
+ /*
+* If simpledrm gets detached from the aperture, it's like unplugging
+* the device. So call drm_dev_unplug().
+*/
+ drm_dev_unplug(dev);
+
+ spin_lock(_drvdata_lock);
+ sdev = platform_get_drvdata(pdev);
+ platform_set_drvdata(pdev, NULL); /* required; see simpledrm_remove() */
+ spin_unlock(_drvdata_lock);
+}
+
+static const struct drm_aperture_funcs simpledrm_aperture_funcs = {
+ .detach = simpledrm_aperture_detach,
+};
+
static int simpledrm_device_init_mm(struct simpledrm_device *sdev)
{
+ struct drm_device *dev = >dev;
struct platform_device *pdev = sdev->pdev;
struct resource *mem;
+ struct drm_aperture *ap;
void __iomem *screen_base;
+ int ret;
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!mem)
return -EINVAL;
+ ap = devm_aperture_acquire(dev, mem->start, resource_size(mem),
+ _aperture_funcs);
+ if (IS_ERR(ap)) {
+ ret = PTR_ERR(ap);
+ drm_err(dev, "could not acquire memory range [0x%llx:0x%llx]:
error %d\n",
+ mem->start, mem->end, ret);
+ return ret;
+ }
+
screen_base = devm_ioremap_wc(>dev, mem->start,
resource_size(mem));
if (!screen_base)
@@ -625,12 +670,18 @@ simpledrm_simple_display_pipe_enable(struct
drm_simple_display_pipe *pipe,
struct drm_shadow_plane_state *shadow_plane_state =
to_drm_shadow_plane_state(plane_state);
struct drm_framebuffer *fb = plane_state->fb;
void *vmap = shadow_plane_state->map[0].vaddr; /* TODO: Use mapping
abstraction properly */
+ struct drm_device *dev = >dev;
+ int idx;
if (!fb)
return;
+ if (!drm_dev_enter(dev, ))
+ return;
+
drm_fb_blit_dstclip(sdev->screen_base, sdev->pitch,
sdev->format->format, vmap, fb);
+ drm_dev_exit(idx);
}
static void
@@ -642,7 +693,9 @@ simpledrm_simple_display_pipe_update(struct
drm_simple_display_pipe *pipe,
struct drm_shadow_plane_state *shadow_plane_state =
to_drm_shadow_plane_state(plane_state);
void *vmap = shadow_plane_state->map[0].vaddr; /* TODO: Use mapping
abstraction properly */
struct drm_framebuffer *fb = plane_state->fb;
+ struct drm_device *dev = >dev;
struct drm_rect clip;
+ int idx;
if (!fb)
return;
@@ -650,8 +703,13 @@ simpledrm_simple_display_pipe_update(struct
drm_simple_display_pipe *pipe,
if (!drm_atomic_helper_damage_merged(old_plane_state, plane_state,
))
return;
+ if (!drm_dev_enter(dev, ))
+ return;
+
drm_fb_blit_rect_dstclip(sdev->screen_base, sdev->pitch,
sdev->format->format, vmap,
[PATCH v2 03/10] drm/aperture: Move fbdev conflict helpers into drm_aperture.h
Fbdev's helpers for handling conflicting framebuffers are related to
framebuffer apertures, not console emulation. Therefore move them into a
drm_aperture.h, which will contain the interfaces for the new aperture
helpers.
Signed-off-by: Thomas Zimmermann
Tested-by: nerdopolis
---
Documentation/gpu/drm-internals.rst | 6 +++
include/drm/drm_aperture.h | 60 +
include/drm/drm_fb_helper.h | 56 ++-
3 files changed, 69 insertions(+), 53 deletions(-)
create mode 100644 include/drm/drm_aperture.h
diff --git a/Documentation/gpu/drm-internals.rst
b/Documentation/gpu/drm-internals.rst
index 12272b168580..4c7642d2ca34 100644
--- a/Documentation/gpu/drm-internals.rst
+++ b/Documentation/gpu/drm-internals.rst
@@ -75,6 +75,12 @@ update it, its value is mostly useless. The DRM core prints
it to the
kernel log at initialization time and passes it to userspace through the
DRM_IOCTL_VERSION ioctl.
+Managing Ownership of the Framebuffer Aperture
+--
+
+.. kernel-doc:: include/drm/drm_aperture.h
+ :internal:
+
Device Instance and Driver Handling
---
diff --git a/include/drm/drm_aperture.h b/include/drm/drm_aperture.h
new file mode 100644
index ..13766efe9517
--- /dev/null
+++ b/include/drm/drm_aperture.h
@@ -0,0 +1,60 @@
+/* SPDX-License-Identifier: MIT */
+
+#ifndef _DRM_APERTURE_H_
+#define _DRM_APERTURE_H_
+
+#include
+#include
+
+/**
+ * drm_fb_helper_remove_conflicting_framebuffers - remove firmware-configured
framebuffers
+ * @a: memory range, users of which are to be removed
+ * @name: requesting driver name
+ * @primary: also kick vga16fb if present
+ *
+ * This function removes framebuffer devices (initialized by
firmware/bootloader)
+ * which use memory range described by @a. If @a is NULL all such devices are
+ * removed.
+ */
+static inline int
+drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct *a,
+ const char *name, bool primary)
+{
+#if IS_REACHABLE(CONFIG_FB)
+ return remove_conflicting_framebuffers(a, name, primary);
+#else
+ return 0;
+#endif
+}
+
+/**
+ * drm_fb_helper_remove_conflicting_pci_framebuffers - remove
firmware-configured
+ * framebuffers for PCI
devices
+ * @pdev: PCI device
+ * @name: requesting driver name
+ *
+ * This function removes framebuffer devices (eg. initialized by firmware)
+ * using memory range configured for any of @pdev's memory bars.
+ *
+ * The function assumes that PCI device with shadowed ROM drives a primary
+ * display and so kicks out vga16fb.
+ */
+static inline int
+drm_fb_helper_remove_conflicting_pci_framebuffers(struct pci_dev *pdev,
+ const char *name)
+{
+ int ret = 0;
+
+ /*
+* WARNING: Apparently we must kick fbdev drivers before vgacon,
+* otherwise the vga fbdev driver falls over.
+*/
+#if IS_REACHABLE(CONFIG_FB)
+ ret = remove_conflicting_pci_framebuffers(pdev, name);
+#endif
+ if (ret == 0)
+ ret = vga_remove_vgacon(pdev);
+ return ret;
+}
+
+#endif
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index 3b273f9ca39a..d06a3942fddb 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -30,13 +30,13 @@
#ifndef DRM_FB_HELPER_H
#define DRM_FB_HELPER_H
-struct drm_fb_helper;
-
+#include
#include
#include
#include
#include
-#include
+
+struct drm_fb_helper;
enum mode_set_atomic {
LEAVE_ATOMIC_MODE_SET,
@@ -451,54 +451,4 @@ drm_fbdev_generic_setup(struct drm_device *dev, unsigned
int preferred_bpp)
#endif
-/**
- * drm_fb_helper_remove_conflicting_framebuffers - remove firmware-configured
framebuffers
- * @a: memory range, users of which are to be removed
- * @name: requesting driver name
- * @primary: also kick vga16fb if present
- *
- * This function removes framebuffer devices (initialized by
firmware/bootloader)
- * which use memory range described by @a. If @a is NULL all such devices are
- * removed.
- */
-static inline int
-drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct *a,
- const char *name, bool primary)
-{
-#if IS_REACHABLE(CONFIG_FB)
- return remove_conflicting_framebuffers(a, name, primary);
-#else
- return 0;
-#endif
-}
-
-/**
- * drm_fb_helper_remove_conflicting_pci_framebuffers - remove
firmware-configured framebuffers for PCI devices
- * @pdev: PCI device
- * @name: requesting driver name
- *
- * This function removes framebuffer devices (eg. initialized by firmware)
- * using memory range configured for any of @pdev's memory bars.
- *
- * The function assumes that PCI device with shadowed ROM drives a primary
- * display and so kicks out vga16fb.
- */
-static inline int
[PATCH v2 08/10] drm/simpledrm: Acquire clocks from DT device node
Make sure required hardware clocks are enabled while the firmware
framebuffer is in use.
The basic code has been taken from the simplefb driver and adapted
to DRM. Clocks are released automatically via devres helpers.
Signed-off-by: Thomas Zimmermann
Tested-by: nerdopolis
---
drivers/gpu/drm/tiny/simpledrm.c | 108 +++
1 file changed, 108 insertions(+)
diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index c9cef2b50de6..10ca3373b61f 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -1,5 +1,7 @@
// SPDX-License-Identifier: GPL-2.0-only
+#include
+#include
#include
#include
@@ -190,6 +192,12 @@ struct simpledrm_device {
struct drm_device dev;
struct platform_device *pdev;
+ /* clocks */
+#if defined CONFIG_OF && defined CONFIG_COMMON_CLK
+ unsigned int clk_count;
+ struct clk **clks;
+#endif
+
/* simplefb settings */
struct drm_display_mode mode;
const struct drm_format_info *format;
@@ -211,6 +219,103 @@ static struct simpledrm_device
*simpledrm_device_of_dev(struct drm_device *dev)
return container_of(dev, struct simpledrm_device, dev);
}
+/*
+ * Hardware
+ */
+
+#if defined CONFIG_OF && defined CONFIG_COMMON_CLK
+/*
+ * Clock handling code.
+ *
+ * Here we handle the clocks property of our "simple-framebuffer" dt node.
+ * This is necessary so that we can make sure that any clocks needed by
+ * the display engine that the bootloader set up for us (and for which it
+ * provided a simplefb dt node), stay up, for the life of the simplefb
+ * driver.
+ *
+ * When the driver unloads, we cleanly disable, and then release the clocks.
+ *
+ * We only complain about errors here, no action is taken as the most likely
+ * error can only happen due to a mismatch between the bootloader which set
+ * up simplefb, and the clock definitions in the device tree. Chances are
+ * that there are no adverse effects, and if there are, a clean teardown of
+ * the fb probe will not help us much either. So just complain and carry on,
+ * and hope that the user actually gets a working fb at the end of things.
+ */
+
+static void simpledrm_device_release_clocks(void *res)
+{
+ struct simpledrm_device *sdev = simpledrm_device_of_dev(res);
+ unsigned int i;
+
+ for (i = 0; i < sdev->clk_count; ++i) {
+ if (sdev->clks[i]) {
+ clk_disable_unprepare(sdev->clks[i]);
+ clk_put(sdev->clks[i]);
+ }
+ }
+}
+
+static int simpledrm_device_init_clocks(struct simpledrm_device *sdev)
+{
+ struct drm_device *dev = >dev;
+ struct platform_device *pdev = sdev->pdev;
+ struct device_node *of_node = pdev->dev.of_node;
+ struct clk *clock;
+ unsigned int i;
+ int ret;
+
+ if (dev_get_platdata(>dev) || !of_node)
+ return 0;
+
+ sdev->clk_count = of_clk_get_parent_count(of_node);
+ if (!sdev->clk_count)
+ return 0;
+
+ sdev->clks = drmm_kzalloc(dev, sdev->clk_count * sizeof(sdev->clks[0]),
+ GFP_KERNEL);
+ if (!sdev->clks)
+ return -ENOMEM;
+
+ for (i = 0; i < sdev->clk_count; ++i) {
+ clock = of_clk_get(of_node, i);
+ if (IS_ERR(clock)) {
+ ret = PTR_ERR(clock);
+ if (ret == -EPROBE_DEFER)
+ goto err;
+ drm_err(dev, "clock %u not found: %d\n", i, ret);
+ continue;
+ }
+ ret = clk_prepare_enable(clock);
+ if (ret) {
+ drm_err(dev, "failed to enable clock %u: %d\n",
+ i, ret);
+ clk_put(clock);
+ }
+ sdev->clks[i] = clock;
+ }
+
+ return devm_add_action_or_reset(>dev,
+ simpledrm_device_release_clocks,
+ sdev);
+
+err:
+ while (i) {
+ --i;
+ if (sdev->clks[i]) {
+ clk_disable_unprepare(sdev->clks[i]);
+ clk_put(sdev->clks[i]);
+ }
+ }
+ return ret;
+}
+#else
+static int simpledrm_device_init_clocks(struct simpledrm_device *sdev)
+{
+ return 0;
+}
+#endif
+
/*
* Simplefb settings
*/
@@ -534,6 +639,9 @@ simpledrm_device_create(struct drm_driver *drv, struct
platform_device *pdev)
return ERR_CAST(sdev);
sdev->pdev = pdev;
+ ret = simpledrm_device_init_clocks(sdev);
+ if (ret)
+ return ERR_PTR(ret);
ret = simpledrm_device_init_fb(sdev);
if (ret)
return ERR_PTR(ret);
--
2.30.1
___
dri-devel mailing list
