Re: [PATCH 02/11] drm/ttm: cleanup io_mem interface with nouveau
On Tue, Jul 21, 2020 at 09:32:36AM +0200, Christian König wrote:
> Nouveau is the only user of this functionality and evicting io space
> on -EAGAIN is really a misuse of the return code.
>
> Instead switch to using -ENOSPC here which makes much more sense and
> simplifies the code.
>
> Signed-off-by: Christian König
Going from EAGAIN to something else could unbreak something that's held
together as a almost livelock restarting ioctls or whatever. So I looked
for that a bit:
- mmap path seems fine, all errors from the io_reserve stuff here get
remapped to sigbus
- but everywhere else we just pass down the errno it seems, and nouveau
has a bunch of kmaps all around (gpu relocs on pre-nv50 is probably the
big one, if we ignore the memcpy bo move fallback). I haven't found
anything that indicates those chips don't have the ioremapping hw, so
there's some risk I think. Otoh I also don't see anything that would
unbreak the lifelook, so feels minimally.
With that impact to pushbuf ioctl documented in the commit message somehow
this is Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/nouveau/nouveau_bo.c | 2 --
> drivers/gpu/drm/ttm/ttm_bo_util.c| 4 ++--
> 2 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 61355cfb7335..a48652826f67 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -1505,8 +1505,6 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
> struct ttm_mem_reg *reg)
> if (ret != 1) {
> if (WARN_ON(ret == 0))
> return -EINVAL;
> - if (ret == -ENOSPC)
> - return -EAGAIN;
> return ret;
> }
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
> b/drivers/gpu/drm/ttm/ttm_bo_util.c
> index 5e0f3a9caedc..7d2c50fef456 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
> @@ -116,7 +116,7 @@ static int ttm_mem_io_evict(struct ttm_mem_type_manager
> *man)
> struct ttm_buffer_object *bo;
>
> if (!man->use_io_reserve_lru || list_empty(&man->io_reserve_lru))
> - return -EAGAIN;
> + return -ENOSPC;
>
> bo = list_first_entry(&man->io_reserve_lru,
> struct ttm_buffer_object,
> @@ -143,7 +143,7 @@ int ttm_mem_io_reserve(struct ttm_bo_device *bdev,
> mem->bus.io_reserved_count++ == 0) {
> retry:
> ret = bdev->driver->io_mem_reserve(bdev, mem);
> - if (ret == -EAGAIN) {
> + if (ret == -ENOSPC) {
> ret = ttm_mem_io_evict(man);
> if (ret == 0)
> goto retry;
> --
> 2.17.1
>
> ___
> 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: [PATCH 03/11] drm/ttm: remove io_reserve_fastpath flag
On Tue, Jul 21, 2020 at 09:32:37AM +0200, Christian König wrote:
> Just use the use_io_reserve_lru flag. It doesn't make much
> sense to have two flags.
>
> Signed-off-by: Christian König
Yeah looks entirely redundant.
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/nouveau/nouveau_bo.c | 1 -
> drivers/gpu/drm/ttm/ttm_bo.c | 1 -
> drivers/gpu/drm/ttm/ttm_bo_util.c| 8
> include/drm/ttm/ttm_bo_driver.h | 2 --
> 4 files changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index a48652826f67..a1037478fa3f 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -675,7 +675,6 @@ nouveau_bo_init_mem_type(struct ttm_bo_device *bdev,
> uint32_t type,
> }
>
> man->func = &nouveau_vram_manager;
> - man->io_reserve_fastpath = false;
> man->use_io_reserve_lru = true;
> } else {
> man->func = &ttm_bo_manager_func;
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 7be36b9996ed..8b9e7f62bea7 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -1521,7 +1521,6 @@ int ttm_bo_init_mm(struct ttm_bo_device *bdev, unsigned
> type,
> BUG_ON(type >= TTM_NUM_MEM_TYPES);
> man = &bdev->man[type];
> BUG_ON(man->has_type);
> - man->io_reserve_fastpath = true;
> man->use_io_reserve_lru = false;
> mutex_init(&man->io_reserve_mutex);
> spin_lock_init(&man->move_lock);
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
> b/drivers/gpu/drm/ttm/ttm_bo_util.c
> index 7d2c50fef456..6c05f4fd15ae 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
> @@ -93,7 +93,7 @@ EXPORT_SYMBOL(ttm_bo_move_ttm);
>
> int ttm_mem_io_lock(struct ttm_mem_type_manager *man, bool interruptible)
> {
> - if (likely(man->io_reserve_fastpath))
> + if (likely(!man->use_io_reserve_lru))
> return 0;
>
> if (interruptible)
> @@ -105,7 +105,7 @@ int ttm_mem_io_lock(struct ttm_mem_type_manager *man,
> bool interruptible)
>
> void ttm_mem_io_unlock(struct ttm_mem_type_manager *man)
> {
> - if (likely(man->io_reserve_fastpath))
> + if (likely(!man->use_io_reserve_lru))
> return;
>
> mutex_unlock(&man->io_reserve_mutex);
> @@ -136,7 +136,7 @@ int ttm_mem_io_reserve(struct ttm_bo_device *bdev,
>
> if (!bdev->driver->io_mem_reserve)
> return 0;
> - if (likely(man->io_reserve_fastpath))
> + if (likely(!man->use_io_reserve_lru))
> return bdev->driver->io_mem_reserve(bdev, mem);
>
> if (bdev->driver->io_mem_reserve &&
> @@ -157,7 +157,7 @@ void ttm_mem_io_free(struct ttm_bo_device *bdev,
> {
> struct ttm_mem_type_manager *man = &bdev->man[mem->mem_type];
>
> - if (likely(man->io_reserve_fastpath))
> + if (likely(!man->use_io_reserve_lru))
> return;
>
> if (bdev->driver->io_mem_reserve &&
> diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
> index 732167cad130..45522e4fbd6b 100644
> --- a/include/drm/ttm/ttm_bo_driver.h
> +++ b/include/drm/ttm/ttm_bo_driver.h
> @@ -155,7 +155,6 @@ struct ttm_mem_type_manager_func {
> * @use_io_reserve_lru: Use an lru list to try to unreserve io_mem_regions
> * reserved by the TTM vm system.
> * @io_reserve_lru: Optional lru list for unreserving io mem regions.
> - * @io_reserve_fastpath: Only use bdev::driver::io_mem_reserve to obtain
> * @move_lock: lock for move fence
> * static information. bdev::driver::io_mem_free is never used.
> * @lru: The lru list for this memory type.
> @@ -184,7 +183,6 @@ struct ttm_mem_type_manager {
> void *priv;
> struct mutex io_reserve_mutex;
> bool use_io_reserve_lru;
> - bool io_reserve_fastpath;
> spinlock_t move_lock;
>
> /*
> --
> 2.17.1
>
> ___
> 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: [PATCH 04/11] drm/ttm: cleanup coding style and implementation.
On Tue, Jul 21, 2020 at 09:32:38AM +0200, Christian König wrote:
> Only functional change is to always keep io_reserved_count up to date
> for debugging even when it is not used otherwise.
Functional change in a cleanup patch. Tsk. It looks correct though ...
Reviewed-by: Daniel Vetter
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/ttm/ttm_bo_util.c | 97 +++
> 1 file changed, 48 insertions(+), 49 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
> b/drivers/gpu/drm/ttm/ttm_bo_util.c
> index 6c05f4fd15ae..7fb3e0bcbab4 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
> @@ -115,39 +115,35 @@ static int ttm_mem_io_evict(struct ttm_mem_type_manager
> *man)
> {
> struct ttm_buffer_object *bo;
>
> - if (!man->use_io_reserve_lru || list_empty(&man->io_reserve_lru))
> + bo = list_first_entry_or_null(&man->io_reserve_lru,
> + struct ttm_buffer_object,
> + io_reserve_lru);
> + if (!bo)
> return -ENOSPC;
>
> - bo = list_first_entry(&man->io_reserve_lru,
> - struct ttm_buffer_object,
> - io_reserve_lru);
> list_del_init(&bo->io_reserve_lru);
> ttm_bo_unmap_virtual_locked(bo);
> -
> return 0;
> }
>
> -
> int ttm_mem_io_reserve(struct ttm_bo_device *bdev,
> struct ttm_mem_reg *mem)
> {
> struct ttm_mem_type_manager *man = &bdev->man[mem->mem_type];
> - int ret = 0;
> + int ret;
> +
> + if (mem->bus.io_reserved_count++)
> + return 0;
>
> if (!bdev->driver->io_mem_reserve)
> return 0;
> - if (likely(!man->use_io_reserve_lru))
> - return bdev->driver->io_mem_reserve(bdev, mem);
>
> - if (bdev->driver->io_mem_reserve &&
> - mem->bus.io_reserved_count++ == 0) {
> retry:
> - ret = bdev->driver->io_mem_reserve(bdev, mem);
> - if (ret == -ENOSPC) {
> - ret = ttm_mem_io_evict(man);
> - if (ret == 0)
> - goto retry;
> - }
> + ret = bdev->driver->io_mem_reserve(bdev, mem);
> + if (ret == -ENOSPC) {
> + ret = ttm_mem_io_evict(man);
> + if (ret == 0)
> + goto retry;
> }
> return ret;
> }
> @@ -155,35 +151,31 @@ int ttm_mem_io_reserve(struct ttm_bo_device *bdev,
> void ttm_mem_io_free(struct ttm_bo_device *bdev,
>struct ttm_mem_reg *mem)
> {
> - struct ttm_mem_type_manager *man = &bdev->man[mem->mem_type];
> -
> - if (likely(!man->use_io_reserve_lru))
> + if (--mem->bus.io_reserved_count)
> return;
>
> - if (bdev->driver->io_mem_reserve &&
> - --mem->bus.io_reserved_count == 0 &&
> - bdev->driver->io_mem_free)
> - bdev->driver->io_mem_free(bdev, mem);
> + if (!bdev->driver->io_mem_free)
> + return;
>
> + bdev->driver->io_mem_free(bdev, mem);
> }
>
> int ttm_mem_io_reserve_vm(struct ttm_buffer_object *bo)
> {
> + struct ttm_mem_type_manager *man = &bo->bdev->man[bo->mem.mem_type];
> struct ttm_mem_reg *mem = &bo->mem;
> int ret;
>
> - if (!mem->bus.io_reserved_vm) {
> - struct ttm_mem_type_manager *man =
> - &bo->bdev->man[mem->mem_type];
> + if (mem->bus.io_reserved_vm)
> + return 0;
>
> - ret = ttm_mem_io_reserve(bo->bdev, mem);
> - if (unlikely(ret != 0))
> - return ret;
> - mem->bus.io_reserved_vm = true;
> - if (man->use_io_reserve_lru)
> - list_add_tail(&bo->io_reserve_lru,
> - &man->io_reserve_lru);
> - }
> + ret = ttm_mem_io_reserve(bo->bdev, mem);
> + if (unlikely(ret != 0))
> + return ret;
> + mem->bus.io_reserved_vm = true;
> + if (man->use_io_reserve_lru)
> + list_add_tail(&bo->io_reserve_lru,
> + &man->io_reserve_lru);
> return 0;
> }
>
> @@ -191,15 +183,17 @@ void ttm_mem_io_free_vm(struct ttm_buffer_object *bo)
> {
> struct ttm_mem_reg *mem = &bo->mem;
>
> - if (mem->bus.io_r
Re: [PATCH 05/11] drm/ttm: remove TTM_MEMTYPE_FLAG_CMA
On Tue, Jul 21, 2020 at 09:32:39AM +0200, Christian König wrote:
> The original intention was to avoid CPU page table unmaps
> when BOs move between the GTT and SYSTEM domain.
>
> The problem is that this never correctly handled changes
> in the caching attributes or backing pages.
>
> Just drop this for now and simply unmap the CPU page
> tables in all cases.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 4 +--
> drivers/gpu/drm/nouveau/nouveau_bo.c | 3 +-
> drivers/gpu/drm/radeon/radeon_ttm.c| 2 +-
> drivers/gpu/drm/ttm/ttm_bo.c | 34 --
> drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 2 +-
> include/drm/ttm/ttm_bo_driver.h| 1 -
> 6 files changed, 11 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> index 9c0f12f74af9..44fa8bc49d18 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> @@ -93,7 +93,7 @@ static int amdgpu_init_mem_type(struct ttm_bo_device *bdev,
> uint32_t type,
> man->func = &amdgpu_gtt_mgr_func;
> man->available_caching = TTM_PL_MASK_CACHING;
> man->default_caching = TTM_PL_FLAG_CACHED;
> - man->flags = TTM_MEMTYPE_FLAG_MAPPABLE | TTM_MEMTYPE_FLAG_CMA;
> + man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
> break;
> case TTM_PL_VRAM:
> /* "On-card" video ram */
> @@ -108,7 +108,7 @@ static int amdgpu_init_mem_type(struct ttm_bo_device
> *bdev, uint32_t type,
> case AMDGPU_PL_OA:
> /* On-chip GDS memory*/
> man->func = &ttm_bo_manager_func;
> - man->flags = TTM_MEMTYPE_FLAG_FIXED | TTM_MEMTYPE_FLAG_CMA;
> + man->flags = TTM_MEMTYPE_FLAG_FIXED;
> man->available_caching = TTM_PL_FLAG_UNCACHED;
> man->default_caching = TTM_PL_FLAG_UNCACHED;
> break;
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index a1037478fa3f..7883341f8c83 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -695,8 +695,7 @@ nouveau_bo_init_mem_type(struct ttm_bo_device *bdev,
> uint32_t type,
> TTM_PL_FLAG_WC;
> man->default_caching = TTM_PL_FLAG_WC;
> } else {
> - man->flags = TTM_MEMTYPE_FLAG_MAPPABLE |
> - TTM_MEMTYPE_FLAG_CMA;
> + man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
> man->available_caching = TTM_PL_MASK_CACHING;
> man->default_caching = TTM_PL_FLAG_CACHED;
> }
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index 73085523fad7..54af06df865b 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -84,7 +84,7 @@ static int radeon_init_mem_type(struct ttm_bo_device *bdev,
> uint32_t type,
> man->func = &ttm_bo_manager_func;
> man->available_caching = TTM_PL_MASK_CACHING;
> man->default_caching = TTM_PL_FLAG_CACHED;
> - man->flags = TTM_MEMTYPE_FLAG_MAPPABLE | TTM_MEMTYPE_FLAG_CMA;
> + man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
> #if IS_ENABLED(CONFIG_AGP)
> if (rdev->flags & RADEON_IS_AGP) {
> if (!rdev->ddev->agp) {
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 8b9e7f62bea7..0768a054a916 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -272,20 +272,15 @@ static int ttm_bo_handle_move_mem(struct
> ttm_buffer_object *bo,
> struct ttm_operation_ctx *ctx)
> {
> struct ttm_bo_device *bdev = bo->bdev;
> - bool old_is_pci = ttm_mem_reg_is_pci(bdev, &bo->mem);
> - bool new_is_pci = ttm_mem_reg_is_pci(bdev, mem);
> struct ttm_mem_type_manager *old_man = &bdev->man[bo->mem.mem_type];
> struct ttm_mem_type_manager *new_man = &bdev->man[mem->mem_type];
> - int ret = 0;
> + int ret;
>
> - if (old_is_pci || new_is_pci ||
> - ((mem->placement & bo->mem.placement & TTM_PL_MASK_CACHING) == 0)) {
> - ret = ttm_mem_io_lock(old_man, true);
> - if (unlikely(ret != 0))
> - goto out_err;
> -
Re: [PATCH 06/11] drm/radeon: stop using TTM_MEMTYPE_FLAG_MAPPABLE
On Tue, Jul 21, 2020 at 09:32:40AM +0200, Christian König wrote:
> The driver doesn't expose any not-mapable memory resources.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/radeon/radeon_ttm.c | 13 -
> 1 file changed, 4 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index 54af06df865b..b474781a0920 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -76,7 +76,7 @@ static int radeon_init_mem_type(struct ttm_bo_device *bdev,
> uint32_t type,
> switch (type) {
> case TTM_PL_SYSTEM:
> /* System memory */
> - man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
> + man->flags = 0;
> man->available_caching = TTM_PL_MASK_CACHING;
> man->default_caching = TTM_PL_FLAG_CACHED;
> break;
> @@ -84,7 +84,7 @@ static int radeon_init_mem_type(struct ttm_bo_device *bdev,
> uint32_t type,
> man->func = &ttm_bo_manager_func;
> man->available_caching = TTM_PL_MASK_CACHING;
> man->default_caching = TTM_PL_FLAG_CACHED;
> - man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
> + man->flags = 0;
> #if IS_ENABLED(CONFIG_AGP)
> if (rdev->flags & RADEON_IS_AGP) {
> if (!rdev->ddev->agp) {
> @@ -92,8 +92,6 @@ static int radeon_init_mem_type(struct ttm_bo_device *bdev,
> uint32_t type,
> (unsigned)type);
> return -EINVAL;
> }
> - if (!rdev->ddev->agp->cant_use_aperture)
> - man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
There is a bunch of agp drivers (alpha, ppc, that kind of stuff) with this
flag set. And radeon.ko did at least once work on these. And your patch to
disable agp only changes the default, it doesn't rip out the code.
So not sure your assumption here is correct.
-Daniel
> man->available_caching = TTM_PL_FLAG_UNCACHED |
>TTM_PL_FLAG_WC;
> man->default_caching = TTM_PL_FLAG_WC;
> @@ -103,8 +101,7 @@ static int radeon_init_mem_type(struct ttm_bo_device
> *bdev, uint32_t type,
> case TTM_PL_VRAM:
> /* "On-card" video ram */
> man->func = &ttm_bo_manager_func;
> - man->flags = TTM_MEMTYPE_FLAG_FIXED |
> - TTM_MEMTYPE_FLAG_MAPPABLE;
> + man->flags = TTM_MEMTYPE_FLAG_FIXED;
> man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
> man->default_caching = TTM_PL_FLAG_WC;
> break;
> @@ -394,7 +391,6 @@ static int radeon_bo_move(struct ttm_buffer_object *bo,
> bool evict,
>
> static int radeon_ttm_io_mem_reserve(struct ttm_bo_device *bdev, struct
> ttm_mem_reg *mem)
> {
> - struct ttm_mem_type_manager *man = &bdev->man[mem->mem_type];
> struct radeon_device *rdev = radeon_get_rdev(bdev);
>
> mem->bus.addr = NULL;
> @@ -402,8 +398,7 @@ static int radeon_ttm_io_mem_reserve(struct ttm_bo_device
> *bdev, struct ttm_mem_
> mem->bus.size = mem->num_pages << PAGE_SHIFT;
> mem->bus.base = 0;
> mem->bus.is_iomem = false;
> - if (!(man->flags & TTM_MEMTYPE_FLAG_MAPPABLE))
> - return -EINVAL;
> +
> switch (mem->mem_type) {
> case TTM_PL_SYSTEM:
> /* system memory */
> --
> 2.17.1
>
> ___
> 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: [PATCH 07/11] drm/vmwgfx: stop using TTM_MEMTYPE_FLAG_MAPPABLE
On Tue, Jul 21, 2020 at 09:32:41AM +0200, Christian König wrote:
> The driver doesn't expose any not-mapable memory resources.
>
> Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 9 ++---
> 1 file changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> index 6bea7548aee0..1d78187eaba6 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> @@ -742,15 +742,13 @@ static int vmw_init_mem_type(struct ttm_bo_device
> *bdev, uint32_t type,
> switch (type) {
> case TTM_PL_SYSTEM:
> /* System memory */
> -
> - man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
> man->available_caching = TTM_PL_FLAG_CACHED;
> man->default_caching = TTM_PL_FLAG_CACHED;
> break;
> case TTM_PL_VRAM:
> /* "On-card" video ram */
> man->func = &vmw_thp_func;
> - man->flags = TTM_MEMTYPE_FLAG_FIXED | TTM_MEMTYPE_FLAG_MAPPABLE;
> + man->flags = TTM_MEMTYPE_FLAG_FIXED;
> man->available_caching = TTM_PL_FLAG_CACHED;
> man->default_caching = TTM_PL_FLAG_CACHED;
> break;
> @@ -762,7 +760,6 @@ static int vmw_init_mem_type(struct ttm_bo_device *bdev,
> uint32_t type,
>* slots as well as the bo size.
>*/
> man->func = &vmw_gmrid_manager_func;
> - man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
> man->available_caching = TTM_PL_FLAG_CACHED;
> man->default_caching = TTM_PL_FLAG_CACHED;
> break;
> @@ -789,7 +786,6 @@ static int vmw_verify_access(struct ttm_buffer_object
> *bo, struct file *filp)
>
> static int vmw_ttm_io_mem_reserve(struct ttm_bo_device *bdev, struct
> ttm_mem_reg *mem)
> {
> - struct ttm_mem_type_manager *man = &bdev->man[mem->mem_type];
> struct vmw_private *dev_priv = container_of(bdev, struct vmw_private,
> bdev);
>
> mem->bus.addr = NULL;
> @@ -797,8 +793,7 @@ static int vmw_ttm_io_mem_reserve(struct ttm_bo_device
> *bdev, struct ttm_mem_reg
> mem->bus.offset = 0;
> mem->bus.size = mem->num_pages << PAGE_SHIFT;
> mem->bus.base = 0;
> - if (!(man->flags & TTM_MEMTYPE_FLAG_MAPPABLE))
> - return -EINVAL;
> +
> switch (mem->mem_type) {
> case TTM_PL_SYSTEM:
> case VMW_PL_GMR:
> --
> 2.17.1
>
> ___
> 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: [PATCH 08/11] drm/amdgpu: stop using TTM_MEMTYPE_FLAG_MAPPABLE
On Tue, Jul 21, 2020 at 09:32:42AM +0200, Christian König wrote:
> The driver does support some not-mapable resources, but
> those are already handled correctly in the switch/case
> statement in the code.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 11 ---
> 1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> index 44fa8bc49d18..0dd5e802091d 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> @@ -84,7 +84,7 @@ static int amdgpu_init_mem_type(struct ttm_bo_device *bdev,
> uint32_t type,
> switch (type) {
> case TTM_PL_SYSTEM:
> /* System memory */
> - man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
> + man->flags = 0;
> man->available_caching = TTM_PL_MASK_CACHING;
> man->default_caching = TTM_PL_FLAG_CACHED;
> break;
> @@ -93,13 +93,12 @@ static int amdgpu_init_mem_type(struct ttm_bo_device
> *bdev, uint32_t type,
> man->func = &amdgpu_gtt_mgr_func;
> man->available_caching = TTM_PL_MASK_CACHING;
> man->default_caching = TTM_PL_FLAG_CACHED;
> - man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
> + man->flags = 0;
> break;
> case TTM_PL_VRAM:
> /* "On-card" video ram */
> man->func = &amdgpu_vram_mgr_func;
> - man->flags = TTM_MEMTYPE_FLAG_FIXED |
> - TTM_MEMTYPE_FLAG_MAPPABLE;
> + man->flags = TTM_MEMTYPE_FLAG_FIXED;
> man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
> man->default_caching = TTM_PL_FLAG_WC;
> break;
> @@ -796,7 +795,6 @@ static int amdgpu_bo_move(struct ttm_buffer_object *bo,
> bool evict,
> */
> static int amdgpu_ttm_io_mem_reserve(struct ttm_bo_device *bdev, struct
> ttm_mem_reg *mem)
> {
> - struct ttm_mem_type_manager *man = &bdev->man[mem->mem_type];
> struct amdgpu_device *adev = amdgpu_ttm_adev(bdev);
> struct drm_mm_node *mm_node = mem->mm_node;
>
> @@ -805,8 +803,7 @@ static int amdgpu_ttm_io_mem_reserve(struct ttm_bo_device
> *bdev, struct ttm_mem_
> mem->bus.size = mem->num_pages << PAGE_SHIFT;
> mem->bus.base = 0;
> mem->bus.is_iomem = false;
> - if (!(man->flags & TTM_MEMTYPE_FLAG_MAPPABLE))
> - return -EINVAL;
This check catches the various special on-board memories, or at least I
couldnt' find where mmap for these is disallowed.
-Daniel
> +
> switch (mem->mem_type) {
> case TTM_PL_SYSTEM:
> /* system memory */
> --
> 2.17.1
>
> ___
> 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: [PATCH 09/11] drm/nouveau: stop using TTM_MEMTYPE_FLAG_MAPPABLE
On Tue, Jul 21, 2020 at 09:32:43AM +0200, Christian König wrote:
> The driver doesn't expose any not-mapable memory resources.
>
> Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/nouveau/nouveau_bo.c | 13 +
> 1 file changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 7883341f8c83..4ccf937df0d0 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -655,13 +655,12 @@ nouveau_bo_init_mem_type(struct ttm_bo_device *bdev,
> uint32_t type,
>
> switch (type) {
> case TTM_PL_SYSTEM:
> - man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
> + man->flags = 0;
> man->available_caching = TTM_PL_MASK_CACHING;
> man->default_caching = TTM_PL_FLAG_CACHED;
> break;
> case TTM_PL_VRAM:
> - man->flags = TTM_MEMTYPE_FLAG_FIXED |
> - TTM_MEMTYPE_FLAG_MAPPABLE;
> + man->flags = TTM_MEMTYPE_FLAG_FIXED;
> man->available_caching = TTM_PL_FLAG_UNCACHED |
>TTM_PL_FLAG_WC;
> man->default_caching = TTM_PL_FLAG_WC;
> @@ -690,12 +689,12 @@ nouveau_bo_init_mem_type(struct ttm_bo_device *bdev,
> uint32_t type,
> man->func = &ttm_bo_manager_func;
>
> if (drm->agp.bridge) {
> - man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
> + man->flags = 0;
> man->available_caching = TTM_PL_FLAG_UNCACHED |
> TTM_PL_FLAG_WC;
> man->default_caching = TTM_PL_FLAG_WC;
> } else {
> - man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
> + man->flags = 0;
> man->available_caching = TTM_PL_MASK_CACHING;
> man->default_caching = TTM_PL_FLAG_CACHED;
> }
> @@ -1437,7 +1436,6 @@ nouveau_bo_verify_access(struct ttm_buffer_object *bo,
> struct file *filp)
> static int
> nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev, struct ttm_mem_reg
> *reg)
> {
> - struct ttm_mem_type_manager *man = &bdev->man[reg->mem_type];
> struct nouveau_drm *drm = nouveau_bdev(bdev);
> struct nvkm_device *device = nvxx_device(&drm->client.device);
> struct nouveau_mem *mem = nouveau_mem(reg);
> @@ -1447,8 +1445,7 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
> struct ttm_mem_reg *reg)
> reg->bus.size = reg->num_pages << PAGE_SHIFT;
> reg->bus.base = 0;
> reg->bus.is_iomem = false;
> - if (!(man->flags & TTM_MEMTYPE_FLAG_MAPPABLE))
> - return -EINVAL;
> +
> switch (reg->mem_type) {
> case TTM_PL_SYSTEM:
> /* System memory */
> --
> 2.17.1
>
> ___
> 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: [PATCH 10/11] drm/qxl: stop using TTM_MEMTYPE_FLAG_MAPPABLE v2
On Tue, Jul 21, 2020 at 09:32:44AM +0200, Christian König wrote:
> The driver doesn't expose any not-mapable memory resources.
>
> v2: remove unused man variable as well
>
> Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/qxl/qxl_ttm.c | 9 +++--
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
> index a6e67149ef4a..1d8e07b8b19e 100644
> --- a/drivers/gpu/drm/qxl/qxl_ttm.c
> +++ b/drivers/gpu/drm/qxl/qxl_ttm.c
> @@ -54,7 +54,7 @@ static int qxl_init_mem_type(struct ttm_bo_device *bdev,
> uint32_t type,
> switch (type) {
> case TTM_PL_SYSTEM:
> /* System memory */
> - man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
> + man->flags = 0;
> man->available_caching = TTM_PL_MASK_CACHING;
> man->default_caching = TTM_PL_FLAG_CACHED;
> break;
> @@ -62,8 +62,7 @@ static int qxl_init_mem_type(struct ttm_bo_device *bdev,
> uint32_t type,
> case TTM_PL_PRIV:
> /* "On-card" video ram */
> man->func = &ttm_bo_manager_func;
> - man->flags = TTM_MEMTYPE_FLAG_FIXED |
> - TTM_MEMTYPE_FLAG_MAPPABLE;
> + man->flags = TTM_MEMTYPE_FLAG_FIXED;
> man->available_caching = TTM_PL_MASK_CACHING;
> man->default_caching = TTM_PL_FLAG_CACHED;
> break;
> @@ -99,7 +98,6 @@ static void qxl_evict_flags(struct ttm_buffer_object *bo,
> int qxl_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
> struct ttm_mem_reg *mem)
> {
> - struct ttm_mem_type_manager *man = &bdev->man[mem->mem_type];
> struct qxl_device *qdev = qxl_get_qdev(bdev);
>
> mem->bus.addr = NULL;
> @@ -107,8 +105,7 @@ int qxl_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
> mem->bus.size = mem->num_pages << PAGE_SHIFT;
> mem->bus.base = 0;
> mem->bus.is_iomem = false;
> - if (!(man->flags & TTM_MEMTYPE_FLAG_MAPPABLE))
> - return -EINVAL;
> +
> switch (mem->mem_type) {
> case TTM_PL_SYSTEM:
> /* system memory */
> --
> 2.17.1
>
> ___
> 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: [PATCH 11/11] drm/ttm: remove TTM_MEMTYPE_FLAG_MAPPABLE
On Tue, Jul 21, 2020 at 09:32:45AM +0200, Christian König wrote: > Not used any more. And it is bad design to use a TTM flag > to do a check inside a driver. > > Signed-off-by: Christian König > --- > include/drm/ttm/ttm_bo_driver.h | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h > index 71b195e78c7c..9b251853afe2 100644 > --- a/include/drm/ttm/ttm_bo_driver.h > +++ b/include/drm/ttm/ttm_bo_driver.h > @@ -46,7 +46,6 @@ > #define TTM_MAX_BO_PRIORITY 4U > > #define TTM_MEMTYPE_FLAG_FIXED (1 << 0) /* Fixed (on-card) PCI > memory */ > -#define TTM_MEMTYPE_FLAG_MAPPABLE (1 << 1) /* Memory mappable */ I think you can still do this, and it makes sense to delete: Just code a driver-specific check in the io callback which checks whether a buffer can be mappable directly, instead of going through the indirection of using this flag. -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] drm/vkms: add missing drm_crtc_vblank_put to the get/put pair on flush
On Wed, Jul 22, 2020 at 08:04:11AM -0300, Melissa Wen wrote: > This patch adds a missing drm_crtc_vblank_put op to the pair > drm_crtc_vblank_get/put (inc/decrement counter to guarantee vblanks). > > It clears the execution of the following kms_cursor_crc subtests: > 1. pipe-A-cursor-[size,alpha-opaque, NxN-(on-screen, off-screen, sliding, >random, fast-moving])] - successful when running individually. > 2. pipe-A-cursor-dpms passes again > 3. pipe-A-cursor-suspend also passes > > The issue was initially tracked in the sequential execution of IGT > kms_cursor_crc subtest: when running the test sequence or one of its > subtests twice, the odd execs complete and the pairs get stuck in an > endless wait. In the IGT code, calling a wait_for_vblank before the start > of CRC capture prevented the busy-wait. But the problem persisted in the > pipe-A-cursor-dpms and -suspend subtests. > > Checking the history, the pipe-A-cursor-dpms subtest was successful when, > in vkms_atomic_commit_tail, instead of using the flip_done op, it used > wait_for_vblanks. Another way to prevent blocking was wait_one_vblank when > enabling crtc. However, in both cases, pipe-A-cursor-suspend persisted > blocking in the 2nd start of CRC capture, which may indicate that > something got stuck in the step of CRC setup. Indeed, wait_one_vblank in > the crc setup was able to sync things and free all kms_cursor_crc > subtests. > > Tracing and comparing a clean run with a blocked one: > - in a clean one, vkms_crtc_atomic_flush enables vblanks; > - when blocked, only in next op, vkms_crtc_atomic_enable, the vblanks > started. Moreover, a series of vkms_vblank_simulate flow out until > disabling vblanks. > Also watching the steps of vkms_crtc_atomic_flush, when the very first > drm_crtc_vblank_get returned an error, the subtest crashed. On the other > hand, when vblank_get succeeded, the subtest completed. Finally, checking > the flush steps: it increases counter to hold a vblank reference (get), > but there isn't a op to decreased it and release vblanks (put). > > Cc: Daniel Vetter > Cc: Rodrigo Siqueira > Cc: Haneen Mohammed > Signed-off-by: Melissa Wen > --- > drivers/gpu/drm/vkms/vkms_crtc.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c > b/drivers/gpu/drm/vkms/vkms_crtc.c > index ac85e17428f8..a99d6b4a92dd 100644 > --- a/drivers/gpu/drm/vkms/vkms_crtc.c > +++ b/drivers/gpu/drm/vkms/vkms_crtc.c > @@ -246,6 +246,7 @@ static void vkms_crtc_atomic_flush(struct drm_crtc *crtc, > > spin_unlock(&crtc->dev->event_lock); > > + drm_crtc_vblank_put(crtc); Uh so I reviewed this a bit more carefully now, and I dont think this is the correct bugfix. From the kerneldoc of drm_crtc_arm_vblank_event(): * Caller must hold a vblank reference for the event @e acquired by a * drm_crtc_vblank_get(), which will be dropped when the next vblank arrives. So when we call drm_crtc_arm_vblank_event then the vblank_put gets called for us. And that's the only case where we successfully acquired a vblank interrupt reference since on failure of drm_crtc_vblank_get (0 indicates success for that function, failure negative error number) we directly send out the event. So something else fishy is going on, and now I'm totally confused why this even happens. We also have a pile of WARN_ON checks in drm_crtc_vblank_put to make sure we don't underflow the refcount, so it's also not that I think (except if this patch creates more WARNING backtraces). But clearly it changes behaviour somehow ... can you try to figure out what changes? Maybe print out the vblank->refcount at various points in the driver, and maybe also trace when exactly the fake vkms vblank hrtimer is enabled/disabled ... I'm totally confused about what's going on here now. -Daniel > crtc->state->event = NULL; > } > > -- > 2.27.0 > -- 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 5/8] drm/imx: parallel-display: use drm managed resources
On Wed, Jul 22, 2020 at 04:01:53PM +0200, Philipp Zabel wrote:
> On Wed, 2020-07-22 at 15:30 +0200, Philipp Zabel wrote:
> [...]
> > and use drmm_add_action_or_reset() to make sure drm_encoder_cleanup() is
> > called before the memory is freed.
> [...]
> > @@ -259,6 +259,13 @@ static const struct drm_bridge_funcs
> > imx_pd_bridge_funcs = {
> > .atomic_get_output_bus_fmts = imx_pd_bridge_atomic_get_output_bus_fmts,
> > };
> >
> > +static void imx_pd_encoder_cleanup(struct drm_device *drm, void *ptr)
> > +{
> > + struct drm_encoder *encoder = ptr;
> > +
> > + drm_encoder_cleanup(encoder);
> > +}
> > +
> > static int imx_pd_register(struct drm_device *drm,
> > struct imx_parallel_display *imxpd)
> > {
> > @@ -276,7 +283,13 @@ static int imx_pd_register(struct drm_device *drm,
> > */
> > imxpd->connector.dpms = DRM_MODE_DPMS_OFF;
> >
> > - drm_simple_encoder_init(drm, encoder, DRM_MODE_ENCODER_NONE);
> > + ret = drm_simple_encoder_init(drm, encoder, DRM_MODE_ENCODER_NONE);
> > + if (ret)
> > + return ret;
> > +
> > + ret = drmm_add_action_or_reset(drm, imx_pd_encoder_cleanup, encoder);
> > + if (ret)
> > + return ret;
>
> This is only required because this is a component driver: our
> drmm_kzalloc() is called after drmm_mode_config_init(), so we can't rely
> on drm_mode_config_init_release() for cleanup. That is only called after
> drmres already freed our memory.
Yeah I know about the inversion, which is why I haven't yet started typing
the mass conversion for all the drm objects. I think the explicit
drmm_add_action_or_reset is indeed the way to go, except we probably want
some helpers to wrap the allocation, drm_foo_init and adding the reset
action all into one thing (plus you can stuff the reset action into the
allocation instead of the kfree action only, even nicer that way).
But that's maybe for later, and good to have some examples in drivers
already converted over as guidance.
On the series: Acked-by: Daniel Vetter
But way too late for solid review :-)
Cheers, Daniel
>
> regards
> Philipp
> ___
> 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: [PATCH] drm/simple_kms_helper: add drmm_simple_encoder_init()
On Wed, Jul 22, 2020 at 05:08:03PM +0200, Philipp Zabel wrote:
> Hi Thomas,
>
> thank you for your comment.
>
> On Wed, 2020-07-22 at 16:43 +0200, Thomas Zimmermann wrote:
> > Hi
> >
> > Am 22.07.20 um 15:25 schrieb Philipp Zabel:
> > > Add a drm_simple_encoder_init() variant that registers
> > > drm_encoder_cleanup() with drmm_add_action().
> > >
> > > Now drivers can store encoders in memory allocated with drmm_kmalloc()
> > > after the call to drmm_mode_config_init(), without having to manually
> > > make sure that drm_encoder_cleanup() is called before the memory is
> > > freed.
> > >
> > > Signed-off-by: Philipp Zabel
> > > ---
> > > drivers/gpu/drm/drm_simple_kms_helper.c | 42 +
> > > include/drm/drm_simple_kms_helper.h | 4 +++
> > > 2 files changed, 46 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
> > > b/drivers/gpu/drm/drm_simple_kms_helper.c
> > > index 74946690aba4..a243f00cf63d 100644
> > > --- a/drivers/gpu/drm/drm_simple_kms_helper.c
> > > +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> > > @@ -9,6 +9,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #include
> > > #include
> > > #include
> > > @@ -71,6 +72,47 @@ int drm_simple_encoder_init(struct drm_device *dev,
> > > }
> > > EXPORT_SYMBOL(drm_simple_encoder_init);
> > >
> > > +static void drmm_encoder_cleanup(struct drm_device *dev, void *ptr)
> > > +{
> > > + struct drm_encoder *encoder = ptr;
> > > +
> > > + drm_encoder_cleanup(encoder);
> > > +}
> >
> > This doesn't work. DRM cleans up the encoder by invoking the destroy
> > callback from the encoder functions. This additional helper would
> > cleanup the encoder a second time.
>
> Indeed this would require the encoder destroy callback to be NULL.
Yeah the drmm_ versions of these need to check that the ->cleanup hook is
NULL.
Also there's not actually a double-free, since drm_foo_cleanup removes it
from the lists, which means drm_mode_config_cleanup won't even see it. But
if the driver has some additional code in ->cleanup that won't ever run,
so probably still a bug.
I also think that the drmm_foo_ wrappers should also do the allocation
(and upcasting) kinda like drmm_dev_alloc(). Otherwise we're still stuck
with tons of boilerplate.
For now I think it's ok if drivers that switch to drmm_ just copypaste,
until we're sure this is the right thing to do. And then maybe also roll
these out for all objects that stay for the entire lifetime of drm_device
(plane, crtc, encoder, plus variants). Just to make sure we're consistent
across all of them.
-Daniel
> > You can already embed the encoder in another structure and things should
> > work as expected.
>
> If the embedding structure is a component allocated with drmm_kmalloc()
> after the call to drmm_mode_config_init(), the structure will already be
> freed before the destroy callback is run from
> drmm_mode_config_init_release().
>
> regards
> Philipp
> ___
> 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: [PATCH -next 1/2] drm: Remove redundant NULL check
On Thu, Jul 23, 2020 at 11:27:42AM +0800, Li Heng wrote:
> Fix below warnings reported by coccicheck:
> ./drivers/gpu/drm/drm_drv.c:819:2-7: WARNING: NULL check before some freeing
> functions is not needed.
>
> Fixes: 5dad34f3c444 ("drm: Cleanups after drmm_add_final_kfree rollout")
> Signed-off-by: Li Heng
Queued up, should make it into 5.9 merge window, thanks for your patch.
-Daniel
> ---
> drivers/gpu/drm/drm_drv.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index bc38322..13068fd 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -815,8 +815,7 @@ static void drm_dev_release(struct kref *ref)
>
> drm_managed_release(dev);
>
> - if (dev->managed.final_kfree)
> - kfree(dev->managed.final_kfree);
> + kfree(dev->managed.final_kfree);
> }
>
> /**
> --
> 2.7.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/9] drm/ttm: initialize the system domain with defaults
pu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> @@ -742,8 +742,6 @@ static int vmw_init_mem_type(struct ttm_bo_device *bdev,
> uint32_t type,
> switch (type) {
> case TTM_PL_SYSTEM:
> /* System memory */
> - man->available_caching = TTM_PL_FLAG_CACHED;
Above is CACHED, not CACHING, so needs to stay to overwrite the default.
With that fixed:
Reviewed-by: Daniel Vetter
> - man->default_caching = TTM_PL_FLAG_CACHED;
> break;
> case TTM_PL_VRAM:
> /* "On-card" video ram */
> --
> 2.17.1
>
> ___
> 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: [PATCH 2/9] drm/ttm: remove TTM_MEMTYPE_FLAG_FIXED
ttm_bo_init_mm(bdev, TTM_PL_SYSTEM, 0);
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
> b/drivers/gpu/drm/ttm/ttm_bo_util.c
> index 7fb3e0bcbab4..1f502be0b646 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
> @@ -384,7 +384,7 @@ int ttm_bo_move_memcpy(struct ttm_buffer_object *bo,
> *old_mem = *new_mem;
> new_mem->mm_node = NULL;
>
> - if (man->flags & TTM_MEMTYPE_FLAG_FIXED) {
> + if (!man->use_tt) {
> ttm_tt_destroy(ttm);
> bo->ttm = NULL;
> }
> @@ -645,7 +645,7 @@ int ttm_bo_move_accel_cleanup(struct ttm_buffer_object
> *bo,
> if (ret)
> return ret;
>
> - if (man->flags & TTM_MEMTYPE_FLAG_FIXED) {
> + if (!man->use_tt) {
> ttm_tt_destroy(bo->ttm);
> bo->ttm = NULL;
> }
> @@ -674,7 +674,7 @@ int ttm_bo_move_accel_cleanup(struct ttm_buffer_object
> *bo,
>* bo to be unbound and destroyed.
>*/
>
> - if (!(man->flags & TTM_MEMTYPE_FLAG_FIXED))
> + if (man->use_tt)
> ghost_obj->ttm = NULL;
> else
> bo->ttm = NULL;
> @@ -730,7 +730,7 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
>* bo to be unbound and destroyed.
>*/
>
> - if (!(to->flags & TTM_MEMTYPE_FLAG_FIXED))
> + if (to->use_tt)
> ghost_obj->ttm = NULL;
> else
> bo->ttm = NULL;
> @@ -738,7 +738,7 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
> dma_resv_unlock(&ghost_obj->base._resv);
> ttm_bo_put(ghost_obj);
>
> - } else if (from->flags & TTM_MEMTYPE_FLAG_FIXED) {
> + } else if (!from->use_tt) {
>
> /**
>* BO doesn't have a TTM we need to bind/unbind. Just remember
> @@ -768,7 +768,7 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
> if (ret)
> return ret;
>
> - if (to->flags & TTM_MEMTYPE_FLAG_FIXED) {
> + if (!to->use_tt) {
> ttm_tt_destroy(bo->ttm);
> bo->ttm = NULL;
> }
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> index 00cef1a3a178..5d8179d9f394 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> @@ -746,7 +746,6 @@ static int vmw_init_mem_type(struct ttm_bo_device *bdev,
> uint32_t type,
> case TTM_PL_VRAM:
> /* "On-card" video ram */
> man->func = &vmw_thp_func;
> - man->flags = TTM_MEMTYPE_FLAG_FIXED;
> man->available_caching = TTM_PL_FLAG_CACHED;
> man->default_caching = TTM_PL_FLAG_CACHED;
> break;
> @@ -760,6 +759,8 @@ static int vmw_init_mem_type(struct ttm_bo_device *bdev,
> uint32_t type,
> man->func = &vmw_gmrid_manager_func;
> man->available_caching = TTM_PL_FLAG_CACHED;
> man->default_caching = TTM_PL_FLAG_CACHED;
> + /* TODO: This is most likely not correct */
Comment suggests it's a remapping thing, and I've seen some idr allocator
thing in vmwgfx before, i.e. it allocates remapping ids for bo, instead of
remapping space. So I think this is all ok, and no need for the TODO here.
With that:
Reviewed-by: Daniel Vetter
> + man->use_tt = true;
> break;
> default:
> DRM_ERROR("Unsupported memory type %u\n", (unsigned)type);
> diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
> index 9b251853afe2..adac4cd0ba23 100644
> --- a/include/drm/ttm/ttm_bo_driver.h
> +++ b/include/drm/ttm/ttm_bo_driver.h
> @@ -45,8 +45,6 @@
>
> #define TTM_MAX_BO_PRIORITY 4U
>
> -#define TTM_MEMTYPE_FLAG_FIXED (1 << 0) /* Fixed (on-card) PCI
> memory */
> -
> struct ttm_mem_type_manager;
>
> struct ttm_mem_type_manager_func {
> @@ -173,7 +171,7 @@ struct ttm_mem_type_manager {
>
> bool has_type;
> bool use_type;
> - uint32_t flags;
> + bool use_tt;
> uint64_t size;
> uint32_t available_caching;
> uint32_t default_caching;
> --
> 2.17.1
>
> ___
> 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: [PATCH 2/9] drm/ttm: remove TTM_MEMTYPE_FLAG_FIXED
riority]);
> > > @@ -286,8 +286,8 @@ static int ttm_bo_handle_move_mem(struct
> > > ttm_buffer_object *bo,
> > >* Create and bind a ttm if required.
> > >*/
> > > - if (!(new_man->flags & TTM_MEMTYPE_FLAG_FIXED)) {
> > > - bool zero = !(old_man->flags & TTM_MEMTYPE_FLAG_FIXED);
> > > + if (new_man->use_tt) {
> > > + bool zero = old_man->use_tt;
> > > ret = ttm_tt_create(bo, zero);
> > > if (ret)
> > > @@ -314,8 +314,7 @@ static int ttm_bo_handle_move_mem(struct
> > > ttm_buffer_object *bo,
> > > if (bdev->driver->move_notify)
> > > bdev->driver->move_notify(bo, evict, mem);
> > > - if (!(old_man->flags & TTM_MEMTYPE_FLAG_FIXED) &&
> > > - !(new_man->flags & TTM_MEMTYPE_FLAG_FIXED))
> > > + if (old_man->use_tt && new_man->use_tt)
> > > ret = ttm_bo_move_ttm(bo, ctx, mem);
> > > else if (bdev->driver->move)
> > > ret = bdev->driver->move(bo, evict, ctx, mem);
> > > @@ -340,7 +339,7 @@ static int ttm_bo_handle_move_mem(struct
> > > ttm_buffer_object *bo,
> > > out_err:
> > > new_man = &bdev->man[bo->mem.mem_type];
> > > - if (new_man->flags & TTM_MEMTYPE_FLAG_FIXED) {
> > > + if (!new_man->use_tt) {
> > > ttm_tt_destroy(bo->ttm);
> > > bo->ttm = NULL;
> > > }
> > > @@ -1677,6 +1676,7 @@ int ttm_bo_device_init(struct ttm_bo_device *bdev,
> > >* Initialize the system memory buffer type.
> > >* Other types need to be driver / IOCTL initialized.
> > >*/
> > > + bdev->man[TTM_PL_SYSTEM].use_tt = true;
> > > bdev->man[TTM_PL_SYSTEM].available_caching =
> > > TTM_PL_MASK_CACHING;
> > > bdev->man[TTM_PL_SYSTEM].default_caching = TTM_PL_FLAG_CACHED;
> > > ret = ttm_bo_init_mm(bdev, TTM_PL_SYSTEM, 0);
> > > diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
> > > b/drivers/gpu/drm/ttm/ttm_bo_util.c
> > > index 7fb3e0bcbab4..1f502be0b646 100644
> > > --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> > > +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
> > > @@ -384,7 +384,7 @@ int ttm_bo_move_memcpy(struct ttm_buffer_object *bo,
> > > *old_mem = *new_mem;
> > > new_mem->mm_node = NULL;
> > > - if (man->flags & TTM_MEMTYPE_FLAG_FIXED) {
> > > + if (!man->use_tt) {
> > > ttm_tt_destroy(ttm);
> > > bo->ttm = NULL;
> > > }
> > > @@ -645,7 +645,7 @@ int ttm_bo_move_accel_cleanup(struct
> > > ttm_buffer_object *bo,
> > > if (ret)
> > > return ret;
> > > - if (man->flags & TTM_MEMTYPE_FLAG_FIXED) {
> > > + if (!man->use_tt) {
> > > ttm_tt_destroy(bo->ttm);
> > > bo->ttm = NULL;
> > > }
> > > @@ -674,7 +674,7 @@ int ttm_bo_move_accel_cleanup(struct
> > > ttm_buffer_object *bo,
> > >* bo to be unbound and destroyed.
> > >*/
> > > - if (!(man->flags & TTM_MEMTYPE_FLAG_FIXED))
> > > + if (man->use_tt)
> > > ghost_obj->ttm = NULL;
> > > else
> > > bo->ttm = NULL;
> > > @@ -730,7 +730,7 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
> > >* bo to be unbound and destroyed.
> > >*/
> > > - if (!(to->flags & TTM_MEMTYPE_FLAG_FIXED))
> > > + if (to->use_tt)
> > > ghost_obj->ttm = NULL;
> > > else
> > > bo->ttm = NULL;
> > > @@ -738,7 +738,7 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
> > > dma_resv_unlock(&ghost_obj->base._resv);
> > > ttm_bo_put(ghost_obj);
> > > - } else if (from->flags & TTM_MEMTYPE_FLAG_FIXED) {
> > > + } else if (!from->use_tt) {
> > > /**
> > >* BO doesn't have a TTM we need to bind/unbind. Just
&
Re: [PATCH 3/9] drm/radeon: stop implementing init_mem_type
On Thu, Jul 23, 2020 at 05:16:15PM +0200, Christian König wrote:
> Instead just initialize the memory type parameters
> before calling ttm_bo_init_mm.
>
> Signed-off-by: Christian König
Hm what's the motivation here? I do agree that the init_mem_type callback
is rather midlayer-y (having a per-type cast in a callback is a very clear
signal something with the layering is all busted). So removing this sounds
like a good idea, but not really following why just for radeon? Or simply
wip?
-Daniel
> ---
> drivers/gpu/drm/radeon/radeon_ttm.c | 70 ++---
> 1 file changed, 35 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index 9aba18a143e7..b0b59c553785 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -69,43 +69,43 @@ struct radeon_device *radeon_get_rdev(struct
> ttm_bo_device *bdev)
> static int radeon_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
> struct ttm_mem_type_manager *man)
> {
> - struct radeon_device *rdev;
> + return 0;
> +}
>
> - rdev = radeon_get_rdev(bdev);
> +static int radeon_ttm_init_vram(struct radeon_device *rdev)
> +{
> + struct ttm_mem_type_manager *man = &rdev->mman.bdev.man[TTM_PL_VRAM];
>
> - switch (type) {
> - case TTM_PL_SYSTEM:
> - /* System memory */
> - break;
> - case TTM_PL_TT:
> - man->func = &ttm_bo_manager_func;
> - man->available_caching = TTM_PL_MASK_CACHING;
> - man->default_caching = TTM_PL_FLAG_CACHED;
> - man->use_tt = true;
> + man->func = &ttm_bo_manager_func;
> + man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
> + man->default_caching = TTM_PL_FLAG_WC;
> +
> + return ttm_bo_init_mm(&rdev->mman.bdev, TTM_PL_VRAM,
> + rdev->mc.real_vram_size >> PAGE_SHIFT);
> +}
> +
> +static int radeon_ttm_init_gtt(struct radeon_device *rdev)
> +{
> + struct ttm_mem_type_manager *man = &rdev->mman.bdev.man[TTM_PL_TT];
> +
> + man->func = &ttm_bo_manager_func;
> + man->available_caching = TTM_PL_MASK_CACHING;
> + man->default_caching = TTM_PL_FLAG_CACHED;
> + man->use_tt = true;
> #if IS_ENABLED(CONFIG_AGP)
> - if (rdev->flags & RADEON_IS_AGP) {
> - if (!rdev->ddev->agp) {
> - DRM_ERROR("AGP is not enabled for memory type
> %u\n",
> - (unsigned)type);
> - return -EINVAL;
> - }
> - man->available_caching = TTM_PL_FLAG_UNCACHED |
> - TTM_PL_FLAG_WC;
> - man->default_caching = TTM_PL_FLAG_WC;
> + if (rdev->flags & RADEON_IS_AGP) {
> + if (!rdev->ddev->agp) {
> + DRM_ERROR("AGP is not enabled\n");
> + return -EINVAL;
> }
> -#endif
> - break;
> - case TTM_PL_VRAM:
> - /* "On-card" video ram */
> - man->func = &ttm_bo_manager_func;
> - man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
> + man->available_caching = TTM_PL_FLAG_UNCACHED |
> + TTM_PL_FLAG_WC;
> man->default_caching = TTM_PL_FLAG_WC;
> - break;
> - default:
> - DRM_ERROR("Unsupported memory type %u\n", (unsigned)type);
> - return -EINVAL;
> }
> - return 0;
> +#endif
> +
> + return ttm_bo_init_mm(&rdev->mman.bdev, TTM_PL_TT,
> + rdev->mc.gtt_size >> PAGE_SHIFT);
> }
>
> static void radeon_evict_flags(struct ttm_buffer_object *bo,
> @@ -778,8 +778,8 @@ int radeon_ttm_init(struct radeon_device *rdev)
> return r;
> }
> rdev->mman.initialized = true;
> - r = ttm_bo_init_mm(&rdev->mman.bdev, TTM_PL_VRAM,
> - rdev->mc.real_vram_size >> PAGE_SHIFT);
> +
> + r = radeon_ttm_init_vram(rdev);
> if (r) {
> DRM_ERROR("Failed initializing VRAM heap.\n");
> return r;
> @@ -804,8 +804,8 @@ int radeon_ttm_init(struct radeon_device *rdev)
> }
> DRM_INFO("radeon: %uM of VRAM memory ready\n",
>(unsigned) (rdev
Re: [PATCH 3/9] drm/radeon: stop implementing init_mem_type
On Mon, Jul 27, 2020 at 12:30:00PM +0200, dan...@ffwll.ch wrote:
> On Thu, Jul 23, 2020 at 05:16:15PM +0200, Christian König wrote:
> > Instead just initialize the memory type parameters
> > before calling ttm_bo_init_mm.
> >
> > Signed-off-by: Christian König
>
> Hm what's the motivation here? I do agree that the init_mem_type callback
> is rather midlayer-y (having a per-type cast in a callback is a very clear
> signal something with the layering is all busted). So removing this sounds
> like a good idea, but not really following why just for radeon? Or simply
> wip?
nvm, I've seen the next series :-) And Alex already r-b'ed it.
-Daniel
>
>
>
> > ---
> > drivers/gpu/drm/radeon/radeon_ttm.c | 70 ++---
> > 1 file changed, 35 insertions(+), 35 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
> > b/drivers/gpu/drm/radeon/radeon_ttm.c
> > index 9aba18a143e7..b0b59c553785 100644
> > --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> > +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> > @@ -69,43 +69,43 @@ struct radeon_device *radeon_get_rdev(struct
> > ttm_bo_device *bdev)
> > static int radeon_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
> > struct ttm_mem_type_manager *man)
> > {
> > - struct radeon_device *rdev;
> > + return 0;
> > +}
> >
> > - rdev = radeon_get_rdev(bdev);
> > +static int radeon_ttm_init_vram(struct radeon_device *rdev)
> > +{
> > + struct ttm_mem_type_manager *man = &rdev->mman.bdev.man[TTM_PL_VRAM];
> >
> > - switch (type) {
> > - case TTM_PL_SYSTEM:
> > - /* System memory */
> > - break;
> > - case TTM_PL_TT:
> > - man->func = &ttm_bo_manager_func;
> > - man->available_caching = TTM_PL_MASK_CACHING;
> > - man->default_caching = TTM_PL_FLAG_CACHED;
> > - man->use_tt = true;
> > + man->func = &ttm_bo_manager_func;
> > + man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
> > + man->default_caching = TTM_PL_FLAG_WC;
> > +
> > + return ttm_bo_init_mm(&rdev->mman.bdev, TTM_PL_VRAM,
> > + rdev->mc.real_vram_size >> PAGE_SHIFT);
> > +}
> > +
> > +static int radeon_ttm_init_gtt(struct radeon_device *rdev)
> > +{
> > + struct ttm_mem_type_manager *man = &rdev->mman.bdev.man[TTM_PL_TT];
> > +
> > + man->func = &ttm_bo_manager_func;
> > + man->available_caching = TTM_PL_MASK_CACHING;
> > + man->default_caching = TTM_PL_FLAG_CACHED;
> > + man->use_tt = true;
> > #if IS_ENABLED(CONFIG_AGP)
> > - if (rdev->flags & RADEON_IS_AGP) {
> > - if (!rdev->ddev->agp) {
> > - DRM_ERROR("AGP is not enabled for memory type
> > %u\n",
> > - (unsigned)type);
> > - return -EINVAL;
> > - }
> > - man->available_caching = TTM_PL_FLAG_UNCACHED |
> > -TTM_PL_FLAG_WC;
> > - man->default_caching = TTM_PL_FLAG_WC;
> > + if (rdev->flags & RADEON_IS_AGP) {
> > + if (!rdev->ddev->agp) {
> > + DRM_ERROR("AGP is not enabled\n");
> > + return -EINVAL;
> > }
> > -#endif
> > - break;
> > - case TTM_PL_VRAM:
> > - /* "On-card" video ram */
> > - man->func = &ttm_bo_manager_func;
> > - man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
> > + man->available_caching = TTM_PL_FLAG_UNCACHED |
> > +TTM_PL_FLAG_WC;
> > man->default_caching = TTM_PL_FLAG_WC;
> > - break;
> > - default:
> > - DRM_ERROR("Unsupported memory type %u\n", (unsigned)type);
> > - return -EINVAL;
> > }
> > - return 0;
> > +#endif
> > +
> > + return ttm_bo_init_mm(&rdev->mman.bdev, TTM_PL_TT,
> > + rdev->mc.gtt_size >> PAGE_SHIFT);
> > }
> >
> > static void radeon_evict_flags(struct ttm_buffer_object *bo,
> > @@ -778,8 +778,8 @@ int radeon_ttm_init(struct radeon_device *rdev)
> > return r;
> > }
> > rdev
Re: [RFC][PATCH] dma-heap: Add proper kref handling on dma-buf heaps
On Sat, Jul 25, 2020 at 03:26:33AM +, John Stultz wrote:
> Add proper refcounting on the dma_heap structure.
> While existing heaps are built-in, we may eventually
> have heaps loaded from modules, and we'll need to be
> able to properly handle the references to the heaps
Uh I kinda want to wait until we cross that bridge ... this entire vendor
heaps thing still sounds very much like vendor trees hacking around
instead of having upstream drivers using upstream infrastructure.
-Daniel
>
> Cc: Sumit Semwal
> Cc: Andrew F. Davis
> Cc: Benjamin Gaignard
> Cc: Liam Mark
> Cc: Laura Abbott
> Cc: Brian Starkey
> Cc: linux-me...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: John Stultz
> ---
> drivers/dma-buf/dma-heap.c | 31 +++
> include/linux/dma-heap.h | 6 ++
> 2 files changed, 33 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
> index afd22c9dbdcf..90c3720acc1c 100644
> --- a/drivers/dma-buf/dma-heap.c
> +++ b/drivers/dma-buf/dma-heap.c
> @@ -40,6 +40,8 @@ struct dma_heap {
> dev_t heap_devt;
> struct list_head list;
> struct cdev heap_cdev;
> + int minor;
> + struct kref refcount;
> };
>
> static LIST_HEAD(heap_list);
> @@ -190,11 +192,31 @@ void *dma_heap_get_drvdata(struct dma_heap *heap)
> return heap->priv;
> }
>
> +static void dma_heap_release(struct kref *ref)
> +{
> + struct dma_heap *heap = container_of(ref, struct dma_heap, refcount);
> +
> + /* Remove heap from the list */
> + mutex_lock(&heap_list_lock);
> + list_del(&heap->list);
> + mutex_unlock(&heap_list_lock);
> +
> + device_destroy(dma_heap_class, heap->heap_devt);
> + cdev_del(&heap->heap_cdev);
> + xa_erase(&dma_heap_minors, heap->minor);
> +
> + kfree(heap);
> +}
> +
> +void dma_heap_put(struct dma_heap *h)
> +{
> + kref_put(&h->refcount, dma_heap_release);
> +}
> +
> struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info)
> {
> struct dma_heap *heap, *h, *err_ret;
> struct device *dev_ret;
> - unsigned int minor;
> int ret;
>
> if (!exp_info->name || !strcmp(exp_info->name, "")) {
> @@ -223,12 +245,13 @@ struct dma_heap *dma_heap_add(const struct
> dma_heap_export_info *exp_info)
> if (!heap)
> return ERR_PTR(-ENOMEM);
>
> + kref_init(&heap->refcount);
> heap->name = exp_info->name;
> heap->ops = exp_info->ops;
> heap->priv = exp_info->priv;
>
> /* Find unused minor number */
> - ret = xa_alloc(&dma_heap_minors, &minor, heap,
> + ret = xa_alloc(&dma_heap_minors, &heap->minor, heap,
> XA_LIMIT(0, NUM_HEAP_MINORS - 1), GFP_KERNEL);
> if (ret < 0) {
> pr_err("dma_heap: Unable to get minor number for heap\n");
> @@ -237,7 +260,7 @@ struct dma_heap *dma_heap_add(const struct
> dma_heap_export_info *exp_info)
> }
>
> /* Create device */
> - heap->heap_devt = MKDEV(MAJOR(dma_heap_devt), minor);
> + heap->heap_devt = MKDEV(MAJOR(dma_heap_devt), heap->minor);
>
> cdev_init(&heap->heap_cdev, &dma_heap_fops);
> ret = cdev_add(&heap->heap_cdev, heap->heap_devt, 1);
> @@ -267,7 +290,7 @@ struct dma_heap *dma_heap_add(const struct
> dma_heap_export_info *exp_info)
> err2:
> cdev_del(&heap->heap_cdev);
> err1:
> - xa_erase(&dma_heap_minors, minor);
> + xa_erase(&dma_heap_minors, heap->minor);
> err0:
> kfree(heap);
> return err_ret;
> diff --git a/include/linux/dma-heap.h b/include/linux/dma-heap.h
> index 454e354d1ffb..c1572f29cfac 100644
> --- a/include/linux/dma-heap.h
> +++ b/include/linux/dma-heap.h
> @@ -56,4 +56,10 @@ void *dma_heap_get_drvdata(struct dma_heap *heap);
> */
> struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info);
>
> +/**
> + * dma_heap_put - drops a reference to a dmabuf heaps, potentially freeing it
> + * @heap:heap pointer
> + */
> +void dma_heap_put(struct dma_heap *heap);
> +
> #endif /* _DMA_HEAPS_H */
> --
> 2.17.1
>
> ___
> 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: [PATCH 1/3] drm/ast: Do full modeset if the primary plane's format changes
On Mon, Jul 27, 2020 at 09:37:05AM +0200, Thomas Zimmermann wrote:
> The atomic modesetting code tried to distinguish format changes from
> full modesetting operations. In practice, this was buggy and the format
> registers were often updated even for simple pageflips.
Nah it's not buggy, it's intentional. Most hw can update formats in a flip
withouth having to shut down the hw to do so.
> Instead do a full modeset if the primary plane changes formats. It's
> just as rare as an actual mode change, so there will be no performance
> penalty.
>
> The patch also replaces a reference to drm_crtc_state.allow_modeset with
> the correct call to drm_atomic_crtc_needs_modeset().
>
> Signed-off-by: Thomas Zimmermann
> Fixes: 4961eb60f145 ("drm/ast: Enable atomic modesetting")
> Cc: Thomas Zimmermann
> Cc: Gerd Hoffmann
> Cc: Dave Airlie
> Cc: Daniel Vetter
> Cc: Sam Ravnborg
> Cc: Emil Velikov
> Cc: "Y.C. Chen"
> Cc: # v5.6+
> ---
> drivers/gpu/drm/ast/ast_mode.c | 23 ---
> 1 file changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
> index 154cd877d9d1..3680a000b812 100644
> --- a/drivers/gpu/drm/ast/ast_mode.c
> +++ b/drivers/gpu/drm/ast/ast_mode.c
> @@ -527,8 +527,8 @@ static const uint32_t ast_primary_plane_formats[] = {
> static int ast_primary_plane_helper_atomic_check(struct drm_plane *plane,
>struct drm_plane_state *state)
> {
> - struct drm_crtc_state *crtc_state;
> - struct ast_crtc_state *ast_crtc_state;
> + struct drm_crtc_state *crtc_state, *old_crtc_state;
> + struct ast_crtc_state *ast_crtc_state, *old_ast_crtc_state;
> int ret;
>
> if (!state->crtc)
> @@ -550,6 +550,15 @@ static int ast_primary_plane_helper_atomic_check(struct
> drm_plane *plane,
>
> ast_crtc_state->format = state->fb->format;
>
> + old_crtc_state = drm_atomic_get_old_crtc_state(state->state,
> state->crtc);
> + if (!old_crtc_state)
> + return 0;
> + old_ast_crtc_state = to_ast_crtc_state(old_crtc_state);
> + if (!old_ast_crtc_state)
The above two if checks should never fail, I'd wrap them in a WARN_ON.
> + return 0;
> + if (ast_crtc_state->format != old_ast_crtc_state->format)
> + crtc_state->mode_changed = true;
> +
> return 0;
> }
>
> @@ -775,18 +784,18 @@ static void ast_crtc_helper_atomic_flush(struct
> drm_crtc *crtc,
>
> ast_state = to_ast_crtc_state(crtc->state);
>
> - format = ast_state->format;
> - if (!format)
> + if (!drm_atomic_crtc_needs_modeset(crtc->state))
> return;
>
> + format = ast_state->format;
> + if (drm_WARN_ON_ONCE(dev, !format))
> + return; /* BUG: We didn't set format in primary check(). */
Hm that entire ast_state->format machinery looks kinda strange, can't you
just look up the primary plane state everywhere and that's it?
drm_framebuffer are fully invariant and refcounted to the state, so there
really shouldn't be any need to copy format around.
But that's maybe for a next patch. With the commit message clarified that
everything works as designed, and maybe the two WARN_ON added:
Reviewed-by: Daniel Vetter
> +
> vbios_mode_info = &ast_state->vbios_mode_info;
>
> ast_set_color_reg(ast, format);
> ast_set_vbios_color_reg(ast, format, vbios_mode_info);
>
> - if (!crtc->state->mode_changed)
> - return;
> -
> adjusted_mode = &crtc->state->adjusted_mode;
>
> ast_set_vbios_mode_reg(ast, adjusted_mode, vbios_mode_info);
> --
> 2.27.0
>
--
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 2/3] drm/ast: Store image size in HW cursor info
On Mon, Jul 27, 2020 at 09:37:06AM +0200, Thomas Zimmermann wrote:
> Store the image size as part of the HW cursor info, so that the
> cursor show function doesn't require the information from the
> caller. No functional changes.
Uh just pass the state structure and done? All these "store random stuff
in private structures" (they're not even atomic state structures, it's the
driver private thing even!) is very non-atomic. And I see zero reasons why
you have to do this, the cursor stays around.
-Daniel
>
> Signed-off-by: Thomas Zimmermann
> Fixes: 4961eb60f145 ("drm/ast: Enable atomic modesetting")
> Cc: Thomas Zimmermann
> Cc: Gerd Hoffmann
> Cc: Dave Airlie
> Cc: Daniel Vetter
> Cc: Sam Ravnborg
> Cc: Emil Velikov
> Cc: "Y.C. Chen"
> Cc: # v5.6+
> ---
> drivers/gpu/drm/ast/ast_cursor.c | 13 +++--
> drivers/gpu/drm/ast/ast_drv.h| 7 +--
> drivers/gpu/drm/ast/ast_mode.c | 8 +---
> 3 files changed, 17 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/ast/ast_cursor.c
> b/drivers/gpu/drm/ast/ast_cursor.c
> index acf0d23514e8..8642a0ce9da6 100644
> --- a/drivers/gpu/drm/ast/ast_cursor.c
> +++ b/drivers/gpu/drm/ast/ast_cursor.c
> @@ -87,6 +87,8 @@ int ast_cursor_init(struct ast_private *ast)
>
> ast->cursor.gbo[i] = gbo;
> ast->cursor.vaddr[i] = vaddr;
> + ast->cursor.size[i].width = 0;
> + ast->cursor.size[i].height = 0;
> }
>
> return drmm_add_action_or_reset(dev, ast_cursor_release, NULL);
> @@ -194,6 +196,9 @@ int ast_cursor_blit(struct ast_private *ast, struct
> drm_framebuffer *fb)
> /* do data transfer to cursor BO */
> update_cursor_image(dst, src, fb->width, fb->height);
>
> + ast->cursor.size[ast->cursor.next_index].width = fb->width;
> + ast->cursor.size[ast->cursor.next_index].height = fb->height;
> +
> drm_gem_vram_vunmap(gbo, src);
> drm_gem_vram_unpin(gbo);
>
> @@ -249,14 +254,18 @@ static void ast_cursor_set_location(struct ast_private
> *ast, u16 x, u16 y,
> ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xc7, y1);
> }
>
> -void ast_cursor_show(struct ast_private *ast, int x, int y,
> - unsigned int offset_x, unsigned int offset_y)
> +void ast_cursor_show(struct ast_private *ast, int x, int y)
> {
> + unsigned int offset_x, offset_y;
> u8 x_offset, y_offset;
> u8 __iomem *dst, __iomem *sig;
> u8 jreg;
>
> dst = ast->cursor.vaddr[ast->cursor.next_index];
> + offset_x = AST_MAX_HWC_WIDTH -
> +ast->cursor.size[ast->cursor.next_index].width;
> + offset_y = AST_MAX_HWC_HEIGHT -
> +ast->cursor.size[ast->cursor.next_index].height;
>
> sig = dst + AST_HWC_SIZE;
> writel(x, sig + AST_HWC_SIGNATURE_X);
> diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
> index e3a264ac7ee2..57414b429db3 100644
> --- a/drivers/gpu/drm/ast/ast_drv.h
> +++ b/drivers/gpu/drm/ast/ast_drv.h
> @@ -116,6 +116,10 @@ struct ast_private {
> struct {
> struct drm_gem_vram_object *gbo[AST_DEFAULT_HWC_NUM];
> void __iomem *vaddr[AST_DEFAULT_HWC_NUM];
> + struct {
> + unsigned int width;
> + unsigned int height;
> + } size[AST_DEFAULT_HWC_NUM];
> unsigned int next_index;
> } cursor;
>
> @@ -311,8 +315,7 @@ void ast_release_firmware(struct drm_device *dev);
> int ast_cursor_init(struct ast_private *ast);
> int ast_cursor_blit(struct ast_private *ast, struct drm_framebuffer *fb);
> void ast_cursor_page_flip(struct ast_private *ast);
> -void ast_cursor_show(struct ast_private *ast, int x, int y,
> - unsigned int offset_x, unsigned int offset_y);
> +void ast_cursor_show(struct ast_private *ast, int x, int y);
> void ast_cursor_hide(struct ast_private *ast);
>
> #endif
> diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
> index 3680a000b812..5b2b39c93033 100644
> --- a/drivers/gpu/drm/ast/ast_mode.c
> +++ b/drivers/gpu/drm/ast/ast_mode.c
> @@ -671,20 +671,14 @@ ast_cursor_plane_helper_atomic_update(struct drm_plane
> *plane,
> struct drm_plane_state *old_state)
> {
> struct drm_plane_state *state = plane->state;
> - struct drm_framebuffer *fb = state->fb;
> struct ast_private *ast = plane->dev->dev_private;
> - unsigned int offset_x, offset_y;
> -
> - offset_x = AST_MAX_HWC_WIDTH - fb->width;
&g
Re: [PATCH 3/3] drm/ast: Disable cursor while switching display modes
On Mon, Jul 27, 2020 at 09:37:07AM +0200, Thomas Zimmermann wrote:
> The ast's HW cursor requires the primary plane and CRTC to display
> at a correct mode and format. This is not the case while switching
> display modes, which can lead to the screen turing permanently dark.
>
> As a workaround, the ast driver now disables active HW cursors while
> the mode switch takes place. It also synchronizes with the vertical
> refresh to give HW cursor and primary plane some time to catch up on
> each other.
>
> Signed-off-by: Thomas Zimmermann
> Fixes: 4961eb60f145 ("drm/ast: Enable atomic modesetting")
Since you already do modeset when changing primary plane I think the much
cleaner solution is to use drm_atomic_helper_disable_planes_on_crtc() and
drm_atomic_helper_commit_planes() with flags =
DRM_PLANE_COMMIT_ACTIVE_ONLY or so, with corresponding changes in
atomic_commit_tail. Much cleaner instead of hand-rolling this all in
callbacks.
Note that with atomic helpers it is _very_ much encouraged to throw the
helper structure into the wind and write your own stuff, this thing is
intentionally very modular. This is to avoid incomprehensible drivers that
are forced to hack around the helper midlayer in their callbacks like the
below very much looks like.
-Daniel
> Cc: Thomas Zimmermann
> Cc: Gerd Hoffmann
> Cc: Dave Airlie
> Cc: Daniel Vetter
> Cc: Sam Ravnborg
> Cc: Emil Velikov
> Cc: "Y.C. Chen"
> Cc: # v5.6+
> ---
> drivers/gpu/drm/ast/ast_drv.h | 2 ++
> drivers/gpu/drm/ast/ast_mode.c | 53 +-
> 2 files changed, 54 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
> index 57414b429db3..564670b5d2ee 100644
> --- a/drivers/gpu/drm/ast/ast_drv.h
> +++ b/drivers/gpu/drm/ast/ast_drv.h
> @@ -162,6 +162,8 @@ void ast_driver_unload(struct drm_device *dev);
>
> #define AST_IO_MM_OFFSET (0x380)
>
> +#define AST_IO_VGAIR1_VREFRESH BIT(3)
> +
> #define __ast_read(x) \
> static inline u##x ast_read##x(struct ast_private *ast, u32 reg) { \
> u##x val = 0;\
> diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
> index 5b2b39c93033..e18365bbc08c 100644
> --- a/drivers/gpu/drm/ast/ast_mode.c
> +++ b/drivers/gpu/drm/ast/ast_mode.c
> @@ -514,6 +514,17 @@ static void ast_set_start_address_crt1(struct
> ast_private *ast,
>
> }
>
> +static void ast_wait_for_vretrace(struct ast_private *ast)
> +{
> + unsigned long timeout = jiffies + HZ;
> + u8 vgair1;
> +
> + do {
> + vgair1 = ast_io_read8(ast, AST_IO_INPUT_STATUS1_READ);
> + } while (!(vgair1 & AST_IO_VGAIR1_VREFRESH) &&
> + time_before(jiffies, timeout));
> +}
> +
> /*
> * Primary plane
> */
> @@ -666,6 +677,14 @@ static int ast_cursor_plane_helper_atomic_check(struct
> drm_plane *plane,
> return 0;
> }
>
> +static bool ast_disable_cursor_during_modeset(struct drm_plane *cursor_plane)
> +{
> + const struct drm_plane_state *cursor_state = cursor_plane->state;
> +
> + return cursor_state && cursor_state->visible && cursor_state->crtc &&
> +drm_atomic_crtc_needs_modeset(cursor_state->crtc->state);
> +}
> +
> static void
> ast_cursor_plane_helper_atomic_update(struct drm_plane *plane,
> struct drm_plane_state *old_state)
> @@ -678,7 +697,12 @@ ast_cursor_plane_helper_atomic_update(struct drm_plane
> *plane,
> ast_cursor_page_flip(ast);
> }
>
> - ast_cursor_show(ast, state->crtc_x, state->crtc_y);
> + /*
> + * For modesets, delay show() until end of atomic_flush(). See the
> + * atomic_begin() helper for more information.
> + */
> + if (!ast_disable_cursor_during_modeset(plane))
> + ast_cursor_show(ast, state->crtc_x, state->crtc_y);
> }
>
> static void
> @@ -764,6 +788,22 @@ static void ast_crtc_helper_atomic_begin(struct drm_crtc
> *crtc,
> struct ast_private *ast = to_ast_private(crtc->dev);
>
> ast_open_key(ast);
> +
> + /*
> + * HW cursors require the underlying primary plane and CRTC to
> + * display a valid mode and image. This is not the case during
> + * full modeset operations. So we temporarily disable any active
> + * HW cursor and re-enable it at the end of the atomic_flush()
> + * helper. The busy waiting allows the code to sync with the
> + * vertical refresh.
> + *
> + * We only do this during *full* modesets. It does not affect
> + * simple pageflips on t
Re: [PATCH V2] drm: hold gem reference until object is no longer accessed
On Mon, Jul 27, 2020 at 09:55:07PM +0200, Greg KH wrote: > On Mon, Jul 20, 2020 at 06:30:50PM -0400, Steve Cohen wrote: > > A use-after-free in drm_gem_open_ioctl can happen if the > > GEM object handle is closed between the idr lookup and > > retrieving the size from said object since a local reference > > is not being held at that point. Hold the local reference > > while the object can still be accessed to fix this and > > plug the potential security hole. > > > > Signed-off-by: Steve Cohen > > --- > > drivers/gpu/drm/drm_gem.c | 10 -- > > 1 file changed, 4 insertions(+), 6 deletions(-) > > > > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c > > index 7bf628e..ee2058a 100644 > > --- a/drivers/gpu/drm/drm_gem.c > > +++ b/drivers/gpu/drm/drm_gem.c > > @@ -871,9 +871,6 @@ drm_gem_flink_ioctl(struct drm_device *dev, void *data, > > * @file_priv: drm file-private structure > > * > > * Open an object using the global name, returning a handle and the size. > > - * > > - * This handle (of course) holds a reference to the object, so the object > > - * will not go away until the handle is deleted. > > */ > > int > > drm_gem_open_ioctl(struct drm_device *dev, void *data, > > @@ -898,14 +895,15 @@ drm_gem_open_ioctl(struct drm_device *dev, void *data, > > > > /* drm_gem_handle_create_tail unlocks dev->object_name_lock. */ > > ret = drm_gem_handle_create_tail(file_priv, obj, &handle); > > - drm_gem_object_put_unlocked(obj); > > if (ret) > > - return ret; > > + goto err; > > > > args->handle = handle; > > args->size = obj->size; > > > > - return 0; > > +err: > > + drm_gem_object_put_unlocked(obj); > > + return ret; > > } > > > > /** > > As this seems to fix an important issue, any reason it wasn't cc: stable > on it so that it gets backported properly? > > How about a "Fixes:" tag so that we know what commit id it fixes so we > know how far back to backport things? > > And a hint to the maintainers that "this is an issue that needs to get > into 5.8-final, it shouldn't wait around longer please" would have also > been nice to see :) > > And what chagned from v1, aren't you supposed to list that somewhere in > the changelog or below the --- line (never remember what DRM drivers > want here...) > > Care to send a v3? Don't worry, I'm pushing this to drm-misc-fixes now, should still make it to 5.8. Plus cc: stable. I didn't bother with Fixes: since I think the bug is rather old. Also, worst case you leak 32bit of some kernel memory that got reused already (but yeah I know that's often enough to get the foot in somewhere nasty and crack the door open). I think it fell through cracks because Sam said he'll apply, guess that didn't happen. Also yes a changelog, somewhere, for next time around. -Daniel > > thanks, > > greg k-h -- 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: [Freedreno] [PATCH V2] drm: hold gem reference until object is no longer accessed
On Mon, Jul 27, 2020 at 05:54:59PM -0400, coh...@codeaurora.org wrote: > On 2020-07-27 16:11, dan...@ffwll.ch wrote: > > On Mon, Jul 27, 2020 at 09:55:07PM +0200, Greg KH wrote: > > > On Mon, Jul 20, 2020 at 06:30:50PM -0400, Steve Cohen wrote: > > > > A use-after-free in drm_gem_open_ioctl can happen if the > > > > GEM object handle is closed between the idr lookup and > > > > retrieving the size from said object since a local reference > > > > is not being held at that point. Hold the local reference > > > > while the object can still be accessed to fix this and > > > > plug the potential security hole. > > > > > > > > Signed-off-by: Steve Cohen > > > > --- > > > > drivers/gpu/drm/drm_gem.c | 10 -- > > > > 1 file changed, 4 insertions(+), 6 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c > > > > index 7bf628e..ee2058a 100644 > > > > --- a/drivers/gpu/drm/drm_gem.c > > > > +++ b/drivers/gpu/drm/drm_gem.c > > > > @@ -871,9 +871,6 @@ drm_gem_flink_ioctl(struct drm_device *dev, void > > > > *data, > > > > * @file_priv: drm file-private structure > > > > * > > > > * Open an object using the global name, returning a handle and the > > > > size. > > > > - * > > > > - * This handle (of course) holds a reference to the object, so the > > > > object > > > > - * will not go away until the handle is deleted. > > > > */ > > > > int > > > > drm_gem_open_ioctl(struct drm_device *dev, void *data, > > > > @@ -898,14 +895,15 @@ drm_gem_open_ioctl(struct drm_device *dev, void > > > > *data, > > > > > > > > /* drm_gem_handle_create_tail unlocks dev->object_name_lock. */ > > > > ret = drm_gem_handle_create_tail(file_priv, obj, &handle); > > > > - drm_gem_object_put_unlocked(obj); > > > > if (ret) > > > > - return ret; > > > > + goto err; > > > > > > > > args->handle = handle; > > > > args->size = obj->size; > > > > > > > > - return 0; > > > > +err: > > > > + drm_gem_object_put_unlocked(obj); > > > > + return ret; > > > > } > > > > > > > > /** > > > > > > As this seems to fix an important issue, any reason it wasn't cc: > > > stable > > > on it so that it gets backported properly? > > > > > > How about a "Fixes:" tag so that we know what commit id it fixes so we > > > know how far back to backport things? > > > > > > And a hint to the maintainers that "this is an issue that needs to get > > > into 5.8-final, it shouldn't wait around longer please" would have > > > also > > > been nice to see :) > > > > > > And what chagned from v1, aren't you supposed to list that somewhere > > > in > > > the changelog or below the --- line (never remember what DRM drivers > > > want here...) > > > > > > Care to send a v3? > > > > Don't worry, I'm pushing this to drm-misc-fixes now, should still make > > it > > to 5.8. Plus cc: stable. I didn't bother with Fixes: since I think the > > bug > > is rather old. Also, worst case you leak 32bit of some kernel memory > > that > > got reused already (but yeah I know that's often enough to get the foot > > in > > somewhere nasty and crack the door open). > > > > I think it fell through cracks because Sam said he'll apply, guess that > > didn't happen. > > Sam added his Reviewed-By on V1 with a comment to rename the goto label, > but in V2 I also updated the API documentation and the commit text for > a more complete change and thought he would re-add the tag. > > > Also yes a changelog, somewhere, for next time around. > > Apologies, it won't happen again. Should I still submit a V3? > It looks like you've got Greg's concerns covered. Uh no, but we need another patch to re-add the kerneldoc you deleted. I missed that when merging your patch. Also that's kinda what patch changelogs are for, for blind reviewers like me :-) -Daniel > > -Steve > > > -Daniel > > > > > > > > > > thanks, > > > > > > greg k-h -- 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/amd/display: Clear dm_state for fast updates
On Mon, Jul 27, 2020 at 10:49:48PM -0400, Kazlauskas, Nicholas wrote: > On 2020-07-27 5:32 p.m., Daniel Vetter wrote: > > On Mon, Jul 27, 2020 at 11:11 PM Mazin Rezk wrote: > > > > > > On Monday, July 27, 2020 4:29 PM, Daniel Vetter wrote: > > > > > > > On Mon, Jul 27, 2020 at 9:28 PM Christian König > > > > wrote: > > > > > > > > > > Am 27.07.20 um 16:05 schrieb Kazlauskas, Nicholas: > > > > > > On 2020-07-27 9:39 a.m., Christian König wrote: > > > > > > > Am 27.07.20 um 07:40 schrieb Mazin Rezk: > > > > > > > > This patch fixes a race condition that causes a use-after-free > > > > > > > > during > > > > > > > > amdgpu_dm_atomic_commit_tail. This can occur when 2 non-blocking > > > > > > > > commits > > > > > > > > are requested and the second one finishes before the first. > > > > > > > > Essentially, > > > > > > > > this bug occurs when the following sequence of events happens: > > > > > > > > > > > > > > > > 1. Non-blocking commit #1 is requested w/ a new dm_state #1 and > > > > > > > > is > > > > > > > > deferred to the workqueue. > > > > > > > > > > > > > > > > 2. Non-blocking commit #2 is requested w/ a new dm_state #2 and > > > > > > > > is > > > > > > > > deferred to the workqueue. > > > > > > > > > > > > > > > > 3. Commit #2 starts before commit #1, dm_state #1 is used in the > > > > > > > > commit_tail and commit #2 completes, freeing dm_state #1. > > > > > > > > > > > > > > > > 4. Commit #1 starts after commit #2 completes, uses the freed > > > > > > > > dm_state > > > > > > > > 1 and dereferences a freelist pointer while setting the context. > > > > > > > > > > > > > > Well I only have a one mile high view on this, but why don't you > > > > > > > let > > > > > > > the work items execute in order? > > > > > > > > > > > > > > That would be better anyway cause this way we don't trigger a > > > > > > > cache > > > > > > > line ping pong between CPUs. > > > > > > > > > > > > > > Christian. > > > > > > > > > > > > We use the DRM helpers for managing drm_atomic_commit_state and > > > > > > those > > > > > > helpers internally push non-blocking commit work into the system > > > > > > unbound work queue. > > > > > > > > > > Mhm, well if you send those helper atomic commits in the order A,B and > > > > > they execute it in the order B,A I would call that a bug :) > > > > > > > > The way it works is it pushes all commits into unbound work queue, but > > > > then forces serialization as needed. We do _not_ want e.g. updates on > > > > different CRTC to be serialized, that would result in lots of judder. > > > > And hw is funny enough that there's all kinds of dependencies. > > > > > > > > The way you force synchronization is by adding other CRTC state > > > > objects. So if DC is busted and can only handle a single update per > > > > work item, then I guess you always need all CRTC states and everything > > > > will be run in order. But that also totally kills modern multi-screen > > > > compositors. Xorg isn't modern, just in case that's not clear :-) > > > > > > > > Lucking at the code it seems like you indeed have only a single dm > > > > state, so yeah global sync is what you'll need as immediate fix, and > > > > then maybe fix up DM to not be quite so silly ... or at least only do > > > > the dm state stuff when really needed. > > > > > > > > We could also sprinkle the drm_crtc_commit structure around a bit > > > > (it's the glue that provides the synchronization across commits), but > > > > since your dm state is global just grabbing all crtc states > > > > unconditionally as part of that is probably best. > > > > > > > > > > While we could duplicate a copy of that code with not
Re: [PATCH] ttm: ttm_bo_swapout_all doesn't use it's argument.
On Tue, Jul 28, 2020 at 01:42:54PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Just drop the argument from this.
>
> This does ask the question if this is the function vmwgfx
> should be using or should it be doing an evict all like
> the other drivers.
Yeah this looks a bit like ttm_bo_swapout_all shouldn't even be exported
really, it's part of the internal shrinker stuff.
-Daniel
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/ttm/ttm_bo.c| 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
> include/drm/ttm/ttm_bo_api.h| 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index b03747717ec7..f297fd5e02d4 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -1838,7 +1838,7 @@ int ttm_bo_swapout(struct ttm_bo_global *glob, struct
> ttm_operation_ctx *ctx)
> }
> EXPORT_SYMBOL(ttm_bo_swapout);
>
> -void ttm_bo_swapout_all(struct ttm_bo_device *bdev)
> +void ttm_bo_swapout_all(void)
> {
> struct ttm_operation_ctx ctx = {
> .interruptible = false,
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> index 470428387878..fb39826f72c1 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> @@ -1352,7 +1352,7 @@ static int vmw_pm_freeze(struct device *kdev)
> vmw_execbuf_release_pinned_bo(dev_priv);
> vmw_resource_evict_all(dev_priv);
> vmw_release_device_early(dev_priv);
> - ttm_bo_swapout_all(&dev_priv->bdev);
> + ttm_bo_swapout_all();
> if (dev_priv->enable_fb)
> vmw_fifo_resource_dec(dev_priv);
> if (atomic_read(&dev_priv->num_fifo_resources) != 0) {
> diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
> index b1c705a93517..a9e13b252820 100644
> --- a/include/drm/ttm/ttm_bo_api.h
> +++ b/include/drm/ttm/ttm_bo_api.h
> @@ -692,7 +692,7 @@ ssize_t ttm_bo_io(struct ttm_bo_device *bdev, struct file
> *filp,
>
> int ttm_bo_swapout(struct ttm_bo_global *glob,
> struct ttm_operation_ctx *ctx);
> -void ttm_bo_swapout_all(struct ttm_bo_device *bdev);
> +void ttm_bo_swapout_all(void);
>
> /**
> * ttm_bo_uses_embedded_gem_object - check if the given bo uses the
> --
> 2.26.2
>
> ___
> 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: [PATCH 11/13] drm/ast: Managed release of ast firmware
On Tue, Jul 28, 2020 at 09:44:23AM +0200, Thomas Zimmermann wrote:
> The ast driver loads firmware for the DP501 display encoder. The
> patch replaces the removal code with a managed release function.
>
> Signed-off-by: Thomas Zimmermann
Hm a devm_request_firmware which does exactly this would be nice I think.
Maybe as a follow-up refactor?
-Daniel
> ---
> drivers/gpu/drm/ast/ast_dp501.c | 23 ++-
> drivers/gpu/drm/ast/ast_drv.h | 1 -
> drivers/gpu/drm/ast/ast_main.c | 3 ---
> 3 files changed, 14 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/ast/ast_dp501.c b/drivers/gpu/drm/ast/ast_dp501.c
> index 4b85a504825a..88121c0e0d05 100644
> --- a/drivers/gpu/drm/ast/ast_dp501.c
> +++ b/drivers/gpu/drm/ast/ast_dp501.c
> @@ -8,11 +8,24 @@
>
> MODULE_FIRMWARE("ast_dp501_fw.bin");
>
> +static void ast_release_firmware(void *data)
> +{
> + struct ast_private *ast = data;
> +
> + release_firmware(ast->dp501_fw);
> + ast->dp501_fw = NULL;
> +}
> +
> static int ast_load_dp501_microcode(struct drm_device *dev)
> {
> struct ast_private *ast = to_ast_private(dev);
> + int ret;
> +
> + ret = request_firmware(&ast->dp501_fw, "ast_dp501_fw.bin", dev->dev);
> + if (ret)
> + return ret;
>
> - return request_firmware(&ast->dp501_fw, "ast_dp501_fw.bin", dev->dev);
> + return devm_add_action_or_reset(dev->dev, ast_release_firmware, ast);
> }
>
> static void send_ack(struct ast_private *ast)
> @@ -435,11 +448,3 @@ void ast_init_3rdtx(struct drm_device *dev)
> }
> }
> }
> -
> -void ast_release_firmware(struct drm_device *dev)
> -{
> - struct ast_private *ast = to_ast_private(dev);
> -
> - release_firmware(ast->dp501_fw);
> - ast->dp501_fw = NULL;
> -}
> diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
> index 86c9a7ac712b..02908d005b99 100644
> --- a/drivers/gpu/drm/ast/ast_drv.h
> +++ b/drivers/gpu/drm/ast/ast_drv.h
> @@ -312,7 +312,6 @@ bool ast_backup_fw(struct drm_device *dev, u8 *addr, u32
> size);
> bool ast_dp501_read_edid(struct drm_device *dev, u8 *ediddata);
> u8 ast_get_dp501_max_clk(struct drm_device *dev);
> void ast_init_3rdtx(struct drm_device *dev);
> -void ast_release_firmware(struct drm_device *dev);
>
> /* ast_cursor.c */
> int ast_cursor_init(struct ast_private *ast);
> diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
> index 792fb7f616ec..e3b7748335a3 100644
> --- a/drivers/gpu/drm/ast/ast_main.c
> +++ b/drivers/gpu/drm/ast/ast_main.c
> @@ -442,11 +442,8 @@ struct ast_private *ast_device_create(struct drm_driver
> *drv,
>
> void ast_device_destroy(struct ast_private *ast)
> {
> - struct drm_device *dev = &ast->base;
> -
> /* enable standard VGA decode */
> ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xa1, 0x04);
>
> - ast_release_firmware(dev);
> kfree(ast->dp501_fw_addr);
> }
> --
> 2.27.0
>
--
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 12/13] drm/ast: Manage release of firmware backup memory
On Tue, Jul 28, 2020 at 09:44:24AM +0200, Thomas Zimmermann wrote:
> The ast driver keeps a backup copy of the DP501 encoder's firmware. This
> patch adds managed release of the allocated memory.
>
> Signed-off-by: Thomas Zimmermann
We can't really do anything with the firmware after the device is gone, so
I think this is one of the very rare exceptions where devm_kzalloc is the
right thing to do! Totally minor nit though, since either way it gets
cleaned up. But I think conceptually cleaner.
-Daniel
> ---
> drivers/gpu/drm/ast/ast_main.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
> index e3b7748335a3..67e20727d82d 100644
> --- a/drivers/gpu/drm/ast/ast_main.c
> +++ b/drivers/gpu/drm/ast/ast_main.c
> @@ -33,6 +33,7 @@
> #include
> #include
> #include
> +#include
>
> #include "ast_drv.h"
>
> @@ -231,11 +232,11 @@ static int ast_detect_chip(struct drm_device *dev, bool
> *need_post)
> ast->tx_chip_type = AST_TX_SIL164;
> break;
> case 0x08:
> - ast->dp501_fw_addr = kzalloc(32*1024, GFP_KERNEL);
> + ast->dp501_fw_addr = drmm_kzalloc(dev, 32*1024,
> GFP_KERNEL);
> if (ast->dp501_fw_addr) {
> /* backup firmware */
> if (ast_backup_fw(dev, ast->dp501_fw_addr,
> 32*1024)) {
> - kfree(ast->dp501_fw_addr);
> + drmm_kfree(dev, ast->dp501_fw_addr);
> ast->dp501_fw_addr = NULL;
> }
> }
> @@ -444,6 +445,4 @@ void ast_device_destroy(struct ast_private *ast)
> {
> /* enable standard VGA decode */
> ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xa1, 0x04);
> -
> - kfree(ast->dp501_fw_addr);
> }
> --
> 2.27.0
>
--
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 04/13] drm/ast: Managed release of I2C adapter
On Tue, Jul 28, 2020 at 09:44:16AM +0200, Thomas Zimmermann wrote:
> Managed releases of the device's I2C adapter simplify the connector's
> release.
>
> Signed-off-by: Thomas Zimmermann
I think this breaks bisect, since at this point the release callback is
called when the connector is already gone. At the end of the series it's
fine again though.
I've done a very cursory reading of your series to look for high-level
issues, I think overall reasonable. On the series:
Acked-by: Daniel Vetter
But maybe you want to polish a bit more, up to you.
-Daniel
> ---
> drivers/gpu/drm/ast/ast_mode.c | 21 ++---
> 1 file changed, 10 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
> index f421a60d8a96..27eb49bd12b3 100644
> --- a/drivers/gpu/drm/ast/ast_mode.c
> +++ b/drivers/gpu/drm/ast/ast_mode.c
> @@ -39,6 +39,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -591,6 +592,14 @@ static void ast_i2c_setsda(void *i2c_priv, int data)
> }
> }
>
> +static void ast_i2c_release(struct drm_device *dev, void *data)
> +{
> + struct ast_i2c_chan *i2c = data;
> +
> + i2c_del_adapter(&i2c->adapter);
> + i2c->dev = NULL; /* clear to signal absence of I2C support */
> +}
> +
> static int ast_i2c_init(struct ast_i2c_chan *i2c, struct drm_device *dev)
> {
> int ret;
> @@ -618,7 +627,7 @@ static int ast_i2c_init(struct ast_i2c_chan *i2c, struct
> drm_device *dev)
>
> i2c->dev = dev; /* signals presence of I2C support */
>
> - return 0;
> + return drmm_add_action_or_reset(dev, ast_i2c_release, i2c);
> }
>
> static bool ast_i2c_is_initialized(struct ast_i2c_chan *i2c)
> @@ -626,14 +635,6 @@ static bool ast_i2c_is_initialized(struct ast_i2c_chan
> *i2c)
> return !!i2c->dev;
> }
>
> -static void ast_i2c_fini(struct ast_i2c_chan *i2c)
> -{
> - if (!ast_i2c_is_initialized(i2c))
> - return;
> - i2c_del_adapter(&i2c->adapter);
> - i2c->dev = NULL; /* clear to signal absence of I2C support */
> -}
> -
> /*
> * Primary plane
> */
> @@ -1139,8 +1140,6 @@ static enum drm_mode_status ast_mode_valid(struct
> drm_connector *connector,
>
> static void ast_connector_destroy(struct drm_connector *connector)
> {
> - struct ast_connector *ast_connector = to_ast_connector(connector);
> - ast_i2c_fini(&ast_connector->i2c);
> drm_connector_cleanup(connector);
> kfree(connector);
> }
> --
> 2.27.0
>
--
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: [Intel-gfx] [PATCH 0/6] vga-switcheroo: initial dynamic mux switch support
On Mon, Jul 27, 2020 at 03:51:06PM -0500, Daniel Dadap wrote: > Changes to allow vga-switcheroo to switch the mux while modesetting > clients remain active. There is existing support for switching the > mux without checking can_switch; however, this support also does not > reprobe after the mux switch is complete. This patch series adds a new > type of switch event which switches immediately while still calling > client driver callbacks, and updates the i915 DRM-KMS driver to reprobe > eDP outputs after switching the mux to an i915-driven GPU, and to avoid > using eDP links (which i915 always assumes to be connected) while the > mux is switched away. So before digging into the details I think the big issue we need to solve first is locking. And current vga-switcheroo is already broken in that regard (there's some fixme comments in drivers about it), but I never cared because it was full device switch only, initiated by users. But you now add vgaswitcheroo to modeset code, and runtime switching, I don't think we can ignore locking here anymore. Also, it's classic abba deadlock design: i915 modeset code calls your new functions in vgaswitcheroo, and vgaswitcheroo calls into modeset code to shut down stuff. This doesn't work (you get away with it by omitting locking in some places, like the current code). One totally nuts idea I've had is to protect vgaswitcheroo output state with a drm_modeset_lock. That supports full graph locking, which means it doesn't matter where we start: nouveau, i915, vgaswitcheroo. So could work out neatly. Problem: That still leaves the loop for the device switching, which is all tangled up here, so either we make this completely separate, or we figure out a plan how make this work for device switching too. And the additional problem is that drm_modeset_lock is already a highly entrenched lock, I'm not sure whether we can also support the device switching with that approach: The device locking we'd need would need to be an outermost lock, or at least fairly big, whereas drm_modeset_lock is kinda a level below. Or I'm making a mess here (it is already one after all). Also, where's the other side? I know the other side you care about is in the nvidia blob driver, but that doesn't count for upstream. We need that code in nouveau for review and merging. Cheers, Daniel > > Daniel Dadap (6): > vga-switcheroo: add new "immediate" switch event type > vga-switcheroo: Add a way to test for the active client > vga-switcheroo: notify clients of pending/completed switch events > i915: implement vga-switcheroo reprobe() callback > i915: fail atomic commit when muxed away > i915: bail out of eDP link training while mux-switched away > > drivers/gpu/drm/i915/display/intel_display.c | 7 + > .../drm/i915/display/intel_dp_link_training.c | 9 ++ > drivers/gpu/drm/i915/i915_switcheroo.c| 27 +++- > drivers/gpu/vga/vga_switcheroo.c | 153 ++ > include/linux/vga_switcheroo.h| 20 +++ > 5 files changed, 185 insertions(+), 31 deletions(-) > > -- > 2.18.4 > > _______ > 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 11/13] drm/ast: Managed release of ast firmware
On Tue, Jul 28, 2020 at 11:32:04AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 28.07.20 um 11:17 schrieb dan...@ffwll.ch:
> > On Tue, Jul 28, 2020 at 09:44:23AM +0200, Thomas Zimmermann wrote:
> >> The ast driver loads firmware for the DP501 display encoder. The
> >> patch replaces the removal code with a managed release function.
> >>
> >> Signed-off-by: Thomas Zimmermann
> >
> > Hm a devm_request_firmware which does exactly this would be nice I think.
> > Maybe as a follow-up refactor?
>
> There are so many ideas for follow-up patches wrt. devres and drmres, we
> should add a todo item to collect them. Especially, devres is much more
> over head in terms of reviews and kernel building/testing tha tit makes
> sense to collect ideas and address them in larger chunks.
Yeah maybe a section with wanted devres functions in todo.rst makes sense.
For devres it depends which subsystem you're dealing with I guess, and how
much they want to see before it lands.
-Daniel
>
> Best regards
> Thomas
>
> > -Daniel
> >
> >> ---
> >> drivers/gpu/drm/ast/ast_dp501.c | 23 ++-
> >> drivers/gpu/drm/ast/ast_drv.h | 1 -
> >> drivers/gpu/drm/ast/ast_main.c | 3 ---
> >> 3 files changed, 14 insertions(+), 13 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/ast/ast_dp501.c
> >> b/drivers/gpu/drm/ast/ast_dp501.c
> >> index 4b85a504825a..88121c0e0d05 100644
> >> --- a/drivers/gpu/drm/ast/ast_dp501.c
> >> +++ b/drivers/gpu/drm/ast/ast_dp501.c
> >> @@ -8,11 +8,24 @@
> >>
> >> MODULE_FIRMWARE("ast_dp501_fw.bin");
> >>
> >> +static void ast_release_firmware(void *data)
> >> +{
> >> + struct ast_private *ast = data;
> >> +
> >> + release_firmware(ast->dp501_fw);
> >> + ast->dp501_fw = NULL;
> >> +}
> >> +
> >> static int ast_load_dp501_microcode(struct drm_device *dev)
> >> {
> >>struct ast_private *ast = to_ast_private(dev);
> >> + int ret;
> >> +
> >> + ret = request_firmware(&ast->dp501_fw, "ast_dp501_fw.bin", dev->dev);
> >> + if (ret)
> >> + return ret;
> >>
> >> - return request_firmware(&ast->dp501_fw, "ast_dp501_fw.bin", dev->dev);
> >> + return devm_add_action_or_reset(dev->dev, ast_release_firmware, ast);
> >> }
> >>
> >> static void send_ack(struct ast_private *ast)
> >> @@ -435,11 +448,3 @@ void ast_init_3rdtx(struct drm_device *dev)
> >>}
> >>}
> >> }
> >> -
> >> -void ast_release_firmware(struct drm_device *dev)
> >> -{
> >> - struct ast_private *ast = to_ast_private(dev);
> >> -
> >> - release_firmware(ast->dp501_fw);
> >> - ast->dp501_fw = NULL;
> >> -}
> >> diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
> >> index 86c9a7ac712b..02908d005b99 100644
> >> --- a/drivers/gpu/drm/ast/ast_drv.h
> >> +++ b/drivers/gpu/drm/ast/ast_drv.h
> >> @@ -312,7 +312,6 @@ bool ast_backup_fw(struct drm_device *dev, u8 *addr,
> >> u32 size);
> >> bool ast_dp501_read_edid(struct drm_device *dev, u8 *ediddata);
> >> u8 ast_get_dp501_max_clk(struct drm_device *dev);
> >> void ast_init_3rdtx(struct drm_device *dev);
> >> -void ast_release_firmware(struct drm_device *dev);
> >>
> >> /* ast_cursor.c */
> >> int ast_cursor_init(struct ast_private *ast);
> >> diff --git a/drivers/gpu/drm/ast/ast_main.c
> >> b/drivers/gpu/drm/ast/ast_main.c
> >> index 792fb7f616ec..e3b7748335a3 100644
> >> --- a/drivers/gpu/drm/ast/ast_main.c
> >> +++ b/drivers/gpu/drm/ast/ast_main.c
> >> @@ -442,11 +442,8 @@ struct ast_private *ast_device_create(struct
> >> drm_driver *drv,
> >>
> >> void ast_device_destroy(struct ast_private *ast)
> >> {
> >> - struct drm_device *dev = &ast->base;
> >> -
> >>/* enable standard VGA decode */
> >>ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xa1, 0x04);
> >>
> >> - ast_release_firmware(dev);
> >>kfree(ast->dp501_fw_addr);
> >> }
> >> --
> >> 2.27.0
> >>
> >
>
> --
> 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
>
--
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/vkms: add missing drm_crtc_vblank_put to the get/put pair on flush
On Tue, Jul 28, 2020 at 04:16:34PM +, Sidong Yang wrote: > On Sun, Jul 26, 2020 at 12:26:08PM +0200, Daniel Vetter wrote: > > On Sat, Jul 25, 2020 at 9:29 PM Melissa Wen wrote: > > > > > > On Sat, Jul 25, 2020 at 4:19 PM Melissa Wen wrote: > > > > > > > > > No, this very first warning continues (only once) :( > > > > > From here (drm_crtc_vblank_on): > > > > > if (atomic_read(&vblank->refcount) != 0 || > > > > > drm_vblank_offdelay == 0) > > > > > drm_WARN_ON(dev, drm_vblank_enable(dev, pipe)); > > > > > > > > Sorry, not sure when this warning is triggered. > > > > > > Again, I just had to look at the trace: > > > [ 52.299388] drm_get_last_vbltimestamp+0xaa/0xc0 [drm] > > > [ 52.299389] drm_reset_vblank_timestamp+0x5b/0xd0 [drm] > > > [ 52.299389] drm_crtc_vblank_on.cold+0x37/0x103 [drm] > > > [ 52.299390] drm_atomic_helper_commit_modeset_enable > > > > Yeah I think vkms can't generate a reasonable timestamp when the > > hrtimer is off. I thought the warning comes from a different > > callchain, but seems to be a general problem. > > > > I guess in the vkms timestamp function we should check whether the > > timer is running, and if it's not running, then we just grab the > > current time and done. > > I tried some test about this scenario that commit_tail calls in sequence > disable > - enable - commit. > In a first test. there was a warning and found out that it raised from > vkms_get_vblank_timestamp() the code checking vblank_hrtimer's expire time > and > vblank_time. In first run, vblank_time and hrtimer's expire time was both > zero. > because vblank wasn't happened yet. this warning wasn't happend since second > run > that vblank time was set from first run. > > I don't know it's good way to solve the problem. Is there no problem in other > drm modules? Generally real hw drivers always have working clocks, not like the fake ones we have here :-) The idea behind the timestamp callback is that when vblank interrupts aren't enabled, the timestamp will help us keep track of how many vblanks have happened. So I think (but might be wrong) correct fix for this issue would be to check whether vblanks are enabled, and if not, simply pass back the current system time. That's a lie, but much better than whatever value was set last time around the hrtimer fired- e.g. similar problem can happen later on when the vblank interrupt was off for a very long time. -Daniel > > -Sidong > > > -Daniel > > > > > > > > > > > > > > > > > But I'm still wondering why after step 3 we don't get -EINVAL from > > > > > > vblank_get() - after vblank_off() vblank->enabled should be false > > > > > > again, getting us back to the same state as after 1. Is that not > > > > > > happening? > > > > > > > > > > Yes (sorry if it got confused), we got -EINVAL after setp 3: > > > > > > > > > > In step 3, at the end of the 2nd running, we have: > > > > > atomic_disable > > > > > --> vblank_off [!vblank->inmodeset + refcount going 0->1 + > > > > > inmodeset=1] > > > > > and then in next vblank_get: -EINVAL (!vblank->enabled + refcount > > > > > ends 1) > > > > > as in the first step. > > > > > > > > > > Melissa > > > > > > > > > > > -Daniel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > -Sidong > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > crtc->state->event = NULL; > > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > 2.27.0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > Daniel Vetter > > > > > > > > > > > > Software Engineer, Intel Corporation > > > > > > > > > > > > http://blog.ffwll.ch > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Daniel Vetter > > > > > > > > Software Engineer, Intel Corporation > > > > > > > > http://blog.ffwll.ch > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Daniel Vetter > > > > > > Software Engineer, Intel Corporation > > > > > > http://blog.ffwll.ch > > > > > > > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > http://blog.ffwll.ch -- 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] amdgpu_dm: fix nonblocking atomic commit use-after-free
On Tue, Jul 28, 2020 at 01:07:13PM -0400, Kazlauskas, Nicholas wrote: > On 2020-07-28 5:22 a.m., Paul Menzel wrote: > > Dear Linux folks, > > > > > > Am 25.07.20 um 07:20 schrieb Mazin Rezk: > > > On Saturday, July 25, 2020 12:59 AM, Duncan wrote: > > > > > > > On Sat, 25 Jul 2020 03:03:52 + Mazin Rezk wrote: > > > > > > > > > > Am 24.07.20 um 19:33 schrieb Kees Cook: > > > > > > > > > > > > > There was a fix to disable the async path for this driver that > > > > > > > worked around the bug too, yes? That seems like a safer and more > > > > > > > focused change that doesn't revert the SLUB defense for all > > > > > > > users, and would actually provide a complete, I think, workaround > > > > > > > > > > That said, I haven't seen the async disabling patch. If you could > > > > > link to it, I'd be glad to test it out and perhaps we can use that > > > > > instead. > > > > > > > > I'm confused. Not to put words in Kees' mouth; /I/ am confused (which > > > > admittedly could well be just because I make no claims to be a > > > > coder and am simply reading the bug and thread, but I'd appreciate some > > > > "unconfusing" anyway). > > > > > > > > My interpretation of the "async disabling" reference was that it was to > > > > comment #30 on the bug: > > > > > > > > https://bugzilla.kernel.org/show_bug.cgi?id=207383#c30 > > > > > > > > > > > > ... which (if I'm not confused on this point too) appears to be yours. > > > > There it was stated... > > > > > > > > I've also found that this bug exclusively occurs when commit_work is on > > > > the workqueue. After forcing drm_atomic_helper_commit to run all of the > > > > commits without adding to the workqueue and running the OS, the issue > > > > seems to have disappeared. > > > > <<<< > > > > > > > > Would not forcing all commits to run directly, without placing them on > > > > the workqueue, be "async disabling"? That's what I /thought/ he was > > > > referencing. > > > > > > Oh, I thought he was referring to a different patch. Kees, could I get > > > your confirmation on this? > > > > > > The change I made actually affected all of the DRM code, although > > > this could > > > easily be changed to be specific to amdgpu. (By forcing blocking on > > > amdgpu_dm's non-blocking commit code) > > > > > > That said, I'd still need to test further because I only did test it > > > for a > > > couple of hours then. Although it should work in theory. > > > > > > > OTOH your base/context swap idea sounds like a possibly "less > > > > disturbance" workaround, if it works, and given the point in the > > > > commit cycle... (But if it's out Sunday it's likely too late to test > > > > and get it in now anyway; if it's another week, tho...) > > > > > > The base/context swap idea should make the use-after-free behave how it > > > did in 5.6. Since the bug doesn't cause an issue in 5.6, it's less of a > > > "less disturbance" workaround and more of a "no disturbance" workaround. > > > > Sorry for bothering, but is there now a solution, besides reverting the > > commits, to avoid freezes/crashes *without* performance regressions? > > > > > > Kind regards, > > > > Paul > > Mazin's "drm/amd/display: Clear dm_state for fast updates" change > accomplishes this, at least as a temporary hack. Yeah I gets it's horrible, but better than nothing. Reverting the old amdgpu change to a private state object is probably a lot more invasive. > I've started work on a more large scale fix that we could get in in after. Does that include a fix for the "stuff needed by irq handler"? Either way pls cc dri-devel, I think this is something worth of a bit wider discussion. Feels like unsolved homework from the entire "make DC integrate into linux" saga ... -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 0/2] Small cleanups to ingenic-drm driver
On Tue, Jul 28, 2020 at 10:17:36PM +0200, Sam Ravnborg wrote: > Hi Paul. > > On Tue, Jul 28, 2020 at 05:16:39PM +0200, Paul Cercueil wrote: > > Here are a few cleanups to the ingenic-drm driver. > > - some error paths were missing and have been added; > > - the mode validation has been moved to the .mode_valid helper callback. > > > > Cheers, > > -Paul > > > > Paul Cercueil (2): > > drm/ingenic: Handle errors of drm_atomic_get_plane_state > > drm/ingenic: Validate mode in a .mode_valid callback > > Both looks fine, you can add my: > Reviewed-by: Sam Ravnborg > > I assume you will apply the patches. > Maybe wait for Daniel to take a look, he had some feedback on where > to add checks. I assume this is covered by the second patch. Yeah changelog for new versions would be great, but aside from that bickering patch 2 lgtm now. Cheers, Daniel > > Sam > > > > > drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 41 +++ > > 1 file changed, 27 insertions(+), 14 deletions(-) > > > > -- > > 2.27.0 > > > > _______ > > 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: [PATCH -next] drm: xlnx: Fix typo in parameter description
Hi Hyun Kwon,
Are you all sorted with drm-misc commit rights so you can push the 3
(maybe there's more) xlnx fixup patches to drm-misc-next-fixes?
Cheers, Daniel
On Sat, Jul 25, 2020 at 06:34:29AM +, Wei Yongjun wrote:
> Fix typo in parameter description.
>
> Fixes: d76271d22694 ("drm: xlnx: DRM/KMS driver for Xilinx ZynqMP DisplayPort
> Subsystem")
> Reported-by: Hulk Robot
> Signed-off-by: Wei Yongjun
> ---
> drivers/gpu/drm/xlnx/zynqmp_dp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> index 821f7a71e182..3d53638ab15e 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> @@ -44,7 +44,7 @@ MODULE_PARM_DESC(aux_timeout_ms, "DP aux timeout value in
> msec (default: 50)");
> */
> static uint zynqmp_dp_power_on_delay_ms = 4;
> module_param_named(power_on_delay_ms, zynqmp_dp_power_on_delay_ms, uint,
> 0444);
> -MODULE_PARM_DESC(aux_timeout_ms, "DP power on delay in msec (default: 4)");
> +MODULE_PARM_DESC(power_on_delay_ms, "DP power on delay in msec (default:
> 4)");
>
> /* Link configuration registers */
> #define ZYNQMP_DP_LINK_BW_SET0x0
>
>
>
--
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/5] fbdev: Remove trailing whitespace
On Wed, Jul 29, 2020 at 03:41:44PM +0200, Thomas Zimmermann wrote:
> Removes trailing whitespaces in several places.
>
> Signed-off-by: Thomas Zimmermann
checkpatch patch for fbdev, I'm blown :-)
Acked-by: Daniel Vetter
> ---
> drivers/video/fbdev/core/fbmem.c | 10 +-
> include/linux/fb.h | 18 +-
> 2 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbmem.c
> b/drivers/video/fbdev/core/fbmem.c
> index 30e73ec4ad5c..dd0ccf35f7b7 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -777,7 +777,7 @@ fb_read(struct file *file, char __user *buf, size_t
> count, loff_t *ppos)
>
> if (info->fbops->fb_read)
> return info->fbops->fb_read(info, buf, count, ppos);
> -
> +
> total_size = info->screen_size;
>
> if (total_size == 0)
> @@ -842,7 +842,7 @@ fb_write(struct file *file, const char __user *buf,
> size_t count, loff_t *ppos)
>
> if (info->fbops->fb_write)
> return info->fbops->fb_write(info, buf, count, ppos);
> -
> +
> total_size = info->screen_size;
>
> if (total_size == 0)
> @@ -1061,7 +1061,7 @@ EXPORT_SYMBOL(fb_set_var);
>
> int
> fb_blank(struct fb_info *info, int blank)
> -{
> +{
> struct fb_event event;
> int ret = -EINVAL;
>
> @@ -1437,7 +1437,7 @@ __releases(&info->lock)
> return res;
> }
>
> -static int
> +static int
> fb_release(struct inode *inode, struct file *file)
> __acquires(&info->lock)
> __releases(&info->lock)
> @@ -1627,7 +1627,7 @@ static int do_register_framebuffer(struct fb_info
> *fb_info)
> fb_info->pixmap.access_align = 32;
> fb_info->pixmap.flags = FB_PIXMAP_DEFAULT;
> }
> - }
> + }
> fb_info->pixmap.offset = 0;
>
> if (!fb_info->pixmap.blit_x)
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index 2b530e6d86e4..714187bc13ac 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -124,7 +124,7 @@ struct fb_cursor_user {
> * Register/unregister for framebuffer events
> */
>
> -/* The resolution of the passed in fb_info about to change */
> +/* The resolution of the passed in fb_info about to change */
> #define FB_EVENT_MODE_CHANGE 0x01
>
> #ifdef CONFIG_GUMSTIX_AM200EPD
> @@ -459,12 +459,12 @@ struct fb_info {
>
> #if IS_ENABLED(CONFIG_FB_BACKLIGHT)
> /* assigned backlight device */
> - /* set before framebuffer registration,
> + /* set before framebuffer registration,
> remove after unregister */
> struct backlight_device *bl_dev;
>
> /* Backlight level curve */
> - struct mutex bl_curve_mutex;
> + struct mutex bl_curve_mutex;
> u8 bl_curve[FB_BACKLIGHT_LEVELS];
> #endif
> #ifdef CONFIG_FB_DEFERRED_IO
> @@ -483,8 +483,8 @@ struct fb_info {
> char __iomem *screen_base; /* Virtual address */
> char *screen_buffer;
> };
> - unsigned long screen_size; /* Amount of ioremapped VRAM or 0 */
> - void *pseudo_palette; /* Fake palette of 16 colors */
> + unsigned long screen_size; /* Amount of ioremapped VRAM or 0 */
> + void *pseudo_palette; /* Fake palette of 16 colors */
> #define FBINFO_STATE_RUNNING 0
> #define FBINFO_STATE_SUSPENDED 1
> u32 state; /* Hardware state i.e suspend */
> @@ -587,11 +587,11 @@ static inline struct apertures_struct
> *alloc_apertures(unsigned int max_num) {
> * `Generic' versions of the frame buffer device operations
> */
>
> -extern int fb_set_var(struct fb_info *info, struct fb_var_screeninfo *var);
> -extern int fb_pan_display(struct fb_info *info, struct fb_var_screeninfo
> *var);
> +extern int fb_set_var(struct fb_info *info, struct fb_var_screeninfo *var);
> +extern int fb_pan_display(struct fb_info *info, struct fb_var_screeninfo
> *var);
> extern int fb_blank(struct fb_info *info, int blank);
> -extern void cfb_fillrect(struct fb_info *info, const struct fb_fillrect
> *rect);
> -extern void cfb_copyarea(struct fb_info *info, const struct fb_copyarea
> *area);
> +extern void cfb_fillrect(struct fb_info *info, const struct fb_fillrect
> *rect);
> +extern void cfb_copyarea(struct fb_info *info, const struct fb_copyarea
> *area);
> extern void cfb_imageblit(struct fb_info *info, const struct fb_image
> *image);
> /*
> * Drawing operations where framebuffer is in system RAM
> --
> 2.27.0
>
--
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 2/5] fbdev/core: Export framebuffer read and write code as cfb_ function
On Wed, Jul 29, 2020 at 03:41:45PM +0200, Thomas Zimmermann wrote:
> DRM fb helpers require read and write functions for framebuffer
> memory. Export the existing code from fbdev.
>
> Signed-off-by: Thomas Zimmermann
Hm I'm not super sure whether we want to actually reuse this stuff ... We
kinda don't care about the sparc special case, and just having an fbdev
implementation witch has the switch between memcpy and memcpy_to/from_io
in one single place sounds a lot simpler ...
This way we can have a clean split between the old horrors of real fbdev
drivers, and a much cleaner world in drm. It would mean a bit of
copypasting, but I think that's actually a good thing.
In general my idea for drm fbdev emulation is that for any area we have a
problem we just ignore the entire fbmem.c code and write our own: mmap,
backlight handling (still unsolved, and horrible), cfb vs sys here. This
entire fbmem.c stuff is pretty bad midlayer, trying to avoid code
duplication here doesn't seem worth it imo.
Thoughts?
-Daniel
> ---
> drivers/video/fbdev/core/fbmem.c | 53 ++--
> include/linux/fb.h | 5 +++
> 2 files changed, 41 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbmem.c
> b/drivers/video/fbdev/core/fbmem.c
> index dd0ccf35f7b7..b496ff90db3e 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -759,25 +759,18 @@ static struct fb_info *file_fb_info(struct file *file)
> return info;
> }
>
> -static ssize_t
> -fb_read(struct file *file, char __user *buf, size_t count, loff_t *ppos)
> +ssize_t fb_cfb_read(struct fb_info *info, char __user *buf, size_t count,
> + loff_t *ppos)
> {
> unsigned long p = *ppos;
> - struct fb_info *info = file_fb_info(file);
> u8 *buffer, *dst;
> u8 __iomem *src;
> int c, cnt = 0, err = 0;
> unsigned long total_size;
>
> - if (!info || ! info->screen_base)
> - return -ENODEV;
> -
> if (info->state != FBINFO_STATE_RUNNING)
> return -EPERM;
>
> - if (info->fbops->fb_read)
> - return info->fbops->fb_read(info, buf, count, ppos);
> -
> total_size = info->screen_size;
>
> if (total_size == 0)
> @@ -823,16 +816,12 @@ fb_read(struct file *file, char __user *buf, size_t
> count, loff_t *ppos)
>
> return (err) ? err : cnt;
> }
> +EXPORT_SYMBOL(fb_cfb_read);
>
> static ssize_t
> -fb_write(struct file *file, const char __user *buf, size_t count, loff_t
> *ppos)
> +fb_read(struct file *file, char __user *buf, size_t count, loff_t *ppos)
> {
> - unsigned long p = *ppos;
> struct fb_info *info = file_fb_info(file);
> - u8 *buffer, *src;
> - u8 __iomem *dst;
> - int c, cnt = 0, err = 0;
> - unsigned long total_size;
>
> if (!info || !info->screen_base)
> return -ENODEV;
> @@ -840,8 +829,20 @@ fb_write(struct file *file, const char __user *buf,
> size_t count, loff_t *ppos)
> if (info->state != FBINFO_STATE_RUNNING)
> return -EPERM;
>
> - if (info->fbops->fb_write)
> - return info->fbops->fb_write(info, buf, count, ppos);
> + if (info->fbops->fb_read)
> + return info->fbops->fb_read(info, buf, count, ppos);
> + else
> + return fb_cfb_read(info, buf, count, ppos);
> +}
> +
> +ssize_t fb_cfb_write(struct fb_info *info, const char __user *buf,
> + size_t count, loff_t *ppos)
> +{
> + unsigned long p = *ppos;
> + u8 *buffer, *src;
> + u8 __iomem *dst;
> + int c, cnt = 0, err = 0;
> + unsigned long total_size;
>
> total_size = info->screen_size;
>
> @@ -895,6 +896,24 @@ fb_write(struct file *file, const char __user *buf,
> size_t count, loff_t *ppos)
>
> return (cnt) ? cnt : err;
> }
> +EXPORT_SYMBOL(fb_cfb_write);
> +
> +static ssize_t
> +fb_write(struct file *file, const char __user *buf, size_t count, loff_t
> *ppos)
> +{
> + struct fb_info *info = file_fb_info(file);
> +
> + if (!info || !info->screen_base)
> + return -ENODEV;
> +
> + if (info->state != FBINFO_STATE_RUNNING)
> + return -EPERM;
> +
> + if (info->fbops->fb_write)
> + return info->fbops->fb_write(info, buf, count, ppos);
> + else
> + return fb_cfb_write(info, buf, count, ppos);
> +}
>
> int
> fb_pan_display(struct fb_info *info, struct fb_var_screeninfo *var)
> diff --git a/include/linux/fb.h b/include/l
Re: [PATCH 3/5] drm: Add infrastructure for vmap operations of I/O memory
On Wed, Jul 29, 2020 at 03:41:46PM +0200, Thomas Zimmermann wrote:
> Most platforms allow for accessing framebuffer I/O memory with regular
> load and store operations. Some platforms, such as sparc64, require
> the use of special instructions instead.
>
> This patch adds vmap_iomem to struct drm_gem_object_funcs. The new
> interface drm_client_buffer_vmap_iomem() gives DRM clients access to the
> I/O memory buffer. The semantics of struct drm_gem_objcet_funcs.vmap
> change slightly. It used to return system or I/O memory. Now it is
> expected to return memory addresses that can be accessed with regular
> load and store operations. So nothing changes for existing implementations
> of GEM objects. If the GEM object also implements vmap_iomem, a call
> to vmap shall only return system memory, even if I/O memory could be
> accessed with loads and stores.
>
> The existing interface drm_client_buffer_vmap() shall only return memory
> as given by drm_gem_vmap ((i.e., that is accessible via regular load and
> store). The new interface drm_client_buffer_vmap_iomem() shall only
> return I/O memory.
>
> DRM clients must map buffers by calling drm_client_buffer_vmap_iomem()
> and drm_client_buffer_vmap() to get the buffer in I/O or system memory.
> Each function returns NULL if the buffer is in the other memory area.
> Depending on the type of the returned memory, clients must access the
> framebuffer with the appropriate operations.
>
> Signed-off-by: Thomas Zimmermann
Hm I don't think this works, since for more dynamic framebuffers (like
real big gpu ttm drivers) this is a dynamic thing, which can change every
time we do an mmap. So I think the ttm approach of having an is_iomem flag
is a lot better.
The trouble with that is that you don't have correct checking of sparse
mappings, but oh well :-/ The one idea I've had to address that is using
something like this
typedef dma_buf_addr_t {
bool is_iomem;
union {
void __iomem *vaddr_iomem;
void vaddr;
};
};
And then having a wrapper for memcpy_from_dma_buf_addr and
memcpy_to_dma_buf_addr, which switches between memcpy and memcpy_from/toio
depending upon the is_iomem flag.
But it's a lot more invasive unfortunately :-/
-Daniel
> ---
> drivers/gpu/drm/drm_client.c | 52 --
> drivers/gpu/drm/drm_gem.c | 19 +
> drivers/gpu/drm/drm_internal.h | 1 +
> include/drm/drm_client.h | 8 +-
> include/drm/drm_gem.h | 17 +--
> 5 files changed, 91 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
> index 495f47d23d87..b5bbe089a41e 100644
> --- a/drivers/gpu/drm/drm_client.c
> +++ b/drivers/gpu/drm/drm_client.c
> @@ -327,6 +327,46 @@ void *drm_client_buffer_vmap(struct drm_client_buffer
> *buffer)
> }
> EXPORT_SYMBOL(drm_client_buffer_vmap);
>
> +/**
> + * drm_client_buffer_vmap_iomem - Map DRM client buffer into address space
> + * @buffer: DRM client buffer
> + *
> + * This function maps a client buffer into kernel address space. If the
> + * buffer is already mapped, it returns the mapping's address.
> + *
> + * Client buffer mappings are not ref'counted. Each call to
> + * drm_client_buffer_vmap() should be followed by a call to
> + * drm_client_buffer_vunmap(); or the client buffer should be mapped
> + * throughout its lifetime.
> + *
> + * Returns:
> + * The mapped memory's address
> + */
> +void __iomem *drm_client_buffer_vmap_iomem(struct drm_client_buffer *buffer)
> +{
> + void __iomem *vaddr_iomem;
> +
> + if (buffer->vaddr_iomem)
> + return buffer->vaddr_iomem;
> +
> + /*
> + * FIXME: The dependency on GEM here isn't required, we could
> + * convert the driver handle to a dma-buf instead and use the
> + * backend-agnostic dma-buf vmap support instead. This would
> + * require that the handle2fd prime ioctl is reworked to pull the
> + * fd_install step out of the driver backend hooks, to make that
> + * final step optional for internal users.
> + */
> + vaddr_iomem = drm_gem_vmap_iomem(buffer->gem);
> + if (IS_ERR(vaddr_iomem))
> + return vaddr_iomem;
> +
> + buffer->vaddr_iomem = vaddr_iomem;
> +
> + return vaddr_iomem;
> +}
> +EXPORT_SYMBOL(drm_client_buffer_vmap_iomem);
> +
> /**
> * drm_client_buffer_vunmap - Unmap DRM client buffer
> * @buffer: DRM client buffer
> @@ -337,8 +377,16 @@ EXPORT_SYMBOL(drm_client_buffer_vmap);
> */
> void drm_client_buffer_vunmap(struct drm_client_buffer *buffer)
> {
> - drm_gem_vunmap(buffer->gem, buff
Re: [PATCH] drm/vkms: add missing drm_crtc_vblank_put to the get/put pair on flush
On Thu, Jul 30, 2020 at 07:09:25AM -0300, Melissa Wen wrote: > On 07/29, Daniel Vetter wrote: > > On Wed, Jul 29, 2020 at 9:09 PM Melissa Wen wrote: > > > > > > Melissa Wen > > > > > > On Sat, Jul 25, 2020 at 3:12 PM Daniel Vetter wrote: > > > > > > > > On Sat, Jul 25, 2020 at 7:45 PM Melissa Wen > > > > wrote: > > > > > > > > > > On 07/25, Daniel Vetter wrote: > > > > > > On Sat, Jul 25, 2020 at 5:12 AM Sidong Yang > > > > > > wrote: > > > > > > > > > > > > > > On Wed, Jul 22, 2020 at 05:17:05PM +0200, Daniel Vetter wrote: > > > > > > > > On Wed, Jul 22, 2020 at 4:06 PM Melissa Wen > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On 07/22, dan...@ffwll.ch wrote: > > > > > > > > > > On Wed, Jul 22, 2020 at 08:04:11AM -0300, Melissa Wen wrote: > > > > > > > > > > > This patch adds a missing drm_crtc_vblank_put op to the > > > > > > > > > > > pair > > > > > > > > > > > drm_crtc_vblank_get/put (inc/decrement counter to > > > > > > > > > > > guarantee vblanks). > > > > > > > > > > > > > > > > > > > > > > It clears the execution of the following kms_cursor_crc > > > > > > > > > > > subtests: > > > > > > > > > > > 1. pipe-A-cursor-[size,alpha-opaque, NxN-(on-screen, > > > > > > > > > > > off-screen, sliding, > > > > > > > > > > >random, fast-moving])] - successful when running > > > > > > > > > > > individually. > > > > > > > > > > > 2. pipe-A-cursor-dpms passes again > > > > > > > > > > > 3. pipe-A-cursor-suspend also passes > > > > > > > > > > > > > > > > > > > > > > The issue was initially tracked in the sequential > > > > > > > > > > > execution of IGT > > > > > > > > > > > kms_cursor_crc subtest: when running the test sequence or > > > > > > > > > > > one of its > > > > > > > > > > > subtests twice, the odd execs complete and the pairs get > > > > > > > > > > > stuck in an > > > > > > > > > > > endless wait. In the IGT code, calling a wait_for_vblank > > > > > > > > > > > before the start > > > > > > > > > > > of CRC capture prevented the busy-wait. But the problem > > > > > > > > > > > persisted in the > > > > > > > > > > > pipe-A-cursor-dpms and -suspend subtests. > > > > > > > > > > > > > > > > > > > > > > Checking the history, the pipe-A-cursor-dpms subtest was > > > > > > > > > > > successful when, > > > > > > > > > > > in vkms_atomic_commit_tail, instead of using the > > > > > > > > > > > flip_done op, it used > > > > > > > > > > > wait_for_vblanks. Another way to prevent blocking was > > > > > > > > > > > wait_one_vblank when > > > > > > > > > > > enabling crtc. However, in both cases, > > > > > > > > > > > pipe-A-cursor-suspend persisted > > > > > > > > > > > blocking in the 2nd start of CRC capture, which may > > > > > > > > > > > indicate that > > > > > > > > > > > something got stuck in the step of CRC setup. Indeed, > > > > > > > > > > > wait_one_vblank in > > > > > > > > > > > the crc setup was able to sync things and free all > > > > > > > > > > > kms_cursor_crc > > > > > > > > > > > subtests. > > > > > > > > > > > > > > > > > > > > > > Tracing and comparing a clean run with a blocked one: > > > > > > > > > > > - in a clean one, vkms_crtc_atomic_flush enables vblanks; > > > > > > > > >
Re: [PATCH 0/2] Small cleanups to ingenic-drm driver
On Wed, Jul 29, 2020 at 02:28:01AM +0200, Paul Cercueil wrote: > > > Le mer. 29 juil. 2020 à 0:00, dan...@ffwll.ch a écrit : > > On Tue, Jul 28, 2020 at 10:17:36PM +0200, Sam Ravnborg wrote: > > > Hi Paul. > > > > > > On Tue, Jul 28, 2020 at 05:16:39PM +0200, Paul Cercueil wrote: > > > > Here are a few cleanups to the ingenic-drm driver. > > > > - some error paths were missing and have been added; > > > > - the mode validation has been moved to the .mode_valid helper > > > callback. > > > > > > > > Cheers, > > > > -Paul > > > > > > > > Paul Cercueil (2): > > > > drm/ingenic: Handle errors of drm_atomic_get_plane_state > > > > drm/ingenic: Validate mode in a .mode_valid callback > > > > > > Both looks fine, you can add my: > > > Reviewed-by: Sam Ravnborg > > > > > > I assume you will apply the patches. > > > Maybe wait for Daniel to take a look, he had some feedback on where > > > to add checks. I assume this is covered by the second patch. > > > > Yeah changelog for new versions would be great, but aside from that > > bickering patch 2 lgtm now. > > This patchset is V1, I'm fixing issues you saw in the ingenic-drm driver > when reviewing a different patchset. Oh right that was pre-existing issue in which callback to use, apologies for the confusion. -Daniel > > Thanks for the review, I'll apply now. > > -Paul > > > > -- 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/vkms: Fix soft lockup.
/drm_vblank.c:487
> call_timer_fn+0x3a/0x230 kernel/time/timer.c:1404
> expire_timers kernel/time/timer.c:1449 [inline]
> __run_timers kernel/time/timer.c:1773 [inline]
> __run_timers kernel/time/timer.c:1740 [inline]
> run_timer_softirq+0x2b8/0x840 kernel/time/timer.c:1786
> __do_softirq+0x118/0x344 kernel/softirq.c:292
> asm_call_on_stack+0xf/0x20 arch/x86/entry/entry_64.S:711
>
> __run_on_irqstack arch/x86/include/asm/irq_stack.h:22 [inline]
> run_on_irqstack_cond arch/x86/include/asm/irq_stack.h:48 [inline]
> do_softirq_own_stack+0x5a/0x70 arch/x86/kernel/irq_64.c:77
> invoke_softirq kernel/softirq.c:387 [inline]
> __irq_exit_rcu kernel/softirq.c:417 [inline]
> irq_exit_rcu+0xb1/0xd0 kernel/softirq.c:429
> sysvec_apic_timer_interrupt+0x42/0xd0 arch/x86/kernel/apic/apic.c:1091
> asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:596
> [ cut here ]
> WARNING: CPU: 5 PID: 8121 at drivers/gpu/drm/vkms/vkms_crtc.c:21
> vkms_vblank_simulate+0x19a/0x1b0 drivers/gpu/drm/vkms/vkms_crtc.c:21
> Modules linked in:
> CPU: 5 PID: 8121 Comm: syslog-ng Tainted: GW 5.8.0-rc2-csan #2
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> Ubuntu-1.8.2-1ubuntu1 04/01/2014
> RIP: 0010:vkms_vblank_simulate+0x19a/0x1b0 drivers/gpu/drm/vkms/vkms_crtc.c:21
> RSP: 0018:c9184ee8 EFLAGS: 00010046
> RAX: 88822864a080 RBX: 88822ecb8fb0 RCX: 826cd2b0
> RDX: 8001 RSI: 826cd40a RDI: 0007
> RBP: 001f058d R08: 88822864a080 R09: 7fff
> R10: R11: R12: 88822ecb8630
> R13: R14: 017998a35917 R15: 888237d5ed80
> FS: 7f8dcbde0700() GS:888237d4() knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: ff600400 CR3: 00022575f002 CR4: 000626e0
> Call Trace:
>
> __run_hrtimer kernel/time/hrtimer.c:1520 [inline]
> __hrtimer_run_queues+0x14c/0x410 kernel/time/hrtimer.c:1584
> hrtimer_interrupt+0x141/0x2c0 kernel/time/hrtimer.c:1646
> local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1080 [inline]
> __sysvec_apic_timer_interrupt+0x6e/0x170 arch/x86/kernel/apic/apic.c:1097
> asm_call_on_stack+0xf/0x20 arch/x86/entry/entry_64.S:711
>
> __run_on_irqstack arch/x86/include/asm/irq_stack.h:22 [inline]
> run_on_irqstack_cond arch/x86/include/asm/irq_stack.h:48 [inline]
> sysvec_apic_timer_interrupt+0xa9/0xd0 arch/x86/kernel/apic/apic.c:1091
> asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:596
> RIP: 0010:con_should_update drivers/tty/vt/vt.c:291 [inline]
> RIP: 0010:do_con_write.part.0+0xad6/0xfa0 drivers/tty/vt/vt.c:2790
> ---[ end trace d6a6c6a9ecb73597 ]---
> NMI backtrace for cpu 5 skipped: idling at native_halt+0xd/0x10
> arch/x86/include/asm/irqflags.h:66
>
> Cc: sta...@vger.kernel.org
> Reported-by: Hulk Robot
> Signed-off-by: Xu Qiang
> ---
> drivers/gpu/drm/vkms/vkms_crtc.c | 5 -
> drivers/gpu/drm/vkms/vkms_drv.h | 1 +
> 2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c
> b/drivers/gpu/drm/vkms/vkms_crtc.c
> index ac85e17428f8..655294f11bb8 100644
> --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> @@ -49,7 +49,7 @@ static enum hrtimer_restart vkms_vblank_simulate(struct
> hrtimer *timer)
> DRM_DEBUG_DRIVER("Composer worker already queued\n");
> }
>
> - return HRTIMER_RESTART;
> + return output->hrtimer_exit ? HRTIMER_NORESTART : HRTIMER_RESTART;
Hm don't we need some locking for this? Or at least a bit of thought about
ordering and stuff, maybe a comment about what's going on. Or are we
covered already by a different lock (but then maybe the check here should
be moved, and a comment added about which spinlock protects this).
The other question: How did you even end up in here? I think the better
fix would be to make sure the mode we're setting is reasonable, i.e. maybe
a refresh rate between 10Hz and 1000Hz or so. Even slow machines should
then be able to stop the timer ... That would be a lot more reasonable
fix, refresh rate with just a few ns never happen on real displays :-)
Cheers, Daniel
> }
>
> static int vkms_enable_vblank(struct drm_crtc *crtc)
> @@ -66,6 +66,8 @@ static int vkms_enable_vblank(struct drm_crtc *crtc)
> out->period_ns = ktime_set(0, vblank->framedur_ns);
> hrtimer_start(&out->vblank_hrtimer, out->period_ns, HRTIMER_MODE_REL);
>
> + out->hrtimer_exit = false;
> +
> return 0;
> }
>
> @@ -73,6 +75,7 @@ static void vkms_
Re: [PATCH] drm: re-add deleted doc for drm_gem_open_ioctl
On Wed, Jul 29, 2020 at 01:35:52AM -0400, Steve Cohen wrote: > Add back the removed documentation for drm_gem_open_ioctl. > This patch is submitted in response to [1]. > > [1] > https://lore.kernel.org/linux-arm-msm/20200728085244.GY6419@phenom.ffwll.local/ > > Signed-off-by: Steve Cohen > --- > drivers/gpu/drm/drm_gem.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c > index ee2058a..fe94122 100644 > --- a/drivers/gpu/drm/drm_gem.c > +++ b/drivers/gpu/drm/drm_gem.c > @@ -871,6 +871,9 @@ drm_gem_flink_ioctl(struct drm_device *dev, void *data, > * @file_priv: drm file-private structure > * > * Open an object using the global name, returning a handle and the size. > + * > + * This handle (of course) holds a reference to the object, so the object > + * will not go away until the handle is deleted. Applied, thanks. -Daniel > */ > int > drm_gem_open_ioctl(struct drm_device *dev, void *data, > -- > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > a Linux Foundation Collaborative Project > -- 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 2/5] fbdev/core: Export framebuffer read and write code as cfb_ function
On Wed, Jul 29, 2020 at 06:36:03PM +0200, Sam Ravnborg wrote:
> Hi Daniel.
>
> On Wed, Jul 29, 2020 at 03:53:28PM +0200, dan...@ffwll.ch wrote:
> > On Wed, Jul 29, 2020 at 03:41:45PM +0200, Thomas Zimmermann wrote:
> > > DRM fb helpers require read and write functions for framebuffer
> > > memory. Export the existing code from fbdev.
> > >
> > > Signed-off-by: Thomas Zimmermann
> >
> > Hm I'm not super sure whether we want to actually reuse this stuff ... We
> > kinda don't care about the sparc special case, and just having an fbdev
> > implementation witch has the switch between memcpy and memcpy_to/from_io
> > in one single place sounds a lot simpler ...
> >
> > This way we can have a clean split between the old horrors of real fbdev
> > drivers, and a much cleaner world in drm. It would mean a bit of
> > copypasting, but I think that's actually a good thing.
> >
> > In general my idea for drm fbdev emulation is that for any area we have a
> > problem we just ignore the entire fbmem.c code and write our own: mmap,
> > backlight handling (still unsolved, and horrible), cfb vs sys here. This
> > entire fbmem.c stuff is pretty bad midlayer, trying to avoid code
> > duplication here doesn't seem worth it imo.
> >
> > Thoughts?
>
>
> I can see that fbmem is a mix of ioctl support and other stuff.
> We could factor out all the ioctl parts of fbmem.c to a new file
> named fbioctl.c.
>
> And then let the ioctl parts call down into drm stuff and avoid reusing
> the fbdev code when we first reach drm code.
> This would require local copies of:
> sys_read, sys_write, sys_fillrect, sys_copyarea, sys_imageblit
> and more I think which I missed.
>
> With local copies we could avoid some of the special cases and trim the
> unctions to what is required by drm only.
> And then no more fbmem dependencies and no dependencies to several of
> the small helper functions. So less entanglement with fbdev core.
>
> This all sounds simple so I am surely missing a lot a ugly details here.
>
> And should we touch this anyway we need a test suite to verify not too
> much breaks. To the best of my knowledge there is not yet such a test
> suite :-( Maybe because people caring about fbdev are limited.
Well my idea was to not refactor anything, but just have drm copies of the
various fb_ops callbacks. Definitely not even more refactoring :-)
-Daniel
>
> Sam
>
>
>
>
>
> > -Daniel
> >
> > > ---
> > > drivers/video/fbdev/core/fbmem.c | 53 ++--
> > > include/linux/fb.h | 5 +++
> > > 2 files changed, 41 insertions(+), 17 deletions(-)
> > >
> > > diff --git a/drivers/video/fbdev/core/fbmem.c
> > > b/drivers/video/fbdev/core/fbmem.c
> > > index dd0ccf35f7b7..b496ff90db3e 100644
> > > --- a/drivers/video/fbdev/core/fbmem.c
> > > +++ b/drivers/video/fbdev/core/fbmem.c
> > > @@ -759,25 +759,18 @@ static struct fb_info *file_fb_info(struct file
> > > *file)
> > > return info;
> > > }
> > >
> > > -static ssize_t
> > > -fb_read(struct file *file, char __user *buf, size_t count, loff_t *ppos)
> > > +ssize_t fb_cfb_read(struct fb_info *info, char __user *buf, size_t count,
> > > + loff_t *ppos)
> > > {
> > > unsigned long p = *ppos;
> > > - struct fb_info *info = file_fb_info(file);
> > > u8 *buffer, *dst;
> > > u8 __iomem *src;
> > > int c, cnt = 0, err = 0;
> > > unsigned long total_size;
> > >
> > > - if (!info || ! info->screen_base)
> > > - return -ENODEV;
> > > -
> > > if (info->state != FBINFO_STATE_RUNNING)
> > > return -EPERM;
> > >
> > > - if (info->fbops->fb_read)
> > > - return info->fbops->fb_read(info, buf, count, ppos);
> > > -
> > > total_size = info->screen_size;
> > >
> > > if (total_size == 0)
> > > @@ -823,16 +816,12 @@ fb_read(struct file *file, char __user *buf, size_t
> > > count, loff_t *ppos)
> > >
> > > return (err) ? err : cnt;
> > > }
> > > +EXPORT_SYMBOL(fb_cfb_read);
> > >
> > > static ssize_t
> > > -fb_write(struct file *file, const char __user *buf, size_t count, loff_t
> > > *ppos)
> > > +fb_read(struct file *file, char __user *buf, size_t count, loff_t *ppos)
> > > {
> > > - unsigned long p = *ppos;
> > >
Re: [PATCH 3/5] drm: Add infrastructure for vmap operations of I/O memory
On Thu, Jul 30, 2020 at 10:14:43AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 29.07.20 um 15:57 schrieb dan...@ffwll.ch:
> > On Wed, Jul 29, 2020 at 03:41:46PM +0200, Thomas Zimmermann wrote:
> >> Most platforms allow for accessing framebuffer I/O memory with regular
> >> load and store operations. Some platforms, such as sparc64, require
> >> the use of special instructions instead.
> >>
> >> This patch adds vmap_iomem to struct drm_gem_object_funcs. The new
> >> interface drm_client_buffer_vmap_iomem() gives DRM clients access to the
> >> I/O memory buffer. The semantics of struct drm_gem_objcet_funcs.vmap
> >> change slightly. It used to return system or I/O memory. Now it is
> >> expected to return memory addresses that can be accessed with regular
> >> load and store operations. So nothing changes for existing implementations
> >> of GEM objects. If the GEM object also implements vmap_iomem, a call
> >> to vmap shall only return system memory, even if I/O memory could be
> >> accessed with loads and stores.
> >>
> >> The existing interface drm_client_buffer_vmap() shall only return memory
> >> as given by drm_gem_vmap ((i.e., that is accessible via regular load and
> >> store). The new interface drm_client_buffer_vmap_iomem() shall only
> >> return I/O memory.
> >>
> >> DRM clients must map buffers by calling drm_client_buffer_vmap_iomem()
> >> and drm_client_buffer_vmap() to get the buffer in I/O or system memory.
> >> Each function returns NULL if the buffer is in the other memory area.
> >> Depending on the type of the returned memory, clients must access the
> >> framebuffer with the appropriate operations.
> >>
> >> Signed-off-by: Thomas Zimmermann
> >
> > Hm I don't think this works, since for more dynamic framebuffers (like
> > real big gpu ttm drivers) this is a dynamic thing, which can change every
> > time we do an mmap. So I think the ttm approach of having an is_iomem flag
> > is a lot better.
> >
> > The trouble with that is that you don't have correct checking of sparse
> > mappings, but oh well :-/ The one idea I've had to address that is using
> > something like this
> >
> > typedef dma_buf_addr_t {
> > bool is_iomem;
> > union {
> > void __iomem *vaddr_iomem;
> > void vaddr;
> > };
> > };
> >
> > And then having a wrapper for memcpy_from_dma_buf_addr and
> > memcpy_to_dma_buf_addr, which switches between memcpy and memcpy_from/toio
> > depending upon the is_iomem flag.
> >
> > But it's a lot more invasive unfortunately :-/
>
> What do you think about introducing read and write callbacks for GEM
> objects? Like this:
>
> int drm_gem_read(struct drm_gem_object *gbo, size_t off, size_t len,
> void *buf);
>
> int drm_gem_write(struct drm_gem_object *gbo, size_t off, size_t len,
> const void *buf);
>
> The common case would by memcpy, but GEM implementations could provide
> their own thing. The fbdev blit function would look like
>
> vaddr = drm_gem_vmap(gbo)
> if (IS_ERR(vaddr))
> return
>
> for (each line) {
> drm_gem_write(gbo, gbo_line_offset, line_size, src)
> gbo_line_offset = /* next line */
> src = /* next line */
> }
>
> drm_gem_vunmap(gbo);
>
> The whole mess about I/O access would be self-contained.
Copying the irc discussion over: We've had that idea floating around years
ago, i915-gem even implemented in the form of pwrite/pread for usersapce.
But now all userspace moved over to mmap, so read/write has fallen out of
favour.
I'm also not sure whether we really need to fix more than just fbcon on
fbdev on drm emulation, and it feels a bit silly to add read/write just
for that. Also the is_iomem flag on the vmap (and maybe eventually on
mmap, no idea) might be able to let us fix this at least for real
eventually.
Cheers, Daniel
>
> Best regards
> Thomas
>
> > -Daniel
> >
> >> ---
> >> drivers/gpu/drm/drm_client.c | 52 --
> >> drivers/gpu/drm/drm_gem.c | 19 +
> >> drivers/gpu/drm/drm_internal.h | 1 +
> >> include/drm/drm_client.h | 8 +-
> >> include/drm/drm_gem.h | 17 +--
> >> 5 files changed, 91 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
> >> index 495f47d23d87..b5bbe089a41e 100644
> >> --- a/drivers/gpu/drm/drm_client.c
Re: [PATCH] Added orientation quirk for ASUS tablet model T103HAF
On Wed, Jul 29, 2020 at 05:54:16PM +0300, Marius Iacob wrote:
> From 06ba7d3e64e55262bf818084904eec7b7320a2ad Mon Sep 17 00:00:00 2001
> From: Marius Iacob
> Date: Wed, 29 Jul 2020 16:51:41 +0300
> Subject: [PATCH] Added orientation quirk for ASUS tablet model T103HAF
Please format the patch per
https://www.kernel.org/doc/html/latest/process/submitting-patches.html
- subject needs drm: prefix
- signed-off-by missing
- git apply-mbox fails to parse this, don't just paste the output of
something like git show, that doesn't work
Yes I know the kernel process isn't very friendly for newbies, apologies.
-Daniel
>
> ---
> drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
> b/drivers/gpu/drm/drm_panel_orientation_quirks.c
> index d00ea384dcbf..58f5dc2f6dd5 100644
> --- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
> +++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
> @@ -121,6 +121,12 @@ static const struct dmi_system_id orientation_data[] =
> {
> DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "T101HA"),
> },
> .driver_data = (void *)&lcd800x1280_rightside_up,
> + }, { /* Asus T103HAF */
> + .matches = {
> + DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
> + DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "T103HAF"),
> + },
> + .driver_data = (void *)&lcd800x1280_rightside_up,
> }, { /* GPD MicroPC (generic strings, also match on bios date) */
> .matches = {
> DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Default string"),
> --
> 2.27.0
>
> ___
> 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: [PATCH] drm/vkms: fix xrgb on compute crc
On Thu, Jul 30, 2020 at 05:25:24PM -0300, Melissa Wen wrote:
> The previous memset operation was not correctly zeroing the alpha
> channel to compute the crc, and as a result, the IGT subtest
> kms_cursor_crc/pipe-A-cursor-alpha-transparent fails.
>
> Fixes: db7f419c06d7c ("drm/vkms: Compute CRC with Cursor Plane")
>
> Signed-off-by: Melissa Wen
Applied to drm-misc-next, thanks for your patch.
> ---
> drivers/gpu/drm/vkms/vkms_composer.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
> b/drivers/gpu/drm/vkms/vkms_composer.c
> index 4af2f19480f4..b8b060354667 100644
> --- a/drivers/gpu/drm/vkms/vkms_composer.c
> +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> @@ -33,7 +33,7 @@ static uint32_t compute_crc(void *vaddr_out, struct
> vkms_composer *composer)
>+ (i * composer->pitch)
>+ (j * composer->cpp);
> /* XRGB format ignores Alpha channel */
> - memset(vaddr_out + src_offset + 24, 0, 8);
> + bitmap_clear(vaddr_out + src_offset, 24, 8);
Yeah that's a pretty good "oops" oversight on review, nice catch!
Cheers, Daniel
> crc = crc32_le(crc, vaddr_out + src_offset,
> sizeof(u32));
> }
> --
> 2.27.0
>
--
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 00/49] ttm mem manager refactoring.
On Fri, Jul 31, 2020 at 11:17:26AM +0200, Christian König wrote: > Am 31.07.20 um 06:04 schrieb Dave Airlie: > > I started pulling on a thread, and it led me down a hole. > > We might want to make that hole even bigger :) > > How about we rename the ttm_mem_reg into ttm_resource and > ttm_mem_type_manager into ttm_resource_manager. +1 on names I can understand, I alwas get confused about what exactly ttm means with mem_reg and mem_type_manager. -Daniel > > Neither amdgpu's OA/GWS resources nor the IDs in VMGFX are really memory. > > In the long term I also want to move the whole address handling into each > backend. > > Going to send comments on the individual patches as well. > > > This series refactors the ttm ttm_mem_type_manager object into > > a driver owned, allocated, subclassaed object. > > > > It starts with two minor fixes for some bad assumptions in two drivers. > > > > Enables a new init path, ports all the drivers to the new init > > path, and cleans up the old init path. > > Enables a new takedown path, ports all the drivers to the new takedown > > path, and cleans up the old takedown path > > Wraps all access to the memory managers in the bo_device in a wrapper > > across all drivers. > > Make debug callback optional > > Enables driver to provide their own mem manager objects > > Subclasses the objects in all drivers and makes them into driver owned > > object > > Drops the bo_device arrays of pointers, and some unneeded links and > > struct members > > Cleans up one api. > > > > I think I'd probably want to merge all this via drm-misc, so if I can > > collect > > acks/r-b from driver maintainers that would be good. > > > > This is also based on Chrisitan's work to remove init_mem_type, so it won't > > apply until he's finished getting all of that into drm-misc. > > Preparing to push that to drm-misc-next just now. > > Regards, > Christian. > > > > > https://nam11.safelinks.protection.outlook.com/?url=https:%2F%2Fcgit.freedesktop.org%2F~airlied%2Flinux%2Flog%2F%3Fh%3Dttm-refactor-mem-manager&data=02%7C01%7Cchristian.koenig%40amd.com%7Caa32512acf9f4bf455ef08d83506f9d2%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637317651361302583&sdata=2sQt4A48ODl0Nq4P21YG3vRNdhkDZcZp0XHkQ930SAI%3D&reserved=0 > > is the tree I've built this on top off, so it's probably going to get > > rebased > > but the code should stay mostly the same. > > > > I've done some boot testing on nouveau, and I hope to test it on vmwgfx and > > amdgpu soon. > > > > Dave. > > > > > > ___ > 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: [PATCH 34/49] drm/ttm: make manager debug function optional
On Fri, Jul 31, 2020 at 02:05:05PM +1000, Dave Airlie wrote: > From: Dave Airlie > > Signed-off-by: Dave Airlie > --- > drivers/gpu/drm/ttm/ttm_bo.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c > index 92de8a6d7647..1e8fda1c9b3a 100644 > --- a/drivers/gpu/drm/ttm/ttm_bo.c > +++ b/drivers/gpu/drm/ttm/ttm_bo.c > @@ -88,7 +88,7 @@ static void ttm_mem_type_debug(struct ttm_bo_device *bdev, > struct drm_printer *p > drm_printf(p, "size: %llu\n", man->size); > drm_printf(p, "available_caching: 0x%08X\n", > man->available_caching); > drm_printf(p, "default_caching: 0x%08X\n", man->default_caching); > - if (mem_type != TTM_PL_SYSTEM) > + if (mem_type != TTM_PL_SYSTEM && man->func->debug) > (*man->func->debug)(man, p); > } Bit a bikeshed, but what about exporting this function (maybe with the man as argument, not the bdev, mem_type pair) and using it in the first 2 patches? Avoids surprises with optional func->debug. -Daniel > > -- > 2.26.2 > > _______ > 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: [PATCH 49/49] drm/ttm: consolidate manager used apis into a set and get.
On Fri, Jul 31, 2020 at 02:05:20PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> This is probably something we could consider removing, vmwgfx
> is the only user, and we might be able to faciliate it another way
>
> but for now just consolidate it all into accessors.
>
> Signed-off-by: Dave Airlie
Maybe I'm missing something, but doesn't this boild down to:
tmm_mm_used(type) = (bool) ttm_manager_type(type)
now that all resource managers are explicitly registered? I think there's
nothing else left, your ttm_set_driver_manager essentially replaces
ttm_mm_set_use.
-Daniel
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 4 ++--
> drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 4 ++--
> drivers/gpu/drm/nouveau/nouveau_ttm.c | 8
> drivers/gpu/drm/ttm/ttm_bo.c | 6 +++---
> drivers/gpu/drm/ttm/ttm_bo_manager.c | 4 ++--
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 14 +++---
> drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 4 ++--
> drivers/gpu/drm/vmwgfx/vmwgfx_thp.c | 4 ++--
> include/drm/ttm/ttm_bo_driver.h | 8
> 9 files changed, 28 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> index b4480ca30988..7e84aa2c0064 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> @@ -128,7 +128,7 @@ int amdgpu_gtt_mgr_init(struct amdgpu_device *adev,
> uint64_t gtt_size)
> }
>
> ttm_set_driver_manager(&adev->mman.bdev, TTM_PL_TT, &mgr->manager);
> - ttm_bo_use_mm(man);
> + ttm_mm_set_use(man, true);
> return 0;
> }
>
> @@ -146,7 +146,7 @@ void amdgpu_gtt_mgr_fini(struct amdgpu_device *adev)
> struct amdgpu_gtt_mgr *mgr = to_gtt_mgr(man);
> int ret;
>
> - ttm_bo_disable_mm(man);
> + ttm_mm_set_use(man, false);
>
> ret = ttm_bo_force_list_clean(&adev->mman.bdev, man);
> if (ret)
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> index f0e65a6fdf88..50949aa968fd 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> @@ -205,7 +205,7 @@ int amdgpu_vram_mgr_init(struct amdgpu_device *adev)
> DRM_ERROR("Failed to register sysfs\n");
>
> ttm_set_driver_manager(&adev->mman.bdev, TTM_PL_VRAM, &mgr->manager);
> - ttm_bo_use_mm(man);
> + ttm_mm_set_use(man, true);
> return 0;
> }
>
> @@ -223,7 +223,7 @@ void amdgpu_vram_mgr_fini(struct amdgpu_device *adev)
> struct amdgpu_vram_mgr *mgr = to_vram_mgr(man);
> int ret;
>
> - ttm_bo_disable_mm(man);
> + ttm_mm_set_use(man, false);
>
> ret = ttm_bo_force_list_clean(&adev->mman.bdev, man);
> if (ret)
> diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c
> b/drivers/gpu/drm/nouveau/nouveau_ttm.c
> index 89521d3ed9da..32ce930d1bd8 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
> @@ -176,7 +176,7 @@ nouveau_ttm_init_vram(struct nouveau_drm *drm)
> man->use_io_reserve_lru = true;
> ttm_bo_init_mm_base(man, drm->gem.vram_available >> PAGE_SHIFT);
> ttm_set_driver_manager(&drm->ttm.bdev, TTM_PL_VRAM, man);
> - ttm_bo_use_mm(man);
> + ttm_mm_set_use(man, true);
> return 0;
> } else {
> return ttm_bo_man_init(&drm->ttm.bdev, TTM_PL_VRAM,
> @@ -192,7 +192,7 @@ nouveau_ttm_fini_vram(struct nouveau_drm *drm)
> struct ttm_mem_type_manager *man = ttm_manager_type(&drm->ttm.bdev,
> TTM_PL_VRAM);
>
> if (drm->client.device.info.family >= NV_DEVICE_INFO_V0_TESLA) {
> - ttm_bo_disable_mm(man);
> + ttm_mm_set_use(man, false);
> ttm_bo_force_list_clean(&drm->ttm.bdev, man);
> ttm_bo_man_cleanup(man);
> ttm_set_driver_manager(&drm->ttm.bdev, TTM_PL_VRAM, NULL);
> @@ -237,7 +237,7 @@ nouveau_ttm_init_gtt(struct nouveau_drm *drm)
> man->use_tt = true;
> ttm_bo_init_mm_base(man, size_pages);
> ttm_set_driver_manager(&drm->ttm.bdev, TTM_PL_TT, man);
> - ttm_bo_use_mm(man);
> + ttm_mm_set_use(man, true);
> return 0;
> }
>
> @@ -250,7 +250,7 @@ nouveau_ttm_fini_gtt(struct nouveau_drm *drm)
> drm->agp.bridge)
> ttm_bo_man_takedown(&drm->ttm.bdev, TTM_PL_TT);
Re: [PATCH 47/49] drm/ttm: drop list of memory managers from device.
On Fri, Jul 31, 2020 at 02:05:18PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> The driver now controls these, the core just controls the system
> memory one.
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/ttm/ttm_bo.c| 2 --
> include/drm/ttm/ttm_bo_driver.h | 6 --
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index f2b41c4d7d51..f35548ff17e8 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -1608,8 +1608,6 @@ int ttm_bo_device_init(struct ttm_bo_device *bdev,
>
> bdev->driver = driver;
>
> - memset(bdev->man_priv, 0, sizeof(bdev->man_priv));
> -
> ttm_bo_init_sysman(bdev);
>
> bdev->vma_manager = vma_manager;
> diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
> index bfc549782775..b2ffeaed94e7 100644
> --- a/include/drm/ttm/ttm_bo_driver.h
> +++ b/include/drm/ttm/ttm_bo_driver.h
> @@ -414,7 +414,7 @@ struct ttm_bo_device {
> /*
>* access via ttm_manager_type.
>*/
> - struct ttm_mem_type_manager man_priv[TTM_NUM_MEM_TYPES];
> + struct ttm_mem_type_manager sysman; /* move to global */
Not sure we want to move this to global. With the shrinker rework ideas I
discussed with Christian somewhere (I think) we could easily do a
per-device shrinker. And then global kinda completely disappears (minus
maybe a drm-global limit on how much crap you can permanently pin in
system memory for scanout, but that's a different thing I think).
-Daniel
> struct ttm_mem_type_manager *man_drv[TTM_NUM_MEM_TYPES];
> /*
>* Protected by internal locks.
> @@ -446,9 +446,11 @@ struct ttm_bo_device {
> static inline struct ttm_mem_type_manager *ttm_manager_type(struct
> ttm_bo_device *bdev,
> int mem_type)
> {
> + if (mem_type == TTM_PL_SYSTEM)
> + return &bdev->sysman;
> if (bdev->man_drv[mem_type])
> return bdev->man_drv[mem_type];
> - return &bdev->man_priv[mem_type];
> + return NULL;
> }
>
> static inline void ttm_set_driver_manager(struct ttm_bo_device *bdev,
> --
> 2.26.2
>
> ___
> 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: [PATCH 26/49] drm/ttm: add wrapper to get manager from bdev.
On Fri, Jul 31, 2020 at 05:21:38PM +1000, Dave Airlie wrote: > On Fri, 31 Jul 2020 at 17:14, Thomas Zimmermann wrote: > > > > Hi > > > > Am 31.07.20 um 06:04 schrieb Dave Airlie: > > > From: Dave Airlie > > > > > > This will allow different abstractions later. > > > > You should consider moving this patch to the beginning of the series, so > > that patches 1 to 25 can benefit from it. > > I did consider it, but I'd have to move all the follow on patches as > well, and it got messy in rebase land, and I started introducing > errors, so I left it alone, and it's not necessary until the patch > that changes it's definition anyways. I like this ordering a lot better, it gives a clear separation between the different steps. Some code gets touched multiple times, but interleaving the demidlayering would only make this worse I think. -Daniel > > Dave. > ___ > 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: [PATCH] vgaarb: mark vga_tryget static
On Sat, Aug 01, 2020 at 08:17:13AM +0200, Christoph Hellwig wrote:
> This symbols isn't used anywhere outside of vgaarb.c.
>
> Signed-off-by: Christoph Hellwig
Nice catch, patch queued up for 5.9.
Thanks, Daniel
> ---
> drivers/gpu/vga/vgaarb.c | 3 +--
> include/linux/vgaarb.h | 6 --
> 2 files changed, 1 insertion(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
> index f2f3ef8af2710f..5180c5687ee530 100644
> --- a/drivers/gpu/vga/vgaarb.c
> +++ b/drivers/gpu/vga/vgaarb.c
> @@ -529,7 +529,7 @@ EXPORT_SYMBOL(vga_get);
> *
> * 0 on success, negative error code on failure.
> */
> -int vga_tryget(struct pci_dev *pdev, unsigned int rsrc)
> +static int vga_tryget(struct pci_dev *pdev, unsigned int rsrc)
> {
> struct vga_device *vgadev;
> unsigned long flags;
> @@ -554,7 +554,6 @@ int vga_tryget(struct pci_dev *pdev, unsigned int rsrc)
> spin_unlock_irqrestore(&vga_lock, flags);
> return rc;
> }
> -EXPORT_SYMBOL(vga_tryget);
>
> /**
> * vga_put - release lock on legacy VGA resources
> diff --git a/include/linux/vgaarb.h b/include/linux/vgaarb.h
> index 553b34c8b5f700..977caf96c8d2a3 100644
> --- a/include/linux/vgaarb.h
> +++ b/include/linux/vgaarb.h
> @@ -109,12 +109,6 @@ static inline int vga_get_uninterruptible(struct pci_dev
> *pdev,
> return vga_get(pdev, rsrc, 0);
> }
>
> -#if defined(CONFIG_VGA_ARB)
> -extern int vga_tryget(struct pci_dev *pdev, unsigned int rsrc);
> -#else
> -static inline int vga_tryget(struct pci_dev *pdev, unsigned int rsrc) {
> return 0; }
> -#endif
> -
> #if defined(CONFIG_VGA_ARB)
> extern void vga_put(struct pci_dev *pdev, unsigned int rsrc);
> #else
> --
> 2.27.0
>
--
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/syncobj: Tune down unordered timeline DRM_ERROR
On Sat, Aug 01, 2020 at 05:39:50PM +0300, Lionel Landwerlin wrote:
> On 01/08/2020 12:26, Daniel Vetter wrote:
> > Userspace can provoke this, we generally don't allow userspace to spam
> > dmesg. Tune it down to debug. Unfortunately we don't have easy access
> > to the drm_device here (not at all without changing a few things), so
> > leave it as old style dmesg output for now.
> >
> > References: https://patchwork.freedesktop.org/series/80146/
> > Signed-off-by: Daniel Vetter
> > Cc: Chris Wilson
> > Cc: Lionel Landwerlin
> > Cc: "Christian König"
> > ---
> > drivers/gpu/drm/drm_syncobj.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
> > index 3bf73971daf3..6e74e6745eca 100644
> > --- a/drivers/gpu/drm/drm_syncobj.c
> > +++ b/drivers/gpu/drm/drm_syncobj.c
> > @@ -297,7 +297,7 @@ void drm_syncobj_add_point(struct drm_syncobj *syncobj,
> > prev = drm_syncobj_fence_get(syncobj);
> > /* You are adding an unorder point to timeline, which could cause
> > payload returned from query_ioctl is 0! */
> > if (prev && prev->seqno >= point)
> > - DRM_ERROR("You are adding an unorder point to timeline!\n");
> > + DRM_DEBUG("You are adding an unorder point to timeline!\n");
> > dma_fence_chain_init(chain, prev, fence, point);
> > rcu_assign_pointer(syncobj->fence, &chain->base);
>
> Thanks,
>
> Acked-by: Lionel Landwerlin
Thanks for taking a look, applied it now.
-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 v2] fbmem: pull fbcon_update_vcs() out of fb_set_var()
On Thu, Jul 30, 2020 at 07:47:14PM +0900, Tetsuo Handa wrote:
> syzbot is reporting OOB read bug in vc_do_resize() [1] caused by memcpy()
> based on outdated old_{rows,row_size} values, for resize_screen() can
> recurse into vc_do_resize() which changes vc->vc_{cols,rows} that outdates
> old_{rows,row_size} values which were saved before calling resize_screen().
>
> Daniel Vetter explained that resize_screen() should not recurse into
> fbcon_update_vcs() path due to FBINFO_MISC_USEREVENT being still set
> when calling resize_screen().
>
> Instead of masking FBINFO_MISC_USEREVENT before calling fbcon_update_vcs(),
> we can remove FBINFO_MISC_USEREVENT by calling fbcon_update_vcs() only if
> fb_set_var() returned 0. This change assumes that it is harmless to call
> fbcon_update_vcs() when fb_set_var() returned 0 without reaching
> fb_notifier_call_chain().
>
> [1]
> https://syzkaller.appspot.com/bug?id=c70c88cfd16dcf6e1d3c7f0ab8648b3144b5b25e
>
> Reported-and-tested-by: syzbot
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Tetsuo Handa
> Reported-by: kernel test robot for missing #include
Thanks a lot for your patch, queued up to hopefully still make it for
5.9-rc1.
Cheers, Daniel
> ---
> drivers/video/fbdev/core/fbmem.c | 8 ++--
> drivers/video/fbdev/core/fbsysfs.c | 4 ++--
> drivers/video/fbdev/ps3fb.c| 5 +++--
> include/linux/fb.h | 2 --
> 4 files changed, 7 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbmem.c
> b/drivers/video/fbdev/core/fbmem.c
> index 30e73ec..da7c88f 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -957,7 +957,6 @@ static int fb_check_caps(struct fb_info *info, struct
> fb_var_screeninfo *var,
> int
> fb_set_var(struct fb_info *info, struct fb_var_screeninfo *var)
> {
> - int flags = info->flags;
> int ret = 0;
> u32 activate;
> struct fb_var_screeninfo old_var;
> @@ -1052,9 +1051,6 @@ static int fb_check_caps(struct fb_info *info, struct
> fb_var_screeninfo *var,
> event.data = &mode;
> fb_notifier_call_chain(FB_EVENT_MODE_CHANGE, &event);
>
> - if (flags & FBINFO_MISC_USEREVENT)
> - fbcon_update_vcs(info, activate & FB_ACTIVATE_ALL);
> -
> return 0;
> }
> EXPORT_SYMBOL(fb_set_var);
> @@ -1105,9 +1101,9 @@ static long do_fb_ioctl(struct fb_info *info, unsigned
> int cmd,
> return -EFAULT;
> console_lock();
> lock_fb_info(info);
> - info->flags |= FBINFO_MISC_USEREVENT;
> ret = fb_set_var(info, &var);
> - info->flags &= ~FBINFO_MISC_USEREVENT;
> + if (!ret)
> + fbcon_update_vcs(info, var.activate & FB_ACTIVATE_ALL);
> unlock_fb_info(info);
> console_unlock();
> if (!ret && copy_to_user(argp, &var, sizeof(var)))
> diff --git a/drivers/video/fbdev/core/fbsysfs.c
> b/drivers/video/fbdev/core/fbsysfs.c
> index d54c88f..65dae05 100644
> --- a/drivers/video/fbdev/core/fbsysfs.c
> +++ b/drivers/video/fbdev/core/fbsysfs.c
> @@ -91,9 +91,9 @@ static int activate(struct fb_info *fb_info, struct
> fb_var_screeninfo *var)
>
> var->activate |= FB_ACTIVATE_FORCE;
> console_lock();
> - fb_info->flags |= FBINFO_MISC_USEREVENT;
> err = fb_set_var(fb_info, var);
> - fb_info->flags &= ~FBINFO_MISC_USEREVENT;
> + if (!err)
> + fbcon_update_vcs(fb_info, var->activate & FB_ACTIVATE_ALL);
> console_unlock();
> if (err)
> return err;
> diff --git a/drivers/video/fbdev/ps3fb.c b/drivers/video/fbdev/ps3fb.c
> index 9df78fb..203c254 100644
> --- a/drivers/video/fbdev/ps3fb.c
> +++ b/drivers/video/fbdev/ps3fb.c
> @@ -29,6 +29,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include
> @@ -824,12 +825,12 @@ static int ps3fb_ioctl(struct fb_info *info, unsigned
> int cmd,
> var = info->var;
> fb_videomode_to_var(&var, vmode);
> console_lock();
> - info->flags |= FBINFO_MISC_USEREVENT;
> /* Force, in case only special bits changed */
> var.activate |= FB_ACTIVATE_FORCE;
> par->new_mode_id = val;
> retval = fb_set_var(info, &var);
> - info->flags &= ~FBINFO_MISC_USEREVENT;
> +
Re: [PATCH 2/5] fbdev/core: Export framebuffer read and write code as cfb_ function
On Mon, Aug 03, 2020 at 08:46:34AM +0200, Thomas Zimmermann wrote: > Hi > > Am 02.08.20 um 22:01 schrieb Sam Ravnborg: > > On Fri, Jul 31, 2020 at 11:20:33AM +0200, dan...@ffwll.ch wrote: > >> On Wed, Jul 29, 2020 at 06:36:03PM +0200, Sam Ravnborg wrote: > >>> Hi Daniel. > >>> > >>> On Wed, Jul 29, 2020 at 03:53:28PM +0200, dan...@ffwll.ch wrote: > >>>> On Wed, Jul 29, 2020 at 03:41:45PM +0200, Thomas Zimmermann wrote: > >>>>> DRM fb helpers require read and write functions for framebuffer > >>>>> memory. Export the existing code from fbdev. > >>>>> > >>>>> Signed-off-by: Thomas Zimmermann > >>>> > >>>> Hm I'm not super sure whether we want to actually reuse this stuff ... We > >>>> kinda don't care about the sparc special case, and just having an fbdev > >>>> implementation witch has the switch between memcpy and memcpy_to/from_io > >>>> in one single place sounds a lot simpler ... > >>>> > >>>> This way we can have a clean split between the old horrors of real fbdev > >>>> drivers, and a much cleaner world in drm. It would mean a bit of > >>>> copypasting, but I think that's actually a good thing. > >>>> > >>>> In general my idea for drm fbdev emulation is that for any area we have a > >>>> problem we just ignore the entire fbmem.c code and write our own: mmap, > >>>> backlight handling (still unsolved, and horrible), cfb vs sys here. This > >>>> entire fbmem.c stuff is pretty bad midlayer, trying to avoid code > >>>> duplication here doesn't seem worth it imo. > >>>> > >>>> Thoughts? > >>> > >>> > >>> I can see that fbmem is a mix of ioctl support and other stuff. > >>> We could factor out all the ioctl parts of fbmem.c to a new file > >>> named fbioctl.c. > >>> > >>> And then let the ioctl parts call down into drm stuff and avoid reusing > >>> the fbdev code when we first reach drm code. > >>> This would require local copies of: > >>> sys_read, sys_write, sys_fillrect, sys_copyarea, sys_imageblit > >>> and more I think which I missed. > >>> > >>> With local copies we could avoid some of the special cases and trim the > >>> unctions to what is required by drm only. > >>> And then no more fbmem dependencies and no dependencies to several of > >>> the small helper functions. So less entanglement with fbdev core. > >>> > >>> This all sounds simple so I am surely missing a lot a ugly details here. > >>> > >>> And should we touch this anyway we need a test suite to verify not too > >>> much breaks. To the best of my knowledge there is not yet such a test > >>> suite :-( Maybe because people caring about fbdev are limited. > >> > >> Well my idea was to not refactor anything, but just have drm copies of the > >> various fb_ops callbacks. Definitely not even more refactoring :-) > > Thanks for making a prototype, Sam. > > But do we really want to duplicate alls this code from fbdev? It's not > actually pretty and there's little value in rewritting it. If anything, > I can see us extending drm_format_helpers.c and building upon this. Hm yeah this is a lot more horrible than I thought, I was kinda just looking at read/write functions, maybe also mmap, and figured we could simplify this a lot if we just inline and done. But all these image/fill/copy functions are pretty bad, and they seem to care about a lot of corner cases that just don't matter anymore on modern hw. Also agreeing with Tomas that if we do copy this, then building on top of format helpers would make more sense. At that point we probably need a test suite for fbdev, and this entire endeavour becomes rather silly. So maybe compromise approach? E.g. we reuse fbdev helpers with a switch between sys and cfb if it would drag in a huge pile of code for format handling sillynesss. But when all it would drag in is a memcpy_to/fromio or similar, we inline to reduce a bit the midlayer and make it clearer what's going on. Strictly speaking would probably still need a test suite, but I guess we can delay that until the first bug report or so :-) Cheers, Daniel > > Best regards > Thomas > > > > > $ wc -l drivers/gpu/drm/drm_fb_fbdev_helper.c > > 1212 drivers/gpu/drm/drm_fb_fbdev_helper.c > > > > This is a straight copy of: > > $ grep EXPORT drivers/gpu/drm/drm
Re: [PATCH] drm/vkms: modify sequence disable/plane/enable in commit_tail
On Sat, Aug 01, 2020 at 04:30:23PM -0300, Melissa Wen wrote:
> On Wed, Jul 29, 2020 at 12:22 PM Sidong Yang wrote:
> >
> > This patch modifies function call sequence in commit tail. This is for
> > the problem that raised when kms_cursor_crc test is tested repeatedly.
> > In second test, there is an bug that crtc commit doesn't start vblank
> > events.
> > Because there is some error about vblank's refcount. in commit_flush() that
> > called from commit_plane, drm_vblank_get() is called and vblank is enabled
> > in normal case. But in second test, vblank isn't enable for vblank->refcount
> > is already increased in previous test. Increased refcount will be decreased
> > in drm_atomic_helper_commit_modeset_enables() after commit_plane.
> > Therefore, commit_plane should be called after commit_modeset_enable.
> >
> > In this situation, there is a warning raised in get_vblank_timestamp().
> > hrtimer.node.expires and vblank->time are zero for no vblank events before.
> > This patch returns current time when vblank is not enabled.
> >
> Hi Sidong,
>
> I think this patch tries to solve two different issues.
>
> I am not a maintainer, but I believe you can split it.
>
> Everything indicates that changing the commit tail sequence does not
> ideally solve the problem of subtests getting stuck (as we have dicussed);
> however, for me, the treatment of the warning is valid and it is also related
> to other IGT tests using VKMS.
Yeah I think (but haven't tested, definitely need to confirm that) that
the vblank get/put fix from Melissa is the correct fix for all these
issues.
> One option is to send a patch that only treats the warning. I believe that
> in the body of the commit message, it would be nice to have the warning
> that this patch addresses, and when it appears by running an IGT test.
> Also, say why it should be done this way in vkms.
> This info could help future debugging.
Yeah I think splitting out the warning fix is the right thing to do here.
-Daniel
>
> Off-topic: I removed the group's mailing list of the University of São
> Paulo (kernel-usp) from the cc, since I believe you had no intention of
> sending the patch to them.
>
> Best regards,
>
> Melissa
>
> > Cc: Daniel Vetter
> > Cc: Rodrigo Siqueira
> > Cc: Haneen Mohammed
> >
> > Signed-off-by: Sidong Yang
> > ---
> > drivers/gpu/drm/vkms/vkms_crtc.c | 5 +
> > drivers/gpu/drm/vkms/vkms_drv.c | 4 ++--
> > 2 files changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c
> > b/drivers/gpu/drm/vkms/vkms_crtc.c
> > index ac85e17428f8..09c012d54d58 100644
> > --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> > +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> > @@ -86,6 +86,11 @@ static bool vkms_get_vblank_timestamp(struct drm_crtc
> > *crtc,
> > struct vkms_output *output = &vkmsdev->output;
> > struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
> >
> > + if (!READ_ONCE(vblank->enabled)) {
> > + *vblank_time = ktime_get();
> > + return true;
> > + }
> > +
> > *vblank_time = READ_ONCE(output->vblank_hrtimer.node.expires);
> >
> > if (WARN_ON(*vblank_time == vblank->time))
> > diff --git a/drivers/gpu/drm/vkms/vkms_drv.c
> > b/drivers/gpu/drm/vkms/vkms_drv.c
> > index 1e8b2169d834..c2c83a01d4a7 100644
> > --- a/drivers/gpu/drm/vkms/vkms_drv.c
> > +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> > @@ -76,10 +76,10 @@ static void vkms_atomic_commit_tail(struct
> > drm_atomic_state *old_state)
> >
> > drm_atomic_helper_commit_modeset_disables(dev, old_state);
> >
> > - drm_atomic_helper_commit_planes(dev, old_state, 0);
> > -
> > drm_atomic_helper_commit_modeset_enables(dev, old_state);
> >
> > + drm_atomic_helper_commit_planes(dev, old_state, 0);
> > +
> > drm_atomic_helper_fake_vblank(old_state);
> >
> > drm_atomic_helper_commit_hw_done(old_state);
> > --
> > 2.17.1
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Kernel USP" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to kernel-usp+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> > https://groups.google.com/d/msgid/kernel-usp/20200729152231.13249-1-realwakka%40gmail.com.
--
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: Added orientation quirk for ASUS tablet model T103HAF
On Sat, Aug 01, 2020 at 03:34:46PM +0300, Marius Iacob wrote:
> Signed-off-by: Marius Iacob
Queued up for the 5.9 merge window. I also added cc: stable.
-Daniel
> ---
> drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
> b/drivers/gpu/drm/drm_panel_orientation_quirks.c
> index d00ea384dcbf..58f5dc2f6dd5 100644
> --- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
> +++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
> @@ -121,6 +121,12 @@ static const struct dmi_system_id orientation_data[] = {
> DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "T101HA"),
> },
> .driver_data = (void *)&lcd800x1280_rightside_up,
> + }, {/* Asus T103HAF */
> + .matches = {
> + DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
> + DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "T103HAF"),
> + },
> + .driver_data = (void *)&lcd800x1280_rightside_up,
> }, {/* GPD MicroPC (generic strings, also match on bios date) */
> .matches = {
> DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Default string"),
> --
> 2.28.0
>
--
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/vkms: guarantee vblank when capturing crc
On Sat, Aug 01, 2020 at 03:49:29PM -0300, Melissa Wen wrote:
> VKMS needs vblank interrupts enabled to capture CRC. When vblank is
> disabled, tests like kms_cursor_crc and kms_pipe_crc_basic getting stuck
> waiting for a capture that will not occur until vkms wakes up. This
> patch ensures that vblank remains enabled as long as the CRC capture is
> needed.
>
> It clears the execution of the following kms_cursor_crc subtests:
> 1. pipe-A-cursor-[size,alpha-opaque, NxN-(on-screen, off-screen, sliding,
> random, fast-moving])] - successful when running individually.
> 2. pipe-A-cursor-dpms passes again
> 3. pipe-A-cursor-suspend also passes
>
> The issue was initially tracked in the sequential execution of IGT
> kms_cursor_crc subtest: when running the test sequence or one of its
> subtests twice, the odd execs complete and the pairs get stuck in an
> endless wait. In the IGT code, calling a wait_for_vblank on preparing
> for CRC capture prevented the busy-wait. But the problem persisted in
> the pipe-A-cursor-dpms and -suspend subtests.
>
> Checking the history, the pipe-A-cursor-dpms subtest was successful
> when, in vkms_atomic_commit_tail, instead of using the flip_done op, it
> used wait_for_vblanks. Another way to prevent blocking was
> wait_one_vblank when enabling crtc. However, in both cases,
> pipe-A-cursor-suspend persisted blocking in the 2nd start of CRC
> capture, which may indicate that something got stuck in the step of CRC
> setup. Indeed, wait_one_vblank in the crc setup was able to sync things
> and free all kms_cursor_crc subtests.
>
> Besides, other alternatives to force enabling vblanks or prevent
> disabling them such as calling drm_crtc_put_vblank or modeset_enables
> before commit_planes + offdelay = 0, also unlock all subtests
> executions. These facts together converge on the lack of vblank to
> unblock the crc capture.
>
> Finally, considering the vkms's dependence on vblank interruptions to
> perform tasks, this patch acquires a vblank ref when setup CRC source
> and releases ref when disabling crc capture, ensuring vblanks happen to
> compute CRC.
>
> Cc: Rodrigo Siqueira
> Cc: Haneen Mohammed
> Co-developed-by: Sidong Yang
> Signed-off-by: Sidong Yang
> Co-developed-by: Daniel Vetter
> Signed-off-by: Daniel Vetter
> Signed-off-by: Melissa Wen
Excellent summary of the debug story.
> ---
> drivers/gpu/drm/vkms/vkms_composer.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
> b/drivers/gpu/drm/vkms/vkms_composer.c
> index 4af2f19480f4..1161eaa383f1 100644
> --- a/drivers/gpu/drm/vkms/vkms_composer.c
> +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> @@ -241,6 +241,14 @@ int vkms_set_crc_source(struct drm_crtc *crtc, const
> char *src_name)
>
> ret = vkms_crc_parse_source(src_name, &enabled);
>
> + /* Ensure that vblank interruptions are enabled for crc capture */
> + /* Enabling CRC: acquire vblank ref */
This comment just explains what the code does, that's not needed. The
first comment I think can be replaced if we create a little helper
function like
void vkms_set_composer(struct vkms_output, bool enable) {
bool old_state;
if (enabled)
drm_crtc_vblank_get(crtc);
spin_lock_irq(&out->lock);
old_enable = out->composer_enabled;
out->composer_enabled = enabled;
spin_unlock_irq(&out->lock);
if (old_enabled)
drm_crtc_vblank_put(crtc);
}
This should also help as prep for the writeback work, where we have a 2nd
user that might need to enable the composer (maybe even need to switch to
refcounting the composer state then).
> + if (enabled)
> + drm_crtc_vblank_get(crtc);
> + /* Disabling CRC: release vblank ref */
> + if (!src_name)
> + drm_crtc_vblank_put(crtc);
I'm not sure this correctly releases the vblank reference in all cases, I
think the suggestion in the helper function pseudo code should work
better. It does mean we temporarily elevate the vblank refcount if we go
enabled -> enabled, but that's not a problem since it's refcounted.
Cheers, Daniel
> +
> spin_lock_irq(&out->lock);
> out->composer_enabled = enabled;
> spin_unlock_irq(&out->lock);
> --
> 2.27.0
>
--
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 v1 03/22] backlight: Add get/set operations for brightness/power properties
On Sun, Aug 02, 2020 at 01:06:17PM +0200, Sam Ravnborg wrote:
> Add get and set operations to incapsualte access to backlight properties.
>
> One easy win is that the get/set operatiosn can be used when backlight
> is not included in the configuration, resulting in simpler code with
> less ifdef's and thus more readable code.
>
> The set/get methods hides some of the confusing power states, limiting
> the power state to either ON or OFF for the drivers.
>
> Signed-off-by: Sam Ravnborg
> Cc: Lee Jones
> Cc: Daniel Thompson
> Cc: Jingoo Han
> ---
> include/linux/backlight.h | 72 +++
> 1 file changed, 72 insertions(+)
>
> diff --git a/include/linux/backlight.h b/include/linux/backlight.h
> index d683c053ec09..882ceea45ace 100644
> --- a/include/linux/backlight.h
> +++ b/include/linux/backlight.h
> @@ -474,6 +474,78 @@ static inline int backlight_get_brightness(const struct
> backlight_device *bd)
> return bd->props.brightness;
> }
>
> +/**
> + * backlight_get_actual_brightness - Returns the actual brightness
> + *
> + * On failure a negative error code is returned.
> + */
> +static inline int backlight_get_actual_brightness(struct backlight_device
> *bd)
> +{
> + if (bd && bd->ops && bd->ops->get_brightness)
> + return bd->ops->get_brightness(bd);
> + else
> + return -EINVAL;
> +}
> +
> +/**
> + * backlight_get_max_brightness - Returns maximum brightness
> + *
> + * This helper operation is preferred over direct access to
> + * &backlight_properties.max_brightness
> + *
> + * Returns 0 if backlight_device is NULL
> + */
> +
> +static inline int backlight_get_max_brightness(const struct backlight_device
> *bd)
> +{
> + if (bd)
> + return bd->props.max_brightness;
> + else
> + return 0;
> +}
> +
> +/**
> + * backlight_set_brightness - Set the brightness to the specified value
> + *
> + * This helper operation is preferred over direct assignment to
> + * &backlight_properties.brightness.
> + *
> + * If backlight_device is NULL then silently exit.
> + */
> +static inline void backlight_set_brightness(struct backlight_device *bd, int
> brightness)
> +{
> + if (bd)
> + bd->props.brightness = brightness;
Looking at the drivers I think including a call to backlight_update_status
would simplify a lot of code.
> +}
> +
> +/**
> + * backlight_set_power_on - Set power state to ON.
> + *
> + * This helper operation is preferred over direct assignment to
> + * backlight_properties.power.
> + *
> + * If backlight_device is NULL then silently exit.
> + */
> +static inline void backlight_set_power_on(struct backlight_device *bd)
> +{
> + if (bd)
> + bd->props.power = FB_BLANK_UNBLANK;
> +}
> +
> +/**
> + * backlight_set_power_off - Set power state to OFF.
> + *
> + * This helper operation is preferred over direct assignment to
> + * backlight_properties.power.
> + *
> + * If backlight_device is NULL then silently exit.
> + */
> +static inline void backlight_set_power_off(struct backlight_device *bd)
I'm not clear why we need these two above? I thought the long-term plan is
only use backlight_enable/disable and then remove the tri-state power
handling once everyone is converted over?
Or maybe I'm just confused about the goal here ...
-Daniel
> +{
> + if (bd)
> + bd->props.power = FB_BLANK_POWERDOWN;
> +}
> +
> struct backlight_device *
> backlight_device_register(const char *name, struct device *dev, void
> *devdata,
> const struct backlight_ops *ops,
> --
> 2.25.1
>
--
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: [RFC PATCH v1 0/22] backlight: add init macros and accessors
On Sun, Aug 02, 2020 at 01:06:14PM +0200, Sam Ravnborg wrote: > The backlight drivers uses several different patterns when registering > a backlight: > > - Register backlight and assign properties later > - Define a local backlight_properties variable and use memset > - Define a const backlight_properties and assign relevant properties > > On top of this there was differences in what members was assigned in > backlight_properties. > > To align how backlight drivers are initialized introduce following helper > macros: > - DECLARE_BACKLIGHT_INIT_FIRMWARE() > - DECLARE_BACKLIGHT_INIT_PLATFORM() > - DECLARE_BACKLIGHT_INIT_RAW() > > The macros are introduced in patch 2. > > The backlight drivers used direct access to backlight_properties. > Encapsulate these in get/set access operations resulting in following > benefits: > - The drivers no longer need to be concerned about the confusing power states, > as there is now only a set_power_on() and set_power_off() operation. > - The access methods can be called with a NULL pointer so logic around the > access can be made simpler. > - The code is in most cases more readable with the access operations. > - When everyone uses the access methods refactroring in the backlight core is > simpler. > > The get/set operations are introduced in patch 3. > > The first patch trims backlight_update_status() so it can be called with a > NULL > backlight_device. Then the called do not need to add this check just to avoid > a NULL reference. > > The fourth patch introduce the new macros and get/set operations for the > gpio backlight driver, as an example. > > The remaining patches updates most backlight users in drivers/gpu/drm/* > With this patch set applied then: > - Almost all references to FB_BLANK* are gone from drm/* > - All panel drivers uses devm_ variant for registering backlight > - Almost all direct references to backlight properties are gone > > The drm/* patches are used as examples how drivers can benefit from the > new macros and get/set operations. > > Individual patches are only sent to the people listed in the patch + a few > more. > Please check https://lore.kernel.org/dri-devel/ for the full series. > > Feedback welcome! Since this needs backlight patches queued up outside of drm there's two options: - merge the backlight stuff through drm-misc (imo simplest, we have all the fbdev stuff in there too by now) - shared topic branch merged in drm-misc and optionally backlight tree Otherwise this is going to be a pain to merge. -Daniel > > Sam > > Cc: Alex Deucher > Cc: amd-...@lists.freedesktop.org > Cc: Andrzej Hajda > Cc: Christian König > Cc: Chris Wilson > Cc: Daniel Thompson > Cc: Ezequiel Garcia > Cc: Hans de Goede > Cc: Hoegeun Kwon > Cc: Inki Dae > Cc: Jani Nikula > Cc: Jernej Skrabec > Cc: Jingoo Han > Cc: Jonas Karlman > Cc: Joonas Lahtinen > Cc: Jyri Sarha > Cc: Kieran Bingham > Cc: Konrad Dybcio > Cc: Laurent Pinchart > Cc: Lee Jones > Cc: Linus Walleij > Cc: linux-renesas-...@vger.kernel.org > Cc: Maarten Lankhorst > Cc: Manasi Navare > Cc: Neil Armstrong > Cc: Patrik Jakobsson > Cc: Paweł Chmiel > Cc: Philippe CORNU > Cc: Rob Clark > Cc: Robert Chiras > Cc: Rodrigo Vivi > Cc: Sam Ravnborg > Cc: Sebastian Reichel > Cc: Thierry Reding > Cc: Tomi Valkeinen > Cc: "Ville Syrjälä" > Cc: Vinay Simha BN > Cc: Wambui Karuga > Cc: Zheng Bin > > Sam Ravnborg (22): > backlight: Silently fail backlight_update_status() if no device > backlight: Add DECLARE_* macro for device registration > backlight: Add get/set operations for brightness/power properties > backlight: gpio: Use DECLARE_BACKLIGHT_INIT_RAW and get/setters > drm/gma500: Backlight support > drm/panel: asus-z00t-tm5p5-n35596: Backlight update > drm/panel: jdi-lt070me05000: Backlight update > drm/panel: novatek-nt35510: Backlight update > drm/panel: orisetech-otm8009a: Backlight update > drm/panel: raydium-rm67191: Backlight update > drm/panel: samsung-s6e63m0: Backlight update > drm/panel: samsung-s6e63j0x03: Backlight update > drm/panel: samsung-s6e3ha2: Backlight update > drm/panel: sony-acx424akp: Backlight update > drm/panel: sony-acx565akm: Backlight update > drm/bridge: parade-ps8622: Backlight update > drm/tilcdc: Backlight update > drm/radeon: Backlight update > drm/amdgpu/atom: Backlight update > drm/i915: Backlight update > drm/omap: display: Backlight update > drm/shmobile: Backlight update > > drivers/gpu/drm/amd/a
Re: [PATCH v1 06/22] drm/panel: asus-z00t-tm5p5-n35596: Backlight update
On Sun, Aug 02, 2020 at 01:06:20PM +0200, Sam Ravnborg wrote:
> Update backlight to use macro for initialization and the
> backlight_get_brightness() operation to simply the update operation.
>
> Signed-off-by: Sam Ravnborg
> Cc: Konrad Dybcio
> Cc: Thierry Reding
> Cc: Sam Ravnborg
> ---
> .../gpu/drm/panel/panel-asus-z00t-tm5p5-n35596.c | 15 +++
> 1 file changed, 3 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-asus-z00t-tm5p5-n35596.c
> b/drivers/gpu/drm/panel/panel-asus-z00t-tm5p5-n35596.c
> index 39e0f0373f3c..c090fc6f1ed5 100644
> --- a/drivers/gpu/drm/panel/panel-asus-z00t-tm5p5-n35596.c
> +++ b/drivers/gpu/drm/panel/panel-asus-z00t-tm5p5-n35596.c
> @@ -216,14 +216,9 @@ static const struct drm_panel_funcs
> tm5p5_nt35596_panel_funcs = {
> static int tm5p5_nt35596_bl_update_status(struct backlight_device *bl)
> {
> struct mipi_dsi_device *dsi = bl_get_data(bl);
> - u16 brightness = bl->props.brightness;
> + int brightness = backlight_get_brightness(bl);
> int ret;
>
> - if (bl->props.power != FB_BLANK_UNBLANK ||
> - bl->props.fb_blank != FB_BLANK_UNBLANK ||
> - bl->props.state & (BL_CORE_SUSPENDED | BL_CORE_FBBLANK))
> - brightness = 0;
> -
> dsi->mode_flags &= ~MIPI_DSI_MODE_LPM;
>
> ret = mipi_dsi_dcs_set_display_brightness(dsi, brightness);
> @@ -238,7 +233,7 @@ static int tm5p5_nt35596_bl_update_status(struct
> backlight_device *bl)
> static int tm5p5_nt35596_bl_get_brightness(struct backlight_device *bl)
> {
> struct mipi_dsi_device *dsi = bl_get_data(bl);
> - u16 brightness = bl->props.brightness;
> + u16 brightness = backlight_get_brightness(bl);
I'm not sure why we do this, but your patch here changes behaviour in a
way that has bitten us in the past: This now reports a brightness of 0
when the backlight is off. On some backlights (especially firmware ones) 0
means "lowest value", not actually off, so that's one confusion. The other
problem is then that userspace tends to use this as the backlight value to
restore on next boot (or after resume, or after vt switch, resulting in a
very dark or black screen).
Therefore I think in these cases we actually need the direct
bl->props.brightness value.
I think an even cleaner way to solve this would be to change the
get_brightness code in actual_brightness_show to handle negative error
codes from ->get_brightness and use that to fall back to
bd->props.brightness, then we could remove this code here.
That reminds me, probably not a good idea to store a negative value in
backlight_force_update() if this goes wrong into bl->props.brightness.
-Daniel
> int ret;
>
> dsi->mode_flags &= ~MIPI_DSI_MODE_LPM;
> @@ -261,11 +256,7 @@ static struct backlight_device *
> tm5p5_nt35596_create_backlight(struct mipi_dsi_device *dsi)
> {
> struct device *dev = &dsi->dev;
> - const struct backlight_properties props = {
> - .type = BACKLIGHT_RAW,
> - .brightness = 255,
> - .max_brightness = 255,
> - };
> + DECLARE_BACKLIGHT_INIT_RAW(props, 255, 255);
>
> return devm_backlight_device_register(dev, dev_name(dev), dev, dsi,
> &tm5p5_nt35596_bl_ops, &props);
> --
> 2.25.1
>
--
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 v1 10/22] drm/panel: raydium-rm67191: Backlight update
On Sun, Aug 02, 2020 at 01:06:24PM +0200, Sam Ravnborg wrote:
> - Replace direct access to backlight_properties with
> backlight_get_brightness().
> - Use macro for initialization
>
> Signed-off-by: Sam Ravnborg
> Cc: Robert Chiras
> Cc: Thierry Reding
> Cc: Sam Ravnborg
> ---
> drivers/gpu/drm/panel/panel-raydium-rm67191.c | 11 +++
> 1 file changed, 3 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-raydium-rm67191.c
> b/drivers/gpu/drm/panel/panel-raydium-rm67191.c
> index 313637d53d28..5553db385dd5 100644
> --- a/drivers/gpu/drm/panel/panel-raydium-rm67191.c
> +++ b/drivers/gpu/drm/panel/panel-raydium-rm67191.c
> @@ -479,7 +479,7 @@ static int rad_bl_get_brightness(struct backlight_device
> *bl)
> if (ret < 0)
> return ret;
>
> - bl->props.brightness = brightness;
> + backlight_set_brightness(bl, brightness);
This sounds like a bad idea, again because this overrides the software
brightness value potentially when the backlight is off. Althought that's
checked a bit higher up, so not too terrible.
I'm also feeling like a helper for standard mipi dsi panel backlight would
be great, it's pretty much all the same code.
-Daniel
>
> return brightness & 0xff;
> }
> @@ -495,7 +495,7 @@ static int rad_bl_update_status(struct backlight_device
> *bl)
>
> dsi->mode_flags &= ~MIPI_DSI_MODE_LPM;
>
> - ret = mipi_dsi_dcs_set_display_brightness(dsi, bl->props.brightness);
> + ret = mipi_dsi_dcs_set_display_brightness(dsi,
> backlight_get_brightness(bl));
> if (ret < 0)
> return ret;
>
> @@ -539,10 +539,10 @@ static int rad_init_regulators(struct rad_panel *rad)
>
> static int rad_panel_probe(struct mipi_dsi_device *dsi)
> {
> + DECLARE_BACKLIGHT_INIT_RAW(bl_props, 255, 255);
> struct device *dev = &dsi->dev;
> struct device_node *np = dev->of_node;
> struct rad_panel *panel;
> - struct backlight_properties bl_props;
> int ret;
> u32 video_mode;
>
> @@ -588,11 +588,6 @@ static int rad_panel_probe(struct mipi_dsi_device *dsi)
> if (IS_ERR(panel->reset))
> return PTR_ERR(panel->reset);
>
> - memset(&bl_props, 0, sizeof(bl_props));
> - bl_props.type = BACKLIGHT_RAW;
> - bl_props.brightness = 255;
> - bl_props.max_brightness = 255;
> -
> panel->backlight = devm_backlight_device_register(dev, dev_name(dev),
> dev, dsi, &rad_bl_ops,
> &bl_props);
> --
> 2.25.1
>
--
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 v1 15/22] drm/panel: sony-acx565akm: Backlight update
On Sun, Aug 02, 2020 at 01:06:29PM +0200, Sam Ravnborg wrote:
> - Use backlight_get_brightness() helper
> - Use backlight_is_blank() helper
> - Use macro for initialization
> - Drop direct access to backlight properties
> - Use the devm_ variant for registering backlight device, and drop
> all explicit unregistering of the backlight device.
>
> Signed-off-by: Sam Ravnborg
> Cc: Laurent Pinchart
> Cc: Thierry Reding
> Cc: Sam Ravnborg
> ---
> drivers/gpu/drm/panel/panel-sony-acx565akm.c | 44 +++-
> 1 file changed, 15 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-sony-acx565akm.c
> b/drivers/gpu/drm/panel/panel-sony-acx565akm.c
> index 5c4b6f6e5c2d..3fc572d1de13 100644
> --- a/drivers/gpu/drm/panel/panel-sony-acx565akm.c
> +++ b/drivers/gpu/drm/panel/panel-sony-acx565akm.c
> @@ -298,13 +298,7 @@ static void acx565akm_set_brightness(struct
> acx565akm_panel *lcd, int level)
> static int acx565akm_bl_update_status_locked(struct backlight_device *dev)
> {
> struct acx565akm_panel *lcd = dev_get_drvdata(&dev->dev);
> - int level;
> -
> - if (dev->props.fb_blank == FB_BLANK_UNBLANK &&
> - dev->props.power == FB_BLANK_UNBLANK)
> - level = dev->props.brightness;
> - else
> - level = 0;
> + int level = backlight_get_brightness(dev);
>
> acx565akm_set_brightness(lcd, level);
>
> @@ -330,8 +324,7 @@ static int acx565akm_bl_get_intensity(struct
> backlight_device *dev)
>
> mutex_lock(&lcd->mutex);
>
> - if (dev->props.fb_blank == FB_BLANK_UNBLANK &&
> - dev->props.power == FB_BLANK_UNBLANK)
> + if (backlight_is_blank(dev))
> intensity = acx565akm_get_actual_brightness(lcd);
> else
> intensity = 0;
> @@ -348,39 +341,34 @@ static const struct backlight_ops acx565akm_bl_ops = {
>
> static int acx565akm_backlight_init(struct acx565akm_panel *lcd)
> {
> - struct backlight_properties props = {
> - .fb_blank = FB_BLANK_UNBLANK,
> - .power = FB_BLANK_UNBLANK,
> - .type = BACKLIGHT_RAW,
> - };
> int ret;
> -
> - lcd->backlight = backlight_device_register(lcd->name, &lcd->spi->dev,
> -lcd, &acx565akm_bl_ops,
> -&props);
> - if (IS_ERR(lcd->backlight)) {
> - ret = PTR_ERR(lcd->backlight);
> - lcd->backlight = NULL;
> + struct backlight_device *bd;
> + DECLARE_BACKLIGHT_INIT_RAW(props, 0, 255);
> +
> + bd = devm_backlight_device_register(&lcd->spi->dev, lcd->name,
> + &lcd->spi->dev, lcd,
> + &acx565akm_bl_ops, &props);
It's been in a bunch of earlier patches already, but devm_bl freaks me out
a bit with our long-term goal of storing a backlight pointer into
drm_connector->backlight.
Since drm_connector and the underlying backlight device have different
lifetimes that would mean we need to refcount somewhere, or protect
drm_connector->backlight with some lock. The lock might not work because
the drm connector property paths come from the other direction than the
backlight driver unload ... so probably needs to be refcounting.
-Daniel
> + if (IS_ERR(bd)) {
> + ret = PTR_ERR(bd);
> return ret;
> }
>
> + lcd->backlight = bd;
> if (lcd->has_cabc) {
> - ret = sysfs_create_group(&lcd->backlight->dev.kobj,
> + ret = sysfs_create_group(&bd->dev.kobj,
>&acx565akm_cabc_attr_group);
> if (ret < 0) {
> dev_err(&lcd->spi->dev,
> "%s failed to create sysfs files\n", __func__);
> - backlight_device_unregister(lcd->backlight);
> return ret;
> }
>
> lcd->cabc_mode = acx565akm_get_hw_cabc_mode(lcd);
> }
>
> - lcd->backlight->props.max_brightness = 255;
> - lcd->backlight->props.brightness = acx565akm_get_actual_brightness(lcd);
> -
> - acx565akm_bl_update_status_locked(lcd->backlight);
> + backlight_set_brightness(bd, acx565akm_get_actual_brightness(lcd));
> + backlight_set_power_on(bd);
> + backlight_update_status(bd);
>
> return 0;
> }
> @@ -390,8 +378,6 @@ static void acx565akm_backlight_cleanup(struct
> acx565
Re: gma500: monitor-dependent failure to boot FB console (psbdrmfb)
On Tue, Aug 04, 2020 at 01:43:29AM +, Thierry Moreau wrote: > Dear kernel / GPU enthusiasts! > > This list is listed in the kernel MAINTAINERS file for GMA500 GPU kernel > module. Just to avoid disappointment later on: For the gma500 driver it's essentially unmaintained, but we do take patches if they show up. > My message is either a call for help (not a mission-critical issue) or > troubleshooting information useful to fix an outstanding issue in the GMA500 > kernel driver? > > This GMA3650-GPU-based system with a self-supported Linux distribution boots > OK in all cases (ssh access fine when no console). > > With the HAI monitor (actually a 7 inches monitor marketed for the cinema > industry, the edid information reporting a wrong display size), the frame > buffer console is fine, i.e. from the boot log: > > [1.506269] fbcon: psbdrmfb (fb0) is primary device > > Accordingly, there are two entries in the /sys/class/vtconsole/ directory, > names "(S) dummy device" and "(M) frame buffer device". > > Unfortunately, with two ASUS monitors, the above line in the boot log never > appears. And the console turns blank early in the boot process. A single > entry appears in > /sys/class/vtconsole/, i.e. vtcon0/name -> "(S) VGA+". > > In either case Xorg starts fine and switching between ctrl-alt-f7 and > ctrl-alt-f1..6 (either console for HAI or blank for ASUS) works fine. > > Looking in the kernel source tree, 'psbdrmfb' is a frame buffer name > appearing once in the GMA500 GPU source code. > > This what I found in my patient troubleshooting. Uh this is strange, the gma500 driver should still load all fine and register that framebuffer driver. I think the only case where gma500 loads but psbdrmfb isn't set up is if it doesn't detect any outputs. I'd test these monitors with some other linux system first (they might be simply too broken), if that doesn't work you can quirk your system with the video boot parameter perhaps: https://dri.freedesktop.org/docs/drm/fb/modedb.html Cheers, Daniel > > See below: > > two boot log excerpts (grep'ing gcc\|drm\|gma5\|console\|fbcon\|D2550 -C 2) > for the 'pass' and 'fail' boot sequences; > > three edid reports for the (pass) HAI monitor and two (fail) ASUS monitors. > > Thanks in advance, and best regards! > > - Thierry Moreau > > boot sequence, 'pass' > pass:[0.00] Linux version 4.19.48 (root@dodeca1er) (gcc version > 8.4.0 (CRUX-x86_64-multilib)) #5 SMP Fri Jul 31 03:17:03 UTC 2020 > pass-[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-05 root=/dev/sda1 > ro > pass-[0.00] Disabled fast string operations > -- > pass-[0.582174] spurious 8259A interrupt: IRQ7. > pass-[0.584782] Console: colour VGA+ 80x25 > pass:[0.595503] console [tty0] enabled > pass-[0.595635] ACPI: Core revision 20180810 > pass-[0.596080] clocksource: hpet: mask: 0x max_cycles: > 0x, max_idle_ns: 133484882848 ns > -- > pass-[0.858339] sched_clock: Marking stable (843780572, > 14317326)->(964648975, -106551077) > pass-[0.858737] Loading compiled-in X.509 certificates > pass:[0.859638] gma500 :00:02.0: GPU: power management timed out. > pass-[0.880497] ACPI: Video Device [GFX0] (multi-head: yes rom: no > post: no) > pass-[0.881183] acpi device:27: registered as cooling_device5 > pass-[0.881423] input: Video Bus as > /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input3 > pass:[0.881699] [drm] Supports vblank timestamp caching Rev 2 > (21.10.2013). > pass:[0.881817] [drm] No driver support for vblank timestamp query. > pass-[0.885525] hdaudio hdaudioC0D0: Unable to bind the codec > pass-[0.889340] snd_hda_codec_hdmi hdaudioC0D1: HDMI: Unknown ELD > version 1 > -- > pass-[1.361611] sda: sda1 sda2 sda3 sda4 sda5 sda6 sda7 sda8 sda9 sda10 > sda11 > pass-[1.362977] sd 0:0:0:0: [sda] Attached SCSI disk > pass:[1.506269] fbcon: psbdrmfb (fb0) is primary device > pass-[1.599775] ata2: SATA link down (SStatus 0 SControl 300) > pass-[1.640569] snd_hda_codec_hdmi hdaudioC0D1: HDMI: Unknown ELD > version 1 > -- > pass-[2.279237] snd_hda_codec_hdmi hdaudioC0D1: HDMI: Unknown ELD > version 1 > pass-[2.342558] Console: switching to colour frame buffer device 128x45 > pass:[2.352243] gma500 :00:02.0: fb0: psbdrmfb frame buffer device > pass:[2.352451] [drm] Initialized gma500 1.0.0 20140314 for :00:02.0 > on minor 0 > pass:[2.352666] console [netcon0] enabled > pass:[2.352730] netconsole: network logging started > pas
Re: [PATCH 8/8] modules: inherit TAINT_PROPRIETARY_MODULE
On Thu, Jul 30, 2020 at 08:10:27AM +0200, Christoph Hellwig wrote:
> If a TAINT_PROPRIETARY_MODULE exports symbol, inherit the taint flag
> for all modules importing these symbols, and don't allow loading
> symbols from TAINT_PROPRIETARY_MODULE modules if the module previously
> imported gplonly symbols. Add a anti-circumvention devices so people
> don't accidentally get themselves into trouble this way.
>
> Comment from Greg:
> Ah, the proven-to-be-illegal "GPL Condom" defense :)
>
> Signed-off-by: Christoph Hellwig
> Reviewed-by: Greg Kroah-Hartman
If this helps to get the next gpu related entertainment at least cc'ed to
dri-devel, maybe even using an upstream driver, I'm all for it.
Acked-by: Daniel Vetter
> ---
> include/linux/module.h | 1 +
> kernel/module.c| 12
> 2 files changed, 13 insertions(+)
>
> diff --git a/include/linux/module.h b/include/linux/module.h
> index 30b0f5fcdb3c37..e30ed5fa33a738 100644
> --- a/include/linux/module.h
> +++ b/include/linux/module.h
> @@ -389,6 +389,7 @@ struct module {
> unsigned int num_gpl_syms;
> const struct kernel_symbol *gpl_syms;
> const s32 *gpl_crcs;
> + bool using_gplonly_symbols;
>
> #ifdef CONFIG_UNUSED_SYMBOLS
> /* unused exported symbols. */
> diff --git a/kernel/module.c b/kernel/module.c
> index afb2bfdd5134b3..04f993863ae417 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -1456,6 +1456,18 @@ static const struct kernel_symbol
> *resolve_symbol(struct module *mod,
> if (!sym)
> goto unlock;
>
> + if (license == GPL_ONLY)
> + mod->using_gplonly_symbols = true;
> +
> + if (owner && test_bit(TAINT_PROPRIETARY_MODULE, &owner->taints)) {
> + if (mod->using_gplonly_symbols) {
> + sym = NULL;
> + goto getname;
> + }
> + add_taint_module(mod, TAINT_PROPRIETARY_MODULE,
> + LOCKDEP_NOW_UNRELIABLE);
> + }
> +
> if (!check_version(info, name, mod, crc)) {
> sym = ERR_PTR(-EINVAL);
> goto getname;
> --
> 2.27.0
>
--
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 v1 03/22] backlight: Add get/set operations for brightness/power properties
On Tue, Aug 04, 2020 at 09:56:00PM +0200, Sam Ravnborg wrote:
> Hi Daniel et al.
> On Tue, Aug 04, 2020 at 06:43:30PM +0200, dan...@ffwll.ch wrote:
> > On Sun, Aug 02, 2020 at 01:06:17PM +0200, Sam Ravnborg wrote:
> > > Add get and set operations to incapsualte access to backlight properties.
> > >
> > > One easy win is that the get/set operatiosn can be used when backlight
> > > is not included in the configuration, resulting in simpler code with
> > > less ifdef's and thus more readable code.
> > >
> > > The set/get methods hides some of the confusing power states, limiting
> > > the power state to either ON or OFF for the drivers.
> > >
> > > Signed-off-by: Sam Ravnborg
> > > Cc: Lee Jones
> > > Cc: Daniel Thompson
> > > Cc: Jingoo Han
> > > ---
> > > include/linux/backlight.h | 72 +++
> > > 1 file changed, 72 insertions(+)
> > >
> > > diff --git a/include/linux/backlight.h b/include/linux/backlight.h
> > > index d683c053ec09..882ceea45ace 100644
> > > --- a/include/linux/backlight.h
> > > +++ b/include/linux/backlight.h
> > > @@ -474,6 +474,78 @@ static inline int backlight_get_brightness(const
> > > struct backlight_device *bd)
> > > return bd->props.brightness;
> > > }
> > >
> > > +/**
> > > + * backlight_get_actual_brightness - Returns the actual brightness
> > > + *
> > > + * On failure a negative error code is returned.
> > > + */
> > > +static inline int backlight_get_actual_brightness(struct
> > > backlight_device *bd)
> > > +{
> > > + if (bd && bd->ops && bd->ops->get_brightness)
> > > + return bd->ops->get_brightness(bd);
> > > + else
> > > + return -EINVAL;
> > > +}
> > > +
> > > +/**
> > > + * backlight_get_max_brightness - Returns maximum brightness
> > > + *
> > > + * This helper operation is preferred over direct access to
> > > + * &backlight_properties.max_brightness
> > > + *
> > > + * Returns 0 if backlight_device is NULL
> > > + */
> > > +
> > > +static inline int backlight_get_max_brightness(const struct
> > > backlight_device *bd)
> > > +{
> > > + if (bd)
> > > + return bd->props.max_brightness;
> > > + else
> > > + return 0;
> > > +}
> > > +
> > > +/**
> > > + * backlight_set_brightness - Set the brightness to the specified value
> > > + *
> > > + * This helper operation is preferred over direct assignment to
> > > + * &backlight_properties.brightness.
> > > + *
> > > + * If backlight_device is NULL then silently exit.
> > > + */
> > > +static inline void backlight_set_brightness(struct backlight_device *bd,
> > > int brightness)
> > > +{
> > > + if (bd)
> > > + bd->props.brightness = brightness;
> >
> > Looking at the drivers I think including a call to backlight_update_status
> > would simplify a lot of code.
> >
> > > +}
> > > +
> > > +/**
> > > + * backlight_set_power_on - Set power state to ON.
> > > + *
> > > + * This helper operation is preferred over direct assignment to
> > > + * backlight_properties.power.
> > > + *
> > > + * If backlight_device is NULL then silently exit.
> > > + */
> > > +static inline void backlight_set_power_on(struct backlight_device *bd)
> > > +{
> > > + if (bd)
> > > + bd->props.power = FB_BLANK_UNBLANK;
> > > +}
> > > +
> > > +/**
> > > + * backlight_set_power_off - Set power state to OFF.
> > > + *
> > > + * This helper operation is preferred over direct assignment to
> > > + * backlight_properties.power.
> > > + *
> > > + * If backlight_device is NULL then silently exit.
> > > + */
> > > +static inline void backlight_set_power_off(struct backlight_device *bd)
> >
> > I'm not clear why we need these two above? I thought the long-term plan is
> > only use backlight_enable/disable and then remove the tri-state power
> > handling once everyone is converted over?
> >
> > Or maybe I'm just confused about the goal here ...
>
> My TODO for v2:
> - Check all get_brightness implmentations.
> Using backlight_get_brightness is wrong - find a
Re: [PATCH 3/8] drm/amd/display: Honor the offset for plane 0.
On Tue, Aug 04, 2020 at 11:31:14PM +0200, Bas Nieuwenhuizen wrote:
> With modifiers I'd like to support non-dedicated buffers for
> images.
>
> Signed-off-by: Bas Nieuwenhuizen
Uh, I think it'd be really good to preceed this with a bugfix (cc: stable)
which checks that the offset is 0). And then this patch here removing that
again. Or cc: stable this patch here, since we seem to have a gap in
validating addfb.
-Daniel
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14 +-
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 005331c772b7..abc70fbe176d 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -3623,6 +3623,7 @@ fill_plane_dcc_attributes(struct amdgpu_device *adev,
> struct dc *dc = adev->dm.dc;
> struct dc_dcc_surface_param input;
> struct dc_surface_dcc_cap output;
> + uint64_t plane_address = afb->address + afb->base.offsets[0];
> uint32_t offset = AMDGPU_TILING_GET(info, DCC_OFFSET_256B);
> uint32_t i64b = AMDGPU_TILING_GET(info, DCC_INDEPENDENT_64B) != 0;
> uint64_t dcc_address;
> @@ -3666,7 +3667,7 @@ fill_plane_dcc_attributes(struct amdgpu_device *adev,
> AMDGPU_TILING_GET(info, DCC_PITCH_MAX) + 1;
> dcc->independent_64b_blks = i64b;
>
> - dcc_address = get_dcc_address(afb->address, info);
> + dcc_address = get_dcc_address(plane_address, info);
> address->grph.meta_addr.low_part = lower_32_bits(dcc_address);
> address->grph.meta_addr.high_part = upper_32_bits(dcc_address);
>
> @@ -3697,6 +3698,8 @@ fill_plane_buffer_attributes(struct amdgpu_device *adev,
> address->tmz_surface = tmz_surface;
>
> if (format < SURFACE_PIXEL_FORMAT_VIDEO_BEGIN) {
> + uint64_t addr = afb->address + fb->offsets[0];
> +
> plane_size->surface_size.x = 0;
> plane_size->surface_size.y = 0;
> plane_size->surface_size.width = fb->width;
> @@ -3705,9 +3708,10 @@ fill_plane_buffer_attributes(struct amdgpu_device
> *adev,
> fb->pitches[0] / fb->format->cpp[0];
>
> address->type = PLN_ADDR_TYPE_GRAPHICS;
> - address->grph.addr.low_part = lower_32_bits(afb->address);
> - address->grph.addr.high_part = upper_32_bits(afb->address);
> + address->grph.addr.low_part = lower_32_bits(addr);
> + address->grph.addr.high_part = upper_32_bits(addr);
> } else if (format < SURFACE_PIXEL_FORMAT_INVALID) {
> + uint64_t luma_addr = afb->address + fb->offsets[0];
> uint64_t chroma_addr = afb->address + fb->offsets[1];
>
> plane_size->surface_size.x = 0;
> @@ -3728,9 +3732,9 @@ fill_plane_buffer_attributes(struct amdgpu_device *adev,
>
> address->type = PLN_ADDR_TYPE_VIDEO_PROGRESSIVE;
> address->video_progressive.luma_addr.low_part =
> - lower_32_bits(afb->address);
> + lower_32_bits(luma_addr);
> address->video_progressive.luma_addr.high_part =
> - upper_32_bits(afb->address);
> + upper_32_bits(luma_addr);
> address->video_progressive.chroma_addr.low_part =
> lower_32_bits(chroma_addr);
> address->video_progressive.chroma_addr.high_part =
> --
> 2.28.0
>
--
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 6/8] drm/amd/display: Set DC options from modifiers.
_attributes(struct amdgpu_device
> *adev,
>
>
> if (adev->family >= AMDGPU_FAMILY_AI) {
> - ret = fill_gfx9_plane_attributes_from_flags(adev, afb, format,
> rotation,
> - plane_size,
> tiling_info, dcc,
> - address,
> tiling_flags,
> - force_disable_dcc);
> - if (ret)
> - return ret;
> + if (afb->base.flags & DRM_MODE_FB_MODIFIERS) {
> + ret = fill_gfx9_plane_attributes_from_modifiers(adev,
> afb, format,
> + rotation,
> plane_size,
> +
> tiling_info, dcc,
> + address,
> +
> force_disable_dcc);
> + if (ret)
> + return ret;
> + } else {
> + ret = fill_gfx9_plane_attributes_from_flags(adev, afb,
> format, rotation,
> + plane_size,
> tiling_info, dcc,
> + address,
> tiling_flags,
> +
> force_disable_dcc);
> + if (ret)
> + return ret;
So what we've done in i915, but might be too cumbersome with the amdgpu
modifiers, is to map legacy tiling information into modifiers once, at the
beginning of addfb. So in amdgpu_display_user_framebuffer_create(). And
once modifiers are filled in, you ofc set the DRM_MODE_FB_MODIFIERS flag
too in the fb.
Then all the display code only works with modifiers, instead of having a
mix and possible confusion, with breakage when people only test the legacy
path. Which I kinda expect to happen, since amd probably runs with their
own ddx in their CI rig only.
This also avoids a bunch of layering and locking unprettiness, since
display code doesn't need to dig around in gem_bo side of things. On that,
there's another amdgpu_bo_get_tiling_flags in amdgpu_dm_commit_planes
which probably shouldn't be there, and should use computed stuff from
plane state or fb (I changed it to a lockless version to just hack around
locking issues, but still there).
This hopefully/eventually should allow us to entirely phase out the legacy
magic tiling blob attached to bo (we've pulled the trigger on that for
intel now, would have needed to extend the uapi to keep it working was a
good excuse).
Cheers, Daniel
> + }
> } else {
> fill_gfx8_tiling_info_from_flags(tiling_info, tiling_flags);
> }
> --
> 2.28.0
>
--
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 01/59] drm/vmwgfx: consolidate ttm object creation and populate
_unreserve:
> - ttm_bo_unreserve(mob->pt_bo);
> - ttm_bo_put(mob->pt_bo);
> - mob->pt_bo = NULL;
> -
> - return ret;
> + return vmw_bo_create_and_populate(dev_priv, mob->num_pages * PAGE_SIZE,
> &mob->pt_bo);
> }
>
> /**
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> index 2deaaed334e6..8e2a82ded900 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> @@ -817,3 +817,35 @@ struct ttm_bo_driver vmw_bo_driver = {
> .swap_notify = vmw_swap_notify,
> .io_mem_reserve = &vmw_ttm_io_mem_reserve,
> };
> +
> +int vmw_bo_create_and_populate(struct vmw_private *dev_priv,
> +unsigned long bo_size,
> +struct ttm_buffer_object **bo_p)
> +{
> + struct ttm_operation_ctx ctx = {
> + .interruptible = false,
> + .no_wait_gpu = false
> + };
> + struct ttm_buffer_object *bo;
> + int ret;
> +
> + ret = ttm_bo_create(&dev_priv->bdev, bo_size,
> + ttm_bo_type_device,
> + &vmw_sys_ne_placement,
> + 0, false, &bo);
> +
> + if (unlikely(ret != 0))
> + return ret;
> +
> + ret = ttm_bo_reserve(bo, false, true, NULL);
> + BUG_ON(ret != 0);
> + ret = vmw_bo_driver.ttm_tt_populate(bo->ttm, &ctx);
> + if (likely(ret == 0))
> + ret = vmw_bo_map_dma(bo);
> +
> + ttm_bo_unreserve(bo);
> +
> + if (likely(ret == 0))
> + *bo_p = bo;
> + return ret;
> +}
Reviewed-by: Daniel Vetter
> --
> 2.26.2
>
> ___
> 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: [PATCH 02/59] drm/vmwgfx: drop bo map/unmap dma functions.
On Tue, Aug 04, 2020 at 12:55:35PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> The map one was used once, just inline it, and drop them both.
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.h| 2 -
> drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 46 +++---
> 2 files changed, 6 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> index b7c763713b4c..65c414f119c0 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> @@ -1019,8 +1019,6 @@ extern struct ttm_placement vmw_mob_placement;
> extern struct ttm_placement vmw_mob_ne_placement;
> extern struct ttm_placement vmw_nonfixed_placement;
> extern struct ttm_bo_driver vmw_bo_driver;
> -extern int vmw_bo_map_dma(struct ttm_buffer_object *bo);
> -extern void vmw_bo_unmap_dma(struct ttm_buffer_object *bo);
> extern const struct vmw_sg_table *
> vmw_bo_sg_table(struct ttm_buffer_object *bo);
> extern int vmw_bo_create_and_populate(struct vmw_private *dev_priv,
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> index 8e2a82ded900..3a141a08d4bd 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> @@ -519,43 +519,6 @@ static void vmw_ttm_unmap_dma(struct vmw_ttm_tt *vmw_tt)
> vmw_tt->mapped = false;
> }
>
> -
> -/**
> - * vmw_bo_map_dma - Make sure buffer object pages are visible to the device
> - *
> - * @bo: Pointer to a struct ttm_buffer_object
> - *
> - * Wrapper around vmw_ttm_map_dma, that takes a TTM buffer object pointer
> - * instead of a pointer to a struct vmw_ttm_backend as argument.
> - * Note that the buffer object must be either pinned or reserved before
> - * calling this function.
> - */
> -int vmw_bo_map_dma(struct ttm_buffer_object *bo)
> -{
> - struct vmw_ttm_tt *vmw_tt =
> - container_of(bo->ttm, struct vmw_ttm_tt, dma_ttm.ttm);
> -
> - return vmw_ttm_map_dma(vmw_tt);
> -}
> -
> -
> -/**
> - * vmw_bo_unmap_dma - Make sure buffer object pages are visible to the device
> - *
> - * @bo: Pointer to a struct ttm_buffer_object
> - *
> - * Wrapper around vmw_ttm_unmap_dma, that takes a TTM buffer object pointer
> - * instead of a pointer to a struct vmw_ttm_backend as argument.
> - */
> -void vmw_bo_unmap_dma(struct ttm_buffer_object *bo)
> -{
> - struct vmw_ttm_tt *vmw_tt =
> - container_of(bo->ttm, struct vmw_ttm_tt, dma_ttm.ttm);
> -
> - vmw_ttm_unmap_dma(vmw_tt);
> -}
> -
> -
> /**
> * vmw_bo_sg_table - Return a struct vmw_sg_table object for a
> * TTM buffer object
> @@ -839,9 +802,12 @@ int vmw_bo_create_and_populate(struct vmw_private
> *dev_priv,
>
> ret = ttm_bo_reserve(bo, false, true, NULL);
> BUG_ON(ret != 0);
> - ret = vmw_bo_driver.ttm_tt_populate(bo->ttm, &ctx);
> - if (likely(ret == 0))
> - ret = vmw_bo_map_dma(bo);
> + ret = vmw_ttm_populate(bo->ttm, &ctx);
Snuck a replacement for a vfunc call with a direct all in here, maybe
mention that in the commit message.
Reviewed-by: Daniel Vetter
> + if (likely(ret == 0)) {
> + struct vmw_ttm_tt *vmw_tt =
> + container_of(bo->ttm, struct vmw_ttm_tt, dma_ttm.ttm);
> + ret = vmw_ttm_map_dma(vmw_tt);
> + }
>
> ttm_bo_unreserve(bo);
>
> --
> 2.26.2
>
> ___
> 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: [PATCH 20/59] drm/vmwgfx/ttm: convert vram mm init to new code paths
On Tue, Aug 04, 2020 at 12:55:53PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Split out the vram thp init path vs the range manager init.
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 25 +++--
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 4 +---
> drivers/gpu/drm/vmwgfx/vmwgfx_thp.c | 12
> 3 files changed, 28 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> index 1e4c2c6119c3..5a889df2de03 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> @@ -620,6 +620,23 @@ static int vmw_dma_masks(struct vmw_private *dev_priv)
> return ret;
> }
>
> +static int vmw_vram_manager_init(struct vmw_private *dev_priv)
> +{
> + int ret;
> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> + ret = vmw_thp_init(dev_priv);
> +#else
> + struct ttm_mem_type_manager *man = &dev_priv->bdev.man[TTM_PL_VRAM];
> +
> + man->available_caching = TTM_PL_FLAG_CACHED;
> + man->default_caching = TTM_PL_FLAG_CACHED;
> +
> + ret = ttm_range_man_init(&dev_priv->bdev, man,
> + dev_priv->vram_size >> PAGE_SHIFT);
> +#endif
The ifdeffery here looks a bit funny, but not really less convoluted than
the old one I think.
Reviewed-by: Daniel Vetter
> + dev_priv->bdev.man[TTM_PL_VRAM].use_type = false;
> + return ret;
> +}
> static int vmw_driver_load(struct drm_device *dev, unsigned long chipset)
> {
> struct vmw_private *dev_priv;
> @@ -866,16 +883,12 @@ static int vmw_driver_load(struct drm_device *dev,
> unsigned long chipset)
>* Enable VRAM, but initially don't use it until SVGA is enabled and
>* unhidden.
>*/
> - dev_priv->bdev.man[TTM_PL_VRAM].func = &vmw_thp_func;
> - dev_priv->bdev.man[TTM_PL_VRAM].available_caching = TTM_PL_FLAG_CACHED;
> - dev_priv->bdev.man[TTM_PL_VRAM].default_caching = TTM_PL_FLAG_CACHED;
> - ret = ttm_bo_init_mm(&dev_priv->bdev, TTM_PL_VRAM,
> - (dev_priv->vram_size >> PAGE_SHIFT));
> +
> + ret = vmw_vram_manager_init(dev_priv);
> if (unlikely(ret != 0)) {
> DRM_ERROR("Failed initializing memory manager for VRAM.\n");
> goto out_no_vram;
> }
> - dev_priv->bdev.man[TTM_PL_VRAM].use_type = false;
>
> /*
>* "Guest Memory Regions" is an aperture like feature with
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> index 65c414f119c0..10b681725a53 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> @@ -1520,9 +1520,7 @@ vm_fault_t vmw_bo_vm_huge_fault(struct vm_fault *vmf,
>
> /* Transparent hugepage support - vmwgfx_thp.c */
> #ifdef CONFIG_TRANSPARENT_HUGEPAGE
> -extern const struct ttm_mem_type_manager_func vmw_thp_func;
> -#else
> -#define vmw_thp_func ttm_bo_manager_func
> +extern int vmw_thp_init(struct vmw_private *dev_priv);
> #endif
>
> /**
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_thp.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_thp.c
> index b7c816ba7166..0292c931c265 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_thp.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_thp.c
> @@ -115,18 +115,23 @@ static void vmw_thp_put_node(struct
> ttm_mem_type_manager *man,
> }
> }
>
> -static int vmw_thp_init(struct ttm_mem_type_manager *man,
> - unsigned long p_size)
> +int vmw_thp_init(struct vmw_private *dev_priv)
> {
> + struct ttm_mem_type_manager *man = &dev_priv->bdev.man[TTM_PL_VRAM];
> struct vmw_thp_manager *rman;
> + man->available_caching = TTM_PL_FLAG_CACHED;
> + man->default_caching = TTM_PL_FLAG_CACHED;
>
> + ttm_mem_type_manager_init(&dev_priv->bdev, man,
> + dev_priv->vram_size >> PAGE_SHIFT);
> rman = kzalloc(sizeof(*rman), GFP_KERNEL);
> if (!rman)
> return -ENOMEM;
>
> - drm_mm_init(&rman->mm, 0, p_size);
> + drm_mm_init(&rman->mm, 0, man->size);
> spin_lock_init(&rman->lock);
> man->priv = rman;
> + ttm_mem_type_manager_set_used(man, true);
> return 0;
> }
>
> @@ -158,7 +163,6 @@ static void vmw_thp_debug(struct ttm_mem_type_manager
> *man,
> }
>
> const struct ttm_mem_type_manager_func vmw_thp_func = {
> - .init = vmw_thp_init,
> .takedown = vmw_thp_takedown,
> .get_node = vmw_thp_get_node,
> .put_node = vmw_thp_put_node,
> --
> 2.26.2
>
> ___
> 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: [PATCH 21/59] drm/vmwgfx/ttm: switch gmrid allocator to new init paths.
{
> case VMW_PL_GMR:
> gman->max_gmr_ids = dev_priv->max_gmr_ids;
> gman->max_gmr_pages = dev_priv->max_gmr_pages;
> @@ -122,6 +128,8 @@ static int vmw_gmrid_man_init(struct ttm_mem_type_manager
> *man,
> BUG();
> }
> man->priv = (void *) gman;
> +
> + ttm_mem_type_manager_set_used(man, true);
> return 0;
> }
>
> @@ -137,8 +145,7 @@ static int vmw_gmrid_man_takedown(struct
> ttm_mem_type_manager *man)
> return 0;
> }
>
> -const struct ttm_mem_type_manager_func vmw_gmrid_manager_func = {
> - .init = vmw_gmrid_man_init,
> +static const struct ttm_mem_type_manager_func vmw_gmrid_manager_func = {
> .takedown = vmw_gmrid_man_takedown,
> .get_node = vmw_gmrid_man_get_node,
> .put_node = vmw_gmrid_man_put_node,
Reviewed-by: Daniel Vetter
> --
> 2.26.2
>
> ___
> 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: [PATCH 56/59] drm/ttm: add a wrapper for checking if manager is in use
On Tue, Aug 04, 2020 at 12:56:29PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> This converts vmwgfx over to using an interface to set the
> in use and check the in use flag.
>
> Signed-off-by: Dave Airlie
Hm, I think this would be a good candidate to eventually rip out once we
have full sub-classing, since it's for vmwgfx internally only. Maybe add a
todo to the kernel-doc.
-Daniel
> ---
> drivers/gpu/drm/nouveau/nouveau_ttm.c | 1 -
> drivers/gpu/drm/ttm/ttm_bo.c | 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 14 +++---
> include/drm/ttm/ttm_bo_driver.h | 14 ++
> 4 files changed, 22 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c
> b/drivers/gpu/drm/nouveau/nouveau_ttm.c
> index 22185a8dcfa1..38a0e4bd16f7 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
> @@ -240,7 +240,6 @@ nouveau_ttm_init_gtt(struct nouveau_drm *drm)
> ttm_mem_type_manager_init(man, size_pages);
> ttm_set_driver_manager(&drm->ttm.bdev, TTM_PL_TT, man);
> ttm_mem_type_manager_set_used(man, true);
> -
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index cda33b4af681..7d10abae9a60 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -1002,7 +1002,7 @@ static int ttm_bo_mem_placement(struct
> ttm_buffer_object *bo,
> return ret;
>
> man = ttm_manager_type(bdev, mem_type);
> - if (!man || !man->use_type)
> + if (!man || !ttm_mem_type_manager_used(man))
> return -EBUSY;
>
> if (!ttm_bo_mt_compatible(man, mem_type, place, &cur_flags))
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> index 7168403fb4f8..b2f1e7a3b048 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> @@ -630,7 +630,7 @@ static int vmw_vram_manager_init(struct vmw_private
> *dev_priv)
>TTM_PL_FLAG_CACHED, TTM_PL_FLAG_CACHED,
>false, dev_priv->vram_size >> PAGE_SHIFT);
> #endif
> - ttm_manager_type(&dev_priv->bdev, TTM_PL_VRAM)->use_type = false;
> + ttm_mem_type_manager_set_used(ttm_manager_type(&dev_priv->bdev,
> TTM_PL_VRAM), false);
> return ret;
> }
>
> @@ -1192,9 +1192,9 @@ static void __vmw_svga_enable(struct vmw_private
> *dev_priv)
> struct ttm_mem_type_manager *man = ttm_manager_type(&dev_priv->bdev,
> TTM_PL_VRAM);
>
> spin_lock(&dev_priv->svga_lock);
> - if (!man->use_type) {
> + if (!ttm_mem_type_manager_used(man)) {
> vmw_write(dev_priv, SVGA_REG_ENABLE, SVGA_REG_ENABLE);
> - man->use_type = true;
> + ttm_mem_type_manager_set_used(man, true);
> }
> spin_unlock(&dev_priv->svga_lock);
> }
> @@ -1223,8 +1223,8 @@ static void __vmw_svga_disable(struct vmw_private
> *dev_priv)
> struct ttm_mem_type_manager *man = ttm_manager_type(&dev_priv->bdev,
> TTM_PL_VRAM);
>
> spin_lock(&dev_priv->svga_lock);
> - if (man->use_type) {
> - man->use_type = false;
> + if (ttm_mem_type_manager_used(man)) {
> + ttm_mem_type_manager_set_used(man, false);
> vmw_write(dev_priv, SVGA_REG_ENABLE,
> SVGA_REG_ENABLE_HIDE |
> SVGA_REG_ENABLE_ENABLE);
> @@ -1257,8 +1257,8 @@ void vmw_svga_disable(struct vmw_private *dev_priv)
> vmw_kms_lost_device(dev_priv->dev);
> ttm_write_lock(&dev_priv->reservation_sem, false);
> spin_lock(&dev_priv->svga_lock);
> - if (man->use_type) {
> - man->use_type = false;
> + if (ttm_mem_type_manager_used(man)) {
> + ttm_mem_type_manager_set_used(man, false);
> spin_unlock(&dev_priv->svga_lock);
> if (ttm_bo_evict_mm(&dev_priv->bdev, TTM_PL_VRAM))
> DRM_ERROR("Failed evicting VRAM buffers.\n");
> diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
> index 300934289e64..f231fe34e744 100644
> --- a/include/drm/ttm/ttm_bo_driver.h
> +++ b/include/drm/ttm/ttm_bo_driver.h
> @@ -678,6 +678,20 @@ static inline void ttm_mem_type_manager_set_used(struct
> ttm_mem_type_manager *ma
> man->use_type = used;
> }
>
> +/**
> + * ttm_mem_type_manager_used
> + *
> + * @man: Manager to get used state for
> + *
> + * Get the in use flag f
Re: [PATCH 28/59] drm/vmwgfx: takedown vram manager
On Tue, Aug 04, 2020 at 12:56:01PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Don't bother returning EBUSY, nobody cares enough,
> if the driver has a problem, it should deal with it.
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 14 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 1 +
> drivers/gpu/drm/vmwgfx/vmwgfx_thp.c | 23 +--
> 3 files changed, 27 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> index 364d5f3ff9a8..4f4d22bac477 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> @@ -637,6 +637,17 @@ static int vmw_vram_manager_init(struct vmw_private
> *dev_priv)
> dev_priv->bdev.man[TTM_PL_VRAM].use_type = false;
> return ret;
> }
> +
> +static void vmw_vram_manager_fini(struct vmw_private *dev_priv)
> +{
> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> + vmw_thp_fini(dev_priv);
> +#else
> + ttm_bo_man_fini(&dev_priv->bdev,
> + &dev_priv->bdev.man[TTM_PL_VRAM]);
> +#endif
> +}
> +
> static int vmw_driver_load(struct drm_device *dev, unsigned long chipset)
> {
> struct vmw_private *dev_priv;
> @@ -988,7 +999,7 @@ static int vmw_driver_load(struct drm_device *dev,
> unsigned long chipset)
> (void) ttm_bo_clean_mm(&dev_priv->bdev, VMW_PL_MOB);
> if (dev_priv->has_gmr)
> (void) ttm_bo_clean_mm(&dev_priv->bdev, VMW_PL_GMR);
> - (void)ttm_bo_clean_mm(&dev_priv->bdev, TTM_PL_VRAM);
> + vmw_vram_manager_fini(dev_priv);
> out_no_vram:
> (void)ttm_bo_device_release(&dev_priv->bdev);
> out_no_bdev:
> @@ -1042,6 +1053,7 @@ static void vmw_driver_unload(struct drm_device *dev)
> vmw_release_device_early(dev_priv);
> if (dev_priv->has_mob)
> (void) ttm_bo_clean_mm(&dev_priv->bdev, VMW_PL_MOB);
> + vmw_vram_manager_fini(dev_priv);
I think drmm_ would be neat for all this stuff eventually, but we're still
in the very early phases of rolling that out.
> (void) ttm_bo_device_release(&dev_priv->bdev);
> drm_vma_offset_manager_destroy(&dev_priv->vma_manager);
> vmw_release_device_late(dev_priv);
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> index 8f319dd6cdb4..c6530d7b6d51 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> @@ -1521,6 +1521,7 @@ vm_fault_t vmw_bo_vm_huge_fault(struct vm_fault *vmf,
> /* Transparent hugepage support - vmwgfx_thp.c */
> #ifdef CONFIG_TRANSPARENT_HUGEPAGE
> extern int vmw_thp_init(struct vmw_private *dev_priv);
> +void vmw_thp_fini(struct vmw_private *dev_priv);
> #endif
>
> /**
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_thp.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_thp.c
> index 0292c931c265..548f152b9963 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_thp.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_thp.c
> @@ -135,21 +135,25 @@ int vmw_thp_init(struct vmw_private *dev_priv)
> return 0;
> }
>
> -static int vmw_thp_takedown(struct ttm_mem_type_manager *man)
> +void vmw_thp_fini(struct vmw_private *dev_priv)
> {
> + struct ttm_mem_type_manager *man = &dev_priv->bdev.man[TTM_PL_VRAM];
> struct vmw_thp_manager *rman = (struct vmw_thp_manager *) man->priv;
> struct drm_mm *mm = &rman->mm;
> + int ret;
> +
> + ttm_mem_type_manager_disable(man);
>
> + ret = ttm_mem_type_manager_force_list_clean(&dev_priv->bdev, man);
> + if (ret)
> + return;
> spin_lock(&rman->lock);
> - if (drm_mm_clean(mm)) {
> - drm_mm_takedown(mm);
> - spin_unlock(&rman->lock);
> - kfree(rman);
> - man->priv = NULL;
> - return 0;
> - }
> + drm_mm_clean(mm);
> + drm_mm_takedown(mm);
> spin_unlock(&rman->lock);
> - return -EBUSY;
> + kfree(rman);
> + man->priv = NULL;
> + ttm_mem_type_manager_cleanup(man);
> }
>
> static void vmw_thp_debug(struct ttm_mem_type_manager *man,
> @@ -163,7 +167,6 @@ static void vmw_thp_debug(struct ttm_mem_type_manager
> *man,
> }
>
> const struct ttm_mem_type_manager_func vmw_thp_func = {
> - .takedown = vmw_thp_takedown,
> .get_node = vmw_thp_get_node,
> .put_node = vmw_thp_put_node,
> .debug = vmw_thp_debug
Still the mildly icky #ifdef, but looks good to me.
Reviewed-by: Daniel Vetter
> --
> 2.26.2
>
> ___
> 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: [PATCH 33/59] drm/vmwgfx: fix gmrid takedown paths to new interface
On Tue, Aug 04, 2020 at 12:56:06PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 9 -
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 1 +
> drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 11 ---
> 3 files changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> index 4f4d22bac477..f368a9cc0c2a 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> @@ -996,9 +996,9 @@ static int vmw_driver_load(struct drm_device *dev,
> unsigned long chipset)
> vmw_kms_close(dev_priv);
> out_no_kms:
> if (dev_priv->has_mob)
> - (void) ttm_bo_clean_mm(&dev_priv->bdev, VMW_PL_MOB);
> + vmw_gmrid_man_fini(dev_priv, VMW_PL_MOB);
> if (dev_priv->has_gmr)
> - (void) ttm_bo_clean_mm(&dev_priv->bdev, VMW_PL_GMR);
> + vmw_gmrid_man_fini(dev_priv, VMW_PL_GMR);
> vmw_vram_manager_fini(dev_priv);
> out_no_vram:
> (void)ttm_bo_device_release(&dev_priv->bdev);
> @@ -1047,12 +1047,11 @@ static void vmw_driver_unload(struct drm_device *dev)
> vmw_overlay_close(dev_priv);
>
> if (dev_priv->has_gmr)
> - (void)ttm_bo_clean_mm(&dev_priv->bdev, VMW_PL_GMR);
> - (void)ttm_bo_clean_mm(&dev_priv->bdev, TTM_PL_VRAM);
> + vmw_gmrid_man_fini(dev_priv, VMW_PL_GMR);
>
> vmw_release_device_early(dev_priv);
> if (dev_priv->has_mob)
> - (void) ttm_bo_clean_mm(&dev_priv->bdev, VMW_PL_MOB);
> + vmw_gmrid_man_fini(dev_priv, VMW_PL_MOB);
> vmw_vram_manager_fini(dev_priv);
> (void) ttm_bo_device_release(&dev_priv->bdev);
> drm_vma_offset_manager_destroy(&dev_priv->vma_manager);
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> index c6530d7b6d51..aa763c6b1146 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> @@ -1222,6 +1222,7 @@ int vmw_overlay_num_free_overlays(struct vmw_private
> *dev_priv);
> */
>
> int vmw_gmrid_man_init(struct vmw_private *dev_priv, int type);
> +void vmw_gmrid_man_fini(struct vmw_private *dev_priv, int type);
>
> /**
> * Prime - vmwgfx_prime.c
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
> index 141fb14e3583..ec1b5bb01a93 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
> @@ -133,20 +133,25 @@ int vmw_gmrid_man_init(struct vmw_private *dev_priv,
> int type)
> return 0;
> }
>
> -static int vmw_gmrid_man_takedown(struct ttm_mem_type_manager *man)
> +void vmw_gmrid_man_fini(struct vmw_private *dev_priv, int type)
> {
> + struct ttm_mem_type_manager *man = &dev_priv->bdev.man[type];
> struct vmwgfx_gmrid_man *gman =
> (struct vmwgfx_gmrid_man *)man->priv;
>
> + ttm_mem_type_manager_disable(man);
> +
> + ttm_mem_type_manager_force_list_clean(&dev_priv->bdev, man);
> +
> if (gman) {
I don't think this can ever be non-NULL if init worked, not after the
demidlayering. Maybe put a WARN_ON(!gman) in here. With that:
Reviewed-by: Daniel Vetter
> ida_destroy(&gman->gmr_ida);
> kfree(gman);
> }
> - return 0;
> +
> + ttm_mem_type_manager_cleanup(man);
> }
>
> static const struct ttm_mem_type_manager_func vmw_gmrid_manager_func = {
> - .takedown = vmw_gmrid_man_takedown,
> .get_node = vmw_gmrid_man_get_node,
> .put_node = vmw_gmrid_man_put_node,
> };
> --
> 2.26.2
>
> ___
> 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: [PATCH 42/59] drm/vmwgfx/ttm: use wrapper to access memory manager
On Tue, Aug 04, 2020 at 12:56:15PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Signed-off-by: Dave Airlie
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 23 +++
> drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 4 ++--
> drivers/gpu/drm/vmwgfx/vmwgfx_thp.c | 4 ++--
> 3 files changed, 18 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> index f368a9cc0c2a..6ed92f38b54b 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> @@ -634,7 +634,7 @@ static int vmw_vram_manager_init(struct vmw_private
> *dev_priv)
> ret = ttm_range_man_init(&dev_priv->bdev, man,
>dev_priv->vram_size >> PAGE_SHIFT);
> #endif
> - dev_priv->bdev.man[TTM_PL_VRAM].use_type = false;
> + ttm_manager_type(&dev_priv->bdev, TTM_PL_VRAM)->use_type = false;
> return ret;
> }
>
> @@ -644,7 +644,7 @@ static void vmw_vram_manager_fini(struct vmw_private
> *dev_priv)
> vmw_thp_fini(dev_priv);
> #else
> ttm_bo_man_fini(&dev_priv->bdev,
> - &dev_priv->bdev.man[TTM_PL_VRAM]);
> + ttm_manager_type(&dev_priv->bdev, TTM_PL_VRAM));
> #endif
> }
>
> @@ -887,7 +887,7 @@ static int vmw_driver_load(struct drm_device *dev,
> unsigned long chipset)
> DRM_ERROR("Failed initializing TTM buffer object driver.\n");
> goto out_no_bdev;
> }
> - dev_priv->bdev.man[TTM_PL_SYSTEM].available_caching =
> + ttm_manager_type(&dev_priv->bdev, TTM_PL_SYSTEM)->available_caching =
> TTM_PL_FLAG_CACHED;
>
> /*
> @@ -1194,10 +1194,12 @@ static void vmw_master_drop(struct drm_device *dev,
> */
> static void __vmw_svga_enable(struct vmw_private *dev_priv)
> {
> + struct ttm_mem_type_manager *man = ttm_manager_type(&dev_priv->bdev,
> TTM_PL_VRAM);
> +
> spin_lock(&dev_priv->svga_lock);
> - if (!dev_priv->bdev.man[TTM_PL_VRAM].use_type) {
> + if (!man->use_type) {
> vmw_write(dev_priv, SVGA_REG_ENABLE, SVGA_REG_ENABLE);
> - dev_priv->bdev.man[TTM_PL_VRAM].use_type = true;
> + man->use_type = true;
> }
> spin_unlock(&dev_priv->svga_lock);
> }
> @@ -1223,9 +1225,11 @@ void vmw_svga_enable(struct vmw_private *dev_priv)
> */
> static void __vmw_svga_disable(struct vmw_private *dev_priv)
> {
> + struct ttm_mem_type_manager *man = ttm_manager_type(&dev_priv->bdev,
> TTM_PL_VRAM);
> +
> spin_lock(&dev_priv->svga_lock);
> - if (dev_priv->bdev.man[TTM_PL_VRAM].use_type) {
> - dev_priv->bdev.man[TTM_PL_VRAM].use_type = false;
> + if (man->use_type) {
> + man->use_type = false;
> vmw_write(dev_priv, SVGA_REG_ENABLE,
> SVGA_REG_ENABLE_HIDE |
> SVGA_REG_ENABLE_ENABLE);
> @@ -1242,6 +1246,7 @@ static void __vmw_svga_disable(struct vmw_private
> *dev_priv)
> */
> void vmw_svga_disable(struct vmw_private *dev_priv)
> {
> + struct ttm_mem_type_manager *man = ttm_manager_type(&dev_priv->bdev,
> TTM_PL_VRAM);
> /*
>* Disabling SVGA will turn off device modesetting capabilities, so
>* notify KMS about that so that it doesn't cache atomic state that
> @@ -1257,8 +1262,8 @@ void vmw_svga_disable(struct vmw_private *dev_priv)
> vmw_kms_lost_device(dev_priv->dev);
> ttm_write_lock(&dev_priv->reservation_sem, false);
> spin_lock(&dev_priv->svga_lock);
> - if (dev_priv->bdev.man[TTM_PL_VRAM].use_type) {
> - dev_priv->bdev.man[TTM_PL_VRAM].use_type = false;
> + if (man->use_type) {
> + man->use_type = false;
> spin_unlock(&dev_priv->svga_lock);
> if (ttm_bo_evict_mm(&dev_priv->bdev, TTM_PL_VRAM))
> DRM_ERROR("Failed evicting VRAM buffers.\n");
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
> index ec1b5bb01a93..54c85a59dd8b 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
> @@ -98,7 +98,7 @@ static const struct ttm_mem_type_manager_func
> vmw_gmrid_manager_func;
>
> int vmw_gmrid_man_init(struct vmw_private *dev_priv, int type)
> {
> - struct ttm_mem_type_manager *man = &
Re: [PATCH 48/59] drm/vmwgfx/ttm: move thp to driver managed
On Tue, Aug 04, 2020 at 12:56:21PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Signed-off-by: Dave Airlie
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_thp.c | 32 +++--
> 1 file changed, 21 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_thp.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_thp.c
> index 720a24214c74..1cefd9c1e8ea 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_thp.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_thp.c
> @@ -16,10 +16,16 @@
> * @lock: Manager lock.
> */
> struct vmw_thp_manager {
> + struct ttm_mem_type_manager manager;
> struct drm_mm mm;
> spinlock_t lock;
> };
>
> +static struct vmw_thp_manager *to_thp_manager(struct ttm_mem_type_manager
> *man)
> +{
> + return container_of(man, struct vmw_thp_manager, manager);
> +}
> +
> static int vmw_thp_insert_aligned(struct drm_mm *mm, struct drm_mm_node
> *node,
> unsigned long align_pages,
> const struct ttm_place *place,
> @@ -43,7 +49,7 @@ static int vmw_thp_get_node(struct ttm_mem_type_manager
> *man,
> const struct ttm_place *place,
> struct ttm_mem_reg *mem)
> {
> - struct vmw_thp_manager *rman = (struct vmw_thp_manager *) man->priv;
> + struct vmw_thp_manager *rman = to_thp_manager(man);
> struct drm_mm *mm = &rman->mm;
> struct drm_mm_node *node;
> unsigned long align_pages;
> @@ -103,7 +109,7 @@ static int vmw_thp_get_node(struct ttm_mem_type_manager
> *man,
> static void vmw_thp_put_node(struct ttm_mem_type_manager *man,
>struct ttm_mem_reg *mem)
> {
> - struct vmw_thp_manager *rman = (struct vmw_thp_manager *) man->priv;
> + struct vmw_thp_manager *rman = to_thp_manager(man);
>
> if (mem->mm_node) {
> spin_lock(&rman->lock);
> @@ -117,20 +123,24 @@ static void vmw_thp_put_node(struct
> ttm_mem_type_manager *man,
>
> int vmw_thp_init(struct vmw_private *dev_priv)
> {
> - struct ttm_mem_type_manager *man = ttm_manager_type(&dev_priv->bdev,
> TTM_PL_VRAM);
> + struct ttm_mem_type_manager *man;
> struct vmw_thp_manager *rman;
> +
> + rman = kzalloc(sizeof(*rman), GFP_KERNEL);
> + if (!rman)
> + return -ENOMEM;
> +
> + man = &rman->manager;
> man->available_caching = TTM_PL_FLAG_CACHED;
> man->default_caching = TTM_PL_FLAG_CACHED;
>
> ttm_mem_type_manager_init(&dev_priv->bdev, man,
> dev_priv->vram_size >> PAGE_SHIFT);
> - rman = kzalloc(sizeof(*rman), GFP_KERNEL);
> - if (!rman)
> - return -ENOMEM;
>
> drm_mm_init(&rman->mm, 0, man->size);
> spin_lock_init(&rman->lock);
> - man->priv = rman;
> +
> + ttm_set_driver_manager(&dev_priv->bdev, TTM_PL_VRAM, &rman->manager);
> ttm_mem_type_manager_set_used(man, true);
> return 0;
> }
> @@ -138,7 +148,7 @@ int vmw_thp_init(struct vmw_private *dev_priv)
> void vmw_thp_fini(struct vmw_private *dev_priv)
> {
> struct ttm_mem_type_manager *man = ttm_manager_type(&dev_priv->bdev,
> TTM_PL_VRAM);
> - struct vmw_thp_manager *rman = (struct vmw_thp_manager *) man->priv;
> + struct vmw_thp_manager *rman = to_thp_manager(man);
> struct drm_mm *mm = &rman->mm;
> int ret;
>
> @@ -151,15 +161,15 @@ void vmw_thp_fini(struct vmw_private *dev_priv)
> drm_mm_clean(mm);
> drm_mm_takedown(mm);
> spin_unlock(&rman->lock);
> - kfree(rman);
> - man->priv = NULL;
> ttm_mem_type_manager_cleanup(man);
> + ttm_set_driver_manager(&dev_priv->bdev, TTM_PL_VRAM, NULL);
> + kfree(rman);
> }
>
> static void vmw_thp_debug(struct ttm_mem_type_manager *man,
> struct drm_printer *printer)
> {
> - struct vmw_thp_manager *rman = (struct vmw_thp_manager *) man->priv;
> + struct vmw_thp_manager *rman = to_thp_manager(man);
>
> spin_lock(&rman->lock);
> drm_mm_print(&rman->mm, printer);
> --
> 2.26.2
>
> ___
> 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: [PATCH 49/59] drm/vmwgfx/gmrid: convert to driver controlled allocation.
On Tue, Aug 04, 2020 at 12:56:22PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 32 +++
> 1 file changed, 18 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
> index 54c85a59dd8b..bc51b7773084 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
> @@ -37,6 +37,7 @@
> #include
>
> struct vmwgfx_gmrid_man {
> + struct ttm_mem_type_manager manager;
> spinlock_t lock;
> struct ida gmr_ida;
> uint32_t max_gmr_ids;
> @@ -44,13 +45,17 @@ struct vmwgfx_gmrid_man {
> uint32_t used_gmr_pages;
> };
>
> +static struct vmwgfx_gmrid_man *to_gmrid_manager(struct ttm_mem_type_manager
> *man)
> +{
> + return container_of(man, struct vmwgfx_gmrid_man, manager);
> +}
> +
> static int vmw_gmrid_man_get_node(struct ttm_mem_type_manager *man,
> struct ttm_buffer_object *bo,
> const struct ttm_place *place,
> struct ttm_mem_reg *mem)
> {
> - struct vmwgfx_gmrid_man *gman =
> - (struct vmwgfx_gmrid_man *)man->priv;
> + struct vmwgfx_gmrid_man *gman = to_gmrid_manager(man);
> int id;
>
> id = ida_alloc_max(&gman->gmr_ida, gman->max_gmr_ids - 1, GFP_KERNEL);
> @@ -82,8 +87,7 @@ static int vmw_gmrid_man_get_node(struct
> ttm_mem_type_manager *man,
> static void vmw_gmrid_man_put_node(struct ttm_mem_type_manager *man,
> struct ttm_mem_reg *mem)
> {
> - struct vmwgfx_gmrid_man *gman =
> - (struct vmwgfx_gmrid_man *)man->priv;
> + struct vmwgfx_gmrid_man *gman = to_gmrid_manager(man);
>
> if (mem->mm_node) {
> ida_free(&gman->gmr_ida, mem->start);
> @@ -98,13 +102,15 @@ static const struct ttm_mem_type_manager_func
> vmw_gmrid_manager_func;
>
> int vmw_gmrid_man_init(struct vmw_private *dev_priv, int type)
> {
> - struct ttm_mem_type_manager *man = ttm_manager_type(&dev_priv->bdev,
> type);
> + struct ttm_mem_type_manager *man;
> struct vmwgfx_gmrid_man *gman =
> kzalloc(sizeof(*gman), GFP_KERNEL);
>
> if (unlikely(!gman))
> return -ENOMEM;
>
> + man = &gman->manager;
> +
> man->func = &vmw_gmrid_manager_func;
> man->available_caching = TTM_PL_FLAG_CACHED;
> man->default_caching = TTM_PL_FLAG_CACHED;
> @@ -127,8 +133,7 @@ int vmw_gmrid_man_init(struct vmw_private *dev_priv, int
> type)
> default:
> BUG();
> }
> - man->priv = (void *) gman;
> -
> + ttm_set_driver_manager(&dev_priv->bdev, type, &gman->manager);
> ttm_mem_type_manager_set_used(man, true);
> return 0;
> }
> @@ -136,19 +141,18 @@ int vmw_gmrid_man_init(struct vmw_private *dev_priv,
> int type)
> void vmw_gmrid_man_fini(struct vmw_private *dev_priv, int type)
> {
> struct ttm_mem_type_manager *man = ttm_manager_type(&dev_priv->bdev,
> type);
> - struct vmwgfx_gmrid_man *gman =
> - (struct vmwgfx_gmrid_man *)man->priv;
> + struct vmwgfx_gmrid_man *gman = to_gmrid_manager(man);
>
> ttm_mem_type_manager_disable(man);
>
> ttm_mem_type_manager_force_list_clean(&dev_priv->bdev, man);
>
> - if (gman) {
Ah, here it goes, please disregard my suggestion earlier for adding a
WARN_ON, that's just churn.
Reviewed-by: Daniel Vetter
> - ida_destroy(&gman->gmr_ida);
> - kfree(gman);
> - }
> -
> ttm_mem_type_manager_cleanup(man);
> +
> + ttm_set_driver_manager(&dev_priv->bdev, type, NULL);
> + ida_destroy(&gman->gmr_ida);
> + kfree(gman);
> +
> }
>
> static const struct ttm_mem_type_manager_func vmw_gmrid_manager_func = {
> --
> 2.26.2
>
> ___
> 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: [PATCH] drm: sysfs: Add to get current mode
On Wed, Aug 05, 2020 at 06:03:15PM +0800, Huang Jiachai wrote:
> Hi Daniel
>
> 在 2020/8/5 17:36, Daniel Vetter 写道:
> > On Wed, Aug 5, 2020 at 10:37 AM Sandy Huang wrote:
> > > add this node to get the current true mode.
> > >
> > > Signed-off-by: Sandy Huang
> > Uh what's this for? Since it's sysfs, I guess there's something
> > parsing this, which means we'd kinda need to have that piece too.
> >
> > If it's just for debugging purposes, then we already have this
> > information in debugfs, together with everything else that's in the
> > atomic modeset state.
> > -Daniel
>
> yes, this is just for debug;
>
> and i get the information what i need from cat
> /sys/kernel/debug/dri/0/state, thanks.
Cool, sounds like this is resolved. And if you need any additional debug
information about display state, then best to extend that file. It comes
with driver hooks, so that you can include any additional driver stuff, or
outright read out registers and everything.
Cheers, Daniel
>
> > > ---
> > > drivers/gpu/drm/drm_sysfs.c | 30 ++
> > > 1 file changed, 30 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> > > index 939f0032aab1..f39bcd34853b 100644
> > > --- a/drivers/gpu/drm/drm_sysfs.c
> > > +++ b/drivers/gpu/drm/drm_sysfs.c
> > > @@ -19,6 +19,7 @@
> > > #include
> > >
> > > #include
> > > +#include
> > > #include
> > > #include
> > > #include
> > > @@ -236,16 +237,45 @@ static ssize_t modes_show(struct device *device,
> > > return written;
> > > }
> > >
> > > +static ssize_t current_mode_show(struct device *device,
> > > + struct device_attribute *attr,
> > > + char *buf)
> > > +{
> > > + struct drm_connector *connector = to_drm_connector(device);
> > > + struct drm_display_mode *mode;
> > > + struct drm_crtc_state *crtc_state;
> > > + bool interlaced;
> > > + int written = 0;
> > > +
> > > + if (!connector->state || !connector->state->crtc)
> > > + return written;
> > > +
> > > + crtc_state = connector->state->crtc->state;
> > > + if (!crtc_state)
> > > + return written;
> > > +
> > > + mode = &crtc_state->mode;
> > > +
> > > + interlaced = !!(mode->flags & DRM_MODE_FLAG_INTERLACE);
> > > + written += snprintf(buf + written, PAGE_SIZE - written,
> > > "%dx%d%s%d\n",
> > > + mode->hdisplay, mode->vdisplay,
> > > + interlaced ? "i" : "p",
> > > drm_mode_vrefresh(mode));
> > > +
> > > + return written;
> > > +}
> > > +
> > > static DEVICE_ATTR_RW(status);
> > > static DEVICE_ATTR_RO(enabled);
> > > static DEVICE_ATTR_RO(dpms);
> > > static DEVICE_ATTR_RO(modes);
> > > +static DEVICE_ATTR_RO(current_mode);
> > >
> > > static struct attribute *connector_dev_attrs[] = {
> > > &dev_attr_status.attr,
> > > &dev_attr_enabled.attr,
> > > &dev_attr_dpms.attr,
> > > &dev_attr_modes.attr,
> > > + &dev_attr_current_mode.attr,
> > > NULL
> > > };
> > >
> > > --
> > > 2.17.1
> > >
> > >
> > >
> >
> --
> Best Regard
>
> 黄家钗
> Sandy Huang
> Addr: 福州市鼓楼区铜盘路软件大道89号福州软件园A区21号楼(350003)
> No. 21 Building, A District, No.89,software Boulevard Fuzhou,Fujian,PRC
> Tel：+86 0591-87884919 8690
> E-mail：h...@rock-chips.com
>
>
>
--
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/8] drm/atomic-helper: reset vblank on crtc reset
On Thu, Aug 06, 2020 at 03:43:02PM +0900, Tetsuo Handa wrote:
> As of commit 47ec5303d73ea344 ("Merge
> git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next") on linux.git ,
> my VMware environment cannot boot. Do I need to bisect?
That sounds like a good idea, but please start a new thread (not reply to
some random existing ones), with maintainers for drivers/gpu/drm/vmwgfx
only. Not a massive list of random folks who have no idea what's going on
here. From get_maintainers.pl
$ scripts/get_maintainer.pl -f drivers/gpu/drm/vmwgfx/
VMware Graphics (supporter:DRM DRIVER
FOR VMWARE VIRTUAL GPU)
Roland Scheidegger (supporter:DRM DRIVER FOR VMWARE
VIRTUAL GPU)
David Airlie (maintainer:DRM DRIVERS)
Daniel Vetter (maintainer:DRM DRIVERS)
dri-devel@lists.freedesktop.org (open list:DRM DRIVER FOR VMWARE VIRTUAL GPU)
linux-ker...@vger.kernel.org (open list)
Cheers, Daniel
>
> [9.314496][T1] vga16fb: mapped to 0x71050562
> [9.467770][T1] Console: switching to colour frame buffer device 80x30
> [9.632092][T1] fb0: VGA16 VGA frame buffer device
> [9.651768][T1] ACPI: AC Adapter [ACAD] (on-line)
> [9.672544][T1] input: Power Button as
> /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0
> [9.722373][T1] ACPI: Power Button [PWRF]
> [9.744231][T1] ioatdma: Intel(R) QuickData Technology Driver 5.00
> [9.820147][T1] N_HDLC line discipline registered with maxframe=4096
> [9.835649][T1] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
> [9.852567][T1] 00:05: ttyS0 at I/O 0x3f8 (irq = 4, base_baud =
> 115200) is a 16550A
> [ 10.033372][T1] Cyclades driver 2.6
> [ 10.049928][T1] Initializing Nozomi driver 2.1d
> [ 10.065493][T1] RocketPort device driver module, version 2.09,
> 12-June-2003
> [ 10.095368][T1] No rocketport ports found; unloading driver
> [ 10.112430][T1] Non-volatile memory driver v1.3
> [ 10.127090][T1] Linux agpgart interface v0.103
> [ 10.144037][T1] agpgart-intel :00:00.0: Intel 440BX Chipset
> [ 10.162275][T1] agpgart-intel :00:00.0: AGP aperture is 256M @ 0x0
> [ 10.181130][T1] [drm] DMA map mode: Caching DMA mappings.
> [ 10.195150][T1] [drm] Capabilities:
> [ 10.208728][T1] [drm] Rect copy.
> [ 10.222772][T1] [drm] Cursor.
> [ 10.235364][T1] [drm] Cursor bypass.
> [ 10.249121][T1] [drm] Cursor bypass 2.
> [ 10.260590][T1] [drm] 8bit emulation.
> [ 10.272220][T1] [drm] Alpha cursor.
> [ 10.284670][T1] [drm] 3D.
> [ 10.295051][T1] [drm] Extended Fifo.
> [ 10.305180][T1] [drm] Multimon.
> [ 10.315506][T1] [drm] Pitchlock.
> [ 10.325167][T1] [drm] Irq mask.
> [ 10.334262][T1] [drm] Display Topology.
> [ 10.343519][T1] [drm] GMR.
> [ 10.352775][T1] [drm] Traces.
> [ 10.362166][T1] [drm] GMR2.
> [ 10.370716][T1] [drm] Screen Object 2.
> [ 10.379220][T1] [drm] Command Buffers.
> [ 10.388489][T1] [drm] Command Buffers 2.
> [ 10.396055][T1] [drm] Guest Backed Resources.
> [ 10.403290][T1] [drm] DX Features.
> [ 10.409911][T1] [drm] HP Command Queue.
> [ 10.417820][T1] [drm] Capabilities2:
> [ 10.424216][T1] [drm] Grow oTable.
> [ 10.430423][T1] [drm] IntraSurface copy.
> [ 10.436371][T1] [drm] Max GMR ids is 64
> [ 10.442651][T1] [drm] Max number of GMR pages is 65536
> [ 10.450317][T1] [drm] Max dedicated hypervisor surface memory is 0 kiB
> [ 10.458809][T1] [drm] Maximum display memory size is 262144 kiB
> [ 10.466330][T1] [drm] VRAM at 0xe800 size is 4096 kiB
> [ 10.474704][T1] [drm] MMIO at 0xfe00 size is 256 kiB
> [ 10.484625][T1] [TTM] Zone kernel: Available graphics memory: 4030538
> KiB
> [ 10.500730][T1] [TTM] Zone dma32: Available graphics memory: 2097152
> KiB
> [ 10.516851][T1] [TTM] Initializing pool allocator
> [ 10.527542][T1] [TTM] Initializing DMA pool allocator
> [ 10.540197][T1] BUG: kernel NULL pointer dereference, address:
> 0438
> [ 10.550087][T1] #PF: supervisor read access in kernel mode
> [ 10.550087][T1] #PF: error_code(0x) - not-present page
> [ 10.550087][T1] PGD 0 P4D 0
> [ 10.550087][T1] Oops: [#1] PREEMPT SMP
> [ 10.550087][T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.8.0+ #271
> [ 10.550087][T1] Hardware name: VMware, Inc. VMware Virtual
> Platform/440BX Desktop Reference Platform, BIOS 6.00 02/27/2020
> [ 10.550087][T1] RIP: 0010:drm_dev_has_vblank+0x9/0x20
> [ 10.550087][T1] Code: 5d 41 5e 41 5f e9 e7 fa 01 ff e8 e2 fa 01 ff 45
Re: [PATCH] drm/amdgpu: fix spelling mistake "Falied" -> "Failed"
On Thu, Aug 06, 2020 at 09:36:41AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> On Wed, 05 Aug 2020 15:19:38 -0700 Joe Perches wrote:
> >
> > On Wed, 2020-08-05 at 17:27 -0400, Alex Deucher wrote:
> > > On Wed, Aug 5, 2020 at 4:53 PM Joe Perches wrote:
> > > > On Wed, 2020-08-05 at 16:01 -0400, Alex Deucher wrote:
> > > > > On Wed, Aug 5, 2020 at 7:35 AM Colin King
> > > > > wrote:
> > > > > > From: Colin Ian King
> > > > > >
> > > > > > There is a spelling mistake in a DRM_ERROR message. Fix it.
> > > > > >
> > > > > > Signed-off-by: Colin Ian King
> > > > >
> > > > > This is already fixed.
> > > >
> > > > This fix is not in today's -next.
> > > >
> > > > Perhaps whatever tree it's fixed in should be in -next.
> > > >
> > >
> > > Weird. It's in the drm-next tree as:
> > >
> > > commit 4afaa61db9cf5250b5734c2531b226e7b3a3d691
> > > Author: Colin Ian King
> > > Date: Fri Jul 10 09:37:58 2020 +0100
> > >
> > > drm/amdgpu: fix spelling mistake "Falied" -> "Failed"
> > >
> > > There is a spelling mistake in a DRM_ERROR error message. Fix it.
> > >
> > > Signed-off-by: Colin Ian King
> > > Signed-off-by: Alex Deucher
> > >
> > > Alex
> > >
> > > > $ git show --oneline -s
> > > > d15fe4ec0435 (HEAD, tag: next-20200805, origin/master, origin/HEAD) Add
> > > > linux-next specific files for 20200805
> > > >
> > > > $ git grep -i falied drivers
> > > > drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c:
> > > > DRM_ERROR("Falied to terminate tmr\n");
> > > >
> > > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> > > > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> > > > []
> > > > > > @@ -2010,7 +2010,7 @@ static int psp_suspend(void *handle)
> > > > > >
> > > > > > ret = psp_tmr_terminate(psp);
> > > > > > if (ret) {
> > > > > > - DRM_ERROR("Falied to terminate tmr\n");
> > > > > > + DRM_ERROR("Failed to terminate tmr\n");
> > > > > > return ret;
> > > > > > }
> >
> > Dunno.
> >
> > Maybe it's due to some ordering of trees in
> > how -next accumulates patches?
>
> The spelling error is introduced in two commits:
>
> c564b8601ae9 ("drm/amdgpu: add TMR destory function for psp")
>
> in Linus' tree between v5.8-rc4 and rc5
>
> 90937420c44f ("drm/amdgpu: add TMR destory function for psp")
>
> in the amdgpu tree between two merges by the drm tree. In this same
> interval, the error is corrected by commit
>
> 4afaa61db9cf ("drm/amdgpu: fix spelling mistake "Falied" -> "Failed"")
>
> so when David comes to merge the amdgpu tree in commit
>
> 206739119508 ("Merge tag 'amd-drm-next-5.9-2020-07-17' of
> git://people.freedesktop.org/~agd5f/linux into drm-next")
>
> the spelling error has been introduced on one side of the merge and
> introduced and corrected on the other. This would have produced a
> conflict which David presumably resolved in haste by picking the HEAD
> side of the merge instead of the MERGE_HEAD side (it happens).
>
> This could have been avoided by not cherry-picking fix commits around
> in the amdgpu process - instead having a fixes branch that is merged
> into the next branch after the fixes branch has been accepted upstream
> (that way there is only one commit for each fix and less conflicts).
>
> I have to deal with these sort of conflicts (sometimes daily) due to
> the drm processes. Its a pain as I have to track down each conflict to
> see if the same patches appear on both sides of merges and then try to
> figure out what other changes occur. (This is only slightly helped by
> have the "cherry-picked from" tags in the fix commits.)
Yeah cherry-picking breaks if you only occasionally cherry-pick - then
stuff gets lost.
I'd say just apply it once more for the merge window fixes pull.
-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 2/3] backlight: pwm_bl: Artificially add 0% during interpolation
On Mon, Jul 20, 2020 at 09:25:21PM -0700, Alexandru Stan wrote: > Some displays need the low end of the curve cropped in order to make > them happy. In that case we still want to have the 0% point, even though > anything between 0% and 5%(example) would be skipped. > > Signed-off-by: Alexandru Stan > --- > > drivers/video/backlight/pwm_bl.c | 8 > 1 file changed, 8 insertions(+) > > diff --git a/drivers/video/backlight/pwm_bl.c > b/drivers/video/backlight/pwm_bl.c > index 5193a72305a2..b24711ddf504 100644 > --- a/drivers/video/backlight/pwm_bl.c > +++ b/drivers/video/backlight/pwm_bl.c > @@ -349,6 +349,14 @@ static int pwm_backlight_parse_dt(struct device *dev, > /* Fill in the last point, since no line starts here. */ > table[x2] = y2; > > + /* > + * If we don't start at 0 yet we're increasing, assume > + * the dts wanted to crop the low end of the range, so > + * insert a 0 to provide a display off mode. > + */ > + if (table[0] > 0 && table[0] < table[num_levels - 1]) > + table[0] = 0; Isn't that what the enable/disable switch in backlights are for? There's lots of backligh drivers (mostly the firmware variety) where setting the backlight to 0 does not shut it off, it's just the lowest setting. But I've not been involved in the details of these discussions. -Daniel > + > /* >* As we use interpolation lets remove current >* brightness levels table and replace for the > -- > 2.27.0 > > ___ > 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: [PATCH 1/7] drm/amd/display: Store tiling_flags and tmz_surface on dm_plane_state
On Thu, Jul 30, 2020 at 04:36:36PM -0400, Nicholas Kazlauskas wrote:
> [Why]
> Store these in advance so we can reuse them later in commit_tail without
> having to reserve the fbo again.
>
> These will also be used for checking for tiling changes when deciding
> to reset the plane or not.
I've also dropped some comments on Bas' series for adding modifiers which
might be relevant for shuffling all this. But yeah stuff this into plane
state sounds like a good idea.
-Daniel
>
> [How]
> This change should mostly be a refactor. Only commit check is affected
> for now and I'll drop the get_fb_info calls in prepare_planes and
> commit_tail after.
>
> This runs a prepass loop once we think that all planes have been added
> to the context and replaces the get_fb_info calls with accessing the
> dm_plane_state instead.
>
> Cc: Bhawanpreet Lakha
> Cc: Rodrigo Siqueira
> Signed-off-by: Nicholas Kazlauskas
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 60 +++
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 2 +
> 2 files changed, 37 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 8d64f5fde7e2..7cc5ab90ce13 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -3700,8 +3700,17 @@ static int fill_dc_scaling_info(const struct
> drm_plane_state *state,
> static int get_fb_info(const struct amdgpu_framebuffer *amdgpu_fb,
> uint64_t *tiling_flags, bool *tmz_surface)
> {
> - struct amdgpu_bo *rbo = gem_to_amdgpu_bo(amdgpu_fb->base.obj[0]);
> - int r = amdgpu_bo_reserve(rbo, false);
> + struct amdgpu_bo *rbo;
> + int r;
> +
> + if (!amdgpu_fb) {
> + *tiling_flags = 0;
> + *tmz_surface = false;
> + return 0;
> + }
> +
> + rbo = gem_to_amdgpu_bo(amdgpu_fb->base.obj[0]);
> + r = amdgpu_bo_reserve(rbo, false);
>
> if (unlikely(r)) {
> /* Don't show error message when returning -ERESTARTSYS */
> @@ -4124,13 +4133,10 @@ static int fill_dc_plane_attributes(struct
> amdgpu_device *adev,
> struct drm_crtc_state *crtc_state)
> {
> struct dm_crtc_state *dm_crtc_state = to_dm_crtc_state(crtc_state);
> - const struct amdgpu_framebuffer *amdgpu_fb =
> - to_amdgpu_framebuffer(plane_state->fb);
> + struct dm_plane_state *dm_plane_state = to_dm_plane_state(plane_state);
> struct dc_scaling_info scaling_info;
> struct dc_plane_info plane_info;
> - uint64_t tiling_flags;
> int ret;
> - bool tmz_surface = false;
> bool force_disable_dcc = false;
>
> ret = fill_dc_scaling_info(plane_state, &scaling_info);
> @@ -4142,15 +4148,12 @@ static int fill_dc_plane_attributes(struct
> amdgpu_device *adev,
> dc_plane_state->clip_rect = scaling_info.clip_rect;
> dc_plane_state->scaling_quality = scaling_info.scaling_quality;
>
> - ret = get_fb_info(amdgpu_fb, &tiling_flags, &tmz_surface);
> - if (ret)
> - return ret;
> -
> force_disable_dcc = adev->asic_type == CHIP_RAVEN && adev->in_suspend;
> - ret = fill_dc_plane_info_and_addr(adev, plane_state, tiling_flags,
> + ret = fill_dc_plane_info_and_addr(adev, plane_state,
> + dm_plane_state->tiling_flags,
> &plane_info,
> &dc_plane_state->address,
> - tmz_surface,
> + dm_plane_state->tmz_surface,
> force_disable_dcc);
> if (ret)
> return ret;
> @@ -5753,6 +5756,10 @@ dm_drm_plane_duplicate_state(struct drm_plane *plane)
> dc_plane_state_retain(dm_plane_state->dc_state);
> }
>
> + /* Framebuffer hasn't been updated yet, so retain old flags. */
> + dm_plane_state->tiling_flags = old_dm_plane_state->tiling_flags;
> + dm_plane_state->tmz_surface = old_dm_plane_state->tmz_surface;
> +
> return &dm_plane_state->base;
> }
>
> @@ -8557,13 +8564,9 @@ dm_determine_update_type_for_commit(struct
> amdgpu_display_manager *dm,
> continue;
>
> for_each_oldnew_plane_in_state(state, plane, old_plane_state,
> new_plane_state, j) {
> - const struct amdgpu_framebuffer *amdgp
Re: [PATCH 0/7] drm/amd/display: Drop DRM private objects from amdgpu_dm
On Thu, Jul 30, 2020 at 04:36:35PM -0400, Nicholas Kazlauskas wrote: > Based on the analysis of the bug from [1] the best course of action seems > to be swapping off of DRM private objects back to subclassing DRM atomic > state instead. > > This patch series implements this change, but not yet the other changes > suggested in the threads from that bug - these will come later. > > CCing dri-devel per Daniel's suggestion since this issue brought > some interesting misuse of private objects. I ended up reading around a bit, and it feels like the sub-objects might make a reasonable private state structure perhaps. Like dc_stream_state, at least when reading around in e.g. dc_remove_stream_from_ctx. But would need to come up with a plan how to integrate this on the other os side of DC I guess :-) Anyway I'd say more evidence that dc_state needs to subclass drm_atomic_state. Another thing I wondered is whether we should rename drm_atomic_state to drm_atomic_state_update, so it's clear it's the container with the updated states, not a real state object thing itself. -Daniel > > [1] https://bugzilla.kernel.org/show_bug.cgi?id=207383 > > Nicholas Kazlauskas (7): > drm/amd/display: Store tiling_flags and tmz_surface on dm_plane_state > drm/amd/display: Reset plane when tiling flags change > drm/amd/display: Avoid using unvalidated tiling_flags and tmz_surface > in prepare_planes > drm/amd/display: Use validated tiling_flags and tmz_surface in > commit_tail > drm/amd/display: Reset plane for anything that's not a FAST update > drm/amd/display: Drop dm_determine_update_type_for_commit > drm/amd/display: Replace DRM private objects with subclassed DRM > atomic state > > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 967 ++ > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 13 +- > 2 files changed, 343 insertions(+), 637 deletions(-) > > -- > 2.25.1 > > ___ > 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: [PATCH 3/7] drm/amd/display: Avoid using unvalidated tiling_flags and tmz_surface in prepare_planes
On Thu, Jul 30, 2020 at 04:36:38PM -0400, Nicholas Kazlauskas wrote:
> [Why]
> We're racing with userspace as the flags could potentially change
> from when we acquired and validated them in commit_check.
Uh ... I didn't know these could change. I think my comments on Bas'
series are even more relevant now. I think long term would be best to bake
these flags in at addfb time when modifiers aren't set. And otherwise
always use the modifiers flag, and completely ignore the legacy flags
here.
-Daniel
>
> [How]
> We unfortunately can't drop this function in its entirety from
> prepare_planes since we don't know the afb->address at commit_check
> time yet.
>
> So instead of querying new tiling_flags and tmz_surface use the ones
> from the plane_state directly.
>
> While we're at it, also update the force_disable_dcc option based
> on the state from atomic check.
>
> Cc: Bhawanpreet Lakha
> Cc: Rodrigo Siqueira
> Signed-off-by: Nicholas Kazlauskas
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 36 ++-
> 1 file changed, 19 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index bf1881bd492c..f78c09c9585e 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -5794,14 +5794,8 @@ static int dm_plane_helper_prepare_fb(struct drm_plane
> *plane,
> struct list_head list;
> struct ttm_validate_buffer tv;
> struct ww_acquire_ctx ticket;
> - uint64_t tiling_flags;
> uint32_t domain;
> int r;
> - bool tmz_surface = false;
> - bool force_disable_dcc = false;
> -
> - dm_plane_state_old = to_dm_plane_state(plane->state);
> - dm_plane_state_new = to_dm_plane_state(new_state);
>
> if (!new_state->fb) {
> DRM_DEBUG_DRIVER("No FB bound\n");
> @@ -5845,27 +5839,35 @@ static int dm_plane_helper_prepare_fb(struct
> drm_plane *plane,
> return r;
> }
>
> - amdgpu_bo_get_tiling_flags(rbo, &tiling_flags);
> -
> - tmz_surface = amdgpu_bo_encrypted(rbo);
> -
> ttm_eu_backoff_reservation(&ticket, &list);
>
> afb->address = amdgpu_bo_gpu_offset(rbo);
>
> amdgpu_bo_ref(rbo);
>
> + /**
> + * We don't do surface updates on planes that have been newly created,
> + * but we also don't have the afb->address during atomic check.
> + *
> + * Fill in buffer attributes depending on the address here, but only on
> + * newly created planes since they're not being used by DC yet and this
> + * won't modify global state.
> + */
> + dm_plane_state_old = to_dm_plane_state(plane->state);
> + dm_plane_state_new = to_dm_plane_state(new_state);
> +
> if (dm_plane_state_new->dc_state &&
> - dm_plane_state_old->dc_state !=
> dm_plane_state_new->dc_state) {
> - struct dc_plane_state *plane_state =
> dm_plane_state_new->dc_state;
> + dm_plane_state_old->dc_state != dm_plane_state_new->dc_state) {
> + struct dc_plane_state *plane_state =
> + dm_plane_state_new->dc_state;
> + bool force_disable_dcc = !plane_state->dcc.enable;
>
> - force_disable_dcc = adev->asic_type == CHIP_RAVEN &&
> adev->in_suspend;
> fill_plane_buffer_attributes(
> adev, afb, plane_state->format, plane_state->rotation,
> - tiling_flags, &plane_state->tiling_info,
> - &plane_state->plane_size, &plane_state->dcc,
> - &plane_state->address, tmz_surface,
> - force_disable_dcc);
> + dm_plane_state_new->tiling_flags,
> + &plane_state->tiling_info, &plane_state->plane_size,
> + &plane_state->dcc, &plane_state->address,
> + dm_plane_state_new->tmz_surface, force_disable_dcc);
> }
>
> return 0;
> --
> 2.25.1
>
> ___
> 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: [PATCH 5/7] drm/amd/display: Reset plane for anything that's not a FAST update
On Thu, Jul 30, 2020 at 04:36:40PM -0400, Nicholas Kazlauskas wrote: > [Why] > MEDIUM or FULL updates can require global validation or affect > bandwidth. By treating these all simply as surface updates we aren't > actually passing this through DC global validation. > > [How] > There's currently no way to pass surface updates through DC global > validation, nor do I think it's a good idea to change the interface > to accept these. > > DC global validation itself is currently stateless, and we can move > our update type checking to be stateless as well by duplicating DC > surface checks in DM based on DRM properties. > > We wanted to rely on DC automatically determining this since DC knows > best, but DM is ultimately what fills in everything into DC plane > state so it does need to know as well. > > There are basically only three paths that we exercise in DM today: > > 1) Cursor (async update) > 2) Pageflip (fast update) > 3) Full pipe programming (medium/full updates) > > Which means that anything that's more than a pageflip really needs to > go down path #3. > > So this change duplicates all the surface update checks based on DRM > state instead inside of should_reset_plane(). > > Next step is dropping dm_determine_update_type_for_commit and we no > longer require the old DC state at all for global validation. I think we do something similar in i915, where we have a "nothing except base address changed" fast path, but for anything else we fully compute a new state. Obviously you should try to keep global state synchronization to a minimum for this step, so it's not entirely only 2 options. Once we have the states, we compare them and figure out whether we can get away with a fast modeset operation (maybe what you guys call medium update). Anyway I think being slightly more aggressive with computing full state, and then falling back to more optimized update again is a good approach. Only risk is if we you have too much synchronization in your locking (e.g. modern compositors do like to change tiling and stuff, especially once you have modifiers enabled, so this shouldn't cause a sync across crtc except when absolutely needed). -Daniel > > Optimization can come later so we don't reset DC planes at all for > MEDIUM udpates and avoid validation, but we might require some extra > checks in DM to achieve this. > > Cc: Bhawanpreet Lakha > Cc: Hersen Wu > Signed-off-by: Nicholas Kazlauskas > --- > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 25 +++ > 1 file changed, 25 insertions(+) > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > index 0d5f45742bb5..2cbb29199e61 100644 > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > @@ -8336,6 +8336,31 @@ static bool should_reset_plane(struct drm_atomic_state > *state, > if (old_other_state->crtc != new_other_state->crtc) > return true; > > + /* Src/dst size and scaling updates. */ > + if (old_other_state->src_w != new_other_state->src_w || > + old_other_state->src_h != new_other_state->src_h || > + old_other_state->crtc_w != new_other_state->crtc_w || > + old_other_state->crtc_h != new_other_state->crtc_h) > + return true; > + > + /* Rotation / mirroring updates. */ > + if (old_other_state->rotation != new_other_state->rotation) > + return true; > + > + /* Blending updates. */ > + if (old_other_state->pixel_blend_mode != > + new_other_state->pixel_blend_mode) > + return true; > + > + /* Alpha updates. */ > + if (old_other_state->alpha != new_other_state->alpha) > + return true; > + > + /* Colorspace changes. */ > + if (old_other_state->color_range != > new_other_state->color_range || > + old_other_state->color_encoding != > new_other_state->color_encoding) > + return true; > + > /* Framebuffer checks fall at the end. */ > if (!old_other_state->fb || !new_other_state->fb) > continue; > -- > 2.25.1 > > ___ > 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: [PATCH 7/7] drm/amd/display: Replace DRM private objects with subclassed DRM atomic state
On Thu, Jul 30, 2020 at 04:36:42PM -0400, Nicholas Kazlauskas wrote: > [Why] > DM atomic check was structured in a way that we required old DC state > in order to dynamically add and remove planes and streams from the > context to build the DC state context for validation. > > DRM private objects were used to carry over the last DC state and > were added to the context on nearly every commit - regardless of fast > or full so we could check whether or not the new state could affect > bandwidth. > > The problem with this model is that DRM private objects do not > implicitly stall out other commits. > > So if you have two commits touching separate DRM objects they could > run concurrently and potentially execute out of order - leading to a > use-after-free. > > If we want this to be safe we have two options: > 1. Stall out concurrent commits since they touch the same private object > 2. Refactor DM to not require old DC state and drop private object usage > > [How] > This implements approach #2 since it still allows for judder free > updates in multi-display scenarios. > > I'll list the big changes in order at a high level: > > 1. Subclass DRM atomic state instead of using DRM private objects. > > DC relied on the old state to determine which changes cause bandwidth > updates but now we have DM perform similar checks based on DRM state > instead - dropping the requirement for old state to exist at all. > > This means that we can now build a new DC context from scratch whenever > we have something that DM thinks could affect bandwidth. > > Whenever we need to rebuild bandwidth we now add all CRTCs and planes > to the DRM state in order to get the absolute set of DC streams and > DC planes. > > This introduces a stall on other commits, but this stall already > exists because of the lock_and_validation logic and it's necessary > since updates may move around pipes and require full reprogramming. Hm I think long term would be neat if you can first just add the dc streams for the current planes (if you convert them individually to private state objects), and ask DC to recompute specifics just for that. If DC then says "yes I need an even bigger recompute" only then do you grab all the streams and everything else. The idea is that essentially you treat individual stream objects as read-locks on that part of the overall global state, and only when you need to do a write do you grab all the "read locks" to do the update. But might not actually help for your hw. Just highlighting this as a pattern we've done. -Daniel > > 2. Drop workarounds to add planes to maintain z-order early in atomic > check. This is no longer needed because of the changes for (1). > > This also involves fixing up should_plane_reset checks since we can just > avoid resetting streams and planes when they haven't actually changed. > > 3. Rework dm_update_crtc_state and dm_update_plane_state to be single > pass instead of two pass. > > This is necessary since we no longer have the dc_state to add and > remove planes to the context in and we want to defer creation to the > end of commit_check. > > It also makes the logic a lot simpler to follow since as an added bonus. > > Cc: Bhawanpreet Lakha > Cc: Harry Wentland > Cc: Leo Li > Cc: Daniel Vetter > Signed-off-by: Nicholas Kazlauskas > --- > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 720 +++--- > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 11 +- > 2 files changed, 280 insertions(+), 451 deletions(-) > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > index 59829ec81694..97a7dfc620e8 100644 > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > @@ -1839,7 +1839,6 @@ static int dm_resume(void *handle) > struct drm_plane *plane; > struct drm_plane_state *new_plane_state; > struct dm_plane_state *dm_new_plane_state; > - struct dm_atomic_state *dm_state = > to_dm_atomic_state(dm->atomic_obj.state); > enum dc_connection_type new_connection_type = dc_connection_none; > struct dc_state *dc_state; > int i, r, j; > @@ -1879,11 +1878,6 @@ static int dm_resume(void *handle) > > return 0; > } > - /* Recreate dc_state - DC invalidates it when setting power state to > S3. */ > - dc_release_state(dm_state->context); > - dm_state->context = dc_create_state(dm->dc); > - /* TODO: Remove dc_state->dccg, use dc->dccg directly. */ > - dc_resource_state_construct(dm->dc, dm_state->context); > > /*
Re: [PATCH v1 4/4] drm/ast: Disable planes while switching display modes
On Wed, Aug 05, 2020 at 12:54:28PM +0200, Thomas Zimmermann wrote:
> The ast HW cursor requires the primary plane and CRTC to display at
> a valid mode and format. This is not the case while switching
> display modes, which can lead to the screen turing permanently dark.
>
> As a workaround, the ast driver now disables active planes while the
> mode or format switch takes place. It also synchronizes with the vertical
> refresh to give CRTC and planes some time to catch up on each other.
> The active planes planes (primary or cursor) will be re-enabled by
> each plane's atomic_update() function.
>
> v2:
> * move the logic into the commit-tail function
>
> Signed-off-by: Thomas Zimmermann
> Fixes: 4961eb60f145 ("drm/ast: Enable atomic modesetting")
> Cc: Thomas Zimmermann
> Cc: Gerd Hoffmann
> Cc: Dave Airlie
> Cc: Daniel Vetter
> Cc: Sam Ravnborg
> Cc: Emil Velikov
> Cc: "Y.C. Chen"
> Cc: # v5.6+
> ---
> drivers/gpu/drm/ast/ast_drv.h | 2 +
> drivers/gpu/drm/ast/ast_mode.c | 68 --
> 2 files changed, 66 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
> index c1af6b725933..467049ca8430 100644
> --- a/drivers/gpu/drm/ast/ast_drv.h
> +++ b/drivers/gpu/drm/ast/ast_drv.h
> @@ -177,6 +177,8 @@ struct ast_private *ast_device_create(struct drm_driver
> *drv,
>
> #define AST_IO_MM_OFFSET (0x380)
>
> +#define AST_IO_VGAIR1_VREFRESH BIT(3)
> +
> #define __ast_read(x) \
> static inline u##x ast_read##x(struct ast_private *ast, u32 reg) { \
> u##x val = 0;\
> diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
> index ae5cb0a333f7..a379d51f3543 100644
> --- a/drivers/gpu/drm/ast/ast_mode.c
> +++ b/drivers/gpu/drm/ast/ast_mode.c
> @@ -514,6 +514,17 @@ static void ast_set_start_address_crt1(struct
> ast_private *ast,
>
> }
>
> +static void ast_wait_for_vretrace(struct ast_private *ast)
> +{
> + unsigned long timeout = jiffies + HZ;
> + u8 vgair1;
> +
> + do {
> + vgair1 = ast_io_read8(ast, AST_IO_INPUT_STATUS1_READ);
> + } while (!(vgair1 & AST_IO_VGAIR1_VREFRESH) &&
> + time_before(jiffies, timeout));
> +}
> +
> /*
> * Primary plane
> */
> @@ -1043,23 +1054,72 @@ static int ast_connector_init(struct drm_device *dev)
> * Mode config
> */
>
> +static bool
> +ast_crtc_needs_planes_disabled(struct drm_crtc_state *old_crtc_state,
> +struct drm_crtc_state *new_crtc_state)
> +{
> + struct ast_crtc_state *old_ast_crtc_state, *new_ast_crtc_state;
> +
> + if (drm_atomic_crtc_needs_modeset(new_crtc_state))
> + return true;
> +
> + old_ast_crtc_state = to_ast_crtc_state(old_crtc_state);
> + new_ast_crtc_state = to_ast_crtc_state(new_crtc_state);
> +
> + if (old_ast_crtc_state->format != new_ast_crtc_state->format)
> + return true;
> +
> + return false;
> +}
> +
> static void
> ast_mode_config_helper_commit_tail(struct drm_atomic_state *old_state)
> {
> struct drm_device *dev = old_state->dev;
> + struct ast_private *ast = to_ast_private(dev);
> + struct drm_crtc_state *old_crtc_state, *new_crtc_state;
> + struct drm_crtc *crtc;
> + int i;
> + bool wait_for_vretrace = false;
>
> drm_atomic_helper_commit_modeset_disables(dev, old_state);
>
> - drm_atomic_helper_commit_planes(dev, old_state, 0);
> + /*
> + * HW cursors require the underlying primary plane and CRTC to
> + * display a valid mode and image. This is not the case during
> + * full modeset operations. So we temporarily disable any active
> + * plane, including the HW cursor. Each plane's atomic_update()
> + * helper will re-enable it if necessary.
> + *
> + * We only do this during *full* modesets. It does not affect
> + * simple pageflips on the planes.
> + */
> + for_each_oldnew_crtc_in_state(old_state, crtc,
> + old_crtc_state,
> + new_crtc_state, i) {
> + if (!ast_crtc_needs_planes_disabled(old_crtc_state,
> + new_crtc_state))
> + continue;
> + drm_atomic_helper_disable_planes_on_crtc(old_crtc_state,
> + false);
> + wait_for_vretrace = true;
> + }
Hm this still feels like you're fighting the framework more than using it.
Comment here, b
Re: [PATCH 7/7] drm/amd/display: Replace DRM private objects with subclassed DRM atomic state
On Thu, Jul 30, 2020 at 04:36:42PM -0400, Nicholas Kazlauskas wrote:
> @@ -440,7 +431,7 @@ struct dm_crtc_state {
> #define to_dm_crtc_state(x) container_of(x, struct dm_crtc_state, base)
>
> struct dm_atomic_state {
> - struct drm_private_state base;
> + struct drm_atomic_state base;
>
> struct dc_state *context;
Also curiosity: Can't we just embed dc_state here, instead of a pointer?
Then it would become a lot more obvious that mostly this is a state object
container like drm_atomic_state, but for the DC specific state structures.
And we could look into moving the actual DC states into drm private states
perhaps (if that helps with the code structure and overall flow).
Maybe as next steps.
-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] drm/gma500: fix spelling mistake "pannel" -> "panel"
On Wed, Aug 05, 2020 at 01:42:27PM +0100, Colin King wrote:
> From: Colin Ian King
>
> There a handful of spelling mistakes. fix them.
>
> Signed-off-by: Colin Ian King
Queued up for 5.10, should show up in linux-next right after the merge
window closes.
-Daniel
> ---
> drivers/gpu/drm/gma500/mdfld_dsi_output.c | 4 ++--
> drivers/gpu/drm/gma500/psb_intel_sdvo.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/mdfld_dsi_output.c
> b/drivers/gpu/drm/gma500/mdfld_dsi_output.c
> index f350ac1ead18..2f3486f32fed 100644
> --- a/drivers/gpu/drm/gma500/mdfld_dsi_output.c
> +++ b/drivers/gpu/drm/gma500/mdfld_dsi_output.c
> @@ -366,7 +366,7 @@ static enum drm_mode_status
> mdfld_dsi_connector_mode_valid(struct drm_connector
> /**
>* FIXME: current DC has no fitting unit, reject any mode setting
>* request
> - * Will figure out a way to do up-scaling(pannel fitting) later.
> + * Will figure out a way to do up-scaling(panel fitting) later.
>**/
> if (fixed_mode) {
> if (mode->hdisplay != fixed_mode->hdisplay)
> @@ -531,7 +531,7 @@ void mdfld_dsi_output_init(struct drm_device *dev,
> dsi_config->connector = dsi_connector;
>
> if (!dsi_config->fixed_mode) {
> - DRM_ERROR("No pannel fixed mode was found\n");
> + DRM_ERROR("No panel fixed mode was found\n");
> goto dsi_init_err0;
> }
>
> diff --git a/drivers/gpu/drm/gma500/psb_intel_sdvo.c
> b/drivers/gpu/drm/gma500/psb_intel_sdvo.c
> index 06e44f47e73e..907f966d6f22 100644
> --- a/drivers/gpu/drm/gma500/psb_intel_sdvo.c
> +++ b/drivers/gpu/drm/gma500/psb_intel_sdvo.c
> @@ -125,7 +125,7 @@ struct psb_intel_sdvo {
> bool is_lvds;
>
> /**
> - * This is sdvo fixed pannel mode pointer
> + * This is sdvo fixed panel mode pointer
>*/
> struct drm_display_mode *sdvo_lvds_fixed_mode;
>
> --
> 2.27.0
>
--
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: [v1] drm/msm/dpu: Fix reservation failures in modeset
On Wed, Aug 05, 2020 at 08:48:34AM -0700, Rob Clark wrote:
> On Wed, Aug 5, 2020 at 6:34 AM Kalyan Thota wrote:
> >
> > In TEST_ONLY commit, rm global_state will duplicate the
> > object and request for new reservations, once they pass
> > then the new state will be swapped with the old and will
> > be available for the Atomic Commit.
> >
> > This patch fixes some of missing links in the resource
> > reservation sequence mentioned above.
> >
> > 1) Creation of a duplicate state in test_only commit (Rob)
> > 2) Allow resource release only during crtc_active false.
> >
> > For #2
> > In a modeset operation, swap state happens well before disable.
> > Hence clearing reservations in disable will cause failures
> > in modeset enable.
> >
> > Sequence:
> > Swap state --> old, new
> > modeset disables --> virt disable
> > modeset enable --> virt modeset
> >
> > Allow reservations to be cleared only when crtc active is false
> > as in that case there wont be any modeset enable after disable.
> >
> > Signed-off-by: Kalyan Thota
> > ---
> > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 7 +--
> > 1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > index 63976dc..b85a576 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > @@ -582,7 +582,7 @@ static int dpu_encoder_virt_atomic_check(
> > dpu_kms = to_dpu_kms(priv->kms);
> > mode = &crtc_state->mode;
> > adj_mode = &crtc_state->adjusted_mode;
> > - global_state = dpu_kms_get_existing_global_state(dpu_kms);
> > + global_state = dpu_kms_get_global_state(crtc_state->state);
> > trace_dpu_enc_atomic_check(DRMID(drm_enc));
> >
> > /*
> > @@ -1172,6 +1172,7 @@ static void dpu_encoder_virt_disable(struct
> > drm_encoder *drm_enc)
> > struct msm_drm_private *priv;
> > struct dpu_kms *dpu_kms;
> > struct dpu_global_state *global_state;
> > + struct drm_crtc_state *crtc_state;
> > int i = 0;
> >
> > if (!drm_enc) {
> > @@ -1191,6 +1192,7 @@ static void dpu_encoder_virt_disable(struct
> > drm_encoder *drm_enc)
> > priv = drm_enc->dev->dev_private;
> > dpu_kms = to_dpu_kms(priv->kms);
> > global_state = dpu_kms_get_existing_global_state(dpu_kms);
> > + crtc_state = drm_enc->crtc->state;
> >
> > trace_dpu_enc_disable(DRMID(drm_enc));
> >
> > @@ -1220,7 +1222,8 @@ static void dpu_encoder_virt_disable(struct
> > drm_encoder *drm_enc)
> >
> > DPU_DEBUG_ENC(dpu_enc, "encoder disabled\n");
> >
> > - dpu_rm_release(global_state, drm_enc);
> > + if (crtc_state->active_changed && !crtc_state->active)
> > + dpu_rm_release(global_state, drm_enc);
>
> I still think releasing the state in the atomic_commit() path is the
> wrong thing to do. In the commit path, the various state objects
> should be immutable.. ie. in the atomic_test() path you derive the new
> hw state (including assignment/release of resources), and
> atomic_commit() is simply pushing the state down to the hw.
>
> Otherwise, this looks better than v1.
Yeah this races and is total no-go. If you touch your state in commit
(except some very specific exceptions), then a next TEST_ONLY atomic_check
might duplicate the atomic state object in an incosistent state, and fail.
Worse, this looks like if you race like that then you might duplicate an
object with old reservations still in place, and then we've essentially
leaked those resources and need to reboot. Yes most compositors use
blocking modesets, but some actually do full nonblocking modesets.
This stuff needs to be moved into the atomic_check code, and your commit
code needs to be careful to use the right state (old or new) when pushing
it into hw.
Cheers, Daniel
>
> BR,
> -R
>
> >
> > mutex_unlock(&dpu_enc->enc_lock);
> > }
> > --
> > 1.9.1
> >
> ___
> 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
[3.11-rc4] [HD2400] - radeon.dpm
Hi > As I suspected, on your system all the performance levels are the same: (...) > [8.961704]power level 0sclk: 45000 mclk: 5 vddc: > 950 > [8.961706]power level 1sclk: 45000 mclk: 5 vddc: > 950 > [8.961708]power level 2sclk: 45000 mclk: 5 vddc: > 950 (...) > So there is no dynamic switching supported on your system. I also had this problem and manage to "fix" it (on a HD2600) :) Please be warnned that this is dangerous, requires editing the bios and may brick your card. Also, will not work on recent cards (but a HD2400 should be ok). Also, this is a hack and no one will support you if things go wrong! You need a windows machine, for some steps, but other can use a linux equivalent... but editing the GPU bios i know no alternative to using the windows program. I also don't know is there is any way in linux to load a GPU bios (and avoid the flashing)... we have the firmware, but i think that the firmware is just a subset of the bios. So here is the "HOWTO": Make a usb pendrive bootable to DOS: Get this files: http://files.extremeoverclocking.com/file.php?f=196 http://pt.kioskea.net/download/baixaki-433-hp-usb-disk-storage-format-tool Unzip the windows98 DOS support to a directory and run the HP usb storage app and format the pendrive. Chek the flag "Create a DOS startup disk" and choose the extracted windows98 files. After formating, download and extract the ATI flash to the pen: http://www.techpowerup.com/downloads/1731/ATIFlash_3.79.html Now lets edit the bios. Ddownload this two apps: http://www.techpowerup.com/gpuz/ -> Dump the GPU Bios http://www.techpowerup.com/rbe/ -> ATI/AMD Bios editor use the gpu-z to dump the current bios, backup it up on a pendrive, to revert to the original bios if needed. use the rbe to edit the power levels. be conservative, DO NOT TOUCH the boot power profiles (this way you can always boot the machine), avoid changing the voltage, as it's more dangerous (but it can also save more power). Edit the lower leves to reduce the GPU frequencies and keep the level 2 high. please note that too low or too high frequencies may cause the card to be unstable. DRAM frequencies usually save little power, but may help reducing the heat. For evey change, test it and check if the card is stable, the picture is not corrupted in different resolutions and loads. Again, if something goes wrong, power off the machine and startup again, the boot profile should be the one that always work (don't forget to have a boot entry in grub that disables the dynamic powermanagement, to avoid jumping to a unstable profile). After doing the changes, save the bios and save it to the pendrive. Now shutdown the machine, make sure you have the full charge and have the power connected. If power faills during the flashing of the bios, you may brick the card/laptop. Startup the computer with the pendriver, enter the DOS and run the flash command: atiflash -p 0 .rom where the .rom is the new "tuned" bios. After some seconds and the command line returned, you can reboot and test it. If something fails, flash back the original bios. Test the card, increase the load, let screen/card enter the sleep mode (screensaver/suspend), change resolutions and look at the temperature. If all OK, you can try to tune even more. So this is a possible (and dangerous) solution for this problem, but may help some people. Good luck higuita ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: fix and rework dma_buf_poll v6
On Wed, Jul 14, 2021 at 3:21 PM Christian König
wrote:
> Just a gentle ping. Or have I missed your reply?
Nah just got overwhelmed with dma-resv discussion and took a break. I
still think some igt (or reviewing what we have) would be good. We
could also just merge Jason's import/export series, since he's typed
the igts for that which us dma_buf poll.
-Daniel
>
> Thanks,
> Christian.
>
> Am 09.07.21 um 14:07 schrieb Christian König:
> > Daniel pointed me towards this function and there are multiple obvious
> > problems
> > in the implementation.
> >
> > First of all the retry loop is not working as intended. In general the retry
> > makes only sense if you grab the reference first and then check the sequence
> > values.
> >
> > Then we should always also wait for the exclusive fence.
> >
> > It's also good practice to keep the reference around when installing
> > callbacks
> > to fences you don't own.
> >
> > And last the whole implementation was unnecessary complex and rather hard to
> > understand which could lead to probably unexpected behavior of the IOCTL.
> >
> > Fix all this by reworking the implementation from scratch. Dropping the
> > whole RCU approach and taking the lock instead.
> >
> > Only mildly tested and needs a thoughtful review of the code.
> >
> > v2: fix the reference counting as well
> > v3: keep the excl fence handling as is for stable
> > v4: back to testing all fences, drop RCU
> > v5: handle in and out separately
> > v6: add missing clear of events
> >
> > Signed-off-by: Christian König
> > CC: sta...@vger.kernel.org
> > ---
> > drivers/dma-buf/dma-buf.c | 156 +-
> > include/linux/dma-buf.h | 2 +-
> > 2 files changed, 72 insertions(+), 86 deletions(-)
> >
> > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> > index eadd1eaa2fb5..39e1ef872829 100644
> > --- a/drivers/dma-buf/dma-buf.c
> > +++ b/drivers/dma-buf/dma-buf.c
> > @@ -72,7 +72,7 @@ static void dma_buf_release(struct dentry *dentry)
> >* If you hit this BUG() it means someone dropped their ref to the
> >* dma-buf while still having pending operation to the buffer.
> >*/
> > - BUG_ON(dmabuf->cb_shared.active || dmabuf->cb_excl.active);
> > + BUG_ON(dmabuf->cb_in.active || dmabuf->cb_out.active);
> >
> > dmabuf->ops->release(dmabuf);
> >
> > @@ -202,16 +202,57 @@ static void dma_buf_poll_cb(struct dma_fence *fence,
> > struct dma_fence_cb *cb)
> > wake_up_locked_poll(dcb->poll, dcb->active);
> > dcb->active = 0;
> > spin_unlock_irqrestore(&dcb->poll->lock, flags);
> > + dma_fence_put(fence);
> > +}
> > +
> > +static bool dma_buf_poll_shared(struct dma_resv *resv,
> > + struct dma_buf_poll_cb_t *dcb)
> > +{
> > + struct dma_resv_list *fobj = dma_resv_get_list(resv);
> > + struct dma_fence *fence;
> > + int i, r;
> > +
> > + if (!fobj)
> > + return false;
> > +
> > + for (i = 0; i < fobj->shared_count; ++i) {
> > + fence = rcu_dereference_protected(fobj->shared[i],
> > + dma_resv_held(resv));
> > + dma_fence_get(fence);
> > + r = dma_fence_add_callback(fence, &dcb->cb, dma_buf_poll_cb);
> > + if (!r)
> > + return true;
> > + dma_fence_put(fence);
> > + }
> > +
> > + return false;
> > +}
> > +
> > +static bool dma_buf_poll_excl(struct dma_resv *resv,
> > + struct dma_buf_poll_cb_t *dcb)
> > +{
> > + struct dma_fence *fence = dma_resv_get_excl(resv);
> > + int r;
> > +
> > + if (!fence)
> > + return false;
> > +
> > + dma_fence_get(fence);
> > + r = dma_fence_add_callback(fence, &dcb->cb, dma_buf_poll_cb);
> > + if (!r)
> > + return true;
> > + dma_fence_put(fence);
> > +
> > + return false;
> > }
> >
> > static __poll_t dma_buf_poll(struct file *file, poll_table *poll)
> > {
> > struct dma_buf *dmabuf;
> > struct dma_resv *resv;
> > - struct dma_resv_list *fobj;
> > - struct dma_fence *fence_excl;
> > + unsigned shared_count;
> > __poll_t events;
> >
Re: [Intel-gfx] [PATCH 3/3] drm/i915/uapi: Add query for L3 bank count
On Thu, Jul 15, 2021 at 03:16:08PM -0700, John Harrison wrote:
> On 6/16/2021 03:25, Daniel Vetter wrote:
> > On Thu, Jun 10, 2021 at 10:46 PM wrote:
> > > From: John Harrison
> > >
> > > Various UMDs need to know the L3 bank count. So add a query API for it.
> > Please link to both the igt test submission for this (there's not even
> > a Test-with: on the cover letter)
> Is there a wiki page that describes all such tags? That is not one I was
> aware of and I can't find anything in the Kernel patch submission wiki or
> DRM maintainers wiki that mentions it.
It's in the CI docs (linked from the main page too)
https://intel-gfx-ci.01.org/test-with.html
> > and the merge requests for the
> > various UMD which uses new uapi.
> Is there a particular tag to use for this?
I think often just a link to the merge request in the cover letter.
Sometimes people also put the link in the uapi patch itself in the commit
message. Which I think would be best.
-Daniel
>
> John.
>
> > Also as other mentioned, full uapi
> > kerneldoc is needed too. Please fill in any gaps in the existing docs
> > that relate to your addition directly (like we've e.g. done for the
> > extension chaining when adding lmem support).
> >
> > Thanks, Daniel
> >
> > > Signed-off-by: John Harrison
> > > ---
> > > drivers/gpu/drm/i915/gt/intel_gt.c | 15 +++
> > > drivers/gpu/drm/i915/gt/intel_gt.h | 1 +
> > > drivers/gpu/drm/i915/i915_query.c | 22 ++
> > > drivers/gpu/drm/i915/i915_reg.h| 1 +
> > > include/uapi/drm/i915_drm.h| 1 +
> > > 5 files changed, 40 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
> > > b/drivers/gpu/drm/i915/gt/intel_gt.c
> > > index 2161bf01ef8b..708bb3581d83 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> > > +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> > > @@ -704,3 +704,18 @@ void intel_gt_info_print(const struct intel_gt_info
> > > *info,
> > >
> > > intel_sseu_dump(&info->sseu, p);
> > > }
> > > +
> > > +int intel_gt_get_l3bank_count(struct intel_gt *gt)
> > > +{
> > > + struct drm_i915_private *i915 = gt->i915;
> > > + intel_wakeref_t wakeref;
> > > + u32 fuse3;
> > > +
> > > + if (GRAPHICS_VER(i915) < 12)
> > > + return -ENODEV;
> > > +
> > > + with_intel_runtime_pm(gt->uncore->rpm, wakeref)
> > > + fuse3 = intel_uncore_read(gt->uncore, GEN10_MIRROR_FUSE3);
> > > +
> > > + return hweight32(REG_FIELD_GET(GEN12_GT_L3_MODE_MASK, ~fuse3));
> > > +}
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
> > > b/drivers/gpu/drm/i915/gt/intel_gt.h
> > > index 7ec395cace69..46aa1cf4cf30 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_gt.h
> > > +++ b/drivers/gpu/drm/i915/gt/intel_gt.h
> > > @@ -77,6 +77,7 @@ 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);
> > > +int intel_gt_get_l3bank_count(struct intel_gt *gt);
> > >
> > > void intel_gt_watchdog_work(struct work_struct *work);
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_query.c
> > > b/drivers/gpu/drm/i915/i915_query.c
> > > index 96bd8fb3e895..0e92bb2d21b2 100644
> > > --- a/drivers/gpu/drm/i915/i915_query.c
> > > +++ b/drivers/gpu/drm/i915/i915_query.c
> > > @@ -10,6 +10,7 @@
> > > #include "i915_perf.h"
> > > #include "i915_query.h"
> > > #include
> > > +#include "gt/intel_gt.h"
> > >
> > > static int copy_query_item(void *query_hdr, size_t query_sz,
> > > u32 total_length,
> > > @@ -502,6 +503,26 @@ static int query_hwconfig_table(struct
> > > drm_i915_private *i915,
> > > return hwconfig->size;
> > > }
> > >
> > > +static int query_l3banks(struct drm_i915_private *i915,
> > > +struct drm_i915_query_item *query_item)
> > > +{
> > > + u32 banks;
> > > +
> > > + if (query_item->length == 0)
> > > + return sizeof(banks);
> > > +
> > > + if (query_item-&g
Re: [PATCH v3 0/2] allow simple{fb, drm} drivers to be used on non-x86 EFI platforms
On Mon, Jul 19, 2021 at 09:10:52AM +0200, Ard Biesheuvel wrote:
> On Mon, 19 Jul 2021 at 04:59, Dave Airlie wrote:
> >
> > On Thu, 15 Jul 2021 at 18:11, Thomas Zimmermann wrote:
> > >
> > > Hi
> > >
> > > Am 13.07.21 um 18:59 schrieb Javier Martinez Canillas:
> > > > On 6/25/21 3:09 PM, Javier Martinez Canillas wrote:
> > > >> The simplefb and simpledrm drivers match against a "simple-framebuffer"
> > > >> device, but for aarch64 this is only registered when using Device Trees
> > > >> and there's a node with a "simple-framebuffer" compatible string.
> > > >>
> > > >> There is no code to register a "simple-framebuffer" platform device
> > > >> when
> > > >> using EFI instead. In fact, the only platform device that's registered
> > > >> in
> > > >> this case is an "efi-framebuffer", which means that the efifb driver is
> > > >> the only driver supported to have an early console with EFI on aarch64.
> > > >>
> > > >> The x86 architecture platform has a Generic System Framebuffers (sysfb)
> > > >> support, that register a system frambuffer platform device. It either
> > > >> registers a "simple-framebuffer" for the simple{fb,drm} drivers or
> > > >> legacy
> > > >> VGA/EFI FB devices for the vgafb/efifb drivers.
> > > >>
> > > >> The sysfb is generic enough to be reused by other architectures and
> > > >> can be
> > > >> moved out of the arch/x86 directory to drivers/firmware, allowing the
> > > >> EFI
> > > >> logic used by non-x86 architectures to be folded into sysfb as well.
> > > >>
> > > >
> > > > Any more comments on this series? It would be nice for this to land so
> > > > the
> > > > simpledrm driver could be used on aarch64 EFI systems as well.
> > > >
> > > > The patches have already been acked by x86 and DRM folks.
> > >
> > > Time to get this merged, I'd say. People are asking for these patches
> > > already.
> >
> > Can we just merge via drm-misc and make sure the acks are present and
> > I'll deal with the fallout if any.
> >
>
> Fine with me. Could you stick it on a separate branch so I can double
> check whether there are any issues wrt the EFI tree?
It'll pop up in linux-next for integration testing or you can pick up the
patch here for test-merge if you want.
And since Dave has given a blanket cheque for handling fallout he'll deal
with the need for fixups too if there's any.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH v3 1/5] drm/print: fixup spelling in a comment
On Wed, Jul 14, 2021 at 11:51:34AM -0600, Jim Cromie wrote: > s/prink/printk/ - no functional changes > > Signed-off-by: Jim Cromie Applied to drm-misc-next, thanks for your patch. -Daniel > --- > include/drm/drm_print.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h > index 9b66be54dd16..15a089a87c22 100644 > --- a/include/drm/drm_print.h > +++ b/include/drm/drm_print.h > @@ -327,7 +327,7 @@ static inline bool drm_debug_enabled(enum > drm_debug_category category) > /* > * struct device based logging > * > - * Prefer drm_device based logging over device or prink based logging. > + * Prefer drm_device based logging over device or printk based logging. > */ > > __printf(3, 4) > -- > 2.31.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH v3 3/5] drm/print: RFC add choice to use dynamic debug in drm-debug
yet (or maybe the ones that drivers shouldn't used need more
__ prefixes to denote them as internal, dunno).
- I guess deprecation notice for drm_debug_enabled() and all that, so that
we have a consistent interface. Doing the conversion will probably
highlight the need for a bit more infrastructure and tooling, e.g. the
bigger dump functions (like edid hex dump, or also the various decode
helpers we have for dp, hdmi infoframes and all that) ideally have a
single dyn_debug label to enable all of them instead of line-by-line.
Tbh no idea how this should work, might need dyndbg work too.
- For the driver side of this we probably want a
Documentation/gpu/TODO.rst entry if it's not all easy to convert
directly.
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 7ff89690a976..e4524ccba040 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -57,6 +57,19 @@ config DRM_DEBUG_MM
>
> If in doubt, say "N".
>
> +config DRM_USE_DYNAMIC_DEBUG
> + bool "use dynamic debug to implement drm.debug"
> + default n
> + depends on DRM
> + depends on DYNAMIC_DEBUG || DYNAMIC_DEBUG_CORE
> + depends on JUMP_LABEL
> + help
> + The drm debug category facility does a lot of unlikely bit-field
> + tests at runtime; while cheap individually, the cost accumulates.
> + This option uses dynamic debug facility (if configured and
> + using jump_label) to avoid those runtime checks, patching
> + the kernel when those debugs are desired.
Can't we just make this an internal option that's enabled automatically
when dyndbg is around? Plus a comment somewhere that we really recommend
enabling dyndbg for drm. Or would this mean that in certain dyndbg
configurations we'd loose all the debug lines, which would suck?
Anyway there's a pile of details, but the big picture I really like.
Especially that we can make dyndbg seamlessly support drm.debug is really
nice.
Cheers, Daniel
> +
> config DRM_DEBUG_SELFTEST
> tristate "kselftests for DRM"
> depends on DRM
> diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
> index 111b932cf2a9..e2acdfc7088b 100644
> --- a/drivers/gpu/drm/drm_print.c
> +++ b/drivers/gpu/drm/drm_print.c
> @@ -52,8 +52,75 @@ MODULE_PARM_DESC(debug, "Enable debug output, where each
> bit enables a debug cat
> "\t\tBit 5 (0x20) will enable VBL messages (vblank code)\n"
> "\t\tBit 7 (0x80) will enable LEASE messages (leasing code)\n"
> "\t\tBit 8 (0x100) will enable DP messages (displayport code)");
> +
> +#ifndef CONFIG_DRM_USE_DYNAMIC_DEBUG
> module_param_named(debug, __drm_debug, int, 0600);
>
> +#else
> +static char *format_class_prefixes[] = {
> + cDRM_UT_CORE,
> + cDRM_UT_DRIVER,
> + cDRM_UT_KMS,
> + cDRM_UT_PRIME,
> + cDRM_UT_ATOMIC,
> + cDRM_UT_VBL,
> + cDRM_UT_STATE,
> + cDRM_UT_LEASE,
> + cDRM_UT_DP,
> + cDRM_UT_DRMRES
> +};
> +
> +#define OUR_QUERY_SIZE 64 /* > strlen "format '^%s' %cp" + longest prefix */
> +
> +static int param_set_dyndbg(const char *instr, const struct kernel_param *kp)
> +{
> + unsigned int val;
> + unsigned long changes, result;
> + int rc, chgct = 0, totct = 0, bitpos;
> + char query[OUR_QUERY_SIZE];
> +
> + rc = kstrtouint(instr, 0, &val);
> + if (rc) {
> + pr_err("%s: failed\n", __func__);
> + return -EINVAL;
> + }
> + result = val;
> + changes = result ^ __drm_debug;
> +
> + pr_debug("changes:0x%lx from result:0x%lx\n", changes, result);
> +
> + for_each_set_bit(bitpos, &changes, ARRAY_SIZE(format_class_prefixes)) {
> +
> + sprintf(query, "format '^%s' %cp",
> format_class_prefixes[bitpos],
> + test_bit(bitpos, &result) ? '+' : '-');
> +
> + chgct = dynamic_debug_exec_queries(query, "drm*");
> + if (chgct < 0) {
> + pr_err("%s: exec err:%d on: %s\n", __func__, chgct,
> query);
> + continue;
> + }
> + pr_debug("change ct:%d on %s\n", chgct, query);
> + totct += chgct;
> + }
> + pr_debug("total changes: %d\n", totct);
> + __drm_debug = result;
> + return 0;
> +}
> +
> +static int param_get_dyndbg(char *buffer, const struct kernel_param *kp)
> +{
> + pr_debug("debug-val:0x%x %u\n", __drm_debug, *((unsigned int
> *)kp->arg));
> + return scnprintf(bu
Re: [PATCH 1/4] drm: Introduce drm_modeset_lock_ctx_retry()
On Thu, Jul 15, 2021 at 09:49:51PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Quite a few places are hand rolling the modeset lock backoff dance.
> Let's suck that into a helper macro that is easier to use without
> forgetting some steps.
>
> The main downside is probably that the implementation of
> drm_with_modeset_lock_ctx() is a bit harder to read than a hand
> rolled version on account of being split across three functions,
> but the actual code using it ends up being much simpler.
>
> Cc: Sean Paul
> Cc: Daniel Vetter
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_modeset_lock.c | 44 ++
> include/drm/drm_modeset_lock.h | 20 ++
> 2 files changed, 64 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_modeset_lock.c
> b/drivers/gpu/drm/drm_modeset_lock.c
> index fcfe1a03c4a1..083df96632e8 100644
> --- a/drivers/gpu/drm/drm_modeset_lock.c
> +++ b/drivers/gpu/drm/drm_modeset_lock.c
> @@ -425,3 +425,47 @@ int drm_modeset_lock_all_ctx(struct drm_device *dev,
> return 0;
> }
> EXPORT_SYMBOL(drm_modeset_lock_all_ctx);
> +
> +void _drm_modeset_lock_begin(struct drm_modeset_acquire_ctx *ctx,
> + struct drm_atomic_state *state,
> + unsigned int flags, int *ret)
> +{
> + drm_modeset_acquire_init(ctx, flags);
> +
> + if (state)
> + state->acquire_ctx = ctx;
> +
> + *ret = -EDEADLK;
> +}
> +EXPORT_SYMBOL(_drm_modeset_lock_begin);
> +
> +bool _drm_modeset_lock_loop(int *ret)
> +{
> + if (*ret == -EDEADLK) {
> + *ret = 0;
> + return true;
> + }
> +
> + return false;
> +}
> +EXPORT_SYMBOL(_drm_modeset_lock_loop);
> +
> +void _drm_modeset_lock_end(struct drm_modeset_acquire_ctx *ctx,
> +struct drm_atomic_state *state,
> +int *ret)
> +{
> + if (*ret == -EDEADLK) {
> + if (state)
> + drm_atomic_state_clear(state);
> +
> + *ret = drm_modeset_backoff(ctx);
> + if (*ret == 0) {
> + *ret = -EDEADLK;
> + return;
> + }
> + }
> +
> + drm_modeset_drop_locks(ctx);
> + drm_modeset_acquire_fini(ctx);
> +}
> +EXPORT_SYMBOL(_drm_modeset_lock_end);
> diff --git a/include/drm/drm_modeset_lock.h b/include/drm/drm_modeset_lock.h
> index aafd07388eb7..5eaad2533de5 100644
> --- a/include/drm/drm_modeset_lock.h
> +++ b/include/drm/drm_modeset_lock.h
> @@ -26,6 +26,7 @@
>
> #include
>
> +struct drm_atomic_state;
> struct drm_modeset_lock;
>
> /**
> @@ -203,4 +204,23 @@ modeset_lock_fail:
> \
> if (!drm_drv_uses_atomic_modeset(dev)) \
> mutex_unlock(&dev->mode_config.mutex);
>
> +void _drm_modeset_lock_begin(struct drm_modeset_acquire_ctx *ctx,
> + struct drm_atomic_state *state,
> + unsigned int flags,
> + int *ret);
> +bool _drm_modeset_lock_loop(int *ret);
> +void _drm_modeset_lock_end(struct drm_modeset_acquire_ctx *ctx,
> +struct drm_atomic_state *state,
> +int *ret);
> +
> +/*
> + * Note that one must always use "continue" rather than
> + * "break" or "return" to handle errors within the
> + * drm_modeset_lock_ctx_retry() block.
I'm not sold on loop macros with these kind of restrictions, C just isn't
a great language for these. That's why e.g. drm_connector_iter doesn't
give you a macro, but only the begin/next/end function calls explicitly.
Yes the macro we have is also not nice, but at least it's a screaming
macro since it's all uppercase, so options are all a bit sucky. Which
leads me to think we have a bit a https://xkcd.com/927/ situation going
on.
I think minimally we should have one way to do this.
-Daniel
> + */
> +#define drm_modeset_lock_ctx_retry(ctx, state, flags, ret) \
> + for (_drm_modeset_lock_begin((ctx), (state), (flags), &(ret)); \
> + _drm_modeset_lock_loop(&(ret)); \
> + _drm_modeset_lock_end((ctx), (state), &(ret)))
> +
> #endif /* DRM_MODESET_LOCK_H_ */
> --
> 2.31.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH 1/7] vgaarb: remove VGA_DEFAULT_DEVICE
On Fri, Jul 16, 2021 at 09:14:02AM +0200, Christian König wrote: > Am 16.07.21 um 08:16 schrieb Christoph Hellwig: > > The define is entirely unused. > > > > Signed-off-by: Christoph Hellwig > > I'm not an expert for this particular code, but at least of hand everything > you do here makes totally sense. > > Whole series is Acked-by: Christian König Care to also push this into drm-misc-next since you looked already? -Daniel > > Regards, > Christian. > > > --- > > include/linux/vgaarb.h | 6 -- > > 1 file changed, 6 deletions(-) > > > > diff --git a/include/linux/vgaarb.h b/include/linux/vgaarb.h > > index dc6ddce92066..26ec8a057d2a 100644 > > --- a/include/linux/vgaarb.h > > +++ b/include/linux/vgaarb.h > > @@ -42,12 +42,6 @@ > > #define VGA_RSRC_NORMAL_IO 0x04 > > #define VGA_RSRC_NORMAL_MEM0x08 > > -/* Passing that instead of a pci_dev to use the system "default" > > - * device, that is the one used by vgacon. Archs will probably > > - * have to provide their own vga_default_device(); > > - */ > > -#define VGA_DEFAULT_DEVICE (NULL) > > - > > struct pci_dev; > > /* For use by clients */ > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
